Re: About F19 Firewall
Hello, - Original Message - > From: Mateusz Marzantowicz > Subject: Re: About F19 Firewall > > Maybe, true but I doubt that simpler set of rules, that never get > audited, written by inexperienced users are more secure than "complex" > rules in FirewallD which at last had chance to be checked. It's not that simpler rules are more secure, but they come handy if one is to audit them or modify them for his/her set-up. Such modifications could be merged back as user contributions, which only helps to strengthen the tool or set of rules. The thing with complexity is, it keeps, even the able people, away from fiddling with things which I feel sort of beats the whole purpose. As in, if amongst all the available zones, a user is always going to use just one everywhere, it beats the purpose of other zones and the promise of security too, no? Worse is, people would just turn it(Firewalld) off because they can not understand it or make it work for them. > BTW, there is not that much magic in rules applied by FirewallD and > other firewall solutions for Linux have similar level of rule complexity > (ufw, shorewall, etc.) True. We can not avoid complexity. There are complex set-ups & networks, which need complex rules. Firewalld as a tool would be right having features to enable a user who wish to create such complexity and define rules for the same. But providing it by default for individual Fedora users, who don't need it, doesn't feel right. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [ACTION REQUIRED] Blocking more retired packages in F20+
On 09/17/2013 06:15 PM, Till Maas wrote: Hi, the package 'xorriso' is retired, but not yet blocked, because 'cdw' depends on it. Therefore either 'xorriso' needs to be unretired with a review or 'cdw' needs to be retired or drop the dependency. I just blocked the following packages in koji for F20+, because they were retired some time ago, but not yet blocked: abby aimage amide autobuild-applet autotrust bluemodem cricscore-applet darkice gnome-exe-thumbnailer gnome-shell-extension-mediaplayers gnome-shell-extension-noim gnome-shell-extension-presentation-mode gnome-shell-extension-righthotcorner gnome-specimen gnome-xcf-thumbnailer ifplugd metagoofil osutil php-laconica python-certifi ruby-fam ruby-racc trustyrc They might also lack a dead.package, but I will write a separate mail about this. I noticed there is the package 'libircclient-qt' which was only retired in Rawhide but not Branched (F20). Is this really intentional? Since F20 is not yet released, it is still a good idea to retire it, because it seems to be renamed. Done, thanks. Regards Till Regards, Jan Kaluza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphan Packages: plone, zope
I am no longer able to dedicate the time that the plone and zope packages need to be able to run on Fedora. I am orphaning these packages as of today and hope another community member is able to pick them up. -- Jonathan Steffan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [ACTION REQUIRED] Blocking more retired packages in F20+
On Tue, Sep 17, 2013 at 11:06:42PM +0200, Robert Scheck wrote: > please orphan xorriso immediately (if not already done so). The variant of > xorriso that libisoburn ships does not contain any bundled libraries, while > the stand-alone package xorriso bundles a bunch of libraries. It is now blocked and dead.packaged. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Provenpackagers can help (was: Re: OCaml 4.01.0 coming to Fedora Rawhide this weekend)
On Tue, Sep 17, 2013 at 10:23:16AM -0600, Jerry James wrote:
> On Sat, Sep 14, 2013 at 7:04 AM, Richard W.M. Jones wrote:
> > For provenpackagers who want to pitch in with OCaml builds, here's a
> > summary of what I'm doing:
>
> While looking through the packages still needing a rebuild, I have
> noticed all 3 of the following:
> - ExclusiveArch: %{ocaml_arches}
> - ExcludeArch: sparc64 s390 s390x
> - No ExcludeArch or ExclusiveArch at all
>
> Only the first is correct, right? We ought to try to be consistent about
> this.
It's a good question. I've not been touching any of these lines.
%{ocaml_arches} is defined as part of RPM (/etc/rpm/macros.ocaml-srpm).
But it's not accurate and I don't know who put it in RPM.
There's no reason why OCaml shouldn't be compiled on any architecture
that has a C compiler. On a tiny minority you'd only be able to use
the slower bytecode implementation, but the only arches I'm aware this
is the case are s390{,x} & aarch64. On all the others there is some
native code compiler, even if it's not upstream (like ppc64).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [ACTION REQUIRED] Blocking more retired packages in F20+
On Tue, Sep 17, 2013 at 03:52:51PM -0400, Paul Wouters wrote: > On Tue, 17 Sep 2013, Till Maas wrote: > > >I just blocked the following packages in koji for F20+, because they > >were retired some time ago, but not yet blocked: > > >autotrust > > >They might also lack a dead.package, but I will write a separate mail > >about this. > > Indeed. fixed. (autotools was merged into unbound upstream and > abandoned) > > I used fedpkg retire, but got a bunch of: > > pwouters is not allowed to change ownership of this package fedpkg retire tries to retire the package for which it first needs to be orphaned. This autotrust was already retired in packagedb, this failed. I adjusted the dead.package file to not only say "f17", it seems something went wrong there. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [ACTION REQUIRED] Blocking more retired packages in F20+
Richard Shaw wrote: > I'll look at fixing up xorriso... Upstream seems to be active. xorriso [1] is deprecated because now it's a subpackage of libisoburn [2]. [1] http://koji.fedoraproject.org/koji/packageinfo?packageID=8737 [2] http://koji.fedoraproject.org/koji/packageinfo?packageID=12680 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [ACTION REQUIRED] Blocking more retired packages in F20+
Hello guys, On Tue, 17 Sep 2013, Xose Vazquez Perez wrote: > xorriso [1] is deprecated because now it's a subpackage of libisoburn [2]. please orphan xorriso immediately (if not already done so). The variant of xorriso that libisoburn ships does not contain any bundled libraries, while the stand-alone package xorriso bundles a bunch of libraries. Greetings, Robert pgp0C7kLIIqzP.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 20-Alpha RC3 AMIS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi all, RC2 images have been uploaded to EC2 and are available at ami-0d256e64 : us-east-1 image for i386 ami-3f256e56 : us-east-1 image for x86_64 additionally if your looking to the AMI's they have been added to files in the release tree http://dl.fedoraproject.org/pub/alt/stage/20-Alpha-RC3/Images/i386/Fedora-Images-i386-20-Alpha-AMI http://dl.fedoraproject.org/pub/alt/stage/20-Alpha-RC3/Images/x86_64/Fedora-Images-x86_64-20-Alpha-AMI when we get to final alpha and the images are uploaded to all regions they will all be listed and the file will be signed in the final tree Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (GNU/Linux) iEYEARECAAYFAlI4uBgACgkQkSxm47BaWfeFzQCeKvQmQXPf2lgdeP8RULWh4qcG NoMAn15VMlo4mIYJaDXu7Oa2NjrkIVwi =nBtg -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [ACTION REQUIRED] Blocking more retired packages in F20+
I'll look at fixing up xorriso... Upstream seems to be active. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: how to build a scratch build of an older version of my package ?
On Tue, Sep 17, 2013 at 2:30 PM, David Timms wrote: > In trying to track down when a bug began showing up, I'd like to build > an earlier version of my package eg from 9 months ago (hence earlier > upstream release and different spec/patches). How can that be achieved > on the builder ? > > Does the build system keep the build logs of old packages, ie that shows > what build requires-version was installed, and which gcc compiler > version was used ? > > I'm not sure if you can build from a previous commit in git with fedpkg but you can pretty much build whatever you want with a source RPM so if could get a hold of the older source RPM (perhaps from an older Fedora release) then you can submit it to koji. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [ACTION REQUIRED] Blocking more retired packages in F20+
On Tue, 17 Sep 2013, Till Maas wrote: I just blocked the following packages in koji for F20+, because they were retired some time ago, but not yet blocked: autotrust They might also lack a dead.package, but I will write a separate mail about this. Indeed. fixed. (autotools was merged into unbound upstream and abandoned) I used fedpkg retire, but got a bunch of: pwouters is not allowed to change ownership of this package Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
how to build a scratch build of an older version of my package ?
In trying to track down when a bug began showing up, I'd like to build an earlier version of my package eg from 9 months ago (hence earlier upstream release and different spec/patches). How can that be achieved on the builder ? Does the build system keep the build logs of old packages, ie that shows what build requires-version was installed, and which gcc compiler version was used ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] 2013-09-18 @ 16:00 UTC - F20 Alpha Blocker Bug Review #6
# F20 Alpha Blocker Review meeting #6 # Date: 2013-09-18 # Time: 16:00 UTC (12:00 EDT, 09:00 PDT) # Location: #fedora-blocker-review on irc.freenode.net Go/No-Go #2 will be on this Thursday, so it's time for what will hopefully be the last last blocker review meeting for F20 alpha. We'll be running through the final blockers and freeze exception bugs. The current list is available at: http://qa.fedoraproject.org/blockerbugs/current We'll be reviewing the bugs to determine ... 1. Whether they meet the alpha release criteria [1] and should stay on the list 2. Whether they are getting the attention they need [1] http://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria For guidance on Blocker and FreezeException bugs, please refer to - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process For the blocker review meeting protocol, see -https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting signature.asc Description: PGP signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1009094] RFE: Upgrade F18's perl-Try-Tiny to >= 0.12
https://bugzilla.redhat.com/show_bug.cgi?id=1009094 Ralf Corsepius changed: What|Removed |Added Blocks||1008300 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=yEPrxCAGHn&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1009094] New: RFE: Upgrade F18's perl-Try-Tiny to >= 0.12
https://bugzilla.redhat.com/show_bug.cgi?id=1009094 Bug ID: 1009094 Summary: RFE: Upgrade F18's perl-Try-Tiny to >= 0.12 Product: Fedora Version: 18 Component: perl-Try-Tiny Assignee: p...@city-fan.org Reporter: rc040...@freenet.de QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, p...@city-fan.org, perl-de...@lists.fedoraproject.org Description of problem: perl-Apache-LogFormat-Compiler-0.13 requires Try::Tiny >= 0.12 F18 currently ships perl-Try-Tiny-0.11, F19 currently ships perl-Try-Tiny-0.12. I'd therefore suggest to upgrade F18's perl-Try-Tiny to the status of F19. Additional info: perl-Apache-LogFormat-Compiler is a new dependency of perl-Plack, which can not be bug-fixed rsp. upgraded without perl-Try-Tiny >= 0.12. Shouldn't you have sufficient time, I'd simply git merge origin/f19 into f18 and rebuild. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=4BqcfxBjl8&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1009094] RFE: Upgrade F18's perl-Try-Tiny to >= 0.12
https://bugzilla.redhat.com/show_bug.cgi?id=1009094 --- Comment #3 from Paul Howarth --- There's a buildroot override in place for this too. koji wait-repo f18-build --build=perl-Try-Tiny-0.12-1.fc18 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=AFokdjKy6V&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Try-Tiny] Created tag perl-Try-Tiny-0.12-1.fc18
The lightweight tag 'perl-Try-Tiny-0.12-1.fc18' was created pointing to: 5cc9e37... Update to 0.12 (documentation fixes) -- 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
[Bug 1009094] RFE: Upgrade F18's perl-Try-Tiny to >= 0.12
https://bugzilla.redhat.com/show_bug.cgi?id=1009094 --- Comment #2 from Fedora Update System --- perl-Try-Tiny-0.12-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/perl-Try-Tiny-0.12-1.fc18 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=C0Zg2kC753&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Intent to retire python-jinja
Hi, I'd like to retire the python-jinja package, containing the Jinja1 template engine, which has been superseded by Jinja2 for a very long time. Jinja2 is packaged as python-jinja2 in Fedora. However, there's one package left that depends on it: olpc-library. Can anyone comment on the status of that package, and if it would be possible to switch over to Jinja2? Regards, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File Apache-LogFormat-Compiler-0.13.tar.gz uploaded to lookaside cache by corsepiu
A file has been added to the lookaside cache for perl-Apache-LogFormat-Compiler: fd04ee3f4c2164b7f7909d85f11e467a Apache-LogFormat-Compiler-0.13.tar.gz -- 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: Provenpackagers can help (was: Re: OCaml 4.01.0 coming to Fedora Rawhide this weekend)
On Sat, Sep 14, 2013 at 7:04 AM, Richard W.M. Jones wrote:
> For provenpackagers who want to pitch in with OCaml builds, here's a
> summary of what I'm doing:
While looking through the packages still needing a rebuild, I have
noticed all 3 of the following:
- ExclusiveArch: %{ocaml_arches}
- ExcludeArch: sparc64 s390 s390x
- No ExcludeArch or ExclusiveArch at all
Only the first is correct, right? We ought to try to be consistent about this.
--
Jerry James
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Retiring libeio
On Mon, Sep 9, 2013 at 6:49 AM, Paul Howarth wrote: > I'd be quite happy if someone would take perl-IO-AIO off my hands. My only > interest in it is as an (optional) backend and test dependency of > perl-AnyEvent, which I co-maintain - I picked it up when a previous > maintainer orphaned it. > > If someone is keen to look after the bundling issue, I'll be happy to hand > over the package. Otherwise, it looks like a lot of hassle and I'll probably > end up orphaning it and letting nature take its course. I took a look at it, and the perl module does an #include "libeio/eio.c" (not .h), so there's no way to link it to libeio normally without a lot of work. :-( Probably best to let it die if nobody has any interest in it. -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Retiring libeio
What a mess! I sure do seem to be attracted to bundled library issues, like insects are attracted to shiny lights. :-( On Sun, Sep 8, 2013 at 12:48 AM, Michael Schwendt wrote: > On Sat, 7 Sep 2013 18:03:48 -0700, T.C. Hollingsworth wrote: > >> I adopted libeio back when Node.js still bundled it to aid in the unbundling >> effort, but upstream "fixed" the bundling problem here by no longer using >> libeio for anything. > > That explains a bit more! > > libeio is bundled within perl-IO-AIO at Fedora > > http://search.cpan.org/~mlehmann/IO-AIO-4.18/AIO.pm > > and is built as a private AIO.so lib. I might add that this Perl module also shares the same author as libeio itself. > I've tried to find out why there haven't been any libeio releases to download, > although it's at version 4.18 already. The home page says it's Beta. The cvs > snapshot contains doc files that refer to libev (that one is at 4.15), which > is a separate package (also at Fedora). The source also bundles ecb.h, which > refers to libecb from the same author. That's "libecb" at Fedora. Upstream has never released tarballs that I'm aware of. The libeio package generates tarballs from release tags in CVS. There actually seems to be a 4.19 tag in CVS now, though IO::AIO is still on 4.18. Sorry I never noticed the libecb bundling. I could push a patch to fix it right now, but I have absolutely no way of testing it since nothing uses libeio and it doesn't have a test suite. :-( -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Wednesday's FESCo Meeting (2013-09-18)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '-MM-DD HH:MM UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1173 provenpackager request .fesco 1173 https://fedorahosted.org/fesco/ticket/1173 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[ACTION REQUIRED] Blocking more retired packages in F20+
Hi, the package 'xorriso' is retired, but not yet blocked, because 'cdw' depends on it. Therefore either 'xorriso' needs to be unretired with a review or 'cdw' needs to be retired or drop the dependency. I just blocked the following packages in koji for F20+, because they were retired some time ago, but not yet blocked: abby aimage amide autobuild-applet autotrust bluemodem cricscore-applet darkice gnome-exe-thumbnailer gnome-shell-extension-mediaplayers gnome-shell-extension-noim gnome-shell-extension-presentation-mode gnome-shell-extension-righthotcorner gnome-specimen gnome-xcf-thumbnailer ifplugd metagoofil osutil php-laconica python-certifi ruby-fam ruby-racc trustyrc They might also lack a dead.package, but I will write a separate mail about this. I noticed there is the package 'libircclient-qt' which was only retired in Rawhide but not Branched (F20). Is this really intentional? Since F20 is not yet released, it is still a good idea to retire it, because it seems to be renamed. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: abrt server report: 20130917
On Tue, Sep 17, 2013 at 03:57:55PM +0200, Michal Toman wrote: > In last two weeks these components were crashing the most: > > 1. kernel seen 85925 times (52% of all reports) > https://retrace.fedoraproject.org/faf/problems/1174076/ > https://retrace.fedoraproject.org/faf/problems/1209703/ I've noticed a problem in your code that attributes blame to the 'function' field. In that second trace: Call Trace: [] ? print_hardware_dmi_name+0x2b/0x30 [] warn_slowpath_common+0x63/0x80 [] ? carl9170_op_tx+0x733/0x810 [carl9170] [] ? carl9170_op_tx+0x733/0x810 [carl9170] [] warn_slowpath_null+0x22/0x30 [] carl9170_op_tx+0x733/0x810 [carl9170] the '?' fields are junk on the stack, and not actually the functions we're in. Instead of blaming print_hardware_dmi_name, this trace should be attributed to carl9170_op_tx. Everything else above that is either noise on the stack from previous calls, or parts of the "dump trace" logic. I'd ignore the ? functions completely for this purpose. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: About F19 Firewall
On 17.09.2013 15:02, Kevin Kofler wrote: > P J P wrote: >> Hmmn, it should have been a package for user to install at will, rather >> than a replacement of an understandable firewall. > > +1, the fact that this is opt-out rather than opt-in (even for upgrades from > Fedora ≤ 17 – I had to go out of my way to disable that "feature" > immediately after upgrading to F18) really sucks, also considering that it > is written in Python. (The core system should be free of interpreted > languages. Lennart is going out of his way to replace shell stuff by fast > native code in systemd, why sabotage that effort by shoving a Python > firewall down our throats?) > It's written in Python and so what? Interpreted languages like Perl and Bash are widely used in Linux world to implement many tools. I don't buy argumentation that if something is not implemented in C it sucks. Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 20-Alpha RC2 AMIS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 17 Sep 2013 05:06:00 -0400 (EDT) Jaroslav Reznik wrote: > - Original Message - > > On Thu, Sep 12, 2013 at 04:46:17PM -0500, Dennis Gilmore wrote: > > > ami-1bb5fc72 : us-east-1 image for i386 > > > > This still doesn't boot. (We're working on it.) > > Matt, > any news on this? I used separate kickstarts for RC3 the i386 image has kernel-PAE installed which should fix the issue Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (GNU/Linux) iEYEARECAAYFAlI4brUACgkQkSxm47BaWfdrEACgq8W2yKyYV74hn5AsuhRqEXbf l9YAn3gwi7BKwwK6sqCMmg226xQi9YHO =KI14 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Test-Fatal] Created tag perl-Test-Fatal-0.012-1.fc20
The lightweight tag 'perl-Test-Fatal-0.012-1.fc20' was created pointing to: d8b724a... Update to 0.012 -- 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
[perl-Test-Fatal] Created tag perl-Test-Fatal-0.012-1.fc21
The lightweight tag 'perl-Test-Fatal-0.012-1.fc21' was created pointing to: d8b724a... Update to 0.012 -- 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
abrt server report: 20130917
In last two weeks these components were crashing the most: 1. kernel seen 85925 times (52% of all reports) https://retrace.fedoraproject.org/faf/problems/1174076/ https://retrace.fedoraproject.org/faf/problems/1209703/ 2. xulrunner seen 10191 times (6% of all reports) https://retrace.fedoraproject.org/faf/problems/727281/ https://retrace.fedoraproject.org/faf/problems/757169/ 3. glib-networking seen 8701 times (5% of all reports) https://retrace.fedoraproject.org/faf/problems/1127716/ RHBZ#998232 https://retrace.fedoraproject.org/faf/problems/1154608/ 4. tracker seen 5771 times (4% of all reports) https://retrace.fedoraproject.org/faf/problems/869238/ RHBZ#966764 https://retrace.fedoraproject.org/faf/problems/1250621/ RHBZ#957533 5. gnome-shell seen 4673 times (3% of all reports) https://retrace.fedoraproject.org/faf/problems/864616/ RHBZ#953325, RHBZ#1002524 https://retrace.fedoraproject.org/faf/problems/20295/ RHBZ#827158, RHBZ#905168 Hot problems: ID Components Count --- 1174076kernel 26633 1127716glib-networking 8243 1209703kernel 6318 727281 xulrunner 4872 138934 meld3927 57483 blueman 2798 1059468kernel 2748 1178557kernel 2369 1173865kernel 1686 1146230kernel 1580 URL: https://retrace.fedoraproject.org/faf/problems/hot/ Long-term problems: ID Components Count --- 577402 libgsf 77299 1174076kernel 70639 727281 xulrunner 54614 57483 blueman35539 757169 xulrunner 31407 20295 gnome-shell29302 898437 kernel 24020 244577 xulrunner 21868 365559 setroubleshoot 18585 138934 meld 17977 URL: https://retrace.fedoraproject.org/faf/problems/longterm/ Most destabilized components: Component Jump Graph -- kernel 2398 ▁▄▄▅▃█▇ glib-networking 2004 ▁▁▂█▄▄▆ tracker 464 ▁▁▂▄▂█▅ xulrunner465 ▁▁█▄▄▅▄ PackageKit 240 ▁▁▃▇▇█▇ Most stabilized components: Component Jump Graph -- meld 67 ▄█▆▅▁▁▆ pulseaudio -26 ▄█▁▁▂▂▃ policycoreutils -4 ▁█▁ libgsf23 ▂█▄▄▁▂▄ yum -6 ▃█▃▃▃▁▁ Server URL: https://retrace.fedoraproject.org/faf/ Report a bug: https://github.com/abrt/faf/issues/new Server sources: https://github.com/abrt/faf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Suggestion: bmap files and bmaptool
On Sun, 2013-08-18 at 16:43 +0100, Pádraig Brady wrote: > You definitely need the fsync before doing the fiemap. > We saw this on certain file systems including ext4 when adding > fiemap support (efficient reading of holes) to cp. > This is a bug in the fiemap interface IMHO in that it returns > fairly useless data unless FIEMAP_FLAG_SYNC is specified. > For a general utility like cp, we couldn't sync each file before copying > (even only large files), so we restrict fiemap usage to files that > have a different disk usage than apparent size and so probably contain holes. FYI, I've just made sure I use the FIEMAP_FLAG_SYNC is used in the project. -- Best Regards, Artem Bityutskiy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Suggestion: bmap files and bmaptool
On Wed, 2013-08-14 at 12:24 +0200, Björn Persson wrote: > Artem Bityutskiy wrote: > >On Wed, 2013-08-14 at 11:44 +0200, Till Maas wrote: > >> On Wed, Aug 14, 2013 at 12:21:23PM +0300, Artem Bityutskiy wrote: > >> > On Wed, 2013-08-14 at 10:37 +0200, Till Maas wrote: > >> > > On Wed, Aug 14, 2013 at 09:31:22AM +0300, Artem Bityutskiy wrote: > >> > > > >> > > > Other things like reading from remote sites, progress > >> > > > indicator, protecting your mounted disks, uncompressing > >> > > > on-the-fly, checking sha1 of the data ond of the bmap file > >> > > > itself - are goodies, although important ones. > >> > > > >> > > Why sha1? If the check is there for security reasons, please use > >> > > at least sha256. > >> > > >> > Should not be difficult to implement if there is demand. > >> > >> SHA-256 is used to create the signatures of other distributed files: > >> https://fedoraproject.org/static/checksums/Fedora-19-i386-CHECKSUM > >> > >> Therefore if bmap is used it should also use at least SHA 256. It is > >> recommended against using SHA-1 for more than 7 years now: > >> http://csrc.nist.gov/groups/ST/hash/policy_2006.html > > > >Sure, good point, thank you, I'll implement sha-256 support. > > Speaking of security, how is the integrity of the bmap file itself > verified? A checksum is of no use if you don't know who generated the > checksum. Fedora's checksum files are OpenPGP signed, as you can see in > the one that Till linked to. I don't see a cryptographic signature in > your example file. Are there detached signatures for the bmap files? > And does Bmaptool verify the signatures? I've implemented gpg signature verification. Now the bmap file can be gpg-signed and in this case bmaptool will verify the signature. Both Fedora-like "clearsign" gpg signatures and detached signatures are supported. -- Best Regards, Artem Bityutskiy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Suggestion: bmap files and bmaptool
On Wed, 2013-08-14 at 11:44 +0200, Till Maas wrote: > On Wed, Aug 14, 2013 at 12:21:23PM +0300, Artem Bityutskiy wrote: > > On Wed, 2013-08-14 at 10:37 +0200, Till Maas wrote: > > > On Wed, Aug 14, 2013 at 09:31:22AM +0300, Artem Bityutskiy wrote: > > > > > > > Other things like reading from remote sites, progress indicator, > > > > protecting your mounted disks, uncompressing on-the-fly, checking sha1 > > > > of the data ond of the bmap file itself - are goodies, although > > > > important ones. > > > > > > Why sha1? If the check is there for security reasons, please use at > > > least sha256. > > > > Should not be difficult to implement if there is demand. > > SHA-256 is used to create the signatures of other distributed files: > https://fedoraproject.org/static/checksums/Fedora-19-i386-CHECKSUM FYI, I've implemented SHA-256 support and it will be the default for bmaptool soon. I also made sure other hash functions can be used as well (e.g., SHA-512). -- Best Regards, Artem Bityutskiy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Reminder on how to EOL a package
Dennis Gilmore writes: > [...] Also please note that you are not to Retire packages for > stable Fedora's [...] Can this be mechanically enforced? - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Reminder on how to EOL a package
Dennis Gilmore wrote: > Also please note that you are not to Retire packages for stable > Fedora's we have no way to remove them and If you retire it they will > be in a weird state where the package will be in the repos and > available to install but koji will say its blocked. It will create > confusion for both users and fellow developers. So DO NOT DO IT. Then why does the tool allow doing that in the first place? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: About F19 Firewall
P J P wrote: > Hmmn, it should have been a package for user to install at will, rather > than a replacement of an understandable firewall. +1, the fact that this is opt-out rather than opt-in (even for upgrades from Fedora ≤ 17 – I had to go out of my way to disable that "feature" immediately after upgrading to F18) really sucks, also considering that it is written in Python. (The core system should be free of interpreted languages. Lennart is going out of his way to replace shell stuff by fast native code in systemd, why sabotage that effort by shoving a Python firewall down our throats?) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: About F19 Firewall
On 09/15/2013 08:52 PM, P J P wrote: Why are there so many chains? Most are empty. Those which have rules, jump from one chain to another and that jumps to yet another. https://bugzilla.redhat.com/show_bug.cgi?id=907375#c2 Multicast DNS is allowed in the internal network(chain IN_internal_allow). Who uses it? http://fedoraproject.org/wiki/Features/AvahiDefaultOnDesktop Then I looked at the firewall configuration GUI tool. That's even more baffling. It is, yes. It had started as quite simple tool but bloated very fast because all the features we added recently. -- Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: abrt Bugzilla summary
> > ABRT provides per component customization. > > > > https://github.com/abrt/abrt/wiki/FAQ#component-specific-bugzilla-bug-formatting > > Excellent. Given that almost no packages are shipping these, is there > any guideline or guidance how to do so? Just add them to our packages? > Anything we need to require? Just add the files to your package as described on the FAQ page. According to the packaging guidelines you have to add "Requires: libreport-filesystem" line because /etc/libreport/plugins/ directory is owned by that package. > > Might be nice to work with FPC/packaging list and come up with a clear > guideline for these. > > kevin Good idea. I will take care of it. Thanks! Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: abrt Bugzilla summary
On 09/16/2013 11:47 PM, Kevin Fenzi wrote: On Mon, 16 Sep 2013 11:08:02 -0400 (EDT) Jakub Filak wrote: I wonder if someday it would make sense to customize this per user? Possibly too much complexity... kevin ABRT provides per component customization. https://github.com/abrt/abrt/wiki/FAQ#component-specific-bugzilla-bug-formatting Excellent. Given that almost no packages are shipping these, is there any guideline or guidance how to do so? Just add them to our packages? Anything we need to require? Might be nice to work with FPC/packaging list and come up with a clear guideline for these. - your package needs to require libreport-filesystem --Jirka kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: About F19 Firewall
On 17.09.2013 12:31, Nicolas Mailhot wrote: > > Le Mar 17 septembre 2013 11:33, Björn Persson a écrit : >> Mateusz Marzantowicz wrote: >>> Wireless networks have unique "names" and are represented as different >>> connections on NetworkManager (network connection != interface). For >>> network named "MyHomeNet" one can associate Home zone in NetworkManager >>> and for network "CoffeShowHotSpot" one assigns Public zone. You don't >>> have to change anything once it's assigned. >> >> So when some innocent-looking guy is sitting in the café with a >> smartphone posing as an access point with an SSID of "MyHomeNet", will >> your Fedora laptop connect to it, switch to the Home zone, and assume >> that everybody on that network is friendly? > > Does not matter if the firewall rules become complex enough no one will > ever audit them and they become the malware-ridden black-boxes common in > windows environments. > > (though systemd and gnome3 are taking the 'pile of overengineered rules no > one checks' route fast) > Maybe, true but I doubt that simpler set of rules, that never get audited, written by inexperienced users are more secure than "complex" rules in FirewallD which at last had chance to be checked. BTW, there is not that much magic in rules applied by FirewallD and other firewall solutions for Linux have similar level of rule complexity (ufw, shorewall, etc.) Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: About F19 Firewall
Le Mar 17 septembre 2013 11:33, Björn Persson a écrit : > Mateusz Marzantowicz wrote: >>Wireless networks have unique "names" and are represented as different >>connections on NetworkManager (network connection != interface). For >>network named "MyHomeNet" one can associate Home zone in NetworkManager >>and for network "CoffeShowHotSpot" one assigns Public zone. You don't >>have to change anything once it's assigned. > > So when some innocent-looking guy is sitting in the café with a > smartphone posing as an access point with an SSID of "MyHomeNet", will > your Fedora laptop connect to it, switch to the Home zone, and assume > that everybody on that network is friendly? Does not matter if the firewall rules become complex enough no one will ever audit them and they become the malware-ridden black-boxes common in windows environments. (though systemd and gnome3 are taking the 'pile of overengineered rules no one checks' route fast) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 20 Alpha Go/No-Go Meeting #2, Thursday, September 19 @ 17:00 UTC
Join us on irc.freenode.net in #fedora-meeting-2 for this important meeting, wherein we shall determine the readiness of the Fedora 20 Alpha. This is the second attempt to release Fedora 20 Alpha. Thursday, September 19, 2013 17:00 UTC (1 PM EDT, 10 AM PDT, 19:00 CEST) "Before each public release Development, QA and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the Go/No-Go Meeting." "Verifying that the Release criteria are met is the responsibility of the QA Team." For more details about this meeting see: https://fedoraproject.org/wiki/Go_No_Go_Meeting In the meantime, keep an eye on the Fedora 20 Alpha Blocker list: http://qa.fedoraproject.org/blockerbugs/milestone/20/alpha/buglist Jaroslav ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: About F19 Firewall
On 09/17/2013 11:33 AM, Björn Persson wrote: Mateusz Marzantowicz wrote: Wireless networks have unique "names" and are represented as different connections on NetworkManager (network connection != interface). For network named "MyHomeNet" one can associate Home zone in NetworkManager and for network "CoffeShowHotSpot" one assigns Public zone. You don't have to change anything once it's assigned. So when some innocent-looking guy is sitting in the café with a smartphone posing as an access point with an SSID of "MyHomeNet", will your Fedora laptop connect to it, switch to the Home zone, and assume that everybody on that network is friendly? What about BSSID and SSID combo? (Sad reality is that it could be changed too) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: abrt Bugzilla summary
On Mon, Sep 16, 2013 at 06:11:24PM +0200, Till Maas wrote:
> On Mon, Sep 16, 2013 at 01:26:55PM +0200, Karel Zak wrote:
> > On Mon, Sep 16, 2013 at 12:34:50PM +0200, Till Maas wrote:
> > > On Mon, Sep 16, 2013 at 10:36:41AM +0200, Karel Zak wrote:
> > >
> > > > For example if you use mutt then all you need is to add
> > > >
> > > > unignore X-Bugzilla-Product X-Bugzilla-Component
> > > >
> > > > to your .muttrc.
> > > >
> > > > It's pretty common that we don't have component name in BZ summary...
> > >
> > > But this does not show the component in the "index" view, or can this be
> > > changed as well? I always add the component to the summary for Bugs I
> > > report to get this information before I need to open the mail itself.
> >
> > "Change Columns" link in the search output.
>
> I meant the index view in mutt, i.e. the list of messages.
Ah, it's not possible, but it would be nice to have some extension to
the mutt index_format, something like %x{headername}.
Karel
--
Karel Zak
http://karelzak.blogspot.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: About F19 Firewall
Mateusz Marzantowicz wrote: >Wireless networks have unique "names" and are represented as different >connections on NetworkManager (network connection != interface). For >network named "MyHomeNet" one can associate Home zone in NetworkManager >and for network "CoffeShowHotSpot" one assigns Public zone. You don't >have to change anything once it's assigned. So when some innocent-looking guy is sitting in the café with a smartphone posing as an access point with an SSID of "MyHomeNet", will your Fedora laptop connect to it, switch to the Home zone, and assume that everybody on that network is friendly? -- Björn Persson Sent from my computer. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 20-Alpha RC2 AMIS
- Original Message - > On Thu, Sep 12, 2013 at 04:46:17PM -0500, Dennis Gilmore wrote: > > ami-1bb5fc72 : us-east-1 image for i386 > > This still doesn't boot. (We're working on it.) Matt, any news on this? Thanks Jaroslav > -- > Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ > -- > test mailing list > t...@lists.fedoraproject.org > To unsubscribe: > https://admin.fedoraproject.org/mailman/listinfo/test -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: About F19 Firewall
Hi Mateusz, - Original Message - > From: Mateusz Marzantowicz > Subject: Re: About F19 Firewall > > Wireless networks have unique "names" and are represented as different > connections on NetworkManager (network connection != interface). For > network named "MyHomeNet" one can associate Home zone in > NetworkManager and for network "CoffeShowHotSpot" one assigns Public zone. > You > don't have to change anything once it's assigned. Public zone is as I > understand strictest but usable one (block zone does not allow traffic). > This can also be applied to wired connection. Yep, true.Individual zones for each type of network seems to offer choice and versatility from Firewalld. But a user could end up using the same zone for all networks, because it appears as the default one when doing the network <=> zone assignment in NetworkManager. I don't use NetworkManager so not sure how it works. > I agree they're harder to understand and maintain manually by sysadmin but > they're not designed for such usage. Hmmn, it should have been a package for user to install at will, rather than a replacement of an understandable firewall. Thanks. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1008407] perl-Pod-Spell-1.07 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1008407 Jitka Plesnikova changed: What|Removed |Added Depends On||1008856 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=pkgPJSDqzp&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Unretiring gpx-viewer / Review Swap
On Tue, 2013-09-17 at 00:04 +0200, Christian Krause wrote: > Hi, > > according to > http://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers > I'd like to announce that I want to unretire the package gpx-viewer. > > The package was retired because it didn't build for multiple Fedora > releases: > > https://pkgs.fedoraproject.org/cgit/gpx-viewer.git/tree/dead.package > > Upstream is not very active, but there are still occasional bug fixes > committed: > > https://launchpad.net/gpx-viewer > > gpx-viewer has one advantage over the full-featured tools like josm or > merkaartor: it can display a GPX track using OpenStreet maps without any > setup or configuration. > > The required review request can be found here: > https://bugzilla.redhat.com/show_bug.cgi?id=1008701 > > If someone would like to swap a review, I'd be happy to help, too! > > > Best regards, > Christian I'll take the review. Volker -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Math-NumSeq] New version 64 (#1008403)
commit 413aa8a8f28b9394106c9d4587cde1aeae3ebc34
Author: Miro Hrončok
Date: Tue Sep 17 10:14:50 2013 +0200
New version 64 (#1008403)
.gitignore|1 +
perl-Math-NumSeq.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index efc18fc..1072efd 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
/Math-NumSeq-55.tar.gz
/Math-NumSeq-62.tar.gz
/Math-NumSeq-63.tar.gz
+/Math-NumSeq-64.tar.gz
diff --git a/perl-Math-NumSeq.spec b/perl-Math-NumSeq.spec
index 8ad0848..a18b748 100644
--- a/perl-Math-NumSeq.spec
+++ b/perl-Math-NumSeq.spec
@@ -1,5 +1,5 @@
Name: perl-Math-NumSeq
-Version:63
+Version:64
Release:1%{?dist}
Summary:Number sequences
License:GPLv3+
@@ -96,6 +96,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Sep 17 2013 Miro Hrončok - 64-1
+- New version 64 (#1008403)
+
* Mon Sep 02 2013 Miro Hrončok - 63-1
- New version 63
- %%{__perl} to perl
diff --git a/sources b/sources
index 80dfdd0..cf77cf6 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-30e4f73ed3a83ad5c2f3571f8d65eff3 Math-NumSeq-63.tar.gz
+a1b7833d5da6381b1ee1ce5158e19ebf Math-NumSeq-64.tar.gz
--
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: About F19 Firewall
On 16.09.2013 07:55, P J P wrote: >Hello Tomasz, > > - Original Message - >> From: Tomasz Torcz >> Subject: Re: About F19 Firewall >> You seem to have missed this Fedora *18* feature: >> https://fedoraproject.org/wiki/Features/firewalld-default >> firewall-cmd is supposed to isolate user from all this chains. > > >Yep, true. My contention is not with the tool, but with the complexity it > adds to the rules with all the zones and sub-chains and user-space tooling > around it. > > >-> https://fedoraproject.org/wiki/FirewallD > > > As I suspected a zone describes a network one is currently connected in. It > could be home, work, public(wifi at a coffee shop) etc. That means one must > keep shifting from home to work to home and in between public for > coffee-shop. I wonder who's going to do that every day. If they don't they > either don't get to use the network services or are not protected enough. Ex. > one always has the 'public' zone rules activated. > Wireless networks have unique "names" and are represented as different connections on NetworkManager (network connection != interface). For network named "MyHomeNet" one can associate Home zone in NetworkManager and for network "CoffeShowHotSpot" one assigns Public zone. You don't have to change anything once it's assigned. Public zone is as I understand strictest but usable one (block zone does not allow traffic). This can also be applied to wired connection. The reason for all that chains is to allow adding/removing rules without need to reload all of them. It's written somewhere on FirewallD's site. I agree they're harder to understand and maintain manually by sysadmin but they're not designed for such usage. Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
