> component: CCfits (sergiopr)
> file:
> CCfits-debuginfo-2.3-2.fc15.i686/usr/lib/debug/.build-id/da/7236759b8c63fab2925bd308123b9b277a238c
>- unused debuginfo, binary is not packaged: /usr/bin/cookbook
The debuginfo is collected from the %buildroot directories. There is an
rpmbuild check
> That does not mean that the compressed contents will always be the same.
> At least the gzip compressed tarballs from github contain a time stamp.
That is true of the tarball-generation feature of gitweb or whatever it's
called last I looked too. It's easily fixed by having it pass -n to gzip
(
> What I was more worried about was what happens when sdt.h is included in
> plain C code. Whatever you think of C++ apps that don't play nice with
> , such a complaint is unlikely to impress authors of plain C
> apps.
The only header used by in C is .
(Frankly I can't tell any more why we even
It's not a bug. It's a choice of behavior that has been well-understood
for a very long time, even if some developers have only recently become
aware of it and are upset about the choices made long ago. When you want a
different choice for your program, use the compiler flag.
--
devel mailing li
That is consistent with the normal git workflow. Since fedpkg is a helper
around simple git operations, it would make sense for it to give you a
message saying you might want to pull, and to have a --pull option to do it
for you.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.f
> But then that breaks simple things that (mostly) worked with the old
> cvs/Makefile system.
>
>fedpkg prep
>Traceback (most recent call last):
> ...
>git.errors.GitCommandError: 'git config --get branch.resurrect.merge'
> returned exit status 1:
Do something like:
git
> Is anybody seeing any real value of having different commit ACLs per
> Fedora branch? I've seen some argument for EPEL vs Fedora, but is there
> real value in ACLs for f13, f14, devel, etc...?
The pkgdb interface distinguishes them. Apparently there was some
motivation for that in the first pl
> I am not sure ERESTARTNOINTR leaks to user-space. Probably reporter
> noticed ERESTARTNOINTR in strace.out and came to the wrong conclusion.
> Afaics, make reports -EINVAL.
But I don't think vfork is supposed to be able to fail with EINVAL.
So something is fishy.
--
devel mailing list
devel@lis
> On Thu, Dec 02, 2010 at 09:27:34AM -0800, John Reiser wrote:
> > vfork() can fail with ERESTARTNOINTR which is 513
> > and somewhat young. 'make' did not know:
> >https://bugzilla.redhat.com/show_bug.cgi?id=659382
> >
> > If your package has any shell-like feature
> > then it might be good
> It looks like glibc is missing TLS support. Do I submit a BZ against
> glibc?
That is simply not the case and it's hard to see how you came to such
a conclusion.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Hmm. I did a build with:
mock -r fedora-rawhide-x86_64 mono-2.8-1.1.fc15.src.rpm
on an f13/x86-64 host and it finished without complaint.
All the resultant binaries are 64-bit, not 32-bit.
So any hacks with -m32 are surely quite wrong.
Perhaps something is indeed wonky in koji, or maybe s
> Hi,
>
> > > {standard input}: Assembler messages:
> > > {standard input}:24487: Error: @TLSLDM reloc is not supported with
> > > 64-bit output format
> > > {standard input}:24487: Error: junk `...@tlsld' after expression
> > > make[3]: *** [libmonoruntimesgen_la-sgen-gc.lo] Error 1
> >
> > This
> {standard input}: Assembler messages:
> {standard input}:24487: Error: @TLSLDM reloc is not supported with
> 64-bit output format
> {standard input}:24487: Error: junk `...@tlsld' after expression
> make[3]: *** [libmonoruntimesgen_la-sgen-gc.lo] Error 1
This is certainly a case of compiling i38
> On Mon, Oct 04, 2010 at 12:48:20PM -0700, Roland McGrath wrote:
> > File a glibc bug.
>
> Upstream or in Fedora's bugzilla? (or both?)
Both doesn't hurt, but you can just file in Fedora and let the
package maintainer handle escalating it.
--
devel mailing list
deve
File a glibc bug.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> /usr/bin/ld: fldigi-trx.o: 'thread_id_' accessed both as normal and
> thread local symbol
> fldigi-trx.o: could not read symbols: File format not recognized
> collect2: ld returned 1 exit status
> make[2]: *** [fldigi] Error 1
Use 'eu-readelf -s foo.o | fgrep thread_id_' on each .o that goes int
As I said before, this is almost certainly the wrong fix. If you share
your code already, you will get the help you need quickly. As long as you
don't, and just ask over-specific questions rather than let people see the
context to help you properly, you will get only frustration.
Thanks,
Roland
This note comes from crt1.o, which is linked into every normal program
(both static and dynamic). Off hand, I'm not sure of anything that
actually checks this note.
What it indicates is the minimum required kernel version that glibc was
built for (its --enable-kernel configure option). This cont
> I can email you over the throwback from the build (or the spec file with
> altered patches), but as it dies on on the missing build ID (even with
> the LDFLAGS thing added), there is no build.
The log might help. I meant, the source, so I can attempt the build.
Use git. It's your friend. Just
> I've not come across this (mainly as I've not been that active due to a
> mix of work problems and hardware problems which meant a big
> re-install). Most of mono is built, but I've just hit this error
>
> *** ERROR: No build ID note found
> in
> /home/paul/rpmbuild/BUILDROOT/mono-2.8-1.fc15.i3
The koji database does contain the file lists in some fashion.
You can see from the "info" link for an rpm on a "buildinfo" page.
e.g. https://koji.fedoraproject.org/koji/buildinfo?buildID=180269
-> https://koji.fedoraproject.org/koji/rpminfo?rpmID=2041477
I bet some koji guru around here can wr
Perhaps local and so forth could be given a --dist=foo switch, and these
sorts of errors could say "can't figure out your dist from git, use --dist
or fix your repo".
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> Here is what I'm doing:
>
> fedpkg clone kernel
> fedpkg switch-branch f14
> git checkout -b pnfs-all-2.6.35-2010-08-05
Make that 'git checkout --track -b pnfs-blah-blah origin/f14/master'.
Or, equivalently, after the fact, do:
git config branch.pnfs-blah-blah.remote origin
git
I believe the manifest ACL behavior is that you are permitted to push to a
branch called fN/anything if you are on the pkgdb ACL for fN, and to
anything not matching fN/* if you are on the pkgdb ACL for devel/rawhide.
So the practical answer is probably that whatever the maintainers for a
particula
> Not sure if I've asked the wider audience here, but is the import.log
> file of any use to anybody? It's one more file that might differ
> between branches even when all else is the same, and I don't necessarily
> want to keep munging it with fedpkg when importing items. Would anybody
> cry if
> $ cat Makefile
> # Makefile for source rpm: pungi
> # $Id$
> .PHONY :: $(ARCHES) sources uploadsource upload export check build-check
[...]
Just use a single .DEFAULT: or %: rule, you don't need to list anything.
(And :: is almost never what you meant.)
Thanks,
Roland
--
devel mailing list
de
> It was suggested to keep the Makefile that exists in every package
> module/branch in CVS right now, but set it up so that any Make command
> issued would print a reminder to the user that the Make system has been
> retired and to use fedpkg.
So the expectation would be people leave this boile
> > Using names like f13, el5, and so forth would also keep dist-git
> > consistent with git branch naming conventions. If we were to do
> > something like that we might as well just use the value of %{dist}.
But that's just too obviously right for us to be allowed to do it!
> That was going t
> My first idea would be for fedpkg to do something similar to the
> following when trying to find out the target to build for:
>
> 0. If "--target F-13" is given, use that as target.
> If not, continue.
> 1. Determine the current git branch ($origbranch=$curbranch).
> 2. Check 'git con
> That said, I don't think I'd use either HEAD or master as the branch name
> since they both have some sort of association with how git itself works
> unless the name actually matches 100% with the concept that you're trying to
> express here.
This is nothing more or less than our convention for
My opinion is that a branch called F-/master is the nicest thing.
Actually, all else being equal, I'd probably go for it being called
f/master, since gratuitous caps and punctuation in branch names is
not a normal git convention. (But I only really care about the
structure of the names, not the sp
> > Unresolved regressions
> > --
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16353
> > Subject : 2.6.35 regression
> > Submitter : Zeev Tarantov
> > Date: 2010-07-05 13:04 (4 days old)
> > Message-ID :
> > References
> This is accurate.
>
> the files must be identical if they are not elf binaries.
I think the .py[co] files embed timestamps or something like that.
So they are nonidentical but not actually different at all.
You want all python to be in things that you don't want two of, AFAICT.
In general one
> So I'd package up stuff, do a koji build, download it, run my
> representative test suite, upload the result and do another build.
Oh. Well, sure then. What was the question? You don't want much of it
automated at all then, but you're asking about the little?
The profiled build will litter
> I dunno, I'm not a multilib expert, just an asshole telling you to make
> it work =)
I'm no expert on the rpm part of the world either, but I have seen many
things and I'll yell some out from the corner now and then.
> I think it probably doesn't 'work', in the sense that you can't install
> th
> This has a multilib problem. libstdc++ has a few of the same files in
> both the x86-64 and i686 packages, making it impossible to have both
> installed (which should be possible, and is in F13).
>
> The files are a few Python bits
> in /usr/share/gcc-4.5.0/python/libstdcxx/v6/ .
Would it work
> Is there a way to include pre-packaged workloads analysis? I realise
> we'd have to regenerate these somehow possible for each compiler update
> (not sure how the files look).
What a "workload" means to the compiler is all the results of all the
conditional branches in the compiled code. What s
I agree. The relevant concept is not "owner", but "sucker", or "victim".
When businessspeak people say someone "owns" a piece of work, what they
mean is to identify the person as the recipient of problems, complaints,
pleas for help, and perhaps even, rarely, praise, regarding the state of
the wor
nscd and sssd exist in part exactly to address this issue.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
It's normal to get a single foo-debuginfo package from a foo.src.rpm.
Please explain exactly why this is a problem for you.
Thanks,
Roland
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> Hm. I can see the use of this, but I can also see issues with how you
> do updates for it sanely (if at all.)
Why would you do updates for it? Your install CD/DVD to use for rescue
boot doesn't get updated. I'd think you'd just install a pristine newer
one verbatim if you had a reason to bothe
Ideally I think abrt's crash signature stuff ought to find two
characteristic failures are the same, and so send a reporter to
an existing bug report. Then that bug can be marked closed with
an annotation explaining what you need to install. (Of course,
it's also arguably wiser to have a hook in
> Knock yourself out:
>
> http://fpaste.org/FnFc/
>
> as I replied to John, though, oddly enough when I re-ran the command
> manually, it succeeded. Trying to see if it builds through mock now.
Are you sure that's the right command? The ld error mentions
libvo/vo_vaapi.o, but that file name doe
> Also, the "undefined reference to symbol" error is typical for the 'you
> left it out of the linker line' situation, but "could not read symbols:
> Invalid operation" is not, I've never seen that error before.
This and several other odd-looking things are "normal" cascade errors from
an undefine
> Actually what I do, Roland, it that I grab binutils daily tarball
> and rebuild it as Source0 of Rawhide's SRPM (really ugly...) so I
> always use the latest one, see '-r' option. Drawback in the script
> is that it always rebuilds binutils even if you have today's
> binutils RPMs somewhere, tha
Nice hack, Michal! As you are aware, I have been slowly preparing things
to get towards the option of using gold for real in the future. Making
this sort of testing easy is about the next thing I thought someone should
do (and wasn't going to hack on myself!), so it's a thrill to see you've
taken
> Though CFLAGS is not the issue, LIBS= is.
You are mistaken. Your configure check decides -pthread alone is
sufficient (which it is), and that is all it sets. If your configure put
-lpthread into LIBS, then you would not have a problem. The substitution
of LIBS into the makefile is working fin
-pthread is indeed sufficient when it's really given to the linking $CC run.
> Does someone know why this is going wrong?
In unbound.spec I see:
%{__make} CFLAGS="$RPM_OPT_FLAGS -D_GNU_SOURCE" QUIET=no %{?_smp_mflags}
This overrides the CFLAGS setting written into Makefile by configure.
You sh
What ldconfig actually does is fairly stupid. When a file is not something
else (i.e. ELF), it checks if the entire contents contain either "GROUP"
or "GNU ld script" and barfs if they don't.
So the generic advice is to put:
/* GNU ld script
Explain briefly what this is here for. */
at the
> Is it ok to backport changes to F-12 for fixed packages in F-13 for
> this DSO feature?
The changes to a package's linking lines that you make for this issue are
cleaning up sloppy practice to what was always the right thing to be doing.
So it should always be fine to do that in builds for earl
> Sure? For the libpng case I have a build failure which looks like this
> isn't the case (bug 565047):
>
>
> /usr/bin/ld: /usr/lib/gcc/i686-redhat-linux/4.4.3/../../../libpng12.so:
> undefined reference to symbol 'crc32'
> /usr/bin/ld: note: 'crc32' is defined in DSO /lib/libz.so.1 so try
>
> But I'm asking about -pthread option (which is detect/use for this package).
-pthread is the same as -D_REENTRANT at the beginning (which is useless)
and -lpthread at the end. I don't recommend using it at all. Just use
-lpthread instead (at the end of the link line, like all other libraries).
> Note that _libraries_ generally do not have a problem building in a
> --no-add-needed world. ELF does not require that all references in a
> DSO be resolvable at ld time, and this linking change does not change
> that. If your library libfoo uses symbols from libbar but does not
> itself link a
> Well, I'd say it's at least as important that the fix should be done in
> the appropriate place - the source code's configure step - and not
> wedged into the spec file. And then, of course, it should be sent
> upstream.
Absolutely!
Thanks,
Roland
--
devel mailing list
devel@lists.fedoraproje
> To answer the question, it works because the CFLAGS happen to be applied
> to the linker command as well as the LDFLAGS. As Roland says, though,
> adding it to CFLAGS is the wrongest fix, forcing it into LDFLAGS via the
> spec file is slightly less wrong, but having the upstream code add the
> fl
> Hi,
> On Wed, Feb 10, 2010 at 12:51 AM, Roland McGrath wrote:
> >> Replace
> >> make CFLAGS="%{optflags} -X11" %{?_smp_mflags}
> >> with
> >> make CFLAGS="%{optflags}" LDFLAGS="-lX11" %{?_smp_mflags}
> >
&
> Replace
> make CFLAGS="%{optflags} -X11" %{?_smp_mflags}
> with
> make CFLAGS="%{optflags}" LDFLAGS="-lX11" %{?_smp_mflags}
This is still not really ideal. For the long run, you should be fixing the
upstream package so that it passes -lX11 where it needs it. The most proper
change keeps -l
> Will there we a switch to give me the old behavior? I might want this for
> my own legacy code.
Not forever. You really should fix your makefiles. It's just cleaning
up usage that was sloppy originally.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mail
> They will only be so for a fairly short time, and you gave no specific
> time frame for landing the change (only 'pretty soon'), so it was not
> entirely clear. Thanks.
Sorry, we meant to be clear that it was "now" as of the posting.
--
devel mailing list
devel@lists.fedoraproject.org
https://a
> Worth clarifying here: Rawhide or (and?) F13?
They are still the same thing, so both. gcc-4.4.3-5.fc13 is there right now.
Thanks,
Roland
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> But, you have added an explicit dependency upon libdb to your executable
> by mentioning -ldb on the gcc command line. Therefore libdb will be
> loaded at execution start-up. But libdb has a dependency upon
> libpthread, so that library will also be loaded at execution start-up.
> Hence whe
> Right - Obviously I had not considered the case of a weak reference to a
> symbol defined in an as-needed DSO. I'll look into it today.
You're going to confuse the poor bystanders by using the wrong terminology.
There is no issue with as-needed. It's only --no-add-needed we are talking
about
> > That's correct. In other words, the libfoo.so DSO will only be used at
> > runtime if the presence of -lfoo at link time actually had any effect on
> > what symbols got resolved to what. But --as-needed is not really apropos
> > in this thread.
>
> OK, if RPM picks only the libraries that ar
>
> - "Jussi Lehtola" wrote:
> >
> > So is --as-needed within the current default flags?
>
> As far as I know, no. The default will still be --no-as-needed.
That's correct. This change does not affect --as-needed at all.
> The --as-needed flag will link libraries if
> A) they define symb
> I have problems to understand the xmlrpc-c build failure
>
> | /usr/bin/ld.bfd: xml-rpc-api2cpp.5842.test: undefined reference to symbol
> 'pthread_cancel@@GLIBC_2.2.5'
>
> pthread_cancel() is not used by the program. I see it in the .plt section
> only but not where it is referenced.
>
> I wo
> 78 of those seem to be caused by separated libtinfo. In default
> ncurses configuration libtinfo is included in libncurses, so I don't
> think the upstreams will be very happy about adding support for
> non-standard configurations.
>
> Petr Machata suggested we could work around it by replacing
> According to notting and the experimentation that I did after the FESCo
> meeting, the shared libraries bring in any libraries that they depend on.
> However, if the application linking to the shared library also requires the
> third shared library but doesn't explicitly link it then the link wil
> SystemTap is failing on pthread_cancel, which is odd since we have no
> mention of pthread in our own sources. It seems to be pulled in by some
> headers in the STL. Consider this minimal example:
>
> $ cat string.cxx
> #include
> int main()
> {
> return std::string("foo").length() != 3;
68 matches
Mail list logo
