Re: What are the rules for updating a package?
On 03/14/2012 07:51 PM, Jon Ciesla wrote: 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. In the end, does this not end up being a judgement call by the maintainer even if that involves major numbering update/upgrade? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning json due to legal issues in newer versions.
According to repoquery nothing depends on this package anymore so I orphaned it in rawhide. If noone takes it I'll deprecate and remove it in beginnning of April. Alex - Original Message - > From: "Tom Callaway" > To: json-ow...@fedoraproject.org, scm-comm...@lists.fedoraproject.org > Sent: Wednesday, March 14, 2012 4:54:49 AM > Subject: [json] add a clarifying note to the spec file about the legal issues > with newer versions of this source > > commit 4cc8674a9a4de2a7e143aa5695004b6013abb75e > Author: Tom Callaway > Date: Tue Mar 13 22:54:46 2012 -0400 > > add a clarifying note to the spec file about the legal issues > with newer versions of this source > > json.spec |9 + > 1 files changed, 9 insertions(+), 0 deletions(-) > --- > diff --git a/json.spec b/json.spec > index 1778124..099d627 100644 > --- a/json.spec > +++ b/json.spec > @@ -1,3 +1,12 @@ > +# Note from Fedora Legal! > +# Please, do not update this package to a newer revision. > +# Later versions of the "json" upstream source have been relicensed > +# under an idiotic license containing an unenforceable clause which > +# makes the whole work non-free. Upstream thinks it is funny that > their > +# immature license causes heartburn for serious users, and is not > willing > +# to change it, hence, we're stuck here on the version 3 "apache" > build. > +# - 2012-03-13 - le...@fedoraproject.org > + > # Copyright (c) 2000-2009, JPackage Project > # All rights reserved. > # > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /etc/default in Fedora
On 03/13/2012 02:17 PM, James Antill wrote: On Sat, 2012-03-10 at 18:20 +, Richard W.M. Jones wrote: 'Course we could go further and rename /etc/httpd -> /etc/apache (and rename the package, both matching Debian), which should have been done a long time ago. It used to be like that: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/ch-httpd.html#S2-HTTPD-V2-DIFF-RPM ...but upstream explicitly requested that we change it. Why and why just us? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hi I'm Anthony Sasadeusz and I want to help package
On Thu, Mar 15, 2012 at 5:11 AM, Anthony Sasadeusz wrote: > 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 > Please check out https://bugzilla.redhat.com/show_bug.cgi?id=606430 -- Praveen Kumar http://fedoraproject.org/ http://kumar-pravin.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /etc/default in Fedora
On Thu, Mar 15, 2012 at 07:44:53AM +, "Jóhann B. Guðmundsson" wrote: > On 03/13/2012 02:17 PM, James Antill wrote: > >On Sat, 2012-03-10 at 18:20 +, Richard W.M. Jones wrote: > >>'Course we could go further and rename /etc/httpd -> /etc/apache (and > >>rename the package, both matching Debian), which should have been done > >>a long time ago. > > It used to be like that: > > > >http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/ch-httpd.html#S2-HTTPD-V2-DIFF-RPM > > > >...but upstream explicitly requested that we change it. > > > > Why and why just us? Good question, we deviate from upstream default: http://wiki.apache.org/httpd/DistrosDefaultLayout -- Tomasz Torcz "God, root, what's the difference?" xmpp: zdzich...@chrome.pl "God is more forgiving." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On 2012-03-14, Dan Williams wrote: > 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. > How does fd00::/16 differes from 10.0.0.0/8? Why getting site scope address in IPv4 is Ok, while getting such address in IPv6 is considered as failure? Unfortunatelly companies expect deploying NAT66 (network multihoming while missing access to BGP). Also user may expect installation from local mirror or through proxy. I think you are doing the installer to much smart resulting in crappy behaviour in special cases. If you want to check connectivy, let's ping official Fedora mirror. Present the ping result to user as a hint, but do not prevent him from proceding. -- Petr -- 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|MODIFIED|CLOSED Resolution||RAWHIDE Last Closed||2012-03-15 06:09:29 -- 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
F-17 Branched report: 20120315 changes
Compose started at Thu Mar 15 08:15:03 UTC 2012 Broken deps for x86_64 -- [HippoDraw] HippoDraw-devel-1.21.3-2.fc17.i686 requires python-numarray HippoDraw-devel-1.21.3-2.fc17.x86_64 requires python-numarray HippoDraw-python-1.21.3-2.fc17.x86_64 requires python-numarray [aeolus-conductor] aeolus-conductor-0.4.0-2.fc17.noarch requires ruby(abi) = 0:1.8 [aeolus-configserver] aeolus-configserver-0.4.1-5.fc17.noarch requires ruby-nokogiri [alexandria] alexandria-0.6.8-2.fc17.1.noarch requires ruby(abi) = 0:1.8 [amsn] amsn-0.98.4-9.fc17.x86_64 requires libgstfarsight-0.10.so.0()(64bit) [aunit] aunit-2010-3.fc16.i686 requires libgnat-4.6.so aunit-2010-3.fc16.x86_64 requires libgnat-4.6.so()(64bit) [catfish] catfish-engines-0.3.2-4.fc17.1.noarch requires pinot [comoonics-cdsl-py] comoonics-cdsl-py-0.2-19.noarch requires comoonics-base-py [comoonics-cluster-py] comoonics-cluster-py-0.1-25.noarch requires comoonics-base-py [contextkit] contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) [couchdb] couchdb-1.0.3-2.fc16.x86_64 requires libicuuc.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicui18n.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicudata.so.46()(64bit) [dh-make] dh-make-0.55-4.fc17.noarch requires debhelper [empathy] empathy-3.3.5-3.fc17.x86_64 requires telepathy-butterfly empathy-3.3.5-3.fc17.x86_64 requires libtelepathy-farsight.so.0()(64bit) empathy-3.3.5-3.fc17.x86_64 requires libgstfarsight-0.10.so.0()(64bit) [eruby] eruby-1.0.5-17.fc17.x86_64 requires libruby.so.1.8()(64bit) eruby-libs-1.0.5-17.fc17.i686 requires ruby(abi) = 0:1.8 eruby-libs-1.0.5-17.fc17.i686 requires libruby.so.1.8 eruby-libs-1.0.5-17.fc17.x86_64 requires ruby(abi) = 0:1.8 eruby-libs-1.0.5-17.fc17.x86_64 requires libruby.so.1.8()(64bit) [gajim] gajim-0.15-0.4.beta4.fc17.noarch requires farsight2-python [ganyremote] ganyremote-5.13-2.fc17.noarch requires bluez-utils >= 0:3.35 [gcc-python-plugin] gcc-python2-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python2-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 [gdal] gdal-ruby-1.7.3-12.fc17.x86_64 requires libruby.so.1.8()(64bit) [gearmand] gearmand-0.23-2.fc17.x86_64 requires libtcmalloc.so.0()(64bit) gearmand-0.23-2.fc17.x86_64 requires libmemcached.so.8()(64bit) gearmand-0.23-2.fc17.x86_64 requires libboost_program_options-mt.so.1.47.0()(64bit) [genius] genius-1.0.12-2.fc15.x86_64 requires libgmp.so.3()(64bit) gnome-genius-1.0.12-2.fc15.x86_64 requires libgmp.so.3()(64bit) [ghc-conduit] ghc-conduit-0.2.2-1.fc17.i686 requires libHSlifted-base-0.1.0.3-ghc7.0.4.so ghc-conduit-0.2.2-1.fc17.i686 requires ghc(lifted-base-0.1.0.3) = 0:3cd2f5651657fddd87690f7280ea9d3b ghc-conduit-0.2.2-1.fc17.x86_64 requires libHSlifted-base-0.1.0.3-ghc7.0.4.so()(64bit) ghc-conduit-0.2.2-1.fc17.x86_64 requires ghc(lifted-base-0.1.0.3) = 0:f261afc8420a2629ebb4586fc5993f75 ghc-conduit-devel-0.2.2-1.fc17.i686 requires ghc-prof(lifted-base-0.1.0.3) = 0:3cd2f5651657fddd87690f7280ea9d3b ghc-conduit-devel-0.2.2-1.fc17.i686 requires ghc-devel(lifted-base-0.1.0.3) = 0:3cd2f5651657fddd87690f7280ea9d3b ghc-conduit-devel-0.2.2-1.fc17.x86_64 requires ghc-prof(lifted-base-0.1.0.3) = 0:f261afc8420a2629ebb4586fc5993f75 ghc-conduit-devel-0.2.2-1.fc17.x86_64 requires ghc-devel(lifted-base-0.1.0.3) = 0:f261afc8420a2629ebb4586fc5993f75 [gnatcoll] gnatcoll-2011-6.fc17.i686 requires libgnat-4.6.so gnatcoll-2011-6.fc17.i686 requires libgnarl-4.6.so gnatcoll-2011-6.fc17.x86_64 requires libgnat-4.6.so()(64bit) gnatcoll-2011-6.fc17.x86_64 requires libgnarl-4.6.so()(64bit) [gnome-phone-manager] gnome-phone-manager-0.66-9.fc17.x86_64 requires libgnome-bluetooth.so.9()(64bit) [gnome-user-share] gnome-user-share-3.0.1-3.fc17.x86_64 requires libgnome-bluetooth.so.9()(64bit) [gorm] gorm-1.2.13-0.2.20110331.fc17.i686 requires libobjc.so.3 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-gui.so.0.20 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-base.so.1.23 gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libobjc.so.3()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-gui.so.0.20()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-base.so.1.23()(64bit) [gphpedit] gphpedit-0.9.95-0.2.20090209snap.fc15.x86_64 requir
File Pod-Wordlist-hanekomu-1.120740.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Pod-Wordlist-hanekomu: 063695efb3b3a84f09f4c31a13cdae94 Pod-Wordlist-hanekomu-1.120740.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: What are the rules for updating a package?
2012/3/15 "Jóhann B. Guðmundsson" : > On 03/14/2012 07:51 PM, Jon Ciesla wrote: >> >> 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. > > > In the end, does this not end up being a judgement call by the maintainer > even if that involves major numbering update/upgrade? In practice, yes, but the guideline is there to help keep things from changing too radically inside a stable release. A soname bump, for example, without perfectly coordinated rebuilds of dependant packages, could break applications. Then there are things like file format changes, config syntax, etc. -J > JBG > -- > 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
FUDCon Kuala Lumpur travel subsidy requests are now open
Greetings, As you may know, there is a planned APAC FUDCon in Kuala Lumpur coming up soon, May 18-20 in Kuala Lumpur, Malaysia. https://fedoraproject.org/wiki/FUDCon:KualaLumpur_2012 If you are planning to attend FUDCon Kuala Lumpur and need a travel subsidy, the ticketing system is currently open for requests. Requests will be accepted through March 27, 2012. Please note that funding requests without a ticket will not be considered. The travel budget is limited, and preference will be given to attendees from the APAC region who are actively contributing to Fedora, and have detailed their participation plans for FUDCon in their subsidy request. To place a subsidy request, please follow these steps: 1: Pre-register at https://fedoraproject.org/wiki/FUDCon:KualaLumpur_2012#Pre-registration 2: Put an X in the $$$ column 3: Read about the funding request process and place a funding request ticket in the FUDCon-planning ticket tracker here: https://fedorahosted.org/fudcon-planning/wiki/FundingRequest Thank you! -Robyn ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On Wed, 2012-03-14 at 20:47 +0100, Lars Seipel wrote: > 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. If the IPv6 method is "ignore" (which is the current default) then NM shouldn't be touching IPv6 stuff on that interface; kernel-assigned routes and addresses should be there and untouched by NM. Is that not the case? Dan > > 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
Re: DHCPv6 *still* broken for F17 alpha
On Thu, 2012-03-15 at 10:07 +, Petr Pisar wrote: > On 2012-03-14, Dan Williams wrote: > > 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. > > > How does fd00::/16 differes from 10.0.0.0/8? Why getting site scope > address in IPv4 is Ok, while getting such address in IPv6 is considered > as failure? > > Unfortunatelly companies expect deploying NAT66 (network multihoming > while missing access to BGP). > > Also user may expect installation from local mirror or through proxy. > > I think you are doing the installer to much smart resulting in crappy > behaviour in special cases. > > If you want to check connectivy, let's ping official Fedora mirror. > Present the ping result to user as a hint, but do not prevent him from > proceding. The current connectivity checking code is built-but-inactive in F17, you can enable it by adding these entries to /etc/NetworkManager/NetworkManager.conf: [connectivity] uri=http:// interval=120 the URL is expected to return one or both of: 1) an HTTP header named "X-NetworkManager-Status" with the value of "online" 2) an document body consisting only of the text "NetworkManager is online" (can be customized by an option in the config file) This method lets NM (in the future) detect captive portals and will allow auto-login in those networks. It's basically what Windows does for its connectivity detection too. If we have proxy information, in the near future we'd use it here as well. If NM doesn't get the correct response then for the most part, we can't consider the machine to have Internet connectivity. Obviously this can be disabled (by not specifying a connectivity check URI) for cases where it's known not to work. The only effect this checking will have is to change NetworkManager's state from CONNECTED_GLOBAL to CONNECTED_SITE or CONNECTED_LOCAL. It doesn't do anything odd like disconnect and retry some other connection, which wouldn't make much sense. It just changes some state which apps can use to figure out whether they'd connect to say your IRC server or your email or whatever automatically. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hi I'm Anthony Sasadeusz and I want to help package
On Wed, 2012-03-14 at 16:41 -0700, Anthony Sasadeusz wrote: > 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 Welcome to Fedora development! In case you haven't seen it yet, there's a SIG (special-interest-group) that focuses on Java packaging within Fedora: http://fedoraproject.org/wiki/SIGs/Java so hopefully that page is of interest. (I'm not a member of that SIG, but I know people who are) Good luck, and have fun! Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: coverity 12606 Logically dead code
The previous fix (commit 325abca7135d06225adf5380d726de60dacda5a4) for "Ticket #303 - make DNA range requests work with transactions" introduced this dead code. Since dna_pre_op does not allocate an entry "e", there is no need to check the flag "free_entry" and free it. >From 4e0c70fd1a52d4bc943613bc496751fab2e390c0 Mon Sep 17 00:00:00 2001 From: Noriko Hosoi Date: Thu, 15 Mar 2012 09:17:33 -0700 Subject: [PATCH] coverity 12606 Logically dead code The previous fix (commit 325abca7135d06225adf5380d726de60dacda5a4) for "Ticket #303 - make DNA range requests work with transactions" introduced this dead code. Since dna_pre_op does not allocate an entry "e", there is no need to check the flag "free_entry" and free it. --- ldap/servers/plugins/dna/dna.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/ldap/servers/plugins/dna/dna.c b/ldap/servers/plugins/dna/dna.c index c744e0a..ce2486e 100644 --- a/ldap/servers/plugins/dna/dna.c +++ b/ldap/servers/plugins/dna/dna.c @@ -3214,7 +3214,6 @@ dna_pre_op(Slapi_PBlock * pb, int modtype) char *dn = NULL; Slapi_Mods *smods = NULL; LDAPMod **mods; -int free_entry = 0; int ret = 0; slapi_log_error(SLAPI_LOG_TRACE, DNA_PLUGIN_SUBSYSTEM, @@ -3308,9 +3307,6 @@ dna_pre_op(Slapi_PBlock * pb, int modtype) slapi_mods_free(&smods); } bail: -if (free_entry && e) -slapi_entry_free(e); - if (resulting_e) slapi_entry_free(resulting_e); -- 1.7.7.6 -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please review: coverity 12606 Logically dead code
ack On 03/15/2012 12:22 PM, Noriko Hosoi wrote: > The previous fix (commit 325abca7135d06225adf5380d726de60dacda5a4) > for "Ticket #303 - make DNA range requests work with transactions" > introduced this dead code. Since dna_pre_op does not allocate > an entry "e", there is no need to check the flag "free_entry" and > free it. > > > -- > 389-devel mailing list > 389-de...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[Test-Announce] 2012-03-16 @ 17:00 UTC - F17 Beta Blocker Bug Review #3
# F17 Beta Blocker Review meeting #3 # Date: 2012-03-16 # Time: 17:00 UTC [1] (13:00 EDT, 10:00 PDT - note the DST change) # Location: #fedora-bugzappers on irc.freenode.net I'm sure that everyone is struggling to hold back their excitement but worry not - the next blocker bug review meeting is almost here! The third F17 beta blocker bug review meeting will be this Friday at 17:00 UTC in #fedora-bugzappers. We'll be running through the beta blockers and nice-to-haves. An updated list of blocker bugs is available at: https://fedoraproject.org/wiki/Current_Release_Blockers. We'll be reviewing the bugs to determine ... 1. Whether they meet the beta release criteria [1] and should stay on the list 2. Whether they are getting the attention they need [1] http://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria For guidance on Blocker and Nice-to-have (NTH) bugs, please refer to - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_nth_bug_process For the blocker review meeting protocol, see - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Tim 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
This "karma" stuff is a pain!
Can we just generate "karma" from a comment in bugzilla please? Having to find some other weird place to indicate that a fix "works for me" is a real pain. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 802986] perl-Debug-Client-0.18 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=802986 --- Comment #1 from Petr Pisar 2012-03-15 12:51:23 EDT --- Term::ReadLine::Perl >= 1.0303 is needed for tests. -- 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 802986] perl-Debug-Client-0.18 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=802986 Petr Pisar changed: What|Removed |Added Depends on||803798 -- 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: This "karma" stuff is a pain!
On Thu, Mar 15, 2012 at 11:49 AM, John Ellson wrote: > Can we just generate "karma" from a comment in bugzilla please? Having to > find some other weird place to indicate that a fix "works for me" is a real > pain. Typically the link to the Bodhi update is provided in the BZ. I imagine tighter integration is non-trivial, but I wouldn't be a the one to ask. That would probably be rel-eng, but I'm not positive. -J > John > -- > 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: This "karma" stuff is a pain!
On Thu, 2012-03-15 at 12:04 -0500, Jon Ciesla wrote: > On Thu, Mar 15, 2012 at 11:49 AM, John Ellson wrote: > > Can we just generate "karma" from a comment in bugzilla please? Having to > > find some other weird place to indicate that a fix "works for me" is a real > > pain. > > Typically the link to the Bodhi update is provided in the BZ. I > imagine tighter integration is non-trivial, but I wouldn't be a the > one to ask. That would probably be rel-eng, but I'm not positive. Luke Macken does Bodhi. It certainly sounds non-trivial to me, for a start, Bodhi uses FAS and Bugzilla does not. -- 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: This "karma" stuff is a pain!
Adam Williamson wrote: > Luke Macken does Bodhi. It certainly sounds non-trivial to me, for a > start, Bodhi uses FAS and Bugzilla does not. It would be trivial if these decisions would be made by a human who is CCed on both (i.e. the maintainer of the package) rather than by software. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Debuginfo package for Python-2.7 on F14 mismatched or (l)user error?
Hi Fedorans, we are facing a very strange Python segfault in an OLPC build, based on F14, for XO-1.5 (I know, do you remember _that_ far ago?). The state of the OS and disk is well known, but we cannot make it happen at will. So I got my hands on a coredump, installed the exact same OS (so exact matching disk state as the machine that segfaults, same rpms, etc), and went for http://fedoraproject.org/wiki/StackTraces#Obtaining_a_stack_trace_from_a_core_dump I've yum-installed the matching -debuginfo packages for python, glibc and glib (apparently the segfault is calling glib). Running gdb over the core, it complains: "the .dynamic section for "/usr/lib/python2.7 is not at the expected address", and suggests a yum install (of /usr/lib/debug/.build-id/) that fails. Full error msg from gdb at http://fpaste.org/YqGv/ I can see that some packages have invalid debuginfo subpackages (http://fedoraproject.org/wiki/Packaging:Debuginfo#Useless_or_incomplete_debuginfo_packages_due_to_packaging_issues) , but given Python's importance to the Fedora stack, my bet is that Python's debuginfo is fine, and there's a subtle user error in the middle... To be clear -- we don't suspect Python or the Fedora stack. But something is rotten, and this segfault is the only clue we have. This problem is fairly important for the OLPC team at this time, help on this track appreciated. m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debuginfo package for Python-2.7 on F14 mismatched or (l)user error?
On Thu, 15 Mar 2012 21:18:16 +0100, Martin Langhoff wrote: > we are facing a very strange Python segfault in an OLPC build, based > on F14, for XO-1.5 (I know, do you remember _that_ far ago?). [...] > Full error msg from gdb at http://fpaste.org/YqGv/ All those GDB messages mean your system libraries do not match the core file. Is it a fresh core file from last hours? Is it generated on the same machine you run GDB on? F-14 is EOLed, its repositories incl. debuginfos are out of date, I do not think it matters to spend any time on F-14 at all. Regards, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debuginfo package for Python-2.7 on F14 mismatched or (l)user error?
On Thu, Mar 15, 2012 at 4:58 PM, Jan Kratochvil wrote: > All those GDB messages mean your system libraries do not match the core file. Well, that should just not be. The machine that fails, and my machine have both been installed from the same disk image, which gets written to disk with a process equivalent to dd. And both machines pass rpm -Va just fine. So the binaries should, um, be the same. > Is it a fresh core file from last hours? Is it generated on the same machine > you run GDB on? It is a core from yesterday, on a machine installed from a 'dd' disk image. The machine that fails is exactly on the opposite side of the world. dd'ing the same OS image on my machine doesn't trigger the failure. So there is something funny on the opposite side of the world. > F-14 is EOLed, its repositories incl. debuginfos are out of date Not in this case, at least yum&rpm claim that the debuginfos match. > think it matters to spend any time on F-14 at all. As I stated in my earlier email, I don't want anyone to fix F14, I don't think F14 is to blame. My questions are simpler: - Is python 2.7 debuginfo in F14 known to be good or bad? - If it's known to be good, are there any gotchas not documented in the StackTraces wikipage that could be tripping me up? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debuginfo package for Python-2.7 on F14 mismatched or (l)user error?
On 03/15/2012 01:58 PM, Jan Kratochvil wrote: > On Thu, 15 Mar 2012 21:18:16 +0100, Martin Langhoff wrote: >> we are facing a very strange Python segfault in an OLPC build, based >> on F14, for XO-1.5 (I know, do you remember _that_ far ago?). > [...] >> Full error msg from gdb at http://fpaste.org/YqGv/ > > All those GDB messages mean your system libraries do not match the core file. > > F-14 is EOLed, its repositories incl. debuginfos are out of date, I do not > think it matters to spend any time on F-14 at all. Yes, F-14 is now 1.4 years old, but the situation should not be that bleak. In particular, the mirrors should contain _matching_ packages and debuginfo, and the ordinary install command for a particular debuginfo should succeed. If not, then perhaps a "by-hand" search for the matching debuginfo will succeed. Check the build-id "by hand", too. Search the net for any filename which contains that string. Look at several mirrors of F-14 for your CPU architecture. If manual search fails, then get the source, rebuild the offending package and its debuginfo, install them, re-create the crash, and analyze the new dumps. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debuginfo package for Python-2.7 on F14 mismatched or (l)user error?
Hi John, thanks for the reply - looping back devel@lfo and devel@llo... On Thu, Mar 15, 2012 at 5:14 PM, John Gilmore wrote: > Irreproducible bugs are a real pain. Indeed -- > Try typing "info files" to gdb and see what sections it sees in the > core file and in the executable. I can't make much sense of the output :-/ http://fpaste.org/R457/ > Also, you can run objdump -x on the core file, and on the Python > library, and compare them to see how well the section listings match > up. If the various segments are differently sized, then you clearly > have the wrong debug symbols. > > I also suggest cross-posting to the bug-gdb list, where you'll > find the GDB developers who know how the separate-debug-symbol stuff > works. You might want to make that core file publicly accessible > in case any other developers want to go digging in it. I'll hunt those tracks tmw -- you can see the core file, logs from failing units and more bg info at http://dev.laptop.org/ticket/11698 > Any local Fedora build wizards may know how to find a -debuginfo > package via its build-id. Well, yum should find it ;-) -- but the mystifying thing is yum/rpm seem to have found the right debuginfo file. gdb disagrees. Who's right? > You could also try recompiling python2.7 from its package source, with > debug symbols, ON the machine where you're debugging. The catch... Even if it was reproduceable... I can't make _my_ machine barf. Faraway machines are barfing left and right in mysterious ways, and we are trying to get remote access, etc. But even if I get the remote access, I want to run the currently failing python under gdb, and again we're going to be with mismatched debuginfos. > You may have to debug this without symbols. It looks from your log > like the program counter and/or stack is off in the weeds. Did you > try "bt" to see if any of the stack is accessible? it doesn't look very useful Core was generated by `python /usr/bin/sugar-session'. Program terminated with signal 11, Segmentation fault. #0 0xa7183e2e in ?? () (gdb) bt #0 0xa7183e2e in ?? () #1 0x08f352d0 in ?? () #2 0xa6f0ae57 in ?? () #3 0x08cea354 in ?? () #4 0xa7771878 in ?? () #5 0x in ?? () >> "/usr/lib/python2.7 is not at the expected address", and suggests a > > btw, you mistyped there; the message is about /usr/bin/python2.7, > not /usr/lib/python2.7 (which is a directory). Sorry, you're right. The fpaste url has the actual output at http://fpaste.org/YqGv/ m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F17-alpha: UI unusable
Ok, I don't know what list you want this F17-alpha stuff on but here goes... I downloaded the F17 alpha DVD and installed it on one of my laptops today. I selected Use All Space and Encrypted. At repos I selected Installation Repo and Fedora-i386. Install completed just fine. Boot loader installed and then I rebooted. I created a user account and was able to login to that user account. When the GUI appeared I see Activities on the top left. I click on Activities and see a vertical left menu plus a horizontal menu with tabs Windows | Applications. I scroll through Applications and start a Terminal. All I get is a transparent box with no prompt. I can see an ibeam pointer so I try typing text. Nothing. So next I try to start Firefox. All I get is a blank white box. Can someone point out what is needed here or do I just file bug reports? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17-alpha: UI unusable
On Mar 15, 2012, at 5:20 PM, Gerry Reno wrote: > > Can someone point out what is needed here or do I just file bug reports? I'd suggest installing something more recent, like F17 Beta TC1. http://dl.fedoraproject.org/pub/alt/stage/17-Beta.TC1/ Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17-alpha: UI unusable
Ok, I'll give that a try. Thanks. On 03/15/2012 07:38 PM, Chris Murphy wrote: > On Mar 15, 2012, at 5:20 PM, Gerry Reno wrote: > >> Can someone point out what is needed here or do I just file bug reports? >> > I'd suggest installing something more recent, like F17 Beta TC1. > http://dl.fedoraproject.org/pub/alt/stage/17-Beta.TC1/ > > > > Chris Murphy > > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17-alpha: UI unusable
On Mar 15, 2012, at 5:43 PM, Gerry Reno wrote: > Ok, I'll give that a try. > > Thanks. I suggest netinst.iso or livecd, and enable all the repos in anaconda, so that your installation is current from the first boot. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On Thu, 15 Mar 2012, Dan Williams wrote: The current connectivity checking code is built-but-inactive in F17, you can enable it by adding these entries to /etc/NetworkManager/NetworkManager.conf: [connectivity] uri=http:// interval=120 the URL is expected to return one or both of: 1) an HTTP header named "X-NetworkManager-Status" with the value of "online" 2) an document body consisting only of the text "NetworkManager is online" (can be customized by an option in the config file) This method lets NM (in the future) detect captive portals and will Note that such a scheme has already been setup for other software at: http://fedoraproject.org/static/hotspot.txt It returns "OK" and is guaranteed never to do any redirects, so you can detect hotspots. dnssec-triggerd will use this but we hope this functionality will go into NM itself, so that NM can actually run dnssec-trigger-control commands directly, and incorporate all the gui elements from dnssec-trigger-panel. to understand my babbling, yum install dnssec-trigger, start dnssec-trigger-panel, see "probe", "probe results" and "hotspot mode" I am looking forward to the day that only dnssec-triggerd (or its incorporation into NM) will touch /etc/resolv.conf Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17-alpha: UI unusable
On Thu, 2012-03-15 at 17:45 -0600, Chris Murphy wrote: > On Mar 15, 2012, at 5:43 PM, Gerry Reno wrote: > > > Ok, I'll give that a try. > > > > Thanks. > > I suggest netinst.iso or livecd, and enable all the repos in anaconda, > so that your installation is current from the first boot. And if you still have trouble, it sounds rather like a graphics driver issue, so it would help to know your graphics card. -- 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: F17-alpha: UI unusable
Yeah, installed the beta and I'm still having the exact same problem. Graphics is Geforce FX 5600 On 03/15/2012 09:05 PM, Adam Williamson wrote: > On Thu, 2012-03-15 at 17:45 -0600, Chris Murphy wrote: > >> On Mar 15, 2012, at 5:43 PM, Gerry Reno wrote: >> >> >>> Ok, I'll give that a try. >>> >>> Thanks. >>> >> I suggest netinst.iso or livecd, and enable all the repos in anaconda, >> so that your installation is current from the first boot. >> > And if you still have trouble, it sounds rather like a graphics driver > issue, so it would help to know your graphics card. > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17-alpha: UI unusable
On Thu, 2012-03-15 at 22:22 -0400, Gerry Reno wrote: > Yeah, installed the beta and I'm still having the exact same problem. > > Graphics is Geforce FX 5600 Ah. Then that'll be https://bugzilla.redhat.com/show_bug.cgi?id=745202 . -- 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: F17-alpha: UI unusable
On 03/15/2012 10:30 PM, Adam Williamson wrote: > On Thu, 2012-03-15 at 22:22 -0400, Gerry Reno wrote: > >> Yeah, installed the beta and I'm still having the exact same problem. >> >> Graphics is Geforce FX 5600 >> > Ah. Then that'll be https://bugzilla.redhat.com/show_bug.cgi?id=745202 . > Looks like it. My screen issues are a little bit different but I think it's the same underlying problem: driver issues. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debuginfo package for Python-2.7 on F14 mismatched or (l)user error?
On Thu, 15 Mar 2012 22:31:58 +0100, Martin Langhoff wrote:
> Well, that should just not be. The machine that fails, and my machine
> have both been installed from the same disk image, which gets written
> to disk with a process equivalent to dd.
>
> And both machines pass rpm -Va just fine. So the binaries should, um,
> be the same.
+
> It is a core from yesterday,
There can be difference one of the machines has the files prelink-ed while the
other one does not. prelink runs nightly (/etc/cron.daily/prelink). But it
should be already fixed in your GDB version gdb-7.2-52.fc14, it was fixed in
gdb-7.2-45.fc14 by:
[patch] [i386] Fix {,un}prelinked libraries for attach/core-load
http://sourceware.org/ml/gdb-patches/2011-02/msg00630.html
Still I may have missed some case.
If one of the binaries is prelinked and one was not (or vice verse) the
message "is not at the expected address (wrong library or version mismatch?)"
is really printed (more in the mail above) but the backtrace should work OK.
You can try for the experiment:
/etc/sysconfig/prelink:
# Set this to no to disable prelinking altogether
# (if you change this from yes to no prelink -ua
# will be run next night to undo prelinking)
PRELINKING=no
^^
If it helps please contact me off-list, with your disk image. It assumes the
system generating the core file was not prelinked.
That missing file:
Missing separate debuginfo for
Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install
/usr/lib/debug/.build-id/63/420e48a2edbae61166c708ebd2ff1a5aed1054
is probably for kernel vDSO (as its name is empty), therefore kernel rpm. One
never knows what the build-id matches to until Darkserver gets deployed,
hopefully for F-17:
https://fedoraproject.org/wiki/Darkserver
Thanks,
Jan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
