Martin Langhoff writes:
On Tue, Jun 23, 2009 at 10:33 PM, Seth Vidalskvi...@fedoraproject.org wrote:
they're not insolvable - they are just very very very hard.
:-)
At the end of the day, if the OS doesn't give you atomic multi-file
transactions, and your %pre/%post scripts aren't also
Kevin Kofler writes:
Daniel P. Berrange wrote:
This is seriously dubious for F9, since if it causes a problem there
is next to no time in which to fix it before F9 updates are turned
off. In general I struggle to believe that there is a compelling
need to rebase automake versions in our
Stepan Kasal writes:
Hello,
On Tue, Jun 30, 2009 at 06:58:39PM -0400, Sam Varshavchik wrote:
Kevin Kofler writes:
Some software may need the new version to build.
Then, they need to be patched so that they would get built for F9, or
they should not be built for F9 altogether.
I'm afraid
Toshio Kuratomi writes:
On 07/04/2009 03:22 PM, Richard W.M. Jones wrote:
On Wed, Jul 01, 2009 at 12:40:44PM +0200, Ralf Corsepius wrote:
No, not if they bundle the generated auto* files with their tarballs, as
they are supposed to do.
They're not supposed to do that. Don't make stuff up.
Richard W.M. Jones writes:
There's been lots of previous discussion of this silly idea of
patching generated code. You end up carrying enormous patches
containing just line number changes that often can't be applied
upstream, and can't be carried forward to new upstream releases --
What line
Conrad Meyer writes:
On Sunday 05 July 2009 07:45:46 am Sam Varshavchik wrote:
*snip*
With a subsequent release, you'll still
have to rebase your existing patch, if the new release did not fix the
original bug. As I understand, rpm's default settings now reject fuzz in
patch files, so you'll
Andreas Tunek writes:
Maybe I should clarify my use case experience. After I used GParted to
format the HDD to ext3 (and ext4 later) I tried to create a folder on
the HDD. I could not do this as a normal user, only as root. When I
formatted the HDD to ntfs I could create folders and files. I
Richard W.M. Jones writes:
On Sun, Jul 05, 2009 at 10:45:46AM -0400, Sam Varshavchik wrote:
What line number changes? You cut a patch against configure, and you're
done. That's it.
And you get a big patch containing line numbers. Here's a single line
change to configure.ac
Richard W.M. Jones writes:
On Sun, Jul 05, 2009 at 02:24:43PM -0400, Sam Varshavchik wrote:
For this kind of scope, rebuilding the entire configure
script is overkill, and I wouldn't do it unless I audit it and verify
whether or not upstream is relying on some specific behavior
Orcan Ogetbil writes:
On Sun, Jul 5, 2009 at 2:24 PM, Sam Varshavchik wrote:
[cut]
Patching the configure
script is much safer than patching configure.ac, then have autoconf grok all
.m4 macros and rebuild the whole thing, likely ending up with a completely
different beast, that not only
Kevin Kofler writes:
Sam Varshavchik wrote:
But that's what /you/ want to do, not me. Me, I'll just apply a patch to
the configure script, directly.
And you'll be violating the GPL (unless you're talking about a
BSD-style-licensed software or configure.ac is explicitly marked with
special
Kevin Kofler writes:
Sam Varshavchik wrote:
How exactly would that violate the GPL?
You aren't patching the actual source code.
Oh, no! You mean, the tarball I downloaded from upstream, labeled source
code, did not actually contain the source code?
Looks like I've been snookered
Adam Jackson writes:
On Sun, 2009-07-05 at 18:50 -0400, Sam Varshavchik wrote:
Richard W.M. Jones writes:
On Sun, Jul 05, 2009 at 10:45:46AM -0400, Sam Varshavchik wrote:
What line number changes? You cut a patch against configure, and you're
done. That's it.
And you get a big patch
Kevin Kofler writes:
Sam Varshavchik wrote:
Oh, no! You mean, the tarball I downloaded from upstream, labeled source
code, did not actually contain the source code?
It contains both the actual source code and some unreadable generated
gibberish which is NOT source code and which is being
Kevin Kofler writes:
Sam Varshavchik wrote:
Just because you can't read it, it's not gibberish.
It's not that *I* can't read it, it's that it is just plain hard to read,
especially because it contains workarounds for bazillions of broken
proprietary *nix shells (trying to use Bourne-style
Kevin Kofler writes:
Sam Varshavchik wrote:
Gee, I didn't know that rediffing is a mandatory step.
It is when your patch no longer applies after you upgraded the package to a
new upstream version.
Which, as I pointed out, is still the case if you were to patch configure.ac
instead
Peter Gordon writes:
On Mon, 2009-07-06 at 21:24 -0400, Sam Varshavchik wrote:
Yes, well, that might be one of the reasons why KDE is sweeping over the
Linux desktop, and Gnome is just a fading memory for most.
Please don't claim such obviously fallacious things. Like it or not,
GNOME has
Kevin Kofler writes:
Sam Varshavchik wrote:
Which, as I pointed out, is still the case if you were to patch
configure.ac instead.
But, go ahead and ignore this inconvenient fact, too.
As I explained (and you ignored), configure.ac tends to change a lot less
between upstream releases
Kevin Kofler writes:
Sam Varshavchik wrote:
Sure, why not. It just so happens that, not too long ago, I was in an
analogous position where I had some other package that also built against
zlib, for $dayjob$. At $dayjob$ we also package free software using a
scripted reproducible build
Mark McLoughlin writes:
On Tue, 2009-07-07 at 07:14 -0400, Sam Varshavchik wrote:
libguestfs is a case in point - the Debian maintainer builds it from
git using some unknown version of autoconf, and I build it on RHEL and
This is a rare exception.
No, it's a rare exception for project
Matthew Woehlke writes:
Rui Miguel Silva Seabra wrote:
In a couple of years Microsoft is bought by Fu-Bar Inc and there goes the
promise down the drain.
...if only. The odds of *any* company that might buy out M$ (well, if it
isn't started by Gates and/or Ballmer and/or such) being as bad
Kevin Kofler writes:
Sam Varshavchik wrote:
This may come as a shock to some, but configure does not often change
unless configure.ac changes too.
So, I'm not sure what does the frequency of changes to configure.ac has to
do with anything.
Where your argument falls apart is that patch fuzz
Kevin Kofler writes:
Sam Varshavchik wrote:
That's great, and if this discussion was about cmake, then this would be a
valid point. But, this thread is not about cmake.
That CMake has this feature implies that the autotools suck for not having
it and forcing you to patch the configure
Kevin Kofler writes:
Sam Varshavchik wrote:
I don't get that impression. When I end up upgrading, as a result of the
entire distro upgrade, or otherwise, to a new autotools, I make sure that
I go through my existing configure scripts with a fine-toothed comb. Every
time this happens I always
Kevin Kofler writes:
Sam Varshavchik wrote:
Indeed. Here's an idea -- why don't you mass mail the maintainers of all
the autotools-using projects you can find on Sourceforge, and be sure to
tell them how much autotools suck, and how better CMake is. I'm sure they
will appreciate your helpful
Kevin Kofler writes:
Sam Varshavchik wrote:
Wrong, as usual.
That's an ad hominem argument.
Since each autoconf macro typically expands out to hundreds lines of
shellcode,
But those hundreds of lines of shellcode *CHANGE* with the autoconf and/or
aclocal version!
You're changing
Richard W.M. Jones writes:
On Tue, Jul 07, 2009 at 06:05:47PM -0400, Sam Varshavchik wrote:
If someone thinks that by patching configure.ac, instead of configure,
one achieves tremendous savings in the frequency of needing to rebase
one's patches, they're in a desperate need for a reality
Kevin Kofler writes:
What he was talking about is that rediffing patches, i.e. making patches
apply to a new upstream version (that's what rediffing means for us Fedora
packagers), is more likely to break for configure.ac than for configure.
And that's exactly what I said. Thank you for
Kevin Kofler writes:
Sam Varshavchik wrote:
Kevin Kofler writes:
What he was talking about is that rediffing patches, i.e. making patches
apply to a new upstream version (that's what rediffing means for us
Fedora packagers), is more likely to break for configure.ac than for
configure
Kevin Kofler writes:
Sam Varshavchik wrote:
In my last message, rather than speculate I posted logs from a randomly
chosen project, openldap, that showed that to be not the case.
That's one project. It doesn't prove any sort of a general trend.
That's one more project's worth of data
Dr. Diesel writes:
Please save your work and visit (tech website):
URL:http://hardforum.com/showthread.php?t=1391450amp;page=13http://hardf
orum.com/showthread.php?t=1391450page=13
Screen freezes, mouse has jerky movement, vt switch fails.
Loads fine for me.
F11.i368 all updates as of
Tom Lane writes:
This might be a stupid question, but: what compile and link options
are necessary nowadays for multithreaded code? I see various references
to -pthread and -lpthread, but it's hard to be sure what's
authoritative.
Just -lpthread does the trick for me. The -pthread option is
Michel Salim writes:
On Wed, 2009-08-19 at 19:57 -0700, Roland McGrath wrote:
-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
Pete Zaitcev writes:
On Thu, 22 Oct 2009 12:28:36 -0500, King InuYasha ngomp...@gmail.com wrote:
I just saw this article about an effort to create Universal binary style ELF
binaries for Linux, and I thought that this would be something to watch, so
that Fedora could integrate both x86-32 and
Tom Lane writes:
Mike McGrath mmcgr...@redhat.com writes:
Are people +1'ing getting rid of the broken dependencies script
altogether? or +1'ing to predicting the future and stopping it before it
breaks?
I thought the +1's were for putting in some circuit breakers, so
that when (not if) it
I just did a new install on a spare laptop. I chose the Software
Development option.
Emacs did not get installed.
Also, although neither mysql-devel, nor postgresql-devel, nor even
libtool-ltdl-devel got installed, I ended up with a huge number of -devel
packages, many of whom, from my
Rahul Sundaram writes:
On 11/28/2009 02:12 AM, Sam Varshavchik wrote:
I just did a new install on a spare laptop. I chose the Software
Development option.
Emacs did not get installed.
Also, although neither mysql-devel, nor postgresql-devel, nor even
libtool-ltdl-devel got installed, I ended
Debayan Banerjee writes:
2009/11/28 Rahul Sundaram sunda...@fedoraproject.org:
Why? It's just shows your personal preference for a editor. Emacs is
certainly not needed for software development.
Well one does need an editor for development. Assuming vim and emacs
have roughly equal user
nodata writes:
Am 2010-01-06 18:17, schrieb Matthew Booth:
On 06/01/10 17:00, Adam Jackson wrote:
On Wed, 2010-01-06 at 11:36 -0500, Jarod Wilson wrote:
On 1/6/10 11:07 AM, Adam Jackson wrote:
PGA.
Here's the challenge. To reply to this mail, I hit control-shift-r in
one evo window, and
39 matches
Mail list logo
