I understand the use case, I'm still not super keen on having official
built packages come out of a branch. Makes discovery somewhat
difficult, and leads to problems if we have to bump+build something and
don't realize that the real live code is actually on a branch.
Surely all previous
Another data point for this thread:
x86 is unlike other architectures because 64-bit also has twice as many
registers as 32-bit. So you get to trade off the benefits of register
allocation across more registers against the memory/cache footprint of
64-bit pointers.
--
fedora-devel-list
It's certainly possible that users will rsync the Everything tree, but they
won't be able to do much with it. Is that the usecase you're worried about?
I just rsync'd it from my mirror of choice (kernel.org) and was very glad
to get it releases/12/Everything quickly populated with hard links
It sounds like you are saying that there is no way to export the same
host filesystems with the same client-perceived names under v4 as was
being done before under v[23]. Is that really true?
My old /etc/exports is:
/mirror*(ro,insecure,sync,mp,all_squash)
So clients
But with with older releases I don't messing with people configuration
files since I would not want to break an existing configuration...
Still never suggested that.
Note, there is a number of people who are currently running with
correctly configured v4 server... I would hate to mess
Of course. So push an F-11 update where whatever configuration never
mentions v4 and doesn't work for v4, doesn't advertise v4.
Not sure how I would do this without the update being called a
regression... any update that disables features does not seem
like a good thing...
I described
At the least, there ought to be an F-11 update of whatever server-side
stuff needs to change (in the minimal way not touching non-v4 uses) to
make v4 exports work without temporary configuration hacks. IMHO if you
can't do anything better, you should make F-11 default to not registering
as a v4
That is one of the valid options, but I would think it would better if
the server owner did that tweak, than an nfs-utils update, no?
I'm not suggesting that you do an update that just tweaks config files in
%post or anything like that. I'm suggesting you make the out-of-the-box
behavior with
If it's true cross support, then that should be a noarch package and the
file names it uses should not depend on %{_lib} that way.
Arguably it even belongs in %{_sharedir}, since it is fixed binary content
across all host machines.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
This is an interesting question. I'd hate to think that something being
unable to be included because of technical reasons would cause us to be
unable to call something Fedora.
Well, I think it's more or less whatever works. That is, we require
the various kernel features that the rest of
If we tracked the results of the build process independently of the RPM
itself, we could track much more complicated relationships between
packages (for example, the kernel borrowing bits of the output from the
last glibc build to make its initrd).
Koji's database has that information, sort
Yes, but I do not think we are in good faith satisfying the requirement
to distribute the source for those binaries by pointing back to koji
pages and possibly forcing the user to dig into the lookaside cache.
The requirement is to provide a written offer to give someone the source
when
So that's where I get clobbered. Need to figure out why, but at least I
solved the watch location question.
Yes. Sorry I disappeared there for a bit talking to compiler people about
whether there is a method other than reading the disassembly to find it.
I think there isn't, but I'll see
I agree with Jeff here. Sorry, Jim. I know life is too complicated to
keep track of, but that's just how it is. A robustly-written application
really needs to distinguish the build-time vs runtime dependencies it has.
If you want to make an assumption at run time, then you really have to make
-pthread means -D_REENTRANT and -lpthread. -D_REENTRANT is basically
useless and you should use standard feature test macros or _GNU_SOURCE for
what you want. So just linking with -lpthread is what I would call the
normal and recommended practice.
The man pages are not maintained by people
IMHO koji (and mock for that matter) ought to be running the builds inside
a captive pty whose ouytput it logs anyway, even if they redirect
everything. You never know what crazy nonsense some package is going to try.
You can put LIBC_FATAL_STDERR_=1 in the environment to get those messages
to
How does one setup one of these things?
Since I assume you are implementing it in Python, you might have to ask,
you know, someone who knows Python. I don't, but I have a web browser.
I even have locate '*python*pty*'. So maybe:
import pty
(pid, fd) = pty.fork()
or pty.spawn(...)
--
From build log:
+ /usr/lib/rpm/find-debuginfo.sh --strict-build-id
/builddir/build/BUILD/spambayes-1.0.4
find: `debug': No such file or directory
At first glance this appears to be a problem with the debuginfo
script. Is this a known issue?
It should not even be run on a noarch build, I
It sounds like something that looks at an SELinux policy's rules for SECMARK
and generates corresponding iptables rules would amount to the same thing
you have in mind. Since you load new SELinux policy in a big static-switch
sort of way, it doesn't seem much different in a way you could discern
I don't think I explained it well. I was thinking what if you had this rule:
-A INPUT -Z cups_t -j ACCEPT
and then cups was compromised and started listening on port 80. Since the
above rule has no port restrictions and cups is allowed to accept
connections,
would cups now be able to
So I think most of us in this discussion probably don't actually understand
SECMARK. I sure didn't. I think I might now, sort of. The SELinux policy
just says contexts, and it doesn't say anything about the port numbers.
The point of SECMARK is that you write port-matching rules that are what
/home on this system is a symlink to /disk/data/home, and %_topdir was
/home/beorn/rpm. This caused debuginfo packages without sources, where the
.debug files referenced the sources in the build directory. After I changed
%_topdir to /disk/data/home/beorn/rpm the debuginfo packages seem
You actually want overlap for a while so that when rsyncing you can use
hardlinks instead of having to redownload files you already have.
This is going to be more relevant if koji signing happens and packages don't
get different signatures depending on which repo they are in.
That would be
Releases prior to F-11 wouldn't benefit from that at all, as the RPMs
actually change when going from updates-testing to updates due to being
signed with different keys.
I think it still helps a lot with rsync. The old .all/* files are there to
be seen as almost the same and get rsync
I see, I misinterpreted the fact that all packages have a last modification
date of March 6 or after, it is true that most carry the same name as in
test3. Most of them have therefore been touch'ed and not rebuild, right ?
There is only one build ever done with the same N-V-R.ARCH. The
25 matches
Mail list logo
