Re: FAT and HFS/HFS+ file system resizing restored in parted-3.1
On Wed, Mar 14, 2012 at 12:24 AM, Kevin Kofler wrote: > I wrote: > >> Brian C. Lane wrote: >>> I am going to be leaving parted at 3.0 for F17, I don't want to >>> introduce a large change at this stage. >> >> This is really unhelpful, it's going to leave frontends with no way to >> readd support for the lost functionality for another release. >> >> (FYI, I filed an RFE against upstream kde-partitionmanager to get support >> for this in: https://bugs.kde.org/show_bug.cgi?id=295339 . I might try to >> come up with a patch if upstream doesn't react soon.) >> >> IMHO, we should actually either also upgrade F16 to parted 3.1 or backport >> the new libparted-fs-resize library. > > PS: I also don't see how an added library which Anaconda doesn't even use > could have any potential for breakage. It wouldn't but the core parted has new features too and those have the ability to break things in anaconda, it's not just a new library. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why we need redhat_lsb_trigger.c in redhat-lsb package?
On 03/13/2012 07:04 AM, Xibo Ning wrote:
Hi,
Do we really need a fineness c program to make symbol link? In
redhat-lsb.spec, we can see:
%triggerpostun -- glibc
if [ -x /usr/sbin/redhat_lsb_trigger.%{_target_cpu} ]; then
/usr/sbin/redhat_lsb_trigger.%{_target_cpu}
fi
And in redhat_lsb_trigger.c, the main function is as follows:
if (is_ia64 ())
INTERNAL_SYSCALL (symlink, err, 2, "/emul/ia32-linux/lib/" LDSO, buf);
else
INTERNAL_SYSCALL (symlink, err, 2, LDSO, buf);
Why need we use a manually c program, not sln command? We can copy a
copy of sln, so we can use it even when glibc is removed.
Probably the trigger can be executed at a critical time when no
libraries are available, hence the static binary. I guess sln would be
an alternative.
The best solution would probably be to replace the %triggerpostun with a
lua scriptlet, something like this (totally untested and you'll need to
add the LSB-version somewhere too):
%triggerpostun -p -- glibc
LDSO = "/usr/lib/ld.so"
LSBLDSO = "/usr/lib/ld." + LSB_VERSION + ".so"
%ifarch ia64
LDSO = "/emul/ia32-linux/lib" + LSBLDSO
%fi
posix.symlink(LDSO, LSBLDSO)
Cheers,
Niels
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why we need redhat_lsb_trigger.c in redhat-lsb package?
On Wed, Mar 14, 2012 at 10:08:32AM +0100, Niels de Vos wrote:
> On 03/13/2012 07:04 AM, Xibo Ning wrote:
> The best solution would probably be to replace the %triggerpostun
> with a lua scriptlet, something like this (totally untested and
> you'll need to add the LSB-version somewhere too):
>
> %triggerpostun -p -- glibc
> LDSO = "/usr/lib/ld.so"
> LSBLDSO = "/usr/lib/ld." + LSB_VERSION + ".so"
> %ifarch ia64
> LDSO = "/emul/ia32-linux/lib" + LSBLDSO
> %fi
> posix.symlink(LDSO, LSBLDSO)
That is not equivalent. is_ia64 () is true in the statically linked
binary for %ifarch %{ix86} if running on the ia64 CPU (software emulated).
Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: help with package review
On Tue, Mar 13, 2012 at 07:50:06PM -0400, Julian C. Dunn wrote: > Hi all, > > I'm new to the Fedora project although I've been a long-time Fedora user. I'm > hoping someone can review and sponsor a package that I've had in the pipe for > a while, and am only getting back to dealing with: > > https://bugzilla.redhat.com/show_bug.cgi?id=611372 I guess I could help you with this :) -P > > I'm not sure if I need to trade reviews with someone to push this forward, > but I'm happy to do that as well. > > - Julian pgp8jRkyFf34l.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16 problems with git
Michał Piotrowski writes: > Hi, > > I noticed recently a worrying git behavior. I often do something like that: > git fsck --full > git gc > git push origin master | backup of the entire tree in tar archive > > 'git fsck' or 'git gc' sometimes causes damage to the repository ie: > > $ git fsck --full > error: packed 694728b9fe62ad667f051a109c389403ffa0cb29 from > .git/objects/pack/pack-a4bae2576b36116f1962a5496674ea921eebb6c5.pack > is corrupt > > This time, however, after 'git fsck' rerun I don't get this error > message, but in other cases, the repository is corrupted. Has anyone > noticed similar problems with git on F16? Linus wrote nice document about recovering corrupted blob http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/howto/recover-corrupted-blob-object.txt;h=323b513ed0e0ce8b749672f589a375073a050b97;hb=HEAD -- Nikola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File XML-LibXML-1.95.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-XML-LibXML: 07c9ac47e0456b812e1e3ed1f4d4cb34 XML-LibXML-1.95.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
[perl-XML-LibXML] 1.95 bump
commit 8c221fa865295ffa7a5e98b43b83f123ba0062bd
Author: Petr Šabata
Date: Wed Mar 14 11:43:47 2012 +0100
1.95 bump
.gitignore |1 +
perl-XML-LibXML.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 0b37135..949a0f5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@ XML-LibXML-1.70.tar.gz
/XML-LibXML-1.90.tar.gz
/XML-LibXML-1.92.tar.gz
/XML-LibXML-1.93.tar.gz
+/XML-LibXML-1.95.tar.gz
diff --git a/perl-XML-LibXML.spec b/perl-XML-LibXML.spec
index e3c81ef..06e1427 100644
--- a/perl-XML-LibXML.spec
+++ b/perl-XML-LibXML.spec
@@ -3,7 +3,7 @@ Name: perl-XML-LibXML
# https://bugzilla.redhat.com/show_bug.cgi?id=469480
# it might not be needed anymore
# this module is maintained, the other is not
-Version:1.93
+Version:1.95
Release:1%{?dist}
Epoch: 1
Summary:Perl interface to the libxml2 library
@@ -102,6 +102,9 @@ fi
%{_mandir}/man3/*.3*
%changelog
+* Wed Mar 14 2012 Petr Šabata - 1:1.95-1
+- 1.95 bump, tests bugfixes
+
* Mon Feb 27 2012 Petr Šabata - 1:1.93-1
- 1.93 bumpity, minor bugfix
diff --git a/sources b/sources
index 09b49e6..e95885d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a065849448467fb694b80276039a7126 XML-LibXML-1.93.tar.gz
+07c9ac47e0456b812e1e3ed1f4d4cb34 XML-LibXML-1.95.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
[Bug 803004] perl-XML-LibXML-1.95 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=803004 Petr Šabata changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-XML-LibXML-1.95-1.fc18 Resolution||RAWHIDE Last Closed||2012-03-14 06:49:45 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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: F16 problems with git
2012/3/14 Nikola Pajkovsky : > Michał Piotrowski writes: > >> Hi, >> >> I noticed recently a worrying git behavior. I often do something like that: >> git fsck --full >> git gc >> git push origin master | backup of the entire tree in tar archive >> >> 'git fsck' or 'git gc' sometimes causes damage to the repository ie: >> >> $ git fsck --full >> error: packed 694728b9fe62ad667f051a109c389403ffa0cb29 from >> .git/objects/pack/pack-a4bae2576b36116f1962a5496674ea921eebb6c5.pack >> is corrupt >> >> This time, however, after 'git fsck' rerun I don't get this error >> message, but in other cases, the repository is corrupted. Has anyone >> noticed similar problems with git on F16? > > Linus wrote nice document about recovering corrupted blob > > http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/howto/recover-corrupted-blob-object.txt;h=323b513ed0e0ce8b749672f589a375073a050b97;hb=HEAD Thanks for sharing this link. This is a lot of git magic and I prefer to do backups :) "The most common cause of corruption so far has been memory corruption" - it gives me food for thought. I am using the SSD with Ext4 - I checked it recently with "fsck.ext4 -cvf", it may also be useful to check RAM. > > -- > Nikola > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self introduction
Hello, I'm Martin Werner, otherwise active in the Debian Games Team[0] doing packaging work, and in the Red Eclipse[1] game community working with documentation, licensing, testing, etc. I'm in the process of Packaging Red Eclipse for Fedora[2], I've gone through most of the review process (I hope), thanks Brendan Jones for reviewing! And is now waiting on the dependency Enet 1.3.3 to get into Fedora[3], something which I've also tried to help out with a bit. At the moment I'm focussing on maintaining Red Eclipse in Fedora, but depending on my fancy I might get dragged into other things :) You can ping me by the name "arand" on IRC. My GPG is: pub 4096R/481823D1 2011-10-29 Key fingerprint = 875A 491E CF7B F9E0 A52D 1B2E B5D5 A621 4818 23D1 [0] http://wiki.debian.org/Games [1] http://www.redeclipse.net/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=800930 [3] https://bugzilla.redhat.com/show_bug.cgi?id=739313 https://bugzilla.redhat.com/show_bug.cgi?id=799778 -- Martin Erik Werner signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why we need redhat_lsb_trigger.c in redhat-lsb package?
On Wed, Mar 14, 2012 at 10:13 AM, Jakub Jelinek wrote:
> On Wed, Mar 14, 2012 at 10:08:32AM +0100, Niels de Vos wrote:
>> On 03/13/2012 07:04 AM, Xibo Ning wrote:
>> The best solution would probably be to replace the %triggerpostun
>> with a lua scriptlet, something like this (totally untested and
>> you'll need to add the LSB-version somewhere too):
>>
>> %triggerpostun -p -- glibc
>> LDSO = "/usr/lib/ld.so"
>> LSBLDSO = "/usr/lib/ld." + LSB_VERSION + ".so"
>> %ifarch ia64
>> LDSO = "/emul/ia32-linux/lib" + LSBLDSO
>> %fi
>> posix.symlink(LDSO, LSBLDSO)
>
> That is not equivalent. is_ia64 () is true in the statically linked
> binary for %ifarch %{ix86} if running on the ia64 CPU (software emulated).
Aha, so is_ia64() does some checks and that makes the decision to have
the symlink point to one ld.so or the other.
If those checks can be written in lua, replacing redhat_lsb_trigger.c
would make sense.
Cheers,
Niels
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why we need redhat_lsb_trigger.c in redhat-lsb package?
Niels de Vos (de...@fedoraproject.org) said:
> >> %triggerpostun -p -- glibc
> >> LDSO = "/usr/lib/ld.so"
> >> LSBLDSO = "/usr/lib/ld." + LSB_VERSION + ".so"
> >> %ifarch ia64
> >> LDSO = "/emul/ia32-linux/lib" + LSBLDSO
> >> %fi
> >> posix.symlink(LDSO, LSBLDSO)
> >
> > That is not equivalent. is_ia64 () is true in the statically linked
> > binary for %ifarch %{ix86} if running on the ia64 CPU (software emulated).
>
> Aha, so is_ia64() does some checks and that makes the decision to have
> the symlink point to one ld.so or the other.
> If those checks can be written in lua, replacing redhat_lsb_trigger.c
> would make sense.
Well, it's not as if ia64 is supported in current Fedora or RHEL releases,
so those bits could just be removed...
Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 803003] perl-Tk-Pod-0.9940 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=803003 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Tk-Pod-0.9940 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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 802990] perl-Jemplate-0.262 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=802990 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Jemplate-0.262-1.fc18 Resolution||RAWHIDE Last Closed||2012-03-14 13:13:30 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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
File POE-Component-Resolver-0.916.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-POE-Component-Resolver: ba104cbb998802f789e237f0ac1b8ef7 POE-Component-Resolver-0.916.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
[perl-POE-Component-Resolver] 0.916 bump
commit 4b50260e42e0f233f92dfe89cb91d0ff15a59f3a
Author: Petr Šabata
Date: Wed Mar 14 18:17:53 2012 +0100
0.916 bump
.gitignore |1 +
perl-POE-Component-Resolver.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e648956..f3bc501 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/POE-Component-Resolver-0.914.tar.gz
+/POE-Component-Resolver-0.916.tar.gz
diff --git a/perl-POE-Component-Resolver.spec b/perl-POE-Component-Resolver.spec
index 2d14c2d..11df177 100644
--- a/perl-POE-Component-Resolver.spec
+++ b/perl-POE-Component-Resolver.spec
@@ -1,5 +1,5 @@
Name: perl-POE-Component-Resolver
-Version:0.914
+Version:0.916
Release:1%{?dist}
Summary:Non-blocking getaddrinfo() resolver
License:GPL+ or Artistic
@@ -62,5 +62,8 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Mar 14 2012 Petr Šabata - 0.916-1
+- 0.916 bump
+
* Thu Jan 19 2012 Petr Šabata 0.914-1
- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index 63811fc..5e25f6b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4193ed826d9c4f0fd8629b3f0861c0fb POE-Component-Resolver-0.914.tar.gz
+ba104cbb998802f789e237f0ac1b8ef7 POE-Component-Resolver-0.916.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
[Bug 802985] perl-DBD-Pg-2.19.2 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=802985 Marcela Mašláňová changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution||RAWHIDE Last Closed||2012-03-14 12:37:18 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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: DHCPv6 *still* broken for F17 alpha
On Fri, 2012-03-02 at 14:52 +0100, Tore Anderson wrote: > * Dan Williams > > > 0.9.4 snapshots do not require both methods to complete (with either > > success or failure) before saying the machine is connected. Thus if > > IPv4 completes first, NM will say it's connected, and continue IPv6 in > > the background. And vice versa. > > That is true, however, if IPv6 completes first, and IPv4 (still running > in the background) eventually ends up failing, the *entire connection* > will be torn down - including the perfectly working IPv6 connectivity. > So the successfully connected state only lasts for about 20 seconds. > > A trivial patch that fixes this problem is attached, please apply. I've gone back and forth on this last week; since it changes the default, it would break the case where somebody depends on the current behavior, ie that by default IPv4 may not fail. After this patch is applied, a network where IPv6 connectivity is available but broken (or where the router sends RAs with private prefixes like fdxx::) and IPv4 is for some reason also broken, will make NM show "connected" when in fact we aren't really. The new connectivity detection will help that somewhat, but we haven't enabled it by default yet for a few reasons. I ran into a network when testing this that caused me to think harder about this patch. It's an Actiontec router attached to Comcast (I think) but has no upstream IPv6 connectivity. It sends RAs for the fdxx:: address space and NM dutifully picks that up. So now we've got IPv6 connectivity to a "private" prefix that's not routable. If, in this case, the router's DHCP server died, which sometimes happens on crappy consumer hardware, an upgraded NM would report connected while old NMs would fail the connection. Whether we care enough about this regression (if you want to call it that) versus enabling default IPv6 connectivity I don't know, I tend to think we suck up the regression. But I'm still interested in the failure cases. Next up, since AFAIK fdxx:: is a non-routable private network (like 10/8 right?) should NM say that we're only connected to a site-local network here? That would at least help the situation above, and indicate that something went wrong instead of NM saying we're connected to the internet and nothing working. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On Wednesday 14 March 2012 13:36:06 Dan Williams wrote: > Whether we care enough about this regression (if you want to call it > that) versus enabling default IPv6 connectivity I don't know, I tend to > think we suck up the regression. Please do. The current behaviour of tearing down working IPv6 connections is just painful IMHO. > Next up, since AFAIK fdxx:: is a non-routable private network (like 10/8 > right?) should NM say that we're only connected to a site-local network > here? That's probably the best thing to do, in both cases, IPv4 and IPv6. What NM definitely should not do is say that the connection failed while it's perfectly connected to a local network where there is just no link to the internet. Thanks, Lars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
What are the rules for updating a package?
Red Hat (nee Gluster) is about to release glusterfs-3.2.6. It's a bugfix release. No API/ABI changes (in theory, I haven't done an exhaustive check.) In f16 we released 3.2.5. Am I allowed to update it in f16 to 3.2.6? In f17alpha we also have 3.2.5. Am I allowed to update that at this point in time or is it too late? Thanks, — Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are the rules for updating a package?
On 03/15/2012 01:17 AM, Kaleb S. KEITHLEY wrote: > > Red Hat (nee Gluster) is about to release glusterfs-3.2.6. It's a bugfix > release. No API/ABI changes (in theory, I haven't done an exhaustive > check.) > > In f16 we released 3.2.5. Am I allowed to update it in f16 to 3.2.6? > > In f17alpha we also have 3.2.5. Am I allowed to update that at this > point in time or is it too late? These should be fine. Refer to https://fedoraproject.org/wiki/Updates_Policy Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are the rules for updating a package?
On Wed, Mar 14, 2012 at 2:47 PM, Kaleb S. KEITHLEY wrote: > > Red Hat (nee Gluster) is about to release glusterfs-3.2.6. It's a bugfix > release. No API/ABI changes (in theory, I haven't done an exhaustive check.) > > In f16 we released 3.2.5. Am I allowed to update it in f16 to 3.2.6? > > In f17alpha we also have 3.2.5. Am I allowed to update that at this point in > time or is it too late? As long as it's OK with the glusterfs maintainer, and there truly is no ABI/API change, all of these should be fine. -J > Thanks, > > — > > Kaleb > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- 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: DHCPv6 *still* broken for F17 alpha
On 03/02/2012 11:31 PM, Tore Anderson wrote: * Tom Callaway On 03/02/2012 04:39 PM, Tore Anderson wrote: This one *most likely* works (it assumes /sbin/dhclient in Fedora will *always* use a link-local source address when building a DHCPv6 request. I believe that is the case, but I have not reviewed its source code to verify): ip6tables -A INPUT -p udp --dport 546 -d fe80::/64 -j ACCEPT Can you please confirm that in the source code? I agree that this seems like the better option. Hi again, I've been poking around in the ISC-dhcp code for a while now, but I think I don't have sufficient C skills to follow what is going on 100%. I *think* it doesn't specify the source address anywhere, leaving it up to either glibc or the kernel to pick one when the packet is put on the wire. The ff02::1:2 multicast address (All_DHCP_Relay_Agents_and_Servers) has the link-local scope, so if the entity doing source address selection (be it the kernel or glibc) implements RFC 3484 correctly, the link-local source should be chosen, due to the the "prefer matching scope" rule. (If that didn't come into play, the "prefer longest common prefix" rule would also have ensured the link-local address was used for the source.) On my own system, where the interface is configured both with a link-local address and a global address (from SLAAC) at the time DHCPv6 is invoked, the link-local address is being used (so the "-d fe80::/64" restriction works for me). So, based on observed behaviour, my reading of the IETF standards, and the fact that I cannot find anything that would suggest otherwise in the ISC dhcp sources; my estimate is that it's>95% certain that including "-d fe80::/64" will work in all cases. Or, to put it another way, it's ∞ better than what we have today, and since I assume people would be more comfortable with including that particular restriction in an enabled-by-default ip6tables exception, I say go for it. If it turns out there's someone out there it won't work for, then we can consider changing the rule (or the DHCPv6 client). Best regards, For firewalld we added the dhcpv6-client service in the GIT repo and it is part of the 'work' and 'home' zone already. I will also add it to the 'public' zone (the default zone) and the 'internal' zone for the F-17 package. The dhcpv6-client service adds the rule "-p udp --dport 546 -d fe80::/64 -j ACCEPT" Regards, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice: IPv6 breaking issues tentatively considered blocker for F17
On Tue, 2012-03-13 at 22:45 +1030, Glen Turner wrote: > Hi, > > I am the network engineer at Australia's Academic and Research Network > responsible for assisting the deployment of IPv6 across Australian > universities. Your posting was bought to my attention. > > Your phrasing of the condition for blocking is pretty broad: there are > lots of ways to break IPv6, just as there are with IPv4, and just as > with IPv4 not all of them are significant enough to be blocking. > > Can I suggest the following as a starting point: > - failure in configuration of interface addresses with a link scope > address via stateless address autoconfiguration should block > - failure in configuration of interface addresses with a global scope > via stateless address autoconfiguration should block > - failure in configuration of interface addresses with a global scope > via manual configuration should block > - failure in configuration of DNS forwarding via stateless DHCP6 should > block > - failure in configuration of DNS forwarding via RAs should block > - failure of connectivity of network ::1/128 (localhost) of all > services should block > - failure of unicast or multicast connectivity of link local addressing > of allowed services should block > - failure of unicast connectivity of global addressing of allowed > services should block > - failure of connectivity of ICMP6 service for codes <= 127 should > block > > Non-stateless DHCP6 is primarily used by ISPs to configure customer > routers. Those routers present SLAAC to their downstream users. > > Non-stateless DHCP6 is also used by enterprises who wish to parallel > their existing management of computers via IPv4 DHCP into IPv6. In my > view that is a poor network design choice, but there is no denying that > it is a choice made by some enterprise networks. > > At this point in time you could deploy a IPv6 with manual configuration > and with SLAAC (with both stateless DHCP6 and RAs to configure DNS) and > make most people happy. The significance of the proportion of people > made unhappy may or may not be enough for a release blocking bug (as > opposed to simple lack of support for that IPv6 feature) -- that's > really your choice. > > It also depends if statefull DHCP6 host configuration was supported in a > previous release, in that case a regression leads to such a complicated > scenario for network engineers and systems administrators that the bug > should be release blocking. Thanks, Glen. Let me come clean and say my eyes glazed over about three sentences into that. =) If I'm semi-grokking it vaguely correctly, however, the meat of what you're suggesting here is that stateful (as opposed to stateless) autoconfiguration should not be a blocking issue? As far as 'what worked in previous releases' goes, my impression is that we can pretty much work from the assumption that IPv6 has never entirely worked OOTB on Fedora. -- 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
Hi I'm Anthony Sasadeusz and I want to help package
Hi, I want to try to get involved with the open source community. I am a junior at University of Maryland Baltimore County studying Computer Engineering. My goal is to eventually help out with the JBOSS packaging for Googles summer of code and continue to help out the community. I have good linux skills and know multiple programming languages. Here is a link to my first review request concerning packaging. https://bugzilla.redhat.com/show_bug.cgi?id=803531 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
