ist all the libraries that *they*
depend on, instead of being sloppy.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
James Ralston writes:
> 1. Is Bugzilla having problems right now?
Seems to be working for me ...
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
fix? There's
certainly nothing in their documentation suggesting that there's
such a requirement.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
to use xmlMemSetup() ... basically, you can't replace
libxml's memory management, you just have to live with whatever it
chooses to leak.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
e thing just stays in NEEDINFO state.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
y I think: if you get multiple
reports of the same backtrace then you start to think that it's a real
bug rather than bad RAM. This still does nothing for the basic problem,
though, which is that a backtrace alone isn't very useful for fixing
the bug.
regards, tom
ther monstrous attachment load that dumps
would put on bugzilla, I think we can safely dismiss the idea.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ctive, since someone who could modify the file could
change the checksum too. (I'm assuming it's just a checksum and not
any sort of digital signature.)
The separate /lib directory tree seems the way to go, to me. That way
the checksum files could be named the same as what they check,
Martin Langhoff writes:
> On Fri, Jan 22, 2010 at 8:03 PM, Tom Lane wrote:
>> The separate /lib directory tree seems the way to go, to me. That way
> /usr/share instead of /lib seems more appropriate -
Hardly. Checksums on executables are going to be platform-specific.
Puttin
not doing the right thing.
As Matt said, this sort of difference shouldn't hurt the ability to
merge or cherrypick diffs from one branch to another.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
t I like that
idea a lot better than "branch" files, and especially better than some
complicated rule with multiple places to look for the information.
> Magic inspection of the branch relationships is not a substitute for
> real configuration.
Amen to that.
allel, and
one of the back branches happens to execute first?
What I think would be useful would be to extend the broken-dependency
nagbot so that it also nags if you have a back-branch that's NVR-newer
than any later branch.
IOW: nag good, preventing people from doing their work bad.
awhide should inherit the
latest completed build. It's rawhide, after all.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Rex Dieter writes:
> Tom Lane wrote:
>> Toshio Kuratomi writes:
>>> When you do an update in F-14 and rely on inheritance to get the package
>>> into rawhide, there is a problem. That package will not go to rawhide
>>> until it hits stable in F-14.
>>
en
I forget a package I'm going to need.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
, and even the "N days ago" annotations in the
shortlog view seem wonky, as if the server clock were stuck in early
August.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
off that future day is atm.
There was some discussion last week about teaching the broken-dependencies
nagbot to also nag about NVR sequence discrepancies. Is that feasible
or a reasonable response? Or is that subsumed under your mention of
autoqa?
regards, tom lane
--
devel
nst the policy isn't a helpful way to
proceed.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
s soon as F-14 is stable --- see
http://www.postgresql.org/download/linux
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ce because of
patents. Resurrecting it from the dead now is just an exercise in
misplaced priorities.
But having said that, it's not my decision to make; it's the
libjpeg-turbo authors' decision whether to expend effort in that
direction.
rovide a list of the packages you are intending to rebuild?
Or at least the exact dates where the bad gcc was in use?
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
end, this has to be a case-by-case decision, not something to be
mandated by distro-wide policy.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ake them start keeping their configuration info someplace else
than /etc/sysconfig. This proposal sounds more like "wait, systemd has
not yet broken everything in sight, how can we solve that problem?"
than like something that will actually improve matters for anyone.
Lennart Poettering writes:
> On Mon, 18.07.11 15:34, Tom Lane (t...@redhat.com) wrote:
>> Well, if they didn't need fixed before, they'll certainly need fixed
>> when you make them start keeping their configuration info someplace else
>> than /etc/sysconfig. This
seeming like a better option is to bump the package's Epoch
for the systemd-native release.
Discuss.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Bill Nottingham writes:
> Tom Lane (t...@redhat.com) said:
>> IOW, once I push a mysql update with native systemd support into
>> rawhide, I'll be forbidden from ever rebasing mysql in F15 up to
>> a newer upstream patch release. Considering that upstream issues
>&g
base servers on F15 is already
accustomed to pain.
Michal Hlavinka's solution of explicitly testing for the old sysv init
script seems like a win from here, since I don't intend to continue
packaging that. Anyone have an objection to that approach?
regards,
Toshio Kuratomi writes:
> On Tue, Jul 26, 2011 at 10:37:43AM -0400, Tom Lane wrote:
>> Michal Hlavinka's solution of explicitly testing for the old sysv init
>> script seems like a win from here, since I don't intend to continue
>> packaging that. Anyone hav
on to the %configure calls
in packages where it's actually an issue (which is surely a small
minority, unless Colin has got evidence to the contrary).
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
re useless and not worthy of my time. Auto nagmail to proventesters
might be of some value, but not to the package maintainer.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
so I know I've got packages that were built several weeks ago
and are still waiting in testing. When exactly was the busted rpm
version present in the buildroots?
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
to get the upstreams to think
about inventing non-connection-based protocols for testing database
server status, but I doubt that either one will be receptive.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Adam Williamson writes:
> On Tue, 2011-08-23 at 17:28 -0400, Tom Lane wrote:
>> Yeah. Another way in which socket activation is not transparent is that
>> code might try to determine whether the service is running by seeing
>> whether a connection attempt succeeds. In su
Reindl Harald writes:
> Am 23.08.2011 23:28, schrieb Tom Lane:
>> there's no other way for "mysqladmin ping" to work, for example
> and where is the problem?
I'm not planning on repeating myself either, but: a database
*monitoring* tool, as opposed to a vanilla c
activation of a
database. I'd like to support the option ... the problem is to do so
without breaking existing, expected behaviors.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ikely break users' customizations of
their service setups, which is not something you want to have happen
after a routine "yum update".
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
on my end. I would be prepared to push 9.1 into f16 on
Monday if there were enough people willing to test and up-karma it
before the freeze ... any volunteers out there?
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
=?ISO-8859-2?Q?Micha=B3_Piotrowski?= writes:
> 2011/9/11 Tom Lane :
>> Yeah. I have done test packaging of 9.1rc1 already, so it's pretty much
>> ready to go on my end. I would be prepared to push 9.1 into f16 on
>> Monday if there were enough people willing to test
Bruno Wolff III writes:
> Tom Lane wrote:
>> Yeah. I have done test packaging of 9.1rc1 already, so it's pretty much
>> ready to go on my end. I would be prepared to push 9.1 into f16 on
>> Monday if there were enough people willing to test and up-karma it
&g
Bruno Wolff III writes:
> On Mon, Sep 12, 2011 at 03:16:47 -0400,
> Tom Lane wrote:
>> OK, it's built and filed at
>> https://admin.fedoraproject.org/updates/postgresql-9.1.0-1.fc16
> One thing I noticed is that service postgresql initdb and
> service postgres
=?ISO-8859-2?Q?Micha=B3_Piotrowski?= writes:
> 2011/9/13 Tom Lane :
>> (This isn't new with 9.1, btw --- the last version or so of 9.0
>> for F16 was the same, since we switched over to native systemd
>> files.)
> I used this service file on F15 and it starts slower
=?ISO-8859-2?Q?Micha=B3_Piotrowski?= writes:
> 2011/9/14 Tom Lane :
>> Certainly postgresql.init was never exactly lean-and-mean, so it
>> seems like it ought to have been doing more work than the unit file
>> requires. Are you sure you were comparing apples to apples as f
d at the amount of
work that has been forced on me (as a package maintainer) in the service
of an unproven piece of software that may yet go down the tubes.
Take a look back at the list archives over the past few months, and
ask yourself how happy people actually are with this experiment.
cripting" so I didn't.
Michal's numbers look pretty damning, and I find it remarkable that the
systemd advocates seem to have managed not to read them, let alone admit
that they suggest something's seriously wrong.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
x27;d expect pg_ctl to usually come back after the first
sleep.
So I'm not sure what's happening on Michal's machine, but from here I
don't see anything egregiously wrong with systemd's performance on
this test.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
nfiguration for F17 Branched.
> I don't particularly have a problem with people getting branched by
> default at branch time.
I don't really care which is the default; whichever it is, the need is
to make it reasonably simple to choose the other. But locking rawhide
down in pursuit
did we get into such a situation, and what should
I do about it? Neither specfile appears to have any provision for
bootstrapping.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Petr Pisar writes:
> On 2011-10-05, Tom Lane wrote:
>> For example, cairo BuildRequires: librsvg2-devel, and librsvg2
>> BuildRequires: cairo-devel, so there is no order in which I can rebuild
>> them. How the heck did we get into such a situation, and what should
>&
will need to be rebuilt.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
dora branches rather than rawhide where they belong. Surely, this
is a matter to discuss with the Fedora maintainer(s) of glibc and nobody
else.
And yes, I think it's about time for FESCo to step in and lay down the
law.
regards, tom lane
--
devel
advice to check package
version, and instead have the triggerun script check to see whether the
mysql sysv initscript file is present. I wonder whether anyone else has
dealt with this and has working scriptlets?
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject
re up against similar issues, or will be if they take
back-branch maintenance seriously.)
What I want is a packaging guideline that doesn't simply blow off
the problem of upgrading packages in pre-systemd branches. It's not
an acceptable restriction, and I'm astonished that any
Honza Horak writes:
> On 10/24/2011 05:52 AM, Tom Lane wrote:
>> The idea I have at the moment is to ignore the advice to check package
>> version, and instead have the triggerun script check to see whether the
>> mysql sysv initscript file is present. I wonder whether any
Kevin Kofler writes:
> Tom Lane wrote:
>> FWIW, I'm totally on board with the idea of not switching to systemd in
>> F15 --- and even if I wanted to do that, it's pure luck that the problem
>> doesn't apply to F14->F15 upgrades as well, where such an optio
it is better for end users to use
> #!/usr/bin/env php/python/whatever in scripts.
Why?
This whole thing seems like make-work for packagers, and big
compatibility problems for users, for negligible benefit to either.
regards, tom lane
--
devel mailing list
devel@lists
ple away from Fedora and into
distributions that have more respect for their users' time.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ra for some time now, I believe.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ded directly."
or close variants of that. I assume this is another manifestation of
the same bug being discussed here ... or have the glibc guys managed to
break the world in two different ways in the same release?
regards, tom lane
--
devel ma
Matthias Clasen writes:
> On Wed, 2011-10-26 at 16:12 +0200, Jakub Jelinek wrote:
>> On Wed, Oct 26, 2011 at 10:06:31AM -0400, Tom Lane wrote:
>>> /usr/include/glib-2.0/glib/gmacros.h:32:2: error: #error "Only can
>>> be included directly."
>> You ar
time
being. So existing programs that depend on 1.2.x will continue to work,
but it won't be possible to rebuild a package that has source-level
dependencies on 1.2.x until those are fixed. I think this is enough
to avoid needing a special build tag for staging the rebuilds.
rs worry about fixing mere compiler warnings? I know I can't
claim to spend any time on that, except with my upstream hat on.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Chris Adams writes:
> Once upon a time, Tom Lane said:
>> Any opinions on which way to jump?
> How hard is it to fix source that accesses the fields directly? Do all
> the fields that were previously exposed have direct accessor functions?
AFAIK, they all do, and it sho
hat, I will proceed forward with 1.5, unless somebody thinks
of a very good reason not to.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
t where to find patches.
(Sorry for not being more verbose, but I've got to leave shortly.
If you need help, ask me off-list.)
regards, tom lane
(orphan) amide
(orphan) assogiate
(orphan) emerald
(orphan) gconf-cleaner
(orphan) geda-gattrib
(orphan) geda-gnetlist
7;re going to
have to deal with.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
"Nathanael D. Noblet" writes:
> On 03/22/2011 09:24 AM, Tom Lane wrote:
>> OK, I built mysql 5.5.10 in F-15, but I'm not too clear on the process
>> for getting dependent packages rebuilt in that branch. Any advice what
>> to do next?
> So I just got a b
the ticket for
updates.
(Rawhide builds work for me, though.)
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
s like somebody acted
on the testing request without knowing about the bundled-update plans
:-(.
I think I can revoke the update request but I'm not sure whether that
will make the mess even worse. Comments?
regards, tom lane
--
devel mailing list
devel@lists.fedora
> libtiff also had the same issue and it has been updated today). This has
> already been reported in
> https://bugzilla.redhat.com/show_bug.cgi?id=678635
> How can I find out when this new libtiff update will be added to Fedora
> 14.
https://admin.fedoraproject.org/updates/libtif
We'll push them all at
once once everything's rebuilt.
Attached is a list of what Michael Schwendt's script says the
dependencies are ... man, there are a lot ...
regards, tom lane
package: amarok-2.4.0-2.fc15.i686 from fedora-15-development-i386
package
whide build.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
out --- perhaps it was expecting mysql to export
such a function? We tightened up the exports list some time ago, so
I'd have expected such a problem to be caught already. Did pure-ftpd
get through the F15 mass rebuild successfully?
regards, tom lan
Kevin Kofler writes:
> Tom Lane wrote:
>> ser's problem is
>> /usr/bin/ld: cannot find -lfl
>> which looks to me to be a flex incompatibility unrelated to mysql.
> Probably needs BR flex-static.
Yup, you're right. It's been FTBFS for awhile:
https://bug
about their policy in the first place ...
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
o we need to wait around for somebody to fix these stragglers, or can
we go ahead and release dist-f15-mysql into the general f15-testing
pool? If the latter, what's the procedure for that, pester rel-eng?
regards, tom lane
--
devel mailing list
devel@lists.fedoraproje
re with "fedpkg build --target=dist-f15-mysql". But I think we've
gotten everything that doesn't have pre-existing build problems.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
fix the problem? Shouldn't somebody
with approval power be paying more than zero attention to older
branches?
regards, tom lane
--- Forwarded Message
Date:Sat, 09 Apr 2011 00:00:43 +
From:upda...@fedoraproject.org
To: t...@redhat.com
Subject: [Fedo
how to configure KDE? (I did look into the
power management settings, which seem remarkably over-engineered
and don't offer any clear "sleep" option...)
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Rajeesh K Nambiar writes:
> On Sat, Apr 30, 2011 at 12:00 AM, Tom Lane wrote:
>> Having been not terribly impressed with GNOME 3 in F-15 alpha, I thought
>> I'd try installing the beta with KDE, just to see if the grass is any
>> greener. Â I'm still trying to
knows how
many F15 packages are now going to ship in a FTBFS state?
If I were running things around here, this change would get reverted for
F15. Rawhide, it's fine in.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Adam Williamson writes:
> On Fri, 2011-05-06 at 10:59 -0400, Tom Lane wrote:
>> Well, if they think this is their beta test period, it still merits
>> asking why the heck this type of change is going in now. I agree with
>> Dave that this looks like development material,
.
Done, but given that the glibc maintainers have already stated their
intention to walk away from that update and file a new one so they can
ignore the bad karma on it, I don't have a lot of faith that I wasn't
wasting my time.
regards, tom lane
--
devel maili
Kevin Kofler writes:
> Tom Lane wrote:
>> but it hasn't done anything for the problem that packages that actually
>> need RPC functionality will now FTBFS for lack of a BuildRequires on
>> libtirpc, if not need actual source patches (maybe they were assuming
>> n
certainly broken by this. Please
send the info, I'll take care of those two.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
27;m less familiar with all of mysql's
options but I wouldn't be surprised if there's comparable issues there.
I'd be interested to know whether the OP was using a vanilla my.cnf or
something custom, and exactly what failure mode he saw.
regards, tom lan
=?ISO-8859-2?Q?Micha=B3_Piotrowski?= writes:
> 2011/5/9 Tom Lane :
>> I'd be interested to know whether the OP was using a vanilla my.cnf or
>> something custom, and exactly what failure mode he saw.
> In my case
> [mysqld]
> datadir=/home/data/mysql
> socket=
.
I grow weary of systemd apologists saying that services should be hacked
to work around systemd's limitations. systemd exists to serve the
daemons, not vice versa. If you can't fix these problems, people are
going to decide that systemd is a failed experiment.
here the rest of us have to
deal with it.
Maybe this suggests that we need to work a little harder on supporting
and/or encouraging use of "rawhide branches", so that multiple
developers can work on a shared piece of instability without affecting
all of Fedora-land.
they push code and then ignore bug reports for weeks, which is
not an assumption but the actual facts on the ground in the case that
started this thread.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
arge number of perl-dependent packages, since
we still have libperl.so not being installed into /usr/lib. I don't
think that having the build system enforce a prohibition would be a
good idea at all.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.o
ng RPMs
for F16 as soon as it's released.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
I used to run autoconf during the builds of both the postgresql
and mysql packages for many years. That eventually became unnecessary
in both cases, but I don't recall that autoconf changes ever caused me
any trouble. (gcc, on the other hand, ...)
regards, tom lane
--
de
bler code, instead of
touching the C code. Or fixing a grammar problem by patching bison's
output file instead of the input .y file. It just seems uselessly stone
age. And it certainly does not yield a patch that you are going to be
able to submit to upstream.
regar
ct Fedora packagers to do differently when they need to adjust
the configure script.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
)
This seems to me to be an area best left to the judgment of the
individual packager, based on what he's dealing with in a
particular package.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Kevin Kofler writes:
> Tom Lane wrote:
>> That sounds more like dogmatism than practical thinking. It's common to
>> pre-generate some of the files in a distribution tarball, just so that
>> users aren't required to have specific tools in order to build the code
I just got about half a dozen "broken dependencies in devel" emails that
seem to be completely wacko, as neither the dependent nor the dependee
have changed lately. Something messed up in the repo maybe?
regards, tom lane
--
devel mailing
Luke Macken writes:
> A large number of updates currently suffer from duplicate IDs, and I
> need to figure out a clever way to fix it.
Would it be prudent to not push new updates until you've fixed it?
regards, tom lane
--
devel mailing
1 - 100 of 302 matches
Mail list logo
