#x27;d like to dump mysql in
time for F19, but we need validation that switching to maria doesn't
break anything for anyone.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
to be
ABI-compatible with those library versions.
regards, tom lane
once organizer, Independent JPEG Group
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
t not be the exactly correct word here. The main thing
I'm expecting would be that the "mysql database" package group would
actually give you mariadb, as would the anaconda checkbox.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ext cycle when mysql is completely dropped?
We could leave 'em as is, couldn't we?
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:
>> (If the compatibility testing goes *really* smoothly, maybe we could
>> just drop the requirement for original mysql to still be available,
>> in which case it reduces to the standard package-replacement pr
ith for only short-term benefit. mariadb really
wants to plop down exactly where mysql was sitting: take over the
executable names, the library sonames, the data directory, etc.
Anything else will greatly complicate packaging and open the door
to added bugs.
regards, tom la
everyone's happy. (Of
course, if the rebuild in master fails, then you have more work to do
... but it's work you'd have had to face up to soon anyway.)
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
nt income from
licensing the mysql docs anymore.
This is of course hardly the biggest issue involved with Oracle's
handling of mysql vis-a-vis downstream packagers. But if there were
to be an attempt to deal with the docs licensing problem in particular,
that would be a good solution from my
e to migrate to
mariadb 5.6.x in F20 or F21. I don't think we need the complications
of doing both mysql->maria and 5.5.x->5.6.x at the same time.
Also, keep in mind that 5.6.x was just declared GA yesterday. It's
doubtless still pretty full of bugs.
rega
ges in upstream autoconf yet, and if so what version? If not,
why not?
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
x27;t personally want to.) We'd have
to work out how they would coexist or conflict with the core packages.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
how to transition maintainership
of the "mysql" packages. This would give us some more wiggle room about
managing the transition --- in particular, it's hard to see how we
manage Obsoletes/Provides linkages in any sane fashion if the "mysql"
package name continues in use. I think
that would accomplish little except to complicate
the lives of both users and packagers. But we may need to revisit the
idea that we can just have mariadb obsolete mysql and be done.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ackages this seems to work fine. The
upstream notes tend to have way more info than I could cram into an
update description, anyway.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
do the job.
I realize this doesn't work for packages without such a dependency,
of course.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
n't seem that bad as it stands, though.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
thing
definitive about the worst-case address space wastage due to ASLR in
32-bit builds; anyone here know?
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
.py:264: You could try using --skip-broken to work around the
problem
DEBUG util.py:264: You could try running: rpm -Va --nofiles --nodigest
DEBUG util.py:354: Child return code was: 1
Somebody please fix?
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
critical data on rawhide ;-)
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
PostgreSQL has ever had. I'd appreciate it if people could
test these and up-karma them so they can go stable ASAP.
(Meanwhile, I'm looking for something nice in a brown paper
bag ... it was my bug :-()
regards, tom lane
--
devel mailing list
devel@lists.fedorap
another build try will work.
Yes, I resubmitted the rawhide build and it seems to be running fine
this time. Weird.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Kevin Fenzi writes:
> Tom Lane wrote:
>>>> Somebody please fix?
>> Well, fortunately this is only affecting rawhide, and I would hope
>> nobody is storing critical data on rawhide ;-)
> Sure, but I'd like to note that rawhide users are people too. ;)
> We
rguments based on the name of the package are pretty off-topic.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
latter what
component should I file it against?
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
tgres and filed the results as bz #952946.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
from upstream
in unbundling, because the Porter code isn't widely available as a
prepackaged library. (AFAIK anyway --- has that situation changed in
the last few years?)
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedora
Dhiru Kholia writes:
> On 04/16/13 at 05:59pm, Tom Lane wrote:
>> Pursuant to the recent discussion about using _hardened_build in more
>> packages, I tried turning it on in postgresql. I was unpleasantly
>> surprised to find that that causes the package's regression
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
critical packages, for which there might be some hope of it actually
working as designed.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
"Clyde E. Kunkel" writes:
> On 11/12/2010 02:32 PM, Tom Lane wrote:
>> It's absolutely crystal clear to me that we don't have enough tester
>> manpower to make the current policy workable; it's past time to stop
>> denying that. I'd suggest na
oes not result in more
manpower becoming available ... more likely the opposite.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
dividual ad-hoc test managers is an incredibly inefficient use of
their time.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ale.
Absolutism is not a useful approach to security.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
7;d be great if that actually did happen. But it's just not going to
happen, most of the time for most packages.
(And yeah, if we allow +1 autopush, we should definitely expect -1 is
sufficient to unpush. Maybe bodhi should restrict the combination of
those two settings, rather than either o
t
getting dropped on the initscripts at all. It works perfectly well to
set up these dirs once via RPM --- why shouldn't we make the tmpfs
creation process responsible for cloning the directory structure from
disk?
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Bruno Wolff III writes:
> I also like keeping these from escalating to Tom Lane, who I'd rather
> see working on Postgres.
I appreciate that too ;-) Thanks!
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.
3822862 build (f17-candidate,
/postgresql:2e73ff757cfdd20a708fc783e09ff23f3d8644e0): free
3822862 build (f17-candidate,
/postgresql:2e73ff757cfdd20a708fc783e09ff23f3d8644e0): free -> open
(x86-02.phx2.fedoraproject.org)
WTF? Do I need to fix this, and if so how?
regard
Orion Poplawski writes:
> On 02/27/2012 09:09 AM, Tom Lane wrote:
>> WTF? Do I need to fix this, and if so how?
> git pull
> (to bring in the f17 branch and mark devel as f18)
Hmm, that package indeed hadn't had f17 git pull'd yet. (I had scripted
a git pull in a
de and that's it.
Nope, it's not that easy, as some purely-local operations (eg "fedpkg srpm")
also want to know the dist tag.
I don't actually have a problem with Jesse's solution now that I know
about it; it was just surprising that fedpkg would depend on other
branc
where. On the whole I'm not
attracted to introducing still another discrepancy compared to what
happens in local builds.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Well, what you need to build against is Postgres 9.1.x, because that is
what is in current Fedora releases. I think you should just do -DPG91
and be done with it. You could BuildRequire postgresql-devel >= 9.1.0
if that makes you feel better.
regards, tom lane
--
de
ime to make that happen.
Could we schedule some sort of permanent round-robin FTBFS checks using
idle buildfarm members?
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
and it was just pointed out to me that it
completely fails to handle .include directives. So I'm wondering if
there is anything in the systemd infrastructure that could help me
do this in a more robust way. Ideas anyone?
regards, tom lane
--
devel mai
Tomasz Torcz writes:
> On Sat, Mar 17, 2012 at 10:32:22AM -0400, Tom Lane wrote:
>> I have a shell script that needs to dig the values of a couple of
>> "Environment=" settings out of a systemd service file. Currently
>> it just assumes it knows the search path for
Lennart Poettering writes:
> On Sat, 17.03.12 11:41, Tom Lane (t...@redhat.com) wrote:
>> Tomasz Torcz writes:
>>> You can try
>>> systemctl show -p Environment
>> [ experiments with that ... ] Hm, the output format seems pretty
>> ill-designed, bu
Lennart Poettering writes:
> On Wed, 21.03.12 20:39, Tom Lane (t...@redhat.com) wrote:
>> ... what I find "systemctl show" producing is a line like
>>
>> Environment=PGPORT=5432 PGDATA=/var/lib/pgsql/data PGPORT=5433
>>
>> So I have to pick this apart
can (in the near future) get ARM builders that are fast enough to make
it *practical* for ARM to be a PA. But I think denying that we need
non-Intel PAs is just fundamentally wrongheaded.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Kevin Kofler writes:
> Tom Lane wrote:
>> I thought it was a serious error to drop PPC from primary-arch status.
> I think it was one of the best decisions Fedora ever made. I'm glad I don't
> have to deal with slow PPC builders anymore, nor to fix build errors f
not, I will gladly join
the crowd of villagers with torches and pitchforks.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
gets turned off, by me
and probably a very large fraction of other Fedora users. How is
that "more secure"?
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ce about fixing either libtiff- or
libpng-dependent code, contact me off-list and I'll be glad to
try to help.
regards, tom lane
adrian fbida pre-existing FTBFS (libpng related)
agoode nip2pre-existing FTBFS
agoode opensl
se pthreads then -lpthread would seem
to be indicated.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
the packaging guidelines that addresses the
point. Given that we're converting most Java packages to noarch,
perhaps the issue comes up often enough to justify having a policy?
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Tom Callaway writes:
> On 05/14/2012 10:34 AM, Tom Lane wrote:
>> I recently converted mysql-connector-java from arch to noarch (it used
>> to use GCJ to build, now it doesn't). Martin Cermak pointed out to me
>> that if you had the debuginfo subpackage installed, a
angelog would the only difference
> otherwise, nobody will care. (And if not, try %if 0%{?fedora} > n
> conditionals.)
[ shrug... ] The fact that *you* don't care is not evidence that nobody
else cares, and it is certainly not evidence that nobody else should care.
e.
Anyway, these are surely unrelated to postgres' information_schema.sql,
which is automatically installed when the database is initialized
(hence the OP was getting a lot of errors from the objects already
existing).
regards, tom lane
--
devel mailing list
devel@lists.fe
ight be worth
stealing).
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
suitable testing *might* be a good idea, turning it on
by default seems like a horribly bad one.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Bruno Wolff III writes:
> Tom Lane wrote:
>> See also bug #832029 before being in too much of a hurry to decide that
>> this Must Be A Good Thing. At minimum, it currently seems that we might
>> need per-service tuning of the restart timing parameters before being
ckage an executable script named:
> /usr/libexec/initscripts/legacy-actions/frobozz/xyzzy
What do we need to Require: for this? Is there still a requirement to
hide it in a foo-sysvinit subpackage?
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
htt
over the disappearance
of "service postgresql initdb" in systemd-land, I think this is a
great idea.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
dy blinded by the Systemd Is
The One True Way faith would fail to recognize that.
> I'm pretty sure that this administrators muscle memory which has been
> referred to no longer exist amongst the administrators in the Fedora
> project
I beg to differ. If Bill doesn'
Michael Cronenworth writes:
> On 06/26/2012 06:54 PM, Tom Lane wrote:
>> I beg to differ. If Bill doesn't get his wrist slapped by FPC, I'll
>> be implementing this for postgresql tomorrow, because I'm tired of
>> hearing complaints about it.
> I must be
rough
to the legacy script, I don't see how. Anyway this seems a bit outside
the charter of the legacy-script feature, which IIUC is to let you do
exactly what you did before. If you now prefer postgresql-setup,
by all means keep using that.
regards, tom lane
--
d
7;ll fix that later today. If you got a broken-deps gripe for one
of the dependent packages, please *do not* rebuild.
apologies, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Jon Ciesla writes:
> On Mon, Jul 23, 2012 at 1:52 PM, Tom Lane wrote:
>> So I'll fix that later today. If you got a broken-deps gripe for one
>> of the dependent packages, please *do not* rebuild.
> Whoops, just did Io-language. Let me know when it's fixed, and
rs.)
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
mp the "0.n" part,
but I'd just as soon the upstream-ID part was likely to sort correctly
as well.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
to kill libpng-compat (and libtiff-compat) before we
branch F18.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
r less what Matt Domsch used to be doing; now that he
seems to have stopped, I agree that it would be a good thing for the
Fedora project to start doing it officially.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
handled now.
Agreed, this shouldn't be nearly so ad-hoc. See recent threads.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
843658
Thanks!
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
is not an answer
I intend to accept.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Adam Williamson writes:
> On Wed, 2012-08-01 at 01:53 -0400, Tom Lane wrote:
>> There are still about half a dozen packages left that failed the recent
>> mass rebuild because they contain source-code dependencies on obsolete
>> versions of libpng and/or libtiff. I've
ack that? I see little value in going
through the normal package review pushups, when this is absolutely
nothing except a backwards-compatibility package --- it ought to be
exactly like the F16 libpng package. And I'd like to get it done
before the F18 branch.
regards,
Tom Callaway writes:
> On 08/01/2012 10:03 AM, Tom Lane wrote:
>> What this means, IMO, is that we need to split out libpng12 as a
>> separate package. The current hack that I'm using (bundling 1.2 and 1.5
>> into a single SRPM) was never meant to be more than a very
, so WTF? Where is mock pulling this from?
(The other packages it grabbed seem to be an assortment of mostly fc17
and a few fc18 builds; didn't really check dates on the others, but for
sure this is not a post-mass-rebuild package set.)
regards, tom lane
--
devel ma
Bruno Wolff III writes:
> On Thu, Jul 26, 2012 at 20:13:18 -0400,
> Tom Lane wrote:
>> I'm still hoping to kill libpng-compat (and libtiff-compat) before we
>> branch F18.
> Should libpng12 obsolete libpng-compat?
Doh. I didn't think about
Jesse Keating writes:
> On 08/02/2012 06:27 PM, Tom Lane wrote:
>> I just did
>>
>> /usr/bin/mock -r fedora-rawhide-x86_64 /tmp/freeimage-3.10.0-10.fc18.src.rpm
> Check and see what repo url is in that config file, and see what it
> resolves to when in use?
I di
didn't
find it...)
thanks, 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
=?ISO-8859-2?Q?Micha=B3_Piotrowski?= writes:
> Is there any chance that 9.2 will be available for F18?
I'm holding off until there is a 9.2.0 release, or at least an RC
release, but I do very much want it to be in F18.
regards, tom lane
--
devel mailing li
17 and F16 RPM to remove
this objection. If that doesn't happen, I'm going to resist using them
in my spec files until they are in all active Fedora branches.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
AFAICS.
They don't touch the service's enable state.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Bruno Wolff III writes:
> Tom Lane wrote:
>> Bruno Wolff III writes:
>>> Yeah, it gets old pretty quick when every time some packages get updated,
>>> one needs to enable or disable them again.
>> Huh? That doesn't happen given the current (F16/F17) scri
nt branches. And if these things are macros, we should
not have to.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Scott Schmit writes:
> On Thu, Aug 23, 2012 at 01:22:27AM +0200, Lennart Poettering wrote:
>> On Wed, 22.08.12 19:17, Tom Lane (t...@redhat.com) wrote:
>>> What I would want to see in F16/F17 is macros that exactly duplicate the
>>> previously-standard snippets t
l trace of whether a package thinks it's supposed to be
enabled by default. Having two separate macros is not a bad thing IMO,
even if they happen to have the same expansion today.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
pstream ought to be willing to take back a patch to
make it configurable. /var/run is not a universal standard. You
don't have to look any further than /var/run versus /run to realize
that some flexibility there is a good idea for any upstream that has
any portability pretensions whatsoev
1 - 100 of 302 matches
Mail list logo
