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
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
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
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
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
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
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
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
critical data on rawhide ;-)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
#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
ch, then we can say mariadb-devel
Provides: mysql-devel, and no source changes are needed in other
packages.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
;t libjpeb-turbo-devel provide
> libjpeg-devel and not libjpeg-turbo-compat-devel?
Only if jpeg8 is a drop-in (source code compatible) replacement.
Otherwise you're only moving the point at which failures will occur.
regards, tom lane
--
devel mailing list
devel
Juan Rodriguez writes:
> I did it on a live system, too. The only thing that failed during that time
> was postgres (Which managed to stay borked after it was done and f18
> booted, the pg_upgrade method didn't work properly)
BZ?
regards, tom lane
--
deve
lay. As is, it's unhelpful to
the point of being outright dangerous.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
se releases remain buggy, thus
creating a nasty feedback loop that further helps to drive away people
whose main interest is not in helping to debug the system. Eventually
the short-lived releases would just be rawhide-with-a-different-name.
regards, tom lane
--
devel m
easy to see how to avoid that: force consistency.
But that idea leads you right back to the series-of-releases approach
that we have now.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Adam Williamson writes:
> On Fri, 2012-11-02 at 17:53 -0400, Tom Lane wrote:
>> I've seen a whole lot of user demand for *more* stable versions of
>> Fedora. I've seen none whatever for less stable versions.
> Perhaps I ought to be more clear. I think we can mai
rust to
still work tomorrow or the day after. (Anyone up for porting fedpkg
to Ubuntu?)
I've seen a whole lot of user demand for *more* stable versions of
Fedora. I've seen none whatever for less stable versions.
regards, tom lane
--
devel mailing list
devel@l
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= writes:
> On 11/02/2012 04:25 PM, Tom Lane wrote:
>> How exactly are you going to force maintainers who go missing to do so
>> at a prescheduled time? Real life is seldom that convenient.
> bash script + a cron job should suffi
ery *beginning* of an new development cycle so feature owners and
>>> others working in the community are dealing with active and actively
>>> maintained packages.
How exactly are you going to force maintainers who go missing to do so
at a prescheduled time? Real life is seldom that
ly*, probably a dozen times per release cycle
across the whole distro. Any significant extra burden is going to be
insupportable.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ensure that as much of that time is unproductive as
possible. There is not a third option. (Brooks' _Mythical_Man-Month_
has useful things to say about this sort of scheduling trap --- anybody
who hasn't read it should.)
regards, tom lane
--
devel mailing list
or any other package, we'd be telling the maintainer to hold off
till F19. The rest of us don't get to be doing major feature
development post-beta-freeze.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
sql is now open source in name only.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
t of redundant macros is
anything significant. Meanwhile, by refusing to do this you are
inconveniencing a lot of package maintainers for whom the costs
of having different specfiles in different branches *are* significant.
regards, tom lane
--
devel mailing list
devel@lists
Bruno Wolff III writes:
> On Mon, Sep 10, 2012 at 10:24:40 -0400,
> Tom Lane wrote:
>> PG 9.2 is now released, and F18 isn't beta yet. So I'd like to push it
>> into F18 --- will anyone help test?
> Yeah!
> I'll definitely do some testing. My person
is probably a good change it
> will
> make it in F18. Otherwise it probably won't.
PG 9.2 is now released, and F18 isn't beta yet. So I'd like to push it
into F18 --- will anyone help test?
regards, tom lane
--
devel mailing list
devel@lists.fedoraproj
ackages to
specify the defaults, then we can remove the redundant macro
definitions. In the meantime, people who are arguing against this
seem to be entirely too confident that the current design is perfect.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject
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
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
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
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
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
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
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
=?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
.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
didn't
find it...)
thanks, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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
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
, 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
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
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,
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
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
843658
Thanks!
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
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
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
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
rs.)
regards, 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
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
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
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
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'
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
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
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
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
ight be worth
stealing).
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
't like sqlite, maybe they should be
looking into something like bdb. Embedded databases are simply
different critters from database servers, and trying to pretend that
code designed as the latter can be used as the former is not going
to lead to anything but pain.
rega
1 - 100 of 302 matches
Mail list logo
