Re: manually fixing IPs
On 03/27/2011 10:57 AM, Ralf Corsepius wrote: > And how to tweak /etc/sysconfig/network-scripts/ifcfg-* (and/or > /etc/sysconfig/network) for static IPs such that NM sets > hostname/domainname correctly? > > I have never got this working correctly. > > In all cases, I've tried either "hostname -f" or "hostname" did not work. https://bugzilla.redhat.com/show_bug.cgi?id=648725#c23 Sounds like NM is out of the 'hostname setting' business. You should be able to edit your /etc/hosts manually and NM will not change it. -Jeff signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall
On 12/09/2010 09:00 PM, Curtis Doty wrote: > Why must statefull connection tracking be imposed on every Fedora user? > > Don't get me wrong. I use netfilter all the time and love it. And it's > good to install the userland iptables tools and a simple firewall by > default. But when I'd like to choose Fedora without it (asymmetric > routing anyone?), I now have to rebuild the kernel. [harumph!] > > Was there ever a good reason for making the filter table and conntrack > modules monolithic? They certainly didn't used to be built in... > > ../C Seems like there should be an easy way to 'opt-out' of connection tracking. Have you tried anything like 'iptables -t raw -I PREROUTING -j NOTRACK' ? The iptables man-page says this about the 'raw' table: " This table is used mainly for configuring exemptions from connection tracking in combination with the NOTRACK target. It registers at the netfilter hooks with higher priority and is thus called before ip_conntrack, or any other IP tables. It provides the following built-in chains: PREROUTING (for packets arriving via any network interface) OUTPUT (for packets generated by local processes) " Cheers. -Jeff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why should I ever bother filing another bug?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/09/2010 04:05 PM, "Jóhann B. Guðmundsson" wrote: > On 11/09/2010 09:40 PM, Adam Williamson wrote: >> On Tue, 2010-11-09 at 21:31 +, "Jóhann B. Guðmundsson" wrote: >>> On 11/09/2010 07:50 PM, Adam Williamson wrote: In practice, we run very few metrics on Bugzilla >>> This is the problem we should be gather all kinds of bug metrics and >>> general component activity from bugzilla. >>> >>> This is very vital information for QA group to harvest and have. >>> ( without it we cant find the areas were both parties can do better. ) >>> >>> And since there is general will amongst reporters that this information >>> is collected this I maintainers if they are opposed that this >>> information will be harvested? >>> >>> If so why? >> no-one's opposed to it. Just no-one's actually stepping up to do it. >> We've had three attempts so far within bugzappers to get metrics going, >> and it never works out, because no-one follows through. Demanding that >> it happen is not going to magically make it happen; someone has to do >> the work. > > Do you have any links to the bugzappers discussions about this and the > code that was used in these attempts? > > Do we have access to bugzilla clone to test against? > > JBG For the latest attempt at getting some useful 'metric' data from bugzilla see: http://fedoraproject.org/wiki/BugZappers/Metrics and http://fedoraproject.org/wiki/Talk:BugZappers/Metrics (Those pages are fairly specific to trying to quantify the amount/impact of the work that the triagers are doing.) Additionally, bugzilla's report.cgi is worth looking at. As an example: The number of 'Triaged' Bugs CLOSED in the last 90days with breakdown by resolution[1]. - -Jeff 1: https://bugzilla.redhat.com/report.cgi?x_axis_field=resolution&query_format=report-table&classification=Fedora&product=Fedora&bug_status=CLOSED&chfieldfrom=-90d&chfieldto=Now&chfield=bug_status&chfieldvalue=CLOSED&format=table&action=wrap&field0-0-0=keywords&type0-0-0=substring&value0-0-0=Triaged -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJM2hslAAoJEBHSWqGjRJu75jYH/3Vf58f/gAR4eQ29QvAkyRPs HrQdfIXaKzpBF+7PbXyjQ1Ab0kpZ2Rr1aK/tYg6+O7XCG+HAfFQiLs9vm8MEscJx lJ896zht2+daTzeiNp8L4OwX9JjCeuf7XQaMualK+/EruuHVq/mONyaa1MNMGl/k LoQsGIFEH19eoI0hK7p8AASN5YQhQyp7mbyPJlyXersrg7W8uzmYfk9P7KFUqACE V0CX9nLXI863phEIcTZrfqSUwNd1cGL1WyFR6WZp029ArFaYQMp3FqNXtvKQIJl1 UIrxW4EFrODCsFplVTkNjcXp9sC8YWIwKg2N+wEug8b+zVpzugCdRalmz/DWMgY= =yYVL -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On 07/21/2010 09:36 PM, Dave Airlie wrote: >> Well, I am not a native speaker. We were looking for a verb that >> > basically means "make this take effect immediately". >> > >> > i.e. the "enable"/"disable" commands makes some changes for the next >> > time they are looked at, and then adding --realize on top makes those >> > changes take effect immediately, i.e. so that the unit is start/stopped >> > according to those changes. We actually used "--start=" first (which >> > however is very confusing when you'd write "disable --start" to disable >> > something and then have it stop...) We then considered "--now", because >> > it is not a verb. But eventually we stuck with --realize. It's not >> > great, yes. But we couldnt think of anything better. Happy to take >> > suggestions. But no, --take-effect-immediately is not really an option. > Why have two verbs in a command structure? isn't enable or disable the > order, --now seems like it would be correct, the thing with English is > its flexible about these sort of things. I'm part of the native English group. For me, --now would be an almost self explanatory option, and so easy to remember! If --now is unacceptable, how about --immed. -Jeff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Upcoming Bugzilla Changes: Rawhide Rebase
Greetings, I hope everyone is well. This e-mail is intended to inform you about the upcoming bugzilla changes happening around July 27, 2010 (Rawhide bug rebase) and what you need to do, if anything. We will be automatically changing the version for most rawhide bugs to Fedora 14. This will result in regular bugs reported against rawhide during the Fedora 14 development cycle being changed to version ‘14' instead of their current assignment, ‘rawhide’. This is to align with the branching of Fedora 14 from rawhide and to more accurately tell where in the lineage of releases the bug was last reported. Note that this procedure does not apply to bugs that are open for the ‘Package Review’ component or bugs that have the ''FutureFeature'' or ''Tracking'' keywords set. They will stay open as rawhide bugs indefinitely. If you do not want your bugs changed to version ‘14‘, add the FutureFeature keyword. If you need help changing a large amount of bugs manually, we’d be glad to help. Stop by #fedora-bugzappers on irc.freenode.net and we’ll gladly help you. More about these processes is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping Jeff Raber --- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers ___ 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
