> 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;
> 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
> 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
> 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
>
> - "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
> > 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
> 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
> 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
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
> 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
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
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
> 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
> 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
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
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
> /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
File a glibc bug.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> 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
> {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
> 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
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
> 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
> 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
> 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
> 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
> 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
> 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}
> >
&
> 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
> 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
> 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
> 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).
> 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
>
> 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
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
-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
> 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
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
> 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
> 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
> 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
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
> 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
> 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
> 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
> 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
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
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
> 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
> 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
(
> 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
> 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
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
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
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
> 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
> 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
> 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
> 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
> 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
> > 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
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
> 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 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
> > 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
> 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
> $ 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
> 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
68 matches
Mail list logo
