Re: No Build ID error when building new OpenVZ kernel in FEDORA8
On Thu, 25 Mar 2010 23:50:37 -0600, xinglin wrote: > the error is as following: > "extracting debug info from > /var/tmp/kernel-2.6.18-128.2.1.el5.emulab_openvz_migration-root/usr/src/kernels/2.6.18-128.2.1.el5.emulab_openvz_migration-x86_64/scripts/genksyms/genksyms > extracting debug info from > /var/tmp/kernel-2.6.18-128.2.1.el5.emulab_openvz_migration-root/lib/modules/2.6.18-128.2.1.el5.emulab_openvz_migration/kernel/lib/ts_kmp.ko > *** ERROR: No build ID note found in > /var/tmp/kernel-2.6.18-128.2.1.el5.emulab_openvz_migration-root/lib/modules/2.6.18-128.2.1.el5.emulab_openvz_migration/kernel/lib/ts_kmp.ko > xargs: stat: terminated by signal 13 > error: Bad exit status from /var/tmp/rpm-tmp.5481 (%install) > > > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.5481 (%install)" -bash-3.2$ cd /var/tmp/kernel-2.6.18-128.2.1.el5.emulab_openvz_migration-root/lib/modules/2.6.18-128.2.1.el5.emulab_openvz_migration/kernel/lib/ -bash-3.2$ ls -l total 248K -rwxr--r-- 1 root root 37026 2010-03-26 23:00 crc16.ko -rwxr--r-- 1 root root 37074 2010-03-26 23:00 crc-ccitt.ko -rwxr--r-- 1 root root 37074 2010-03-26 23:00 crc-itu-t.ko drwxr-xr-x 2 root root 4096 2010-03-26 23:00 reed_solomon -rwxr--r-- 1 root root 37509 2010-03-26 23:00 ts_bm.ko -rwxr--r-- 1 root root 39249 2010-03-26 23:00 ts_fsm.ko -rwxr--r-- 1 root root 37262 2010-03-26 23:00 ts_kmp.ko drwxr-xr-x 2 root root 4096 2010-03-26 23:00 zlib_deflate It shows that ts_kmp.ko is created. So probably in that binary file, it does not include a section called .note.gnu.build-id. But the question is why other binaries have included that section? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update testing policy: how to use Bodhi
On Sat, 2010-03-27 at 03:50 +0100, Kevin Kofler wrote: > So I don't think blocking an update outright for having received type 2 > feedback is sane at all. Sigh. That was why I said not to sidetrack the discussion because it was the least important bit of the post. It was just an example of how easily the policy can be adapted. I'm really not interested in thrashing out the tiny details of *that* in *this* thread, that is not what it's for. I had a whole paragraph about the possibility of an override mechanism for maintainers which I left out precisely in order to avoid this kind of discussion, but apparently that wasn't enough... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
Bill Nottingham wrote: > Desktops, yes. Laptops, not really. (Although doing the groups by > form-factors isn't really practical.) Laptops kinda have their builtin UPS, unless you're one of those folks who take out the battery when on AC to save charging cycles. :-) So it would indeed be weird to plug them into an external UPS. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Drop Xorg Nv driver?
On 03/26/2010 08:06 PM, Rahul Sundaram wrote: > Nvidia has announced that they are deprecating it > > http://lists.freedesktop.org/archives/xorg/2010-March/049749.html > > They are recommending users to use Vesa instead as the replacement but > the real reason appears to be Nouveau which Fedora has supported for a > long time now. X developers on linux-kernel list continue to recommend use of nv as a nouveau alternative, when problems with nouveau crop up. As recently as a couple weeks ago... Jeff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Drop Xorg Nv driver?
Hi, Nvidia has announced that they are deprecating it http://lists.freedesktop.org/archives/xorg/2010-March/049749.html They are recommending users to use Vesa instead as the replacement but the real reason appears to be Nouveau which Fedora has supported for a long time now. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update testing policy: how to use Bodhi
On Sat, 2010-03-27 at 00:35 +0100, Mathieu Bridon wrote: > On Sat, Mar 27, 2010 at 00:31, Adam Williamson wrote: > > On Sat, 2010-03-27 at 00:11 +0100, Mathieu Bridon wrote: > >> This is basically what Doug had proposed, except that you added 5. and 6. > > > > Great, glad to hear we're thinking in the same direction from different > > angles :) Do you have a link to his proposal? I don't recall reading it. > > Here it is: >http://lists.fedoraproject.org/pipermail/devel/2010-March/131799.html Oh, yeah, that one. I even replied to it, but it obviously fell prey to my mind-erase of the whole mess of a thread =) in that case, yep, my proposal is more or less just a slight elaboration on Doug's indeed. I may even have subconsciously brought in some elements from Doug's when writing it, so thanks Doug! if you're working in this direction in improving Bodhi, then, from the 'update testing policy' angle, I think I'll just leave it at 'wait and see' for the new Bodhi version. Do you have a vague ETA on when we can expect the improved Bodhi? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update testing policy: how to use Bodhi
On Sat, Mar 27, 2010 at 00:31, Adam Williamson wrote: > On Sat, 2010-03-27 at 00:11 +0100, Mathieu Bridon wrote: >> This is basically what Doug had proposed, except that you added 5. and 6. > > Great, glad to hear we're thinking in the same direction from different > angles :) Do you have a link to his proposal? I don't recall reading it. Here it is: http://lists.fedoraproject.org/pipermail/devel/2010-March/131799.html -- Mathieu Bridon -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update testing policy: how to use Bodhi
On Sat, 2010-03-27 at 00:11 +0100, Mathieu Bridon wrote: > Hi, > > On Fri, Mar 26, 2010 at 23:49, Adam Williamson wrote: > [... snip ...] > > 1. I have tried this update in my regular day-to-day use and seen no > > regressions. > > > > 2. I have tried this update in my regular day-to-day use and seen a > > regression: bug #XX. > > > > 3. (Where the update claims to fix bug #XX) I have tried this update > > and found that it does fix bug #XX. > > > > 4. (Where the update claims to fix bug #XX) I have tried this update > > and found that it does not fix bug #XX. > > > > 5. I have performed the following planned testing on the update: (link > > to test case / test plan) and it passes. > > > > 6. I have performed the following planned testing on the update: (link > > to test case / test plan) and it fails: bug #XX. > > This is basically what Doug had proposed, except that you added 5. and 6. Great, glad to hear we're thinking in the same direction from different angles :) Do you have a link to his proposal? I don't recall reading it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
CVE-2009-2904 - not patched F11 openssh?
Hi, Vulnerability described in CVE-2009-2904 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2904 was addressed in https://rhn.redhat.com/errata/RHSA-2009-1470.html for RHEL. Isn't F11 openssh version also vulnerable? Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update testing policy: how to use Bodhi
Hi, On Fri, Mar 26, 2010 at 23:49, Adam Williamson wrote: [... snip ...] > 1. I have tried this update in my regular day-to-day use and seen no > regressions. > > 2. I have tried this update in my regular day-to-day use and seen a > regression: bug #XX. > > 3. (Where the update claims to fix bug #XX) I have tried this update > and found that it does fix bug #XX. > > 4. (Where the update claims to fix bug #XX) I have tried this update > and found that it does not fix bug #XX. > > 5. I have performed the following planned testing on the update: (link > to test case / test plan) and it passes. > > 6. I have performed the following planned testing on the update: (link > to test case / test plan) and it fails: bug #XX. This is basically what Doug had proposed, except that you added 5. and 6. I know Luke also likes the idea, and I've been toying with implementing Doug's idea in the Bodhi2 branch. Adding those 2 more karma types shouldn't be too hard. >Testers should be able to file multiple types of feedback in one > operation - for instance, 4+1 (the update didn't fix the bug it claimed > to, but doesn't seem to cause any regressions either). Ideally, the > input of feedback should be 'guided' with a freeform element, so there's > a space to enter bug numbers, for instance. That's what I had in mind, but the Bodhi2 branch currently doesn't have any controllers/template, so it will be some time before I have something to show. > I think Bill's proposed policy can be modified quite easily to fit this. > All it would need to say is that for 'important' updates to be accepted, > they would need to have one 'type 1' feedback from a proven tester, and > no 'type 2' feedback from anyone (or something along those lines; this > isn't the main thrust of my post, please don't sidetrack it too > much :>). That's actually one of the points I was missing : rules for (auto-)push / (auto-)unpush. But yeah, it can be agreed on later. > The system could do a count of how many of each type of feedback any > given update has received, but I don't think there's any way we can > sensibly do some kind of mathematical operation on those numbers and > have a 'rating' for the update. Such a system would always give odd / > undesirable results in some cases, I think (just as the current one > does). I believe the above system would be sufficiently clear that there > would be no need for such a number, and we would be able to evaluate > updates properly based just on the information listed. > > What are everyone's thoughts on this? Thanks! I totally agree that this would be far more desirable than the current +1/-1 system. -- Mathieu Bridon -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning greyhounds package
On Sat, Mar 13, 2010 at 15:51:37 -0700, Kevin Fenzi wrote: > I picked up the greyhounds package a while back because it was a fun > game (and I have greyhounds :) > > Sadly however, I am going to orphan it again due to: For now I have grabbed this, but might orphan it again later. If someone more motivated wants to take it let me know. I'll still hang on as an extra maintainer if you do. > > - Upstream is completely dead. I have gotten no response to lists/forum > posts anything. And the last release was almost 2 years ago. I am not in a position to take over upstream. I am already trying to do this for chess and need more time for that. > - It currently fails to build from source due to the recent DSO > changes: https://bugzilla.redhat.com/show_bug.cgi?id=565040 This was pretty easy to fix and I'll commit something soon. -lm needed to get added to a line in src/Makefile.am and src/Makefile.in. Since upstream is dead, there won't be any point in trying to get the Makefile.am patch upstream. > - If currently crashes due to poor coding: > https://bugzilla.redhat.com/show_bug.cgi?id=562038 > (basically trying to reload a saved game makes it crash). I haven't looked at this yet, but will take a quick look at it to see if it is something obvious. > - I just don't have the time to fix it up. ;( > > So, if anyone would like to take it over, feel free. > > kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Update testing policy: how to use Bodhi
Hi, folks. At the last QA meeting, I volunteered (dumb of me!) to draft a policy for testing updates - basically, a policy for what kind of feedback should be posted in Bodhi for candidate updates. This turns out to be pretty hard. =) Thinking about it from an high-level perspective like this, I think it becomes pretty clear that the current system is just broken. The major problem is it attempts to balance things that don't really balance. It lets you say 'works for me' or 'doesn't work' and then sums the two and subtracts the second from the first to give you a 'rating' for the update. This doesn't really mean anything. As has been rehashed many times, there are situations where an update with a positive rating shouldn't go out, and situations where an update with a negative rating should. So the current system isn't really that great. I can't think of a way to draft a policy to guide the use of the current system in such a way that it will be really reliable. I think it'd be much more productive to revise the Bodhi feedback system alongside producing a policy. So, here's a summary of what the new system should aim for. At the high level, what is this system for? It's there for three purposes: 1) to provide maintainers with information they can use in deciding whether to push updates. 2) to provide a mechanism for mandating a certain minimum level of manual testing for 'important' packages, under Bill Nottingham's current update acceptance criteria proposal. 3) to provide an 'audit trail' we can use to look back on how the release of a particular update was handled, in the case where there are problems. Given the above, we need to capture the following types of feedback, as far as I can tell. I don't think there is any sensible way to assign numeric values to any of this feedback. I think we have to trust people to make sensible decisions as long as it's provided, in accordance with any policy we decide to implement on what character updates should have. 1. I have tried this update in my regular day-to-day use and seen no regressions. 2. I have tried this update in my regular day-to-day use and seen a regression: bug #XX. 3. (Where the update claims to fix bug #XX) I have tried this update and found that it does fix bug #XX. 4. (Where the update claims to fix bug #XX) I have tried this update and found that it does not fix bug #XX. 5. I have performed the following planned testing on the update: (link to test case / test plan) and it passes. 6. I have performed the following planned testing on the update: (link to test case / test plan) and it fails: bug #XX. Testers should be able to file multiple types of feedback in one operation - for instance, 4+1 (the update didn't fix the bug it claimed to, but doesn't seem to cause any regressions either). Ideally, the input of feedback should be 'guided' with a freeform element, so there's a space to enter bug numbers, for instance. There is one type of feedback we don't really want or need to capture: "I have tried this update and it doesn't fix bug #XX", where the update doesn't claim to fix that bug. This is a quite common '-1' in the current system, and one we should eliminate. I think Bill's proposed policy can be modified quite easily to fit this. All it would need to say is that for 'important' updates to be accepted, they would need to have one 'type 1' feedback from a proven tester, and no 'type 2' feedback from anyone (or something along those lines; this isn't the main thrust of my post, please don't sidetrack it too much :>). The system could do a count of how many of each type of feedback any given update has received, but I don't think there's any way we can sensibly do some kind of mathematical operation on those numbers and have a 'rating' for the update. Such a system would always give odd / undesirable results in some cases, I think (just as the current one does). I believe the above system would be sufficiently clear that there would be no need for such a number, and we would be able to evaluate updates properly based just on the information listed. What are everyone's thoughts on this? Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning greyhounds package
On Fri, Mar 26, 2010 at 14:34:56 -0600, Kevin Fenzi wrote: > On Fri, 26 Mar 2010 14:28:02 -0500 > Bruno Wolff III wrote: > > > On Sat, Mar 13, 2010 at 15:51:37 -0700, > > Kevin Fenzi wrote: > > > > > > - It currently fails to build from source due to the recent DSO > > > changes: https://bugzilla.redhat.com/show_bug.cgi?id=565040 > > > > I'll take a look at that as part of my engineering servies work. I > > can't really volunteer to be the maintainer (at least not primary) > > for a package without an active upstream as I already have a lot to > > do. > > Well, feel free... but that will only get it building. The real bad bug > here is that you can't ever load a saved game. ;) I might take a quick look at that as well. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning greyhounds package
On Fri, 26 Mar 2010 14:28:02 -0500 Bruno Wolff III wrote: > On Sat, Mar 13, 2010 at 15:51:37 -0700, > Kevin Fenzi wrote: > > > > - It currently fails to build from source due to the recent DSO > > changes: https://bugzilla.redhat.com/show_bug.cgi?id=565040 > > I'll take a look at that as part of my engineering servies work. I > can't really volunteer to be the maintainer (at least not primary) > for a package without an active upstream as I already have a lot to > do. Well, feel free... but that will only get it building. The real bad bug here is that you can't ever load a saved game. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal
On Fri, 2010-03-26 at 16:13 +, Terry Barnaby wrote: > > > > This isn't really true. Or at least, not a productive perspective for > > improving Fedora. There are certainly a lot of bugs in the open drivers > > shipped with Fedora, and there's a lot of work to do to fix them all. I > > sent my own reply to Terry explaining how we're handling this at > > present, but just waving the 'it's all NVIDIA's fault' stick at the > > problem won't make it go away :) > > One little point I noticed recently. I was watching and testing > a package released by Fedora. I was having some email conversations with > some of the upstream developers of that package at the time. > > From what I noticed, there did not seem to be much communication between > the Fedora packagers and the upstream developers. Particularly > the upstream developers appeared to be unaware that their code had been > packaged > for Fedora/Redhat etc. In fact they were looking at creating > a binary release and looking at how to test it on various platforms. > > I don't know if this is an isolated case, but if it is common maybe: Not in the case of graphics, no. In most cases, the 'upstream developers' and Fedora packagers, as far as X.org goes, are the same people. Where this isn't the case, they're in very close contact. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fedora-r-devel-list] R2rpm call for tester
On Fri, 2010-03-26 at 19:50 +, José Matos wrote:
> > For the rest, does it work properly for you ?
>
> OK, I am catching on all the mail after a busy week. I have not yet tried to
> apply the latest version 0.3 here are my comments from previous versions.
>
> I had to use the following patch.
>
> Some notes on the elements of the diff:
>
> * emacs refuses to address the UTF-8 encoding it only recognizes utf-8. That
> is why I have changed it for every file I had to edit.
Ok I will fix this.
> * in R2spec I have the following snippet:
> -self.version = self.file['version']
> +self.version = self.file['version'].replace("-",".")
This should be fixed already in Description.py
> * in RPackage.py I have delegated to rpm the interpretation of rpm macros
> using a pipe. The only exception to this rule is the %{name} macro that is
> not
> set at that time.
This looks much nicer than the dirty solution I was using :-)
> Other than those issues pointed the package works really well, it is nice to
> set back and watch it do all the work. :-)
Cool :-)
FYI, I am playing with R2rpm on cran and I have:
$ ll rpmbuild/SRPMS/R-* |wc -l
857
I think I'll be looking for space for a repo and a i686 builder :-)
Thanks again,
Pierre
___
r-devel mailing list
r-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/r-devel
Re: Status of Fedora 13 Feature: EasierPythonDebugging
On Thu, 2010-03-25 at 19:35 -0400, David Malcolm wrote: > (b) the critically important frame information within the heart of the > bytecode excution loop ought to tell us what code we're running, but is > showing up in gdb as "optimized out". (specifically, the "f" parameter > to function PyEval_EvalFrameEx). > > Unfortunately, this greatly reduces the effectiveness of the feature > (it's still somewhat useful without this, but the feature page would > need a significant rewrite if this doesn't get fixed). > > This looks like a regression of rhbz:556975: > https://bugzilla.redhat.com/show_bug.cgi?id=556975 > > I don't know if this is a gcc/gdb/python issue. > > I've reopened this bug. I haven't yet added it to any of the tracker > bugs: http://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers > > Which tracker should this be in? This is a tricky question. We haven't really answered the question yet of whether bugs impacting the implementation of accepted features for a release should be treated as release blockers; so far we've worked strictly on the basis of the release criteria, which are more about whether the release meets certain targets for quality, more or less regardless of the deeper functionality of the software it contains. I'm not sure it's a super-simple question to answer. The classic question to ask about a proposed blocker bug is 'would we delay the release if this was the only bug in it?', and that's a tough question to answer in the context of something which is essentially an RFE, and one which can be fixed post-release without really causing anyone any significant pain. So the short answer is that at present, we - by 'we' I mean the qa/releng folks who mostly do the release shepherding process - wouldn't consider this bug to be a candidate for F13Beta or F13Blocker. You could put it on F13Target, but the Target tracker has its own problems at present, the short version of which is that basically everyone ignores it. So go ahead, but it likely will have little practical impact... There's obviously space to improve the process here. There may well be space for a dedicated tracker for bugs affecting the implementation of planned features. What various groups - qa, releng, devel - would *do* with such a tracker is also an open question. Ideas? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fedora-r-devel-list] R2rpm call for tester
On Tuesday 23 March 2010 14:12:36 Pierre-Yves wrote:
> > > If I am not asking too much it would be nice if r2rpm could fetch the
> > > sources directly from CRAN if we pass only the package name (or with a
> > > special option for that matter).
> >
> > I have this idea in my mind for some time, I will look into this :-)
>
> Ok this is implemented in the new release (0.2)
> sources:
> https://fedorahosted.org/releases/r/2/r2spec/R2spec-3.0.0pre2.tar.gz
> src.rpm:
> https://fedorahosted.org/releases/r/2/r2spec/R2spec-3.0.0-0.2.fc12.src.rpm
> rpm:
> https://fedorahosted.org/releases/r/2/r2spec/R2spec-3.0.0-0.2.fc12.noarch.r
> pm
>
> As you see I changed the release number so I believe rpm will complain.
>
> The -p option works for cran, bioconductor and the
> r-forge.r-project.org.
>
> I'll look into %{_specdir} and %{_sourcedir} for the release 0.3 ;-)
>
> For the rest, does it work properly for you ?
OK, I am catching on all the mail after a busy week. I have not yet tried to
apply the latest version 0.3 here are my comments from previous versions.
I had to use the following patch.
Some notes on the elements of the diff:
* emacs refuses to address the UTF-8 encoding it only recognizes utf-8. That
is why I have changed it for every file I had to edit.
* in R2spec I have the following snippet:
-self.version = self.file['version']
+self.version = self.file['version'].replace("-",".")
The purpose as we have discussed before is to harmonize the versions used
where in R the - (dash?) and point are equal as far as the package version is
concerned.
As you can imagine I got an error with a package that has this version.
(mAr_1.1-2.tar.gz)
It would be easier to coerce the author to change the name but this only works
for my wife, not necessarily for all the other R packages authors. :-)
* in RPackage.py I have delegated to rpm the interpretation of rpm macros
using a pipe. The only exception to this rule is the %{name} macro that is not
set at that time.
> Thanks for the feed back,
>
> Pierre
Other than those issues pointed the package works really well, it is nice to
set back and watch it do all the work. :-)
--
José Abílio
diff --git a/devel/r2spec/Build.py b/devel/r2spec/Build.py
index 9dfe578..da42c29 100644
--- a/devel/r2spec/Build.py
+++ b/devel/r2spec/Build.py
@@ -1,4 +1,4 @@
-#-*- coding: UTF-8 -*-
+#-*- coding: utf-8 -*-
#***
# R2rpm
diff --git a/devel/r2spec/Description.py b/devel/r2spec/Description.py
index bdc1b77..eaeab70 100644
--- a/devel/r2spec/Description.py
+++ b/devel/r2spec/Description.py
@@ -1,4 +1,4 @@
-#-*- coding: UTF-8 -*-
+#-*- coding: utf-8 -*-
#**
# R2spec
@@ -31,7 +31,7 @@ class Description:
''' Set the version of the package '''
# Retrieve the Version number
try:
-self.version = self.file['version']
+self.version = self.file['version'].replace("-",".")
except KeyError, err:
print "No version set"
self.version = ""
diff --git a/devel/r2spec/R2rpm.py b/devel/r2spec/R2rpm.py
index 60bc994..7f1735c 100644
--- a/devel/r2spec/R2rpm.py
+++ b/devel/r2spec/R2rpm.py
@@ -1,4 +1,4 @@
-#-*- coding: UTF-8 -*-
+#-*- coding: utf-8 -*-
#***
# R2rpm
@@ -61,11 +61,9 @@ class R2rpm:
# Generate the spec file
r = RPackage()
-specdir = r.getRPMTopDirectory()
-if specdir != None:
-os.chdir(specdir + "/SPECS/")
# Enforce the copyfile and the force option
specname = R2spec().main(source, url, bioc, cran, rforge, rproject, True, name, email, True)
+specdir = r.getRPMTopDirectory("_specdir", specname)
specname = specname + ".spec"
self.build.append(specname)
diff --git a/devel/r2spec/RPackage.py b/devel/r2spec/RPackage.py
index 7526aa8..69c34d8 100644
--- a/devel/r2spec/RPackage.py
+++ b/devel/r2spec/RPackage.py
@@ -1,4 +1,4 @@
-#-*- coding: UTF-8 -*-
+#-*- coding: utf-8 -*-
#**
# R2spec
@@ -14,6 +14,7 @@
from Packager import *
from Description import *
from Spec import *
+from subprocess import Popen, PIPE
import os, sys, re, datetime
@@ -247,28 +248,27 @@ class RPackage:
spec.writeSpec(specname)
spec.writeOut()
-def getRPMTopDirectory(self):
-try:
-f = open(os.path.expanduser("~")+"/.rpmmacros", "r")
-rpm = f.read()
-f.close()
-try:
-topdir = re.compile('%_topdir(.*)').findall(rpm)[0].strip()
-topdir = topdir.replace('%(echo $HOME)', os.path.expanduser("~"))
-except IndexError, err:
-print 'No %_topdir defined in ~/.rpmmacros'
-topdir = None
-except IOError, err:
-print 'Cannot read the file .rpmmac
httpd vulnerability - new build?
In view of http://www.securityfocus.com/bid/38580 is there a chance that httpd version 2.2.15 will be built for f13/f12? Thanks -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning greyhounds package
On Sat, Mar 13, 2010 at 15:51:37 -0700, Kevin Fenzi wrote: > > - It currently fails to build from source due to the recent DSO > changes: https://bugzilla.redhat.com/show_bug.cgi?id=565040 I'll take a look at that as part of my engineering servies work. I can't really volunteer to be the maintainer (at least not primary) for a package without an active upstream as I already have a lot to do. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Sendmail 8.14.4 for f12?
On Fri, Mar 26, 2010 at 10:11 AM, Jaroslav Skarvada wrote: > Yes, I will build for f12, f11 > > regards > > Jaroslav Great - thanks Jaroslav -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libgcj or usermode-gtk bug?
On Fri, Mar 26, 2010 at 01:10:16PM -0400, Bill Nottingham wrote: > Matt Domsch (matt_dom...@dell.com) said: > > Which package is throwing this then? the latter I expect... > > Neither, it's java-1.5.0-gcj: https://bugzilla.redhat.com/show_bug.cgi?id=577350 -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Release Engineering meeting summary for 2010-03-26
Minutes:http://meetbot.fedoraproject.org/fedora- meeting/2010-03-26/fedora-releng.2010-03-26-17.36.html Minutes (text): http://meetbot.fedoraproject.org/fedora- meeting/2010-03-26/fedora-releng.2010-03-26-17.36.txt Log:http://meetbot.fedoraproject.org/fedora- meeting/2010-03-26/fedora-releng.2010-03-26-17.36.log.html Meeting summary --- * roll call (Oxf13, 17:36:57) * present are lmacken notting oxf13 (Oxf13, 17:39:45) * regrets jwb (Oxf13, 17:39:48) * Beta! (Oxf13, 17:39:55) * LINK: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test and https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test have the test results (Oxf13, 17:40:45) * rdieter and dgilmore also present (Oxf13, 17:43:17) * Installs don't do multilib, so why put multilib packages on media? (Oxf13, 17:46:09) * ACTION: Oxf13 to look at how difficult it would be to stop doing multilib on media (Oxf13, 17:46:23) * Open Floor (Oxf13, 17:54:47) Meeting ended at 18:13:50 UTC. Action Items * Oxf13 to look at how difficult it would be to stop doing multilib on media signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-13 Branched report: 20100326 changes
Compose started at Fri Mar 26 09:15:05 UTC 2010
Broken deps for i386
--
gnome-web-photo-0.9-4.fc13.i686 requires gecko-libs = 0:1.9.2.1
hornsey-1.5.2-0.1.fc13.i686 requires libclutter-gst-0.10.so.0
libnodeupdown-backend-openib-1.9-5.fc13.i686 requires
libosmcomp.so.3(OSMCOMP_2.3)
libnodeupdown-backend-openib-1.9-5.fc13.i686 requires libosmcomp.so.3
pyclutter-gst-0.9.2-1.fc12.i686 requires libclutter-gst-0.10.so.0
sepostgresql-8.4.2-2488.fc13.i686 requires postgresql-server = 0:8.4.2
totem-youtube-2.29.92-1.fc13.i686 requires libgdata.so.7
zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2
Broken deps for x86_64
--
gnome-web-photo-0.9-4.fc13.x86_64 requires gecko-libs = 0:1.9.2.1
hornsey-1.5.2-0.1.fc13.x86_64 requires libclutter-gst-0.10.so.0()(64bit)
libnodeupdown-backend-openib-1.9-5.fc13.x86_64 requires
libosmcomp.so.3(OSMCOMP_2.3)(64bit)
libnodeupdown-backend-openib-1.9-5.fc13.x86_64 requires
libosmcomp.so.3()(64bit)
pyclutter-gst-0.9.2-1.fc12.x86_64 requires
libclutter-gst-0.10.so.0()(64bit)
sepostgresql-8.4.2-2488.fc13.x86_64 requires postgresql-server = 0:8.4.2
totem-youtube-2.29.92-1.fc13.x86_64 requires libgdata.so.7()(64bit)
zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2
New package curblaster
Sidescrolling shooter, carry the pods through the gate
New package fedora-remix-logos
Fedora Remix logos
New package ibus-table-code
The code tables for IBus-Table
New package ibus-table-latin
The Latin tables for IBus-Table
New package perl-App-cpanminus
Library for get, unpack, build and install CPAN modules
Updated Packages:
GConf2-2.28.0-10.fc13
-
* Thu Mar 18 2010 Tom "spot" Callaway 2.28.0-10
- own /var/lib/rpm-state/ too
arts-1.5.10-12.fc13
---
* Wed Mar 24 2010 Kevin Kofler - 8:1.5.10-12
- don't call snd_pcm_close(NULL), triggers assertion failure in ALSA (#558570)
autofs-5.0.5-23.fc13
* Thu Mar 25 2010 Ian Kent - 1:5.0.5-23.fc13
- fix add locality as valid ldap master map attribute (bz575863).
bibus-1.5.1-2.fc13
--
* Mon Mar 08 2010 Alex Lancaster - 1.5.1-2
- Disable debuginfo package (#547493)
blam-1.8.7-1.fc13
-
* Wed Mar 24 2010 Alex Lancaster - 1.8.7-1
- Update from ancient 1.8.5 to upstream 1.8.7
- Uses webkit rather than gecko by default
- Drop unused patches (seem to be applied upstream) and cleanup spec
- Hopefully fixes #575583
* Tue Mar 23 2010 Jan Horak - 1.8.5-23
- Rebuild against newer gecko
dbus-1.2.22-2.fc13
--
* Mon Mar 22 2010 Colin Walters - 1:1.2.22-2
- Add patch to fix syslog crasher
* Wed Mar 17 2010 Colin Walters - 1:1.2.22-1
- New upstream release
debootstrap-1.0.22-1.fc13
-
* Fri Mar 05 2010 Jan Zeleny - 1.0.22-1
- rebased to 1.0.22
ejabberd-2.1.3-5.fc13
-
* Thu Mar 18 2010 Peter Lemenkov 2.1.3-5
- Init-script fixed
* Thu Mar 18 2010 Peter Lemenkov 2.1.3-4
- Really fix issue with "File operation error: eacces".
* Thu Mar 18 2010 Peter Lemenkov 2.1.3-3
- Relax access rights of /usr/sbin/ejabberdctl (from 0550 to 0755)
- Invoke symlinked consolehelper instead of /usr/sbin/ejabberdctl
in init-script
- Fixed "File operation error: eacces" issue. See rhbz #564686.
* Thu Mar 18 2010 Peter Lemenkov 2.1.3-2
- Init-script enhancements
* Fri Mar 12 2010 Peter Lemenkov 2.1.3-1
- Ver. 2.1.3
- Patches rebased
* Fri Mar 05 2010 Peter Lemenkov 2.1.2-4
- Fixed issue with {erorr,nxdomain}
* Tue Feb 16 2010 Peter Lemenkov 2.1.2-3
- Do not try to backup DB on every fresh install
- Do not force copying old erlang cookie file
- Add missing release notes for ver. 2.1.2
- Require erlang-esasl for krb5 support
- No such %configure option - --enable-debug
- Patches were rebased and renumbered
- Add new BR util-linux(-ng)
emacs-23.1-26.fc13
--
* Fri Mar 19 2010 Jonathan G. Underwood -
1:23.1-26
- Fix broken byte compilation of emacs2.py and emacs3.py with the relevant
python binaries - requires turning off brp-python-bytecompile script
* Mon Mar 15 2010 Jonathan G. Underwood -
1:23.1-25
- Add --eval '(progn (setq load-path (cons "." load-path)))' to byte
compilation macro for packaging add-ons
* Tue Feb 09 2010 Karel Klic 1:23.1-24
- Added a comment about alternatives(8) in %posttrans to the spec file
eric-4.4.2-1.fc13
-
* Sat Mar 06 2010 Johan Cwiklinski 4.4.2-1
- 4.4.2
fedora-release-13-0.7
-
* Mon Mar 22 2010 Jesse Keating - 13-0.7
- Update the release name
glib2-2.23.6-1.fc13
---
* Mon Mar 22 2010 Matthias Clasen - 2.23.6-1
- Update to 2.23.6
gnome-icon-theme-2.29.2-3.fc13
-
Re: Stable Release Updates types proposal
On 03/26/2010 10:26 PM, Till Maas wrote: > On Fri, Mar 26, 2010 at 09:55:19PM +0530, Rahul Sundaram wrote: > > >> http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Inform_Upstream >> >> I sometimes forget as well and not surprised there would be instances >> where upstream is not informed. >> > You added the section about informing upstream about half a year ago, > therefore I guess the majority of package maintainer did not do this. I > know I never did this, unless they already list other distributions or I > had to send a patch. > I had assumed that it would be a obvious thing to do before that. Isn't that the case? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal
* Till Maas [26/03/2010 18:00] : > > You added the section about informing upstream about half a year ago, > therefore I guess the majority of package maintainer did not do this. I > know I never did this, unless they already list other distributions or I > had to send a patch. I've always done this (although I suppose a number of packages have fallen through the cracks), even before that section was there. Interestingly enough, the first upstream I informed replied that I was the first packager to do so despite the fact that his work was already featured in a number of distributions. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libgcj or usermode-gtk bug?
Matt Domsch (matt_dom...@dell.com) said:
> Which package is throwing this then? the latter I expect...
Neither, it's java-1.5.0-gcj:
$ rpm -q --triggers java-1.5.0-gcj-1.5.0.0-30.fc13.x86_64
triggerin scriptlet (using /bin/sh) -- libgcj >= 4.1.2-5
{
GIJ_VERSION=$(gij --version | head -n 2 | tail -n 1 \
| awk '{ print $5 }')
# jaxp_parser_impl
alternatives --install /usr/share/java/jaxp_parser_impl.jar \
jaxp_parser_impl \
/usr/share/java/libgcj-$GIJ_VERSION.jar 20
# rt.jar
RELATIVE=$(/usr/bin/perl -e 'use File::Spec; print
File::Spec->abs2rel($ARGV[0], $ARGV[1])' /usr/share/java
/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib)
ln -sf \
$RELATIVE/libgcj-$GIJ_VERSION.jar \
/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/rt.jar
# libjawt.so
RELATIVE=$(/usr/bin/perl -e 'use File::Spec; print
File::Spec->abs2rel($ARGV[0], $ARGV[1])' /usr/lib64/gcj-$GIJ_VERSION \
/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/x86_64)
ln -sf $RELATIVE/libjawt.so \
/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/x86_64/libjawt.so
# libjvm.so
RELATIVE=$(/usr/bin/perl -e 'use File::Spec; print
File::Spec->abs2rel($ARGV[0], $ARGV[1])' /usr/lib64/gcj-$GIJ_VERSION \
/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/x86_64/client)
ln -sf $RELATIVE/libjvm.so \
/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/x86_64/client/libjvm.so
RELATIVE=$(/usr/bin/perl -e 'use File::Spec; print
File::Spec->abs2rel($ARGV[0], $ARGV[1])' /usr/lib64/gcj-$GIJ_VERSION \
/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/x86_64/server)
ln -sf $RELATIVE/libjvm.so \
/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/x86_64/server/libjvm.so
} || :
Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
libgcj or usermode-gtk bug?
Doing a 'yum upgrade' from F12 to F13 today, I get this: Updating : libgcj-4.4.3-8.fc13.x86_64 604/2235 Can't locate File/Spec.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/local/share/perl5 /usr/lib64/perl5 /usr/share/perl5 /usr/share/perl5 /usr/lib64/perl5 /usr/share/perl5 /usr/local/lib64/perl5/site_perl/5.10.0/x86_64-linux-thread-multi /usr/local/lib/perl5/site_perl/5.10.0 /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/site_perl .) at -e line 1. BEGIN failed--compilation aborted at -e line 1. Can't locate File/Spec.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/local/share/perl5 /usr/lib64/perl5 /usr/share/perl5 /usr/share/perl5 /usr/lib64/perl5 /usr/share/perl5 /usr/local/lib64/perl5/site_perl/5.10.0/x86_64-linux-thread-multi /usr/local/lib/perl5/site_perl/5.10.0 /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/site_perl .) at -e line 1. BEGIN failed--compilation aborted at -e line 1. Can't locate File/Spec.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/local/share/perl5 /usr/lib64/perl5 /usr/share/perl5 /usr/share/perl5 /usr/lib64/perl5 /usr/share/perl5 /usr/local/lib64/perl5/site_perl/5.10.0/x86_64-linux-thread-multi /usr/local/lib/perl5/site_perl/5.10.0 /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/site_perl .) at -e line 1. BEGIN failed--compilation aborted at -e line 1. Can't locate File/Spec.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/local/share/perl5 /usr/lib64/perl5 /usr/share/perl5 /usr/share/perl5 /usr/lib64/perl5 /usr/share/perl5 /usr/local/lib64/perl5/site_perl/5.10.0/x86_64-linux-thread-multi /usr/local/lib/perl5/site_perl/5.10.0 /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/site_perl .) at -e line 1. BEGIN failed--compilation aborted at -e line 1. Updating : usermode-gtk-1.104.1-1.fc13.x86_64 605/2235 Which package is throwing this then? the latter I expect... Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
Chris Adams (cmad...@hiwaay.net) said: > Not commenting on the naming, but I'd put UPS tools on desktops as well. > Lots of people have UPSes attached to home computers, while I only have > a single server monitoring an UPS (datacenter with a big UPS and > generator, the monitoring is just for Nagios to tell us if there's a > problem). Desktops, yes. Laptops, not really. (Although doing the groups by form-factors isn't really practical.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal
On Fri, Mar 26, 2010 at 09:55:19PM +0530, Rahul Sundaram wrote: > http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Inform_Upstream > > I sometimes forget as well and not surprised there would be instances > where upstream is not informed. You added the section about informing upstream about half a year ago, therefore I guess the majority of package maintainer did not do this. I know I never did this, unless they already list other distributions or I had to send a patch. Regards Till pgpjZuS9P5wca.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal
On 03/26/2010 09:43 PM, Terry Barnaby wrote: >> This isn't really true. Or at least, not a productive perspective for >> improving Fedora. There are certainly a lot of bugs in the open drivers >> shipped with Fedora, and there's a lot of work to do to fix them all. I >> sent my own reply to Terry explaining how we're handling this at >> present, but just waving the 'it's all NVIDIA's fault' stick at the >> problem won't make it go away :) >> > One little point I noticed recently. I was watching and testing > a package released by Fedora. I was having some email conversations with > some of the upstream developers of that package at the time. > > >From what I noticed, there did not seem to be much communication between > the Fedora packagers and the upstream developers. > That is unlikely to be the general case. You seem to be extrapolating from a single instance. Fedora on the whole has a policy to work closely with upstream. http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Inform_Upstream I sometimes forget as well and not surprised there would be instances where upstream is not informed. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning kadu
Julian Sikorski wrote: > You need to orphan F-12 and devel as well. Done. When I sent my previous mail I was not able to do it because I got all the time "Request failure" message. Regards, Dawid -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal
> > This isn't really true. Or at least, not a productive perspective for > improving Fedora. There are certainly a lot of bugs in the open drivers > shipped with Fedora, and there's a lot of work to do to fix them all. I > sent my own reply to Terry explaining how we're handling this at > present, but just waving the 'it's all NVIDIA's fault' stick at the > problem won't make it go away :) One little point I noticed recently. I was watching and testing a package released by Fedora. I was having some email conversations with some of the upstream developers of that package at the time. >From what I noticed, there did not seem to be much communication between the Fedora packagers and the upstream developers. Particularly the upstream developers appeared to be unaware that their code had been packaged for Fedora/Redhat etc. In fact they were looking at creating a binary release and looking at how to test it on various platforms. I don't know if this is an isolated case, but if it is common maybe: 1. The upstream developers email addresses or mailing list could be added to an email list on the package in the FedoraBuild system. 2. When a package is submitted for testing then an email and possibly other communications is made between the packager and the upstream developers with the suggestion that the package has been built for testing. 3. All RPM fixes required are emailed back to upstream developers. It seems to me that it would be good if the upstream developers knew of the package and were encouraged to test it. They are most likely to find any initial obvious issues. Cheers Terry -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How is Fedora non-american keyboard support for you?
On Fri, Mar 26, 2010 at 05:21, Orcan Ogetbil wrote: > Then I discovered an .rpmnew file in /etc > (sorry I forgot what it was but it was about layouts). I guess that an > old configuration file was kept in /etc when the keyboard layout > software (what is it?) got updated, and the old configuration file was > not compatible with the new software. I wish this was tested before it > gets pushed to stable. I had the same problem and using the rpmnew file fixed it for me too. I think that was at F11. Christof -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How is Fedora non-american keyboard support for you?
nodata wrote: > I use a German keyboard on all of my machines. Once or twice a year a > bug comes along in Fedora that breaks that and I'm stuck with an > American keyboard and system-config-keyboard to change it back again. I had a problem like that some time several releases ago, but it doesn't happen once a year to me. Björn Persson 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: Linker trouble
On Fri, 2010-03-26 at 06:38 +0100, Lubomir Rintel wrote: > Hi, > > I'm wondering if anyone could enlighten me about why does --as-needed > make a difference here? (let alone the order in which -lGL appears). Because order matters. Linker arguments are positional. Object files are walked left to right along the command line, and are added to the link in order. Archive members are added to the link output if and only if a symbol in that archive member satisfies a reference to a symbol mentioned earlier in the link. --as-needed extends this behaviour to DSOs, such that libraries will only be added to the link if they satisfy a symbol reference from an earlier object. So in your first link line: > [lkund...@localhost VirtualBox-3.1.6_OSE]$ g++ -Wl,--as-needed \ > > -o out/linux.x86/release/obj/VBoxTestOGL/VBoxTestOGL \ > > out/linux.x86/release/obj/VBoxTestOGL/generic/OpenGLTestApp.o \ > > -L/usr/X11R6/lib -L/usr/lib \ > > -lGL \ > > obj/lib/VBoxOGLhostspuload.a obj/bin/VBoxOGLhostcrutil.so > > obj/lib/VBoxOGL2D.a \ > > obj/bin/VBoxRT.so obj/bin/VBoxRT.so obj/lib/VBoxREM.so > > obj/bin/VBoxVMM.so \ > > -lXcursor -lXext -lX11 \ > > obj/lib/VBoxCOM.a obj/bin/VBoxXPCOM.so \ > > /usr/lib/libQtCore.so /usr/lib/libQtGui.so /usr/lib/libQtOpenGL.so OpenGLTestApp.o is added. libGL is looked at, but not added, since the first .o (presumably) doesn't mention any symbol defined in libGL. Later you add the VBoxOGL2D.a archive; VBoxGLSupportInfo.o provides some symbol that one of the earlier objects needs, but adds references to symbols that happen to be defined in libGL. At no point later do you mention libGL again. [1] Therefore: > /usr/bin/ld: obj/lib/VBoxOGL2D.a(VBoxGLSupportInfo.o): undefined reference to > symbol 'glGetString' Whereas: > [lkund...@localhost VirtualBox-3.1.6_OSE]$ g++ -Wl,--as-needed \ > > -o out/linux.x86/release/obj/VBoxTestOGL/VBoxTestOGL \ > > out/linux.x86/release/obj/VBoxTestOGL/generic/OpenGLTestApp.o \ > > -L/usr/X11R6/lib -L/usr/lib \ > > obj/lib/VBoxOGLhostspuload.a obj/bin/VBoxOGLhostcrutil.so > > obj/lib/VBoxOGL2D.a \ > > -lGL \ > > obj/bin/VBoxRT.so obj/bin/VBoxRT.so obj/lib/VBoxREM.so > > obj/bin/VBoxVMM.so \ > > -lXcursor -lXext -lX11 \ > > obj/lib/VBoxCOM.a obj/bin/VBoxXPCOM.so \ > > /usr/lib/libQtCore.so /usr/lib/libQtGui.so /usr/lib/libQtOpenGL.so Here you link libGL _after_ an archive that requires it, so it's included. And: > [lkund...@localhost VirtualBox-3.1.6_OSE]$ g++ \ > > -o out/linux.x86/release/obj/VBoxTestOGL/VBoxTestOGL \ > > out/linux.x86/release/obj/VBoxTestOGL/generic/OpenGLTestApp.o \ > > -L/usr/X11R6/lib -L/usr/lib \ > > -lGL \ > > obj/lib/VBoxOGLhostspuload.a obj/bin/VBoxOGLhostcrutil.so > > obj/lib/VBoxOGL2D.a \ > > obj/bin/VBoxRT.so obj/bin/VBoxRT.so obj/lib/VBoxREM.so > > obj/bin/VBoxVMM.so \ > > -lXcursor -lXext -lX11 \ > > obj/lib/VBoxCOM.a obj/bin/VBoxXPCOM.so \ > > /usr/lib/libQtCore.so /usr/lib/libQtGui.so /usr/lib/libQtOpenGL.so Here you link without --as-needed, so a DT_NEEDED note for libGL is emitted unconditionally; therefore, by the time you get to VBoxOGL2D.a, libGL is included in the link already. [1] - The new linker behaviour in F13 does change things. Recall that the default used to be "--add-needed", which has since been renamed --copy-dt-needed-entries. What this means is, when producing a dynamic object as output, any DT_NEEDED entries in dynamic libraries mentioned on the link line will be copied into the output. The last library in that link line, libQtOpenGL.so, almost certainly has a DT_NEEDED entry for libGL.so already. So, when doing --copy-dt-needed-entries, that link line would have worked: the first mention of -lGL would have been skipped over, but then it would have been included since libQtOpenGL had a DT_NEEDED for it. Now, in F13, since --no-copy-dt-needed-entries is the default, this doesn't happen; DT_NEEDED entries are only emitted for things you really declare that you need. This is desirable; it allows libraries to change the libraries they themselves depend on, without necessarily requiring applications to also be recompiled. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100326 changes
Compose started at Fri Mar 26 08:15:04 UTC 2010 Broken deps for i386 -- anaconda-14.2-1.fc14.i686 requires fcoe-utils >= 0:1.0.12-2.20100323git edje-0.9.93.063-1.fc14.i686 requires libembryo-ver-svn-05.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_job.so.0 emotion-0.1.0.042-5.fc12.i686 requires libevas.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_fb.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_x.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_txt.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_job.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_con.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libedbus.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libevas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libehal.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_fb.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_x.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_ipc.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libefreet.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libedje.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_file.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libefreet_mime.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_con.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_x.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libedje.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_file.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_con.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_x.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_file.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0 evolution-couchdb-0.3.2-2.fc13.i686 requires libcouchdb-glib-1.0.so.1 ewl-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0 ewl-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-0.5.2.042-12.fc12.i686 requires libecore.so.0 ewl-0.5.2.042-12.fc12.i686 requires libefreet.so.0 ewl-0.5.2.042-12.fc12.i686 requires libedje.so.0 ewl-0.5.2.042-12.fc12.i686 requires libecore_file.so.0 ewl-0.5.2.042-12.fc12.i686 requires libefreet_mime.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libedje.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_file.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_evas.so.0 ghc-haskell-platform-2009.3.1.20100115-0.2.fc13.i686 requires ghc-HTTP = 0:4000.0.8 ghc-haskell-platform-2009.3.1.20100115-0.2.fc13.i686 requires ghc-network = 0:2.2.1.5 ghc-haskell-platform-2009.3.1.20100115-0.2.fc13.i686 requires ghc-QuickCheck = 0:2.1.0.2 ghc-haskell-platform-2009.3.1.20100115-0.2.fc13.i686 requires ghc-cgi = 0:3001.1.7.1 ghc-haskell-platform-devel-2009.3.1.20100115-0.2.fc13.i686 requires ghc-QuickCheck-devel = 0:2.1.0.2 ghc-haskell-platform-devel-2009.3.1.20100115-0.2.fc13.i686 requires ghc-cgi-devel = 0:3001.1.7.1 ghc-haskell-platform-devel-2009.3.1.20100115-0.2.fc13.i686 requires ghc-HTTP-devel = 0:4000.0.8 ghc-haskell-platform-devel-2009.3.1.20100115-0.2.fc13.i686 requires ghc-network-devel = 0:2.2.1.5 ghc-haskell-platform-doc-2009.3.1.20100115-0.2.fc13.i686 requires ghc-QuickCheck-doc = 0:2.1.0.2 ghc-haskell-platform-doc-2009.3.1.20100115-0.2.fc13.i686 requires ghc-HTTP-doc = 0:4000.0.8 ghc-haskell-platform-doc-2009.3.1.20100115-0.2.fc13.i686 requires
Re: Linker trouble
Hi Lubomir, Not 100% clear on this, so anyone who has more experience please feel free to correct me. In general, as-needed means that items specified on the command line may not be linked if they are not needed for any objects preceding them in the command line. I believe this is what is happening: Case 1 (as-needed, failure): The symbol from -lGL that failed was not needed by anything preceding -lGL on the command line. Since the as-needed flag is set, g++ just moves on without linking anything. A later object on the command line do require the symbol, but by then the -lGL is no longer in play so there is nothing left to resolve the symbol with. Case 2 (as-needed, success): Because -lGL is called _after_ the .o that requires it, the symbols are correctly linked. When g++ encounters -lGL, it determines that a symbol is required by one of the preceding objects and links accordingly. Case 3 (without as-needed): Without as-needed the default behaviour is to just link everything that is on the command line, so it does not really matter where on the line -lGL is specified. Hope it helps! :) -Charley -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-CGI-Application-Plugin-DBIProfile
perl-CGI-Application-Plugin-DBIProfile has broken dependencies in the rawhide tree: On x86_64: perl-CGI-Application-Plugin-DBIProfile-0.07-1.fc14.noarch requires perl(HTML::BarGraph) perl-CGI-Application-Plugin-DBIProfile-0.07-1.fc14.noarch requires perl(SVG::TT::Graph::Bar) On i386: perl-CGI-Application-Plugin-DBIProfile-0.07-1.fc14.noarch requires perl(HTML::BarGraph) perl-CGI-Application-Plugin-DBIProfile-0.07-1.fc14.noarch requires perl(SVG::TT::Graph::Bar) Please resolve this as soon as possible. -- 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: [Fwd: [SECURITY] Fedora 12 Update: maniadrive-1.2-21.fc12]
Kevin Kofler wrote: > Jon Ciesla wrote: > >> Does anyone else see anything odd about this update? >> > > Maniadrive uses libphp (probably for the "Dedicated server with HTTP > interface" advertised on its About page) and therefore had to be rebuilt for > the PHP security update. > > Kevin Kofler > > Ah, this is what I was ignorant of. Sorry for the noise! -J -- 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: [Fwd: [SECURITY] Fedora 12 Update: maniadrive-1.2-21.fc12]
On Fri, Mar 26, 2010 at 02:16:14PM +0100, Michał Piotrowski wrote: > 2010/3/26 Till Maas : > > On Fri, Mar 26, 2010 at 08:04:51AM -0500, Jon Ciesla wrote: > >> Michał Piotrowski wrote: > >> > 2010/3/26 Jon Ciesla : > >> > > >> >> Does anyone else see anything odd about this update? > >> >> > >> > > >> > I didn't know that maniadrive shares code with php... > >> > > >> > > >> AFAICT, it doesn't. This update looks like PHP itself. . . > > > > AFAICT it BRs php-devel: > > http://cvs.fedoraproject.org/viewvc/rpms/maniadrive/devel/maniadrive.spec?revision=1.20&view=markup > > | BuildRequires: glew-devel ode-devel php-devel php-embedded-devel > > > > But this whole thread is strange. If you think something is odd, please > > say what it is. > > Maniadrive package contains php package changelog AFICS The update notes contain the upstream PHP changelog, but the package changelog is from maniadrive: | ChangeLog: | | * Sat Mar 6 2010 Remi Collet 1.2-21 | - Rebuild for new php 5.3.2 | * Mon Feb 22 2010 Hans de Goede 1.2-20 | - Fix FTBFS (#564773) | * Fri Nov 20 2009 Remi Collet 1.2-19 | - Rebuild for new php 5.3.1 When you look at the update in Bodhi, you will notice that both php and maniadrive have been grouped together: https://admin.fedoraproject.org/updates/php-5.3.2-1.fc12,maniadrive-1.2-21.fc12 Afaics everything is how it should be. Regards Till pgp4HkOjRly8y.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fwd: [SECURITY] Fedora 12 Update: maniadrive-1.2-21.fc12]
2010/3/26 Till Maas : > On Fri, Mar 26, 2010 at 08:04:51AM -0500, Jon Ciesla wrote: >> Michał Piotrowski wrote: >> > 2010/3/26 Jon Ciesla : >> > >> >> Does anyone else see anything odd about this update? >> >> >> > >> > I didn't know that maniadrive shares code with php... >> > >> > >> AFAICT, it doesn't. This update looks like PHP itself. . . > > AFAICT it BRs php-devel: > http://cvs.fedoraproject.org/viewvc/rpms/maniadrive/devel/maniadrive.spec?revision=1.20&view=markup > | BuildRequires: glew-devel ode-devel php-devel php-embedded-devel > > But this whole thread is strange. If you think something is odd, please > say what it is. Maniadrive package contains php package changelog AFICS > If you wonder, whether it requires PHP, look at the > spec. > > Regards > Till > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fwd: [SECURITY] Fedora 12 Update: maniadrive-1.2-21.fc12]
Jon Ciesla wrote: > Does anyone else see anything odd about this update? Maniadrive uses libphp (probably for the "Dedicated server with HTTP interface" advertised on its About page) and therefore had to be rebuilt for the PHP security update. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fwd: [SECURITY] Fedora 12 Update: maniadrive-1.2-21.fc12]
On Fri, Mar 26, 2010 at 08:04:51AM -0500, Jon Ciesla wrote: > Michał Piotrowski wrote: > > 2010/3/26 Jon Ciesla : > > > >> Does anyone else see anything odd about this update? > >> > > > > I didn't know that maniadrive shares code with php... > > > > > AFAICT, it doesn't. This update looks like PHP itself. . . AFAICT it BRs php-devel: http://cvs.fedoraproject.org/viewvc/rpms/maniadrive/devel/maniadrive.spec?revision=1.20&view=markup | BuildRequires: glew-devel ode-devel php-devel php-embedded-devel But this whole thread is strange. If you think something is odd, please say what it is. If you wonder, whether it requires PHP, look at the spec. Regards Till pgp4TTWdC2LdB.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fwd: [SECURITY] Fedora 12 Update: maniadrive-1.2-21.fc12]
Michał Piotrowski wrote: > 2010/3/26 Jon Ciesla : > >> Does anyone else see anything odd about this update? >> > > I didn't know that maniadrive shares code with php... > > AFAICT, it doesn't. This update looks like PHP itself. . . > Regards, > Michal > > >> -J >> >> -- >> in your fear, seek only peace >> in your fear, seek only love >> >> -d. bowie >> >> >> >> Fedora Update Notification >> FEDORA-2010-4212 >> 2010-03-11 07:03:40 >> >> >> Name: maniadrive >> Product : Fedora 12 >> Version : 1.2 >> Release : 21.fc12 >> URL : http://maniadrive.raydium.org/ >> Summary : 3D stunt driving game >> Description : >> ManiaDrive is an arcade car game on acrobatic tracks, with a quick and >> nervous >> gameplay (tracks almost never exceed one minute). Features: Complex car >> physics, Challenging "story mode", LAN and Internet mode, Live scores, >> Track editor, Dedicated server with HTTP interface and More than 30 blocks. >> >> >> Update Information: >> >> This is a maintenance release in the 5.3 series, which includes a large >> number >> of bug fixes.Security Enhancements and Fixes in PHP 5.3.2: - Improved >> LCG >> entropy. (Rasmus, Samy Kamkar) - Fixed safe_mode validation inside >> tempnam() >> when the directory path does not end with a /). (Martin Jansen) - Fixed a >> possible open_basedir/safe_mode bypass in the session extension identified >> by >> Grzegorz Stachowiak. (Ilia)Key Bug Fixes in PHP 5.3.2 include: - Added >> support for SHA-256 and SHA-512 to php's crypt. - Added protection for >> $_SESSION from interrupt corruption and improved "session.save_path" check. >> - >> Fixed bug #51059 (crypt crashes when invalid salt are given). - Fixed bug >> #50940 Custom content-length set incorrectly in Apache sapis. - Fixed bug >> #50847 (strip_tags() removes all tags greater then 1023 bytes long). - >> Fixed >> bug #50723 (Bug in garbage collector causes crash). - Fixed bug #50661 >> (DOMDocument::loadXML does not allow UTF-16). - Fixed bug #50632 >> (filter_input() does not return default value if the variable does not >> exist). >> - Fixed bug #50540 (Crash while running ldap_next_reference test cases). - >> Fixed bug #49851 (http wrapper breaks on 1024 char long headers). - Over 60 >> other bug fixes.Full upstream changelog: >> http://www.php.net/ChangeLog-5.php#5.3.2 >> >> ChangeLog: >> >> * Sat Mar 6 2010 Remi Collet 1.2-21 >> - Rebuild for new php 5.3.2 >> * Mon Feb 22 2010 Hans de Goede 1.2-20 >> - Fix FTBFS (#564773) >> * Fri Nov 20 2009 Remi Collet 1.2-19 >> - Rebuild for new php 5.3.1 >> >> References: >> >> [ 1 ] Bug #570769 - php-5.3.2 is available >>https://bugzilla.redhat.com/show_bug.cgi?id=570769 >> >> >> This update can be installed with the "yum" update program. Use >> su -c 'yum update maniadrive' at the command line. >> For more information, refer to "Managing Software with yum", >> available at http://docs.fedoraproject.org/yum/. >> >> All packages are signed with the Fedora Project GPG key. More details on >> the >> GPG keys used by the Fedora Project can be found at >> https://fedoraproject.org/keys >> >> ___ >> package-announce mailing list >> package-annou...@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/package-announce >> >> -- >> 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: [Fwd: [SECURITY] Fedora 12 Update: maniadrive-1.2-21.fc12]
2010/3/26 Jon Ciesla : > Does anyone else see anything odd about this update? I didn't know that maniadrive shares code with php... Regards, Michal > > -J > > -- > in your fear, seek only peace > in your fear, seek only love > > -d. bowie > > > > Fedora Update Notification > FEDORA-2010-4212 > 2010-03-11 07:03:40 > > > Name : maniadrive > Product : Fedora 12 > Version : 1.2 > Release : 21.fc12 > URL : http://maniadrive.raydium.org/ > Summary : 3D stunt driving game > Description : > ManiaDrive is an arcade car game on acrobatic tracks, with a quick and > nervous > gameplay (tracks almost never exceed one minute). Features: Complex car > physics, Challenging "story mode", LAN and Internet mode, Live scores, > Track editor, Dedicated server with HTTP interface and More than 30 blocks. > > > Update Information: > > This is a maintenance release in the 5.3 series, which includes a large > number > of bug fixes. Security Enhancements and Fixes in PHP 5.3.2: - Improved > LCG > entropy. (Rasmus, Samy Kamkar) - Fixed safe_mode validation inside > tempnam() > when the directory path does not end with a /). (Martin Jansen) - Fixed a > possible open_basedir/safe_mode bypass in the session extension identified > by > Grzegorz Stachowiak. (Ilia) Key Bug Fixes in PHP 5.3.2 include: - Added > support for SHA-256 and SHA-512 to php's crypt. - Added protection for > $_SESSION from interrupt corruption and improved "session.save_path" check. > - > Fixed bug #51059 (crypt crashes when invalid salt are given). - Fixed bug > #50940 Custom content-length set incorrectly in Apache sapis. - Fixed bug > #50847 (strip_tags() removes all tags greater then 1023 bytes long). - > Fixed > bug #50723 (Bug in garbage collector causes crash). - Fixed bug #50661 > (DOMDocument::loadXML does not allow UTF-16). - Fixed bug #50632 > (filter_input() does not return default value if the variable does not > exist). > - Fixed bug #50540 (Crash while running ldap_next_reference test cases). - > Fixed bug #49851 (http wrapper breaks on 1024 char long headers). - Over 60 > other bug fixes. Full upstream changelog: > http://www.php.net/ChangeLog-5.php#5.3.2 > > ChangeLog: > > * Sat Mar 6 2010 Remi Collet 1.2-21 > - Rebuild for new php 5.3.2 > * Mon Feb 22 2010 Hans de Goede 1.2-20 > - Fix FTBFS (#564773) > * Fri Nov 20 2009 Remi Collet 1.2-19 > - Rebuild for new php 5.3.1 > > References: > > [ 1 ] Bug #570769 - php-5.3.2 is available > https://bugzilla.redhat.com/show_bug.cgi?id=570769 > > > This update can be installed with the "yum" update program. Use > su -c 'yum update maniadrive' at the command line. > For more information, refer to "Managing Software with yum", > available at http://docs.fedoraproject.org/yum/. > > All packages are signed with the Fedora Project GPG key. More details on > the > GPG keys used by the Fedora Project can be found at > https://fedoraproject.org/keys > > ___ > package-announce mailing list > package-annou...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/package-announce > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Fwd: [SECURITY] Fedora 12 Update: maniadrive-1.2-21.fc12]
Does anyone else see anything odd about this update? -J -- in your fear, seek only peace in your fear, seek only love -d. bowie --- Begin Message --- Fedora Update Notification FEDORA-2010-4212 2010-03-11 07:03:40 Name: maniadrive Product : Fedora 12 Version : 1.2 Release : 21.fc12 URL : http://maniadrive.raydium.org/ Summary : 3D stunt driving game Description : ManiaDrive is an arcade car game on acrobatic tracks, with a quick and nervous gameplay (tracks almost never exceed one minute). Features: Complex car physics, Challenging "story mode", LAN and Internet mode, Live scores, Track editor, Dedicated server with HTTP interface and More than 30 blocks. Update Information: This is a maintenance release in the 5.3 series, which includes a large number of bug fixes.Security Enhancements and Fixes in PHP 5.3.2: - Improved LCG entropy. (Rasmus, Samy Kamkar) - Fixed safe_mode validation inside tempnam() when the directory path does not end with a /). (Martin Jansen) - Fixed a possible open_basedir/safe_mode bypass in the session extension identified by Grzegorz Stachowiak. (Ilia)Key Bug Fixes in PHP 5.3.2 include: - Added support for SHA-256 and SHA-512 to php's crypt. - Added protection for $_SESSION from interrupt corruption and improved "session.save_path" check. - Fixed bug #51059 (crypt crashes when invalid salt are given). - Fixed bug #50940 Custom content-length set incorrectly in Apache sapis. - Fixed bug #50847 (strip_tags() removes all tags greater then 1023 bytes long). - Fixed bug #50723 (Bug in garbage collector causes crash). - Fixed bug #50661 (DOMDocument::loadXML does not allow UTF-16). - Fixed bug #50632 (filter_input() does not return default value if the variable does not exist). - Fixed bug #50540 (Crash while running ldap_next_reference test cases). - Fixed bug #49851 (http wrapper breaks on 1024 char long headers). - Over 60 other bug fixes.Full upstream changelog: http://www.php.net/ChangeLog-5.php#5.3.2 ChangeLog: * Sat Mar 6 2010 Remi Collet 1.2-21 - Rebuild for new php 5.3.2 * Mon Feb 22 2010 Hans de Goede 1.2-20 - Fix FTBFS (#564773) * Fri Nov 20 2009 Remi Collet 1.2-19 - Rebuild for new php 5.3.1 References: [ 1 ] Bug #570769 - php-5.3.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=570769 This update can be installed with the "yum" update program. Use su -c 'yum update maniadrive' at the command line. For more information, refer to "Managing Software with yum", available at http://docs.fedoraproject.org/yum/. All packages are signed with the Fedora Project GPG key. More details on the GPG keys used by the Fedora Project can be found at https://fedoraproject.org/keys ___ package-announce mailing list package-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/package-announce --- End Message --- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Linker trouble
Hi, I'm wondering if anyone could enlighten me about why does --as-needed make a difference here? (let alone the order in which -lGL appears). [lkund...@localhost VirtualBox-3.1.6_OSE]$ g++ -Wl,--as-needed \ > -o out/linux.x86/release/obj/VBoxTestOGL/VBoxTestOGL \ > out/linux.x86/release/obj/VBoxTestOGL/generic/OpenGLTestApp.o \ > -L/usr/X11R6/lib -L/usr/lib \ > -lGL \ > obj/lib/VBoxOGLhostspuload.a obj/bin/VBoxOGLhostcrutil.so > obj/lib/VBoxOGL2D.a \ > obj/bin/VBoxRT.so obj/bin/VBoxRT.so obj/lib/VBoxREM.so > obj/bin/VBoxVMM.so \ > -lXcursor -lXext -lX11 \ > obj/lib/VBoxCOM.a obj/bin/VBoxXPCOM.so \ > /usr/lib/libQtCore.so /usr/lib/libQtGui.so /usr/lib/libQtOpenGL.so /usr/bin/ld: obj/lib/VBoxOGL2D.a(VBoxGLSupportInfo.o): undefined reference to symbol 'glGetString' /usr/bin/ld: note: 'glGetString' is defined in DSO /usr/lib/libGL.so so try adding it to the linker command line /usr/lib/libGL.so: could not read symbols: Invalid operation collect2: ld returned 1 exit status [lkund...@localhost VirtualBox-3.1.6_OSE]$ g++ -Wl,--as-needed \ > -o out/linux.x86/release/obj/VBoxTestOGL/VBoxTestOGL \ > out/linux.x86/release/obj/VBoxTestOGL/generic/OpenGLTestApp.o \ > -L/usr/X11R6/lib -L/usr/lib \ > obj/lib/VBoxOGLhostspuload.a obj/bin/VBoxOGLhostcrutil.so > obj/lib/VBoxOGL2D.a \ > -lGL \ > obj/bin/VBoxRT.so obj/bin/VBoxRT.so obj/lib/VBoxREM.so > obj/bin/VBoxVMM.so \ > -lXcursor -lXext -lX11 \ > obj/lib/VBoxCOM.a obj/bin/VBoxXPCOM.so \ > /usr/lib/libQtCore.so /usr/lib/libQtGui.so /usr/lib/libQtOpenGL.so [lkund...@localhost VirtualBox-3.1.6_OSE]$ g++ \ > -o out/linux.x86/release/obj/VBoxTestOGL/VBoxTestOGL \ > out/linux.x86/release/obj/VBoxTestOGL/generic/OpenGLTestApp.o \ > -L/usr/X11R6/lib -L/usr/lib \ > -lGL \ > obj/lib/VBoxOGLhostspuload.a obj/bin/VBoxOGLhostcrutil.so > obj/lib/VBoxOGL2D.a \ > obj/bin/VBoxRT.so obj/bin/VBoxRT.so obj/lib/VBoxREM.so > obj/bin/VBoxVMM.so \ > -lXcursor -lXext -lX11 \ > obj/lib/VBoxCOM.a obj/bin/VBoxXPCOM.so \ > /usr/lib/libQtCore.so /usr/lib/libQtGui.so /usr/lib/libQtOpenGL.so [lkund...@localhost VirtualBox-3.1.6_OSE]$ Thank you, Lubo -- Flash is the Web2.0 version of blink and animated gifs. -- Stephen Smoogen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 Branched report: 20100325 changes
Jesse Keating wrote: > On Thu, 2010-03-25 at 17:57 +, Branched Report wrote: >> gnome-web-photo-0.9-4.fc13.i686 requires gecko-libs = 0:1.9.2.1 > > gnome-web-photo has building issues: > http://koji.fedoraproject.org/koji/buildinfo?buildID=163241 Fix queued for stable: https://admin.fedoraproject.org/updates/gnome-web-photo-0.9-6.fc13 Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Sendmail 8.14.4 for f12?
Yes, I will build for f12, f11 regards Jaroslav - Original Message - From: "mike cloaked" To: "Development discussions related to Fedora" Sent: Friday, March 26, 2010 10:06:02 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Sendmail 8.14.4 for f12? Given http://www.securityfocus.com/bid/37543/info is there going to be a build of sendmail 8.14.4 for f12 (and f11) which does not have that vulnerability? -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 Branched report: 20100325 changes
On Fri, Mar 26, 2010 at 9:39 AM, Kevin Kofler wrote: > Peter Robinson wrote: hornsey-1.5.2-0.1.fc13.i686 requires libclutter-gst-0.10.so.0 >>> >>> hornsey has build issues: >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=2075984 >> >> Should be fixed shortly. Known issue due to some of the upstream >> project changes. I'm watching it all very closely. >> pyclutter-gst-0.9.2-1.fc12.i686 requires libclutter-gst-0.10.so.0 >>> >>> pyclutter has build issues: >>> http://koji.fedoraproject.org/koji/buildinfo?buildID=152855 >> >> pyclutter-gst has been split out to a separate package so needs to be >> packaged up as a separate package. Not sure if anyone is working on >> it. I think there's due to be a new upstream release very shortly that >> is compatible with the clutter 1.2 release and associated clutter-gst >> release. > > How "shortly" are these going to come? There's very little time left until > the F13 release. If there are patches in upstream revision control, please > consider backporting them right now. Otherwise, it may be worth trying to > patch these up ourselves so they build. The sooner they get fixed, the > better! I would have done so but the repository has been taken off line for migration. They have said they will be back by then end of March. Believe me the sooner I can stop getting emails for it the better too! Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 Branched report: 20100325 changes
Jesse Keating wrote: > gnome-web-photo has building issues: > http://koji.fedoraproject.org/koji/buildinfo?buildID=163241 Implicit linking issue: /bin/sh ../libtool --tag=CXX --mode=link g++ -pthread -DORBIT2=1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 - I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 - I/usr/include/libpng12 -I/usr/include/libxml2 -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include - I/usr/include/xulrunner-sdk-1.9.2 -I/usr/include/nspr4 -fno-rtti -fshort-wchar -fvisibility=hidden -UGTK_DISABLE_DEPRECATED -O2 -g -pipe -Wall -Wp,- D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -Wall -Wno-unused - Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -O2 -g -pipe -Wall -Wp,- D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -R/usr/lib/xulrunner- sdk-1.9.2/bin -o gnome-web-photo gnome_web_photo-Components.o gnome_web_photo-Embed.o gnome_web_photo-Listener.o gnome_web_photo-Prefs.o gnome_web_photo- Printer.o gnome_web_photo-Writer.o gnome_web_photo-main.o -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 - lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lxml2 -lgconf-2 -lglib-2.0 -lpng12 -ljpeg - L/usr/lib/xulrunner-sdk-1.9.2/lib -lxpcomglue_s -L/usr/lib/xulrunner-sdk-1.9.2/bin -lxul -lxpcom -lxpcomglue libtool: link: g++ -pthread -DORBIT2=1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include - I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 - I/usr/include/libxml2 -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/xulrunner-sdk-1.9.2 -I/usr/include/nspr4 -fno-rtti -fshort-wchar -fvisibility=hidden -UGTK_DISABLE_DEPRECATED -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack- protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -Wall -Wno-unused -Wconversion -Wpointer-arith -Wcast-align - Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector -- param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -o gnome-web-photo gnome_web_photo-Components.o gnome_web_photo-Embed.o gnome_web_photo-Listener.o gnome_web_photo-Prefs.o gnome_web_photo-Printer.o gnome_web_photo-Writer.o gnome_web_photo-main.o -pthread -lgtk-x11-2.0 -lgdk- x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 - lgthread-2.0 -lrt -lxml2 -lgconf-2 -lglib-2.0 -lpng12 -ljpeg -L/usr/lib/xulrunner-sdk-1.9.2/lib -lxpcomglue_s -L/usr/lib/xulrunner-sdk-1.9.2/bin -lxul - lxpcom -lxpcomglue -pthread -Wl,-rpath -Wl,/usr/lib/xulrunner-sdk-1.9.2/bin /usr/bin/ld: /usr/lib/xulrunner-sdk-1.9.2/lib/libxpcomglue.a(nsGlueLinkingDlopen.o): undefined reference to symbol 'dlopen@@GLIBC_2.1' /usr/bin/ld: note: 'dlopen@@GLIBC_2.1' is defined in DSO /lib/libdl.so.2 so try adding it to the linker command line /lib/libdl.so.2: could not read symbols: Invalid operation Yet another victim of the completely unnecessary incompatible ld change which was shoehorned into F13 the day of the feature freeze. When will people understand that this kind of changes BREAKS things and has NO BENEFIT WHATSOEVER? :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 Branched report: 20100325 changes
Peter Robinson wrote: >>> hornsey-1.5.2-0.1.fc13.i686 requires libclutter-gst-0.10.so.0 >> >> hornsey has build issues: >> http://koji.fedoraproject.org/koji/taskinfo?taskID=2075984 > > Should be fixed shortly. Known issue due to some of the upstream > project changes. I'm watching it all very closely. > >>> pyclutter-gst-0.9.2-1.fc12.i686 requires libclutter-gst-0.10.so.0 >> >> pyclutter has build issues: >> http://koji.fedoraproject.org/koji/buildinfo?buildID=152855 > > pyclutter-gst has been split out to a separate package so needs to be > packaged up as a separate package. Not sure if anyone is working on > it. I think there's due to be a new upstream release very shortly that > is compatible with the clutter 1.2 release and associated clutter-gst > release. How "shortly" are these going to come? There's very little time left until the F13 release. If there are patches in upstream revision control, please consider backporting them right now. Otherwise, it may be worth trying to patch these up ourselves so they build. The sooner they get fixed, the better! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
Colin Walters wrote: > Move system-config-lvm to optional > > It's redundant with gnome-disk-utility, and the alternative > desktop UI spins are stripping it out anyways. Uh, no, the KDE spin was not stripping it out. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
Colin Walters wrote: > Several core things depend on info; it just doesn't make sense to have > two info viewers. Except "info" is a royal PITA to use, pinfo was written for a reason! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Sendmail 8.14.4 for f12?
Given http://www.securityfocus.com/bid/37543/info is there going to be a build of sendmail 8.14.4 for f12 (and f11) which does not have that vulnerability? -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
NuFW license change to GPLv3
The NuFW changed its license to GPLv3 from GPLv2. This applies also to the libnuclient library as NuFW subpackage. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: No Build ID error when building new OpenVZ kernel in FEDORA8
I find in all error cases, the error is because of the same file: /linux/lib/ts_kmp.ko. Then I looked into the /linux-2.6.18.x86_64/lib and found there were no object files in that directory. But I can find genksyms.o at /linux-2.6.18.x86_64/scripts/genksyms/genksyms/. So, it looks the reason is there is no object file for ts_kmp. == extracting debug info from /var/tmp/kernel-2.6.18-128.2.1.el5.emulab_openvz_migration-root/usr/src/kernels/2.6.18-128.2.1.el5.emulab_openvz_migration-x86_64/scripts/genksyms/genksyms extracting debug info from /var/tmp/kernel-2.6.18-128.2.1.el5.emulab_openvz_migration-root/lib/modules/2.6.18-128.2.1.el5.emulab_openvz_migration/kernel/lib/ts_kmp.ko *** ERROR: No build ID note found in /var/tmp/kernel-2.6.18-128.2.1.el5.emulab_openvz_migration-root/lib/modules/2.6.18-128.2.1.el5.emulab_openvz_migration/kernel/lib/ts_kmp.ko == I choose no to most of the options when run "make oldconfig". In /linux/.config, TEXTSEARCH_KMP is set to be m. So, I think that's why there is no object file for ts_kmp in /lib. I will try to set yes to all options when run "make oldconfig" to see what difference it will make tomorrow. # # Library routines # CONFIG_CRC_CCITT=m CONFIG_CRC16=m CONFIG_CRC_ITU_T=m CONFIG_CRC32=y CONFIG_LIBCRC32C=y CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m CONFIG_GENERIC_ALLOCATOR=y CONFIG_REED_SOLOMON=m CONFIG_REED_SOLOMON_DEC16=y CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=m CONFIG_TEXTSEARCH_BM=m CONFIG_TEXTSEARCH_FSM=m CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
