Re: PIE breaks detection of available stack depth with getrlimit?
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 tests to >> fail, at least when running a 32-bit build in mock under a 64-bit >> kernel. The cause appears to be that getrlimit(RLIMIT_STACK) reports >> an inflated value for the process's available stack space. > I am wondering why Ubuntu didn't hit this bug earlier since they have > been shipping PIE enabled postgresql for a long time now. I'd bet a nickel they don't bother to run the regression tests during build. It's something that might not get noticed quickly in the field, particularly if most users are on the 64-bit version. > Does this problem occurs only under Linux 3.9 kernel (and not under > Linux <= 3.8 kernel versions) ? Uh, no. I first saw it on my overdue-for-upgrade F16 machine, running kernel-3.6.11-4.fc16.x86_64. I thought maybe it was a old bug, but it's still there in F19. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bundled copies of the Porter stemmer library
Florian Weimer writes:
> I found some packages which embed copies of the Porter stemmer library
> (PostgreSQL, tracker, pl, etc.). Should I file bugs once I have the
> full list, or should I apply for a bundling exception?
Well, as far as postgresql goes, you'll get zero interest 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.fedoraproject.org/mailman/listinfo/devel
Re: PIE breaks detection of available stack depth with getrlimit?
John Reiser writes: >> If you can write a short program that demonstrates the failure, >> say by comparing getrlimit(RLIMIT_STACK) to the results of >> an internal "cat /proc/self/maps", then that's a kernel bug. > [ proposed test program ] That program doesn't fail for me either, but Postgres definitely does; probably the problem is dependent on having a bunch of shlibs loaded, or having a SysV-style shared memory segment, or some other odd little detail. I adapted your program into a debugging-printout patch for Postgres and filed the results as bz #952946. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
PIE breaks detection of available stack depth with getrlimit?
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 tests to
fail, at least when running a 32-bit build in mock under a 64-bit
kernel. The cause appears to be that getrlimit(RLIMIT_STACK) reports
an inflated value for the process's available stack space.
Just to make it more fun, the test doesn't always fail, which makes it
look like address space randomization is affecting how much stack space
you get, but not how much getrlimit tells you you've got.
While 32-bit-under-64-bit-kernel probably isn't very reflective of real
world database usage, it is reflective of what's going to happen in
koji, so I cannot enable _hardened_build until this is resolved.
So is this a kernel bug, or a userspace bug, and if the 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
Re: MySQL and MariaDB in Fedora
Kevin Kofler writes: > Jóhann B. Guðmundsson wrote: >> If I installed mysql and have been running mysql then upgrade I expect >> the upgrade process to pick up the latest mysql we ship upgraded to that >> and I will be continuing to run mysql not be magically moved to fork of >> it mariadb. > Sorry, but the point of the MariaDB feature is that MariaDB will be the > default for everyone. Just like how LibreOffice replaced OpenOffice.org, > Calligra replaced KOffice, X.Org X11 replaced XFree86 etc. It's worth pointing out here that the Oracle folk are intent on pushing that package to mysql 5.6 ASAP. (Honza and I have been recommending to them that they wait till the F20 timeframe, just to reduce the amount of change happening in F19, but in any case it's coming pretty darn soon.) At that point mariadb 5.5 will actually be the lesser-change option for people currently using mysql 5.5. So I don't find Jóhann's argument terribly convincing. There is no no-change update path on the table, and the path that we are making the default requires less change than the other one. So that seems to me to be the right thing; arguments 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
Re: bison, flex have broken deps in rawhide
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 should try and avoid the 'no one uses rawhide, we don't need to > care' thing. Sure. If I didn't care, I wouldn't have been here griping about the problem. > I know you didn't mean it this way, just wanting to note that we do > care about rawhide and should work to making sure it works too. > (which from other emails in the thread its already fixed and building). Yeah, the rawhide build just finished OK. Still would like to know what happened the first time, though. If anyone wants to do a postmortem, the failed build was here: http://koji.fedoraproject.org/koji/taskinfo?taskID=5212558 regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bison, flex have broken deps in rawhide
Bruno Wolff III writes:
> On Fri, Apr 05, 2013 at 00:53:25 +0900,
>Mamoru TASAKA wrote:
>> So I guess repoclosure process is somewhat broken on koji.
> I just did a successful scratch build of postgres 9.2.4 on koji, so it
> might have been a temporary glitch and that 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
Karma needed for urgent postgresql security updates
I have just filed these bodhi requests
https://admin.fedoraproject.org/updates/postgresql-9.1.9-1.fc17
https://admin.fedoraproject.org/updates/postgresql-9.2.4-1.fc18
https://admin.fedoraproject.org/updates/postgresql-9.2.4-1.fc19
for packages fixing what is arguably the worst security bug
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.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bison, flex have broken deps in rawhide
Bruno Wolff III writes:
> On Thu, Apr 04, 2013 at 09:59:36 -0400,
>> Somebody please fix?
> Note that this is needed to rebuild postgresql to fix an important security
> issue for which information how to exploit it are now public. It would be
> really nice to have this fixed today even if that involves untagging the
> m4 build from this morning (assuming that would fix the issue) in order
> to get postgresql 9.2.4 built before doing a real fix.
Well, fortunately this is only affecting rawhide, and I would hope
nobody is storing critical data on rawhide ;-)
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
bison, flex have broken deps in rawhide
DEBUG util.py:264: Getting requirements for postgresql-9.2.4-1.fc20.src DEBUG util.py:264: --> perl-ExtUtils-MakeMaker-6.64-2.fc19.noarch DEBUG util.py:264: --> Already installed : glibc-devel-2.17-5.fc20.x86_64 DEBUG util.py:264: --> bison-2.7-1.fc20.x86_64 DEBUG util.py:264: --> flex-2.5.37-1.fc20.x86_64 DEBUG util.py:264: --> Already installed : gawk-4.0.2-2.fc19.x86_64 DEBUG util.py:264: --> perl-ExtUtils-Embed-1.30-266.fc20.noarch DEBUG util.py:264: --> 4:perl-devel-5.16.3-266.fc20.x86_64 DEBUG util.py:264: --> readline-devel-6.2-7.fc20.x86_64 DEBUG util.py:264: --> zlib-devel-1.2.7-10.fc19.x86_64 DEBUG util.py:264: --> Already installed : systemd-200-3.fc20.x86_64 DEBUG util.py:264: --> python-devel-2.7.3-35.fc20.x86_64 DEBUG util.py:264: --> python3-devel-3.3.0-10.fc20.x86_64 DEBUG util.py:264: --> 1:tcl-devel-8.5.13-2.fc19.x86_64 DEBUG util.py:264: --> 1:openssl-devel-1.0.1e-4.fc20.x86_64 DEBUG util.py:264: --> krb5-devel-1.11.1-7.fc20.x86_64 DEBUG util.py:264: --> openldap-devel-2.4.35-1.fc20.x86_64 DEBUG util.py:264: --> gettext-0.18.2.1-1.fc19.x86_64 DEBUG util.py:264: --> uuid-devel-1.6.2-17.fc20.x86_64 DEBUG util.py:264: --> libxml2-devel-2.9.0-4.fc19.x86_64 DEBUG util.py:264: --> libxslt-devel-1.1.28-2.fc19.x86_64 DEBUG util.py:264: --> pam-devel-1.1.6-9.fc20.x86_64 DEBUG util.py:264: --> systemtap-sdt-devel-2.2-0.94.g48bf64d.fc20.x86_64 DEBUG util.py:264: --> libselinux-devel-2.1.13-12.fc20.x86_64 DEBUG util.py:264: Error: Package: bison-2.7-1.fc20.x86_64 (build) DEBUG util.py:264: Requires: m4 >= 1.4 DEBUG util.py:264: Error: Package: flex-2.5.37-1.fc20.x86_64 (build) DEBUG util.py:264: Requires: m4 DEBUG util.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
Re: Expanding the list of "Hardened Packages"
Jakub Jelinek writes:
> If you don't care about the speed of execution of any programs, just compile
> everything with -fsanitize=address (that will be only ~ 2x slowdown or so).
A different issue that worries me about PIE is the impact on the
available address space in 32-bit builds. For instance, people
routinely configure Postgres to allocate a shared-memory area of a
couple GB, so if either the program text or the stack get moved too
much, configurations that used to work will break for lack of enough
contiguous free address space. I haven't been able to find anything
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
Re: Unhelpful update descriptions
Adam Williamson writes: > On 11/03/13 06:28 PM, Toshio Kuratomi wrote: >> That's not readily apparent in the Updates Policy ... > Ah, you're right, I really should have checked it before posting (yet > again). I was thinking that it discouraged *all* version updates, not > just "major" ones. I personally would still be hesitant to update a > package to a new upstream version if I didn't know what the heck was in > it, but that is indeed apparently just a personal preference and not a > policy :) I think there's no substitute for knowing your upstream --- and therefore, not a whole lot of scope for a one-size-fits-all distro-wide policy. In my case, I work mostly with upstreams that are pretty conservative about what they fix in minor releases, and I would think it irresponsible *not* to push out their minor updates into released Fedora branches. Other upstreams are a lot different though. I'm for leaving this to the package maintainer's discretion. Now, there's no harm in having the guidelines try to explain how to exercise that discretion. Maybe the existing text could use refinement. It doesn'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
Re: MySQL-libs conflicts with mariadb-libs-5.5.29-7.fc19.x86_64
Honza Horak writes: > On 03/11/2013 12:30 AM, Rex Dieter wrote: >> alekc...@googlemail.com wrote: >> 2. Should the "best practice" be to use >> Requires: mariadb, BuildRequires: mariadb-devel >> instead of >> Requires: mysql, BuildRequires: mysql-devel >> now? > mysql and mysql-devel should be still OK, since only mariadb packages > currently provide these symbols (they became only virtual names). Yeah, I think we will consider "mysql" and "mysql-devel" to be virtual Provides now. Generally, dependent packages should still use those for BuildRequires, unless there is some specific reason why you want to build against one particular MySQL clone. Also, if possible it's best not to use "Requires: mysql" at all, but just let the automatic dependency on libmysqlclient.so 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
Re: Unhelpful update descriptions
"Jared K. Smith" writes: > On Mon, Mar 11, 2013 at 11:41 AM, Michael Catanzaro > wrote: >> Perhaps the update policy should have a guideline on the minimum amount >> of information required in this description. E.g. "update to latest >> upstream version" might be a perfectly acceptable description for Fedora >> given the fast pace of updates, but I don't think users should ever be >> seeing "no update information available" and especially not "here is >> where you give an explanation of your update." (And I've seen this one >> multiple times within the past couple of weeks.) > I tend to agree here. That being said, most of my package updates are > something along the lines of "Update to upstream 2.5 release" -- would > you find that descriptive enough, or still lacking in detail? FWIW, I tend to say "update to upstream release XYZ" and give a URL for the upstream release notes for that version. This approach requires an upstream that's well enough organized to have such a webpage for every version, of course; but for my packages 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
Re: Should MariaDB touch my.cnf in %post?
Rahul Sundaram writes: > On Thu, Feb 14, 2013 at 10:13 PM, Kevin Kofler wrote: >> I really don't see what we have to gain from having 2 conflicting versions >> of MySQL in Fedora. > We never had the culture of questioning why anyone should include any > package as long as it meets the current guidelines. As long as there are > maintainers who are willing to deal with it, I don't see why you feel the > need to protest. The real bottom line here is that the current mysql maintainers *aren't* willing to deal with it anymore, and wish to shift our efforts to MariaDB. Barring someone taking up maintainership of Oracle's version, it's going to be an orphan. The current F19 feature for this was written on the assumption that nobody was going to step forward to do that, and thus that we needed to transition existing mysql users to mariadb, and that there wasn't much value in worrying about how to make multiple mysql forks coexist. Now some folk from Oracle have stated that they'd be willing to take up the packaging work to keep their version alive in Fedora. I don't wish to stand in their way, but I think it's fair to wonder how long it'll take them to get up to speed, since they evidently have zero Fedora packaging expertise today. In any case we need to think a bit harder about coexistence issues. I still think there is no need to support concurrent installation of both forks of mysql; 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
Re: Should MariaDB touch my.cnf in %post?
"Norvald H. Ryeng" writes: > On Thu, 14 Feb 2013 08:07:22 +0100, Rahul Sundaram >> Well, unless Oracle as upstream wants to get involved as downstream >> maintainers in Fedora as well. They did offer to do that but don't seem >> to have stepped up yet. > Let's do it now, then. :-) > We want to keep the MySQL package in Fedora and are willing to co-maintain > or take over maintainership if nobody else will do it. We haven't really > discussed this with the current maintainers yet, but from the discussions > on this list it seems they're not interested in maintaining the package > after F19. If us stepping up changes that, we are happy to co-maintain. The way this worked in the past (and still does on RHEL and some other distros) is that MySQL AB provided RPMs named "MySQL", "MySQL-server", etc, which simply conflicted with the Red Hat-supplied packages named "mysql", "mysql-server", etc. Perhaps it would be best to continue that naming tradition, ie establish a new Oracle-maintained Fedora package named "MySQL", instead of figuring out 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 we're going to have to end up with a design in which "mysql" becomes essentially a virtual Provides name. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
Liang Suilong writes: > Thanks for all developers' great work. Here I have two questions about > cluster. > MariaDB stays in Fedora repository now, however, Galera Cluster does not > contain in MariaDB. MariaDB with Galera Cluster is marked as stable. Is > there any plan to enable Galera Cluster feature. > NDBCluster Engine was dropped in Fedora since MySQL 5.1.43. Now MariaDB has > replaced MySQL. Could we also change MySQL package too? Re-enable > NDBCluster? I know MySQL Cluster has different source tarball. There is a > lot of difficulties. Will official MySQL developers help communities? I > hope so. AFAICS, neither of these are things that we could or would want to integrate into the core mysql^H^H^Hmariadb packages. So what this comes down to is whether there's somebody who wants to maintain them as separate Fedora packages. (I don'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
config.guess/config.sub for aarch64 (was Re: Mass Rebuild for Fedora 19)
Dennis Gilmore writes: > Additionally we will be mass patching config.guess and config.sub to > support aarch64 in preperation for 64 bit arm support Hm, it would be much better in the long run to pester upstreams to update to an appropriate version of these files. Are the required changes 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
Re: MySQL 5.6 for Fedora 19
James Hogarth writes:
> On 6 February 2013 13:15, Chris wrote:
>> It would be nice to see MySQL 5.6 for Fedora 19.
> Rather than go through the same thing again I suggest you read this thread
> about mariadb replacing mysql:
To clarify that a little bit: it might be reasonable 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.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
> On 01/28/2013 01:22 PM, Norvald Ryeng wrote: >> We include the docs because they are useful to users downloading the >> software directly from dev.mysql.com, even if Fedora and other distros >> can't redistribute them. >> >> In Debian, recreating the tarball is done by the get-orig-source target >> in debian/rules, so the manual work has to be done only once. After >> that, it's all automatic. Is this different with RPMs in Fedora? The work involved isn't the issue (and yes, it is reasonably well automated). Rather the problem is loss of easy traceability of the source tarball. Someone who wants to verify that I didn't tamper with the rest of the tarball contents while removing the docs has to work harder than just comparing tarball checksums. Rahul Sundaram writes: > Is anything preventing you from providing a configure option? A configure option would hardly help --- the point here is that we can't ship even source tarballs that contain the docs, because of the license problem. What I would see as a good-faith gesture on Oracle's part would be to relicense the docs under the same license as the source code, or some other redistribution-friendly license such as Creative Commons. AIUI the reason for the current restrictive license is that back in the day, MySQL AB felt they had to be restrictive to support their business model of the time. Surely Oracle is not getting any significant 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 standpoint. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
Bruno Wolff III writes: > On Wed, Jan 23, 2013 at 22:38:30 +0100, >Lennart Poettering wrote: >> I'd propose instead that mass branching goes away entirely, and the >> "master" branch too. > This is kind of how things work now at a repo level. There are a couple of > problems though. Sometimes the changes have ripple effects and other packages > also need to get rebuilt for rawhide. The other is that fixes in > updates-testing aren't inherited into rawhide. During freezes this can leave > rawhide broken for a long time. There's a pretty fundamental reason why Lennart's proposal doesn't work: even if a given package is source-wise identical between F-n and F-n+1, that doesn't mean it would be binary-identical. Either the packages it depends on or the build toolchain might well have changed since F-n was split off. IMO, maintainers who abdicate their responsibility to rebuild in rawhide are being unhelpful to the rest of the project, first by possibly supplying incompatible old packages and second by not exercising the rawhide build environment. Is it really so painful to launch an extra "fedpkg build" in the master branch? If you're keeping master and the newest release branch in exact sync, it's surely trivial to script something that will duplicate your commits in one branch into the other and then launch the extra build. Fire-and-forget once a day or whatever, and 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
Re: Proposed F19 Feature: Replace MySQL with MariaDB
Peter Robinson writes:
> Will it be designed to work with the alternatives infrastructure so
> that those that actually want mysql can swap it in/out?
No; we're specifically *not* interested in building alternatives
infrastructure. It would be a waste of effort if we're going to stop
shipping mysql as of F20 (or maybe even F19 if things go well).
Almost certainly, we'll just make the mariadb and mysql packages
Conflict: so they can't be installed concurrently. If we need to
make them be concurrently installable then that's a whole new bag
of hurt to deal with 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 lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
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 problem. >> But I'm not prepared to bet on that quite yet.) > Honestly, I'd be curious as to whether we could get all the compatibility > testing done early enough, and packages changed, such that we could consider > dropping MySQL. It's just... cleaner. Quite honestly, I'd prefer that too. But we need to have a good case that it's not going to break very many things for very many people. Database people hate it when you break their database. So ... as mentioned in the feature page, we really need help testing this during the F19 devel cycle. We'll need to make decisions before we reach alpha/beta stage. It strikes me that we missed a bet in setting up the mariadb package for only F19-and-up in git. If we made a version available for F18, that would allow people to test compatibility without having to run rawhide, which is something that would give most DBAs the willies. However, that would require facing the problem of how to declare the package vis-a-vis mysql, since we surely can't drop mysql from F18. So I could still use some advice as to how we might work the provides-obsoletes-conflicts mechanics for that. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
Kevin Fenzi writes: > Would this involve moving around any of the provides for mysql over to > MariaDB? Yes, that's the general idea --- any dependencies on mysql should result in installing mariadb, unless the user takes specific action to get mysql instead. Ideally we'd just do the standard Provides/Obsoletes dance for replacing one package with another, but I'm not quite sure how that should work if we still want original mysql to be installable. Any thoughts from RPM experts would be welcome. (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 problem. But I'm not prepared to bet on that quite yet.) > Also, what about those packages depending on unversioned "mysql"? > move those in the next 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
Re: Proposed F19 Feature: Replace MySQL with MariaDB
Bill Nottingham writes: > Jaroslav Reznik (jrez...@redhat.com) said: >> We would like to replace MySQL with MariaDB in early development cycle for >> Fedora 19. MySQL will continue to be available for at least one release, but >> MariaDB will become the default. Also, we do not intend to support concurrent >> installation of both packages on the same machine; pick one or the other. > What does it mean to replace it as the default if neither is ever installed > in a default 'next -> next -> next' installation? "Default" might 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
Re: Fwd: [Libjpeg-turbo-users] jpeg-9, API/ABI compatibility, and the future role of this project
Michael Stahl writes: > read more carefully then: the git repo contains binaries built against > different Ubuntu baseline versions, the older of which have jpeg6 and > the newer jpeg8. [ shrug... ] So we'd be incompatible with some of them no matter what. But the bigger point is that we can't let Ubuntu make decisions for us about which versions of which packages Fedora is going to ship. Personally I concur with Adam's newfound opinion that jpeg8 is a dead end we shouldn't be going down. The original point of libjpeg (which succeeded beyond my wildest dreams really) was to promote universal JPEG file compatibility. The latest jpeg8 and jpeg9 versions are antithetical to that goal because they create nonstandard files that can't be read by standard implementations, including older libjpeg. If there were a huge improvement in compression performance maybe there'd be some chance of establishing a new de facto standard, but there isn't --- so this will accomplish little except to fragment the market. I don't think Fedora should be contributing to that, not even to the small extent of breaking ABI compatibility 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
Re: MariaDB in Fedora
Henrique Junior writes:
> Other distros are discussing about the future of MySQL and the
> implementation of MariaDB as default. What is Fedora position about this
> matter?
https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB
We could use help with testing. Personally I'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
Re: MariaDB: Packagers needed
Kevin Fenzi writes: > I think I am with Remi on the above... shipping both for 1 release > would be potentially helpful in seeing issues, we can ask people to > migrate at that time and file bugs, if the bugs are stoppers they can > go back to mysql until fixed. I guess it depends on the maintainer(s) > involved if they feel this would be worthwhile. There will be very substantial costs to either of the schemes that allow mysql and mariadb to be installed in parallel. I'm pretty disinclined to expend the packaging effort, or the user-education effort, if the road map is that we're expecting to drop mysql altogether soon. I'm OK with a ship-both-for-awhile plan as long as it's done by making the packages simply Conflict:. Otherwise I think we'll be doing too much throwaway work. Personally, though, I lean to the just-do-it approach. Remember that mariadb is in the end a fork of mysql. It seems unlikely to me that there are bugs in it that are (a) not in mysql and (b) so catastrophic as to justify the work of dual-packaging, even in the stripped down form of just-make-them-conflict. So I'd rather just make the switch (early in a devel cycle) and fix any bugs we run into. As an example of the sort of work I'd rather not do, if we want to have two packages then it'll be necessary to change BuildRequires in other packages if we want to build/test them against mariadb. If we go straight for the replacement approach, 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
Re: libjpeg-turbo API/ABI bump in F19 (transition from jpeg6 to jpeg8 API/ABI)
Orion Poplawski writes:
> BR of libjpeg-devel now pulls in libjpeg-turbo-compat-devel, but this doesn't
> really work as a drop in replacement because those headers are in
> /usr/include/libjpeg-turbo-compat/.
Yeah, I just whinged about that at bz #887013.
> Shouldn'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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum upgrade from F17 to F18
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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
"M. Edward (Ed) Borasky" writes: > I've now done half a dozen F18 multi-boot installs and I must say it's > a miracle I haven't over-written something I wanted to keep. The thing > that would make it usable for me would be very simple - just put the > partition names on the labeling so I know what's going to end up > where! The rest of the installer is fine but the partitioner needs > either a user interface redesign or extensive documentation. Indeed, it's *spectacularly* bad. Aside from the point you make, I find that it doesn't show you what actions have already been chosen: as soon as you select any of the inadequately-labeled existing partitions, that partition disappears completely from the display. So at the end of the process, all you have to go on is a display of the partitions you've *not* selected to be mounted and/or overwritten. Want to double-check your choices before you push the big red button? Good luck with that. I do like the functionality of showing you the former/existing usage of each partition, but that ought to be an annotation on something that's laid out more like the old display. 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
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
Simon Lukasik writes: > Currently, each Fedora release is kept alive for 13(+/-) months. There > were dozens of threads about shortening or prolonging period -- but I am > not sure if something like the following has been ever discussed: > Each N-th Fedora release -- where N%3==1 -- is alive for 7 months. > Each N-th Fedora release -- where N%3==2 -- is alive for 7 months. > Each N-th Fedora release -- where N%3==0 -- is alive for 19 months. > Additionally, maintainers might be encouraged to push their system wide > changes into N%3==1. As well as they might be encouraged to make the > Fedora N%3==0 their best bread. Wouldn't that just encourage 99% of average users to ignore the short-lived releases? It would sure be a damn tempting approach for me. (Personally, all I want out of Fedora is a stable platform to get my work done on, and the less often I have to reinstall, the better.) I think what you'd have using the short-lived releases is just the same kind of brave souls who are willing to run rawhide or pre-release branched systems. And there aren't that many of them, so you'd get little QA, which would help to ensure those 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 mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
Panu Matilainen writes: > On 11/04/2012 12:17 PM, Michael Scherer wrote: >> And I am doubting that changing the release model will suddenly make >> people do QA. > Adam's point is that reducing the number of branches requiring QA should > permit more thorough QA with the scarce resources available, resources > which currently are spread too wide and too thin with the current model. I understand his hope that it would help, but TBH I think it would make things worse not better. Consider: * Currently, we get barely-adequate QA on the frontmost Fedora branch and none to speak of on the back branches. (Certainly for my packages, the standard update cycle is "push update to testing, wait however long bodhi makes me wait, push to stable" because nobody ever adds any karma except maybe in the latest branch.) That's tolerable, actually, because you're not supposed to push anything but low-risk bugfix updates into the back branches. If you think it needs testing you probably shouldn't be pushing it there. * In a rolling release model, however, major changes are supposed to eventually get pushed into all the branches. Each time one gets pushed further back, an appropriate amount of QA would need to get done, if you want to have any expectation of not breaking that branch. This looks like *more* QA to me, not less. The core problem I see here is that in a rolling-release environment, there's nothing to ensure that major multiple-package-affecting changes hit the "stable" branches in a consistent order. That means that each time you push one back, you are creating a unique new package set with a unique new set of potential issues, and that's why QA would actually be needed. Now it's 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
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
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 maintain the level of > *actual* stability our current 'stable' releases provide with a model > such as I describe, while substantially reducing the amount of resources > we're wasting at least _theoretically_ maintaining up to four releases > at once (currently, 16, 17, 18 and 19). Well, maybe, but yeah you weren't very clear about that. In any case, I'm not seeing how we handle things like library ABI breaks with a rolling release model ... at least not without more work, rather than less, than we have now. > If you're using a Fedora release today you're _already_ fighting OS bugs > more often than most people do, I'd say. I don't buy that really. I hit very few bugs in Fedora -- fewer than in OS X for instance. Possibly this is because I use it as a headless server as much as possible, and thus avoid bugs in the desktop-related code. As a development platform it's remarkably stable. (Now admittedly, I never run rawhide, and generally wait till a month after "official release" before updating my main workstation to a new Fedora version. But with those simple precautions, it is very stable.) regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
Adam Williamson writes: > On Fri, 2012-11-02 at 21:07 +0100, drago01 wrote: >> I disagree with that. Fedora releases had some small regression >> introduced via updates from time but is is *very* usable as a stable >> operating system. > I disagree. It's usable by the kind of people who use Fedora. Uh, no. What you describe is usable by the kind of people who use rawhide. Which is what, 1% of our user base? If that. Abandoning any pretense of having stable releases will eliminate a huge fraction of the user community. For sure it will eliminate *me*. I'm not in the business of fighting OS bugs every single day, and I will not be forced into that business. I have other things that I'm more productive at. I'm curious what you think package maintainers will do their package maintenance on, if there is no Fedora version that they can trust 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
=?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 suffice to achieve just that.
Somehow, we are failing to communicate.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= writes: > On 11/02/2012 03:32 PM, Matthew Miller wrote: >> On Fri, Nov 02, 2012 at 03:12:56PM +, "Jóhann B. Guðmundsson" wrote: >>> Dead/un-maintained packages need to be removed/reassigned at the >>> very *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 convenient. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Stanislav Ochotnicky writes:
> Quoting Michael Cronenworth (2012-11-01 18:33:24)
>> I've wanted to write up a blog post about my plan for a rolling release,
>> but I'll post a snip-it here.
> I recently came up with similar 3-layer idea.
In my little corner of the system, the main thing that causes
distro-level issues is new upstream versions of libraries, carrying
API/ABI breaks. (Recent examples include the libpng 1.2.x -> 1.5.x
and libtiff 3.9.x -> 4.0.x upgrades.) To push one of those into
rawhide, we at least have to rebuild all dependent packages, and
typically some of them need source-level patches too. In the current
model, once that's been done in rawhide, the problem is over: all those
packages will propagate to release branches together. ISTM a rolling
release would make this sort of thing enormously more complicated.
Almost certainly, not all those packages would be at similar levels of
stability and so there would be no point at which they could all get
pushed to any stable branch. How would you handle that without creating
a huge amount of extra work for packagers? Keep in mind this type of
thing happens *constantly*, 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
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Adam Williamson writes: > ... Practically speaking, for F18, > though, I think we just need to soldier on with newUI and get it done as > best we can. Obviously slipping the schedule by a week again and again > in response to the latest fire isn't the best way to do things, but > stepping back and taking a wider view, a release that's a month or two > behind but with a reasonably solid new anaconda wouldn't be a disaster. My concern at this point is exactly that we're "slipping a week at a time", rather than facing up to the *undeniable fact* that anaconda is not close to being shippable. If we don't have a workable contingency plan, I think the best thing to do would be to start slipping a month at a time. And drop the beta-freeze restrictions, until we reach a point where anaconda actually is beta quality. Other people have work they could usefully be getting done, except that they have to jump through these beta-freeze hoops --- which not incidentally are slowing down anaconda work too. It's insane that we are wasting time debating whether anaconda bugs are release blockers or beta blockers or only NTH, when any honest evaluation would recognize that the whole thing hasn't reached alpha quality yet, and *all* those bugs had better get fixed if we don't want F18 to permanently damage the reputation of Fedora. You can slip a month (or two) honestly, or you can fritter it away a week at a time, and 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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
It's time somebody asked this, so ...
Adam Williamson writes:
> What is missing from TC6 and will be added in the next build is the
> ability to choose to reformat the partition. If you do not want to
> reformat it, this is not a problem for you.
It appears to me that anaconda is months away from being shippable.
It's still got major features that are incomplete (one example above,
but there are more), and I don't seem to be able to do anything at all
with it without hitting serious bugs.
How is it that we're even considering shipping this version for F18?
For 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
Re: MariaDB: Packagers needed
Reindl Harald writes:
> i doubt MariaDb would be interface-compatible in most cases
> BUT not binary comatible as you can also not replace MySQL 5.1
> against MySQL 5.5 without compat-packages (remi did outside
> fedora-packages) as long depending packages are linked against
> a specific version
Just for the record, we *did* replace 5.1 with 5.5 without any compat
package, back in Fedora 15. It seemed to go just fine; we had to
rebuild dependent packages, but that was about it (and there weren't
that many). I don't see any reason to think that replacing mysql with
mariadb would be harder than the 5.1-to-5.5 transition was.
And given Oracle's recent antics (refusal to release any information
about security patches, not including new regression tests in releases,
etc etc) we ought to be thinking very hard about doing just that.
Reality is that mysql is now open source in name only.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd macros (f18+)
Lennart Poettering writes:
> But then we'd introduce two macros now, for two old distros, that make
> no sense on the next distros anymore but we could never get rid of them
> anymore, because we'd break the old packages...
So what? It's not like the carrying cost 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.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PostgreSQL 9.2 for F18?
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 personal web server is running on F18 > with updates-testing enabled. Most of the testing will be running simple > queries generated by web requests. Filed at https://admin.fedoraproject.org/updates/postgresql-9.2.0-1.fc18 regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PostgreSQL 9.2 for F18?
Bruno Wolff III writes:
>MichaÅ Piotrowski wrote:
>> Is there any chance that 9.2 will be available for F18?
> I think for 9.1 Tom pushed it just before beta when a few of us promised
> to do some testing pronmptly.
> So if 9.2 gets released before f18 beta there 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.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
Scott Schmit writes: > On Tue, Aug 28, 2012 at 09:39:32AM +0200, Miloslav TrmaÄ wrote: >> This optimizes the migration path at the cost of making the final >> state ugly; I'm not sure that is a good bargain. > Once F20 rolls out and F17 goes EOL, maintainers can simply > s/systemd_post_enable/systemd_post/ and then things won't be so ugly (or > final). I remain of the opinion that it's not a good idea to remove all trace of the per-package enable decisions from the packages themselves. *If* we get to F20 without realizing that we'd like the packages 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.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving pid files from /var/run/$name.pid to /var/run/$name/$name.pid
Hans de Goede writes: > Today I received a bug report to mv sensorsd's pid file from > /var/run/sensorsd.pid to > /var/run/sensorsd/sensorsd.pid, see: > https://bugzilla.redhat.com/show_bug.cgi?id=851428 The traditional argument for not creating pidfiles directly in /var/run is that a daemon that does that has to be started as root, else it won't have permission to write /var/run. A daemon that is intended to run under some non-root UID works a lot better if you make a subdirectory owned by that UID. mysql, for instance, has always used /var/run/mysqld/mysqld.pid. I know nothing about the security level of sensorsd --- if it has to be root-privileged anyway, this argument doesn't have any force for you. But it's generally safer to avoid running daemons as root if that's not absolutely necessary. > Making the requested change means making changes to the daemon C-code, > and if we then upstream these changes, they will cause issues for > other distro's. So I think that upstreaming the necessary changes is > going to be a problem. IMO, if a daemon makes any such assumption in a nonconfigurable way, it's broken and upstream 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 whatsoever. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
Tom Callaway writes:
> 3) We'll adjust the guidelines like this:
> If your service is explicitly enabled by default in Fedora 16 or 17, and
> you wish to have a shared spec file, you will need to add a
> conditionalized call to the "%systemd_post_enable" macro, as follows:
> %post
> %if %{defined fc16} || %{defined fc17}
> %systemd_post_enable apache-httpd.service
> %else
> %systemd_post apache-httpd.service
> %endif
Surely F18 could define %systemd_post_enable as a synonym for
%systemd_post. The entire point of this thread is to make things
simpler for packager maintainers, not load them down with cross-branch
differences. (If I wanted to have a version-dependent %if in there,
I could have done that without any help from the macros.)
A larger point here is that I don't think it's an amazingly good idea to
be removing all 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
Re: Mass changes to packaging
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 they are supposed to replace. Nobody is >>> suggesting that the preset stuff ought to go into the released branches; >>> only that we don't want to have to maintain different specfile versions >>> for the different branches. And if these things are macros, we should >>> not have to. >> The thing is that previously we had to different snippets, one for >> enabling a service after installation, one for leaving it disabled. With >> the macros there is only one which checks the preset policy whether >> something should be enabled. Hence we can't really map the old logic to >> the new macros, I fear. > Well, you could have two macros -- pre-F18 they do what they do now, > F18+, they do the same thing and defer to the policy. Yeah. The plain macros could be the non-auto-enable snippets, which is what the majority of services will be. Then a different macro name for services that think they should auto-enable. TBH I think that is probably a better design than what is there now, because the ground truth for the default enable decision *ought* to be in the packages, and this is as good a way to express that as any. Setting things up so that the packages have no say in this is just going to be a maintenance headache long-term: whoever is "in control of the policy" is going to be deluged with this that and the other change request. It would be a whole lot more maintainable if the "policy" only had to express deltas off the per-package defaults, and not contain every single decision. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
Lennart Poettering writes: > On Wed, 22.08.12 09:25, Kevin Fenzi (ke...@scrye.com) wrote: >> I'll add a me too here. >> >> Any word on if the macros can/will be back-ported to f16/f17? > The preset logic is actually already available in F17, so we could > theoretically backport that, but this would mean we'd also have to > create and maintain a preset policy file for F17, and that's the bit I > am not sure i'd like to do. > Without the preset policy the macros would only turn things off after > installation, never on. What I would want to see in F16/F17 is macros that exactly duplicate the previously-standard snippets they are supposed to replace. Nobody is suggesting that the preset stuff ought to go into the released branches; only that we don't want to have to maintain different specfile versions for the different 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
Re: Mass changes to packaging
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) scriptlets AFAICS. >> They don't touch the service's enable state. > Maybe what I am seeing is something different. I certainly have services > turn back on after updates that I have disabled. sendmail is one example. Hm, that seems pretty odd. sendmail's %post script is %post if [ $1 -eq 1 ] ; then # Initial installation /bin/systemctl enable sendmail.service >/dev/null 2>&1 || : /bin/systemctl enable sm-client.service >/dev/null 2>&1 || : /bin/systemctl daemon-reload >/dev/null 2>&1 || : fi which should not do anything on an update. It would auto-enable if you were installing the package when it was previously not present, but that isn't what you're describing. File a bug maybe? regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
Bruno Wolff III writes: > On Tue, Aug 21, 2012 at 11:59:29 -0400, >Bill Nottingham wrote: >> Presets are a valuable new feature for both distribution constructors >> and administrators - rather than having a single hardcoded policy *in >> the packages* about what starts and doesn't start (and requires rebuilding >> to fix), presets allow an easy way for: > 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) scriptlets 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
Re: Mass changes to packaging (was: Re: New: Introduce new systemd-rpm macros in [...])
"Richard W.M. Jones" writes: > I just received about a dozen bugs like this: > On Tue, Aug 21, 2012 at 02:16:42PM +, bugzi...@redhat.com wrote: >> https://bugzilla.redhat.com/show_bug.cgi?id=850364 > [...] >> Summary: Introduce new systemd-rpm macros in watchdog spec file > [...] Yeah, I got a couple of those too. I do not wish to make the proposed changes, nor would I be happy if someone made them for me, because I do not want to have unnecessary divergences between the spec files for different Fedora branches. That not only creates issues for cherry-picking updates, but it means that I can't for example test-build a rawhide SRPM on my F16 work machine. If the incompatibility is *necessary* then I'll put up with it, but as far as I can see this is only cosmetic at this point. I'd like to see these macros back-ported into F17 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
Re: PostgreSQL 9.2 for F18?
=?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 list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
postgresql Unix-domain sockets moving
Just a heads up: As of postgresql-9.1.4-5 in F17 and later, the postgresql server will create a Unix socket in /var/run/postgresql, as well as in the traditional location of /tmp. /var/run/postgresql is also now the default location where libpq will try to contact the server for a local connection. This change should fix problems with daemons being unable to talk to the database if they run under PrivateTmp (bug #825448). For everybody else, it should be transparent in theory ... but you all know the difference between theory and practice. Let me know if you hit a problem. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Is package lookaside cache based on file name, or md5sum?
Somebody please refresh my memory on this ... I seem to recall reading
that the lookaside cache stores and retrieves files based on their
md5sum, and won't care if two files with different checksums were given
the same name. True?
The particular case I have is that I want to re-generate a documentation
PDF file, and re-upload it to lookaside cache, without changing its
name. So in the "sources" file the md5sum would change, but not the
file name. Will that work, or screw things up?
(Possibly this is explained somewhere in the project wiki, but I didn't
find it...)
thanks, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Insane results from mock "rawhide" build
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 did another rm -rf /var/cache/mock/* and tried again a couple hours
ago, and got a sane-looking package set. So I don't know what the heck
happened last night. It was shortly after somebody on the fedora
infrastructure team had broken and repaired lookaside-cache downloads,
though, so maybe there was some lingering effect of that.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
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 that, but you're probably right.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Insane results from mock "rawhide" build
I just did /usr/bin/mock -r fedora-rawhide-x86_64 /tmp/freeimage-3.10.0-10.fc18.src.rpm after having flushed /var/cache/mock, so that current packages would get pulled down. Or so I thought. When the build failed and I went to find out why, I discovered that it had supplied me with an ancient libtiff: DEBUG util.py:257: libtiff-devel x86_64 3.9.5-2.fc17 fedora 451 k DEBUG util.py:257: libtiffx86_64 3.9.5-2.fc17 fedora 136 k That version of the package was obsoleted in April, not only in rawhide but F17 as well, 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 mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: redhat-lsb-desktop versus transition to current libpng
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 short-term >> stopgap; I'm sure it violates all sorts of packaging guidelines. > Rather than working around the review process, just go ahead and make > the package, upload it somewhere, open a review ticket, and I'll review > it after lunch today. I'm familiar with that package, so it should be a > very quick review for me to complete, and the branching request should > be able to be processed today. Thanks for offering! Review request is in bug #845110 regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: redhat-lsb-desktop versus transition to current libpng
Adam Williamson writes: > On Wed, 2012-08-01 at 00:21 -0700, Adam Williamson wrote: >> A very quick search returns this: >> http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Desktop-generic/LSB-Desktop-generic/libpng.html Thanks. The links I was given previously didn't lead me to that. > Well, that's really it. The format of LSB is a bit odd to a lay reader, > but AFAICT, it really does mean: to be technically in compliance with > LSB-desktop, you need to ship a libpng12.so.0 which provides the listed > functions. End of story. I don't see a workaround. Yeah, looks like it. (I think redhat-lsb.spec is pretty broken in that it onlu appears to be trying to force a particular soname version for libpng, when the spec clearly demands a particular version for each of these libraries. But that's not very relevant right now.) 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 short-term stopgap; I'm sure it violates all sorts of packaging guidelines. Is there any way we can fast-track 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 lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Provenpackager help needed to complete libpng/libtiff transition
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 filed patches to fix them, >> but don't have permissions to do it myself. If any provenpackagers >> have a bit of time to spare, could I pester you to look at these bugs? > Thanks for doing the patches! Have you tried to upstream them, or are > the upstreams for these dead? I have not; I supposed that the respective package maintainers would be in a better position than me to pester their upstreams. These bugs are the ones that I've not gotten a response on from the maintainer, so perhaps the correct question to be asking is whether the Fedora maintainer is asleep at the wheel ... regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
redhat-lsb-desktop versus transition to current libpng
I have been working for the better part of a year on moving Fedora off
of libpng's obsolete 1.2.x release series and onto the current 1.5.x
series. We are practically there now, and I had hoped to drop libpng
1.2 from the distribution before the F18 branch. However, I find that
redhat-lsb-desktop still has a dependency on 1.2, and it's not even
because that package contains any PNG-using code; rather, there's a
manually inserted version-specific dependency in the specfile:
%ifarch %{ix86}
Requires: libpng12.so.0
%endif
%ifarch x86_64
Requires: libpng12.so.0()(64bit)
%endif
This is unlike that specfile's treatment of any other library
it requires. I have been told, at
https://bugzilla.redhat.com/show_bug.cgi?id=835777#c8
that the LSB standard requires libpng 1.2, but without any supporting
evidence. I looked at the underlying ISO documents and don't see any
requirement for libpng at all, let alone 1.2 in particular. I am
doubtful that every other Linux distro is maintaining this long-obsolete
libpng version, too.
I would like to know how to proceed here. "You should keep libpng 1.2
around indefinitely, on the basis of no evidence" 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
Provenpackager help needed to complete libpng/libtiff transition
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 filed patches to fix them,
but don't have permissions to do it myself. If any provenpackagers
have a bit of time to spare, could I pester you to look at these bugs?
Pixie 843294
dcmtk 819236
fuse-emulator 843645
grace 843647
gshutdown 843648
luakit 843652
pngnq 843655
tucnak2 843658
Thanks!
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18
Kevin Kofler writes: > I'm looking into these: > Bill Nottingham wrote: >> Package komparator (fails to build) >> Package krecipes (fails to build) >> Package qalculate-kde (fails to build) >> Package tesseract (fails to build) > but since the build.log files are no longer available, I need to run new > builds first, so it's going to take a while. :-( The tesseract issue is documented at bz 843275. In general, I wish people would be closing out the relevant bugs when they fix these packages ... > I also really dislike the way FTBFS are 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
Re: Suggestion: Continuous mass rebuild
"Richard W.M. Jones" writes: > Currently we're doing a mass rebuild about every couple of releases, > ie. once a year. > Since Dennis Gilmore has written this rebuild script already, why > don't we run the script more or less continuously? Obviously we could > pace the builds so they happen for each package about once a month and > don't overload Koji. > Then we track packages that don't build, say, 3 times in a row, and > file FTBFS bugs for them and after that prioritize fixing them or kick > them out of the distro. I don't think we should do this exactly like a regular mass rebuild: it would create useless churn in the package set, specfile changelogs, etc. What would be useful is to do scratch rebuilds on this sort of schedule, without changing anything in git, and file bugs anytime a rebuild fails. That is more or 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
Re: [ACTION REQUIRED v4] Retiring packages for F-18
Bruno Wolff III writes: > On Wed, Jul 25, 2012 at 18:24:52 -0400, >Bill Nottingham wrote: >> Updated with new list of packages that have failed to build. >> Package stratagus (fails to build) > statagus is currently FTBFS because it isn't using the newer libpng API. > Assuming that's all that's wrong with it, I'll be able to fix this soon. FWIW, quite a few of the packages in Bill's FTBFS list have dependencies on libpng-compat, which makes me suspicious that the libpng API changes might be the reason (or one reason) why they FTBFS. I've spent this afternoon preparing patches for the remaining old-libpng dependencies that are *not* on that list. I'm willing to help out with libpng issues in these too, assuming that their maintainers care about keeping them alive. I'm still hoping 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
Re: [ACTION REQUIRED v4] Retiring packages for F-18
Jesse Keating writes: > On Thu, 2012-07-26 at 15:37 -0700, Adam Williamson wrote: >> The date is useful for making it >> immediately obvious how up-to-date a package is, I guess, but it has no >> really key function for differentiating builds any more.) > It's not even that. With CVS you could have done a checkout of a tag > which could be quite old compared to the day's date you did the > checkout. Using the date somewhat assumes you're doing a checkout of > HEAD, which isn't always the case. I'd move that embedding the date in > there is of little use. The good thing about putting the date in there is that it's likely to help the NEVR sort correctly, whereas git hashes for instance will certainly not help. Upstreams have been known to change SCMs from time to time, as well. I realize we're supposed to bump 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
Re: [ACTION REQUIRED v3] Retiring packages for F-18
Bill Nottingham writes: > Before we branch for Fedora 18, as is custom, we will block currently > orphaned packages and packages that have failed to build since Fedora 16. > The following packages are currently orphaned, or fail to build. > [snip] That list seems seriously incomplete. I'm aware of at least these others that have FTBFS in both F17 and F18 mass rebuilds, as evidenced by their release tags: alevt-0:1.6.2-16.fc15.x86_64 eboard-0:1.1.1-7.fc15.x86_64 enigma-0:1.01-15.x86_64 fbdesk-0:1.4.1-7.fc15.x86_64 fuse-emulator-0:1.0.0.1-1.fc16.x86_64 gconf-cleaner-0:0.0.3-2.fc15.x86_64 gdmap-0:0.8.1-8.fc15.x86_64 gimmix-0:0.5.7.1-2.fc15.x86_64 gnofract4d-0:3.13-2.fc15.x86_64 grace-0:5.1.22-9.fc16.x86_64 gshutdown-0:0.2-8.fc16.x86_64 gtksourceview-1:1.8.5-8.fc15.i686 gtksourceview-1:1.8.5-8.fc15.x86_64 hardinfo-0:0.5.1-3.fc15.x86_64 libgdiplus-0:2.10-2.fc16.i686 libgdiplus-0:2.10-2.fc16.x86_64 libgtksourceviewmm-1:0.3.1-7.fc15.i686 libgtksourceviewmm-1:0.3.1-7.fc15.x86_64 libharu-0:2.1.0-3.fc15.i686 libharu-0:2.1.0-3.fc15.x86_64 libpano12-0:2.8.6-5.fc15.i686 libpano12-0:2.8.6-5.fc15.x86_64 libpano12-tools-0:2.8.6-5.fc15.x86_64 metapixel-0:1.0.2-7.fc15.x86_64 munipack-0:1.2.10-2.fc15.i686 munipack-0:1.2.10-2.fc15.x86_64 pngcrush-0:1.6.10-7.fc15.x86_64 pngnq-0:1.1-1.fc16.x86_64 printoxx-0:2.8.1-2.fc15.x86_64 putty-0:0.60-7.20100910svn.fc15.x86_64 rpmdepsize-0:1.0-7.fc15.x86_64 stratagus-0:2.2.4-9.fc15.x86_64 tangogps-0:0.99.4-3.fc15.x86_64 tesseract-0:3.00-2.fc15.i686 tesseract-0:3.00-2.fc15.x86_64 tucnak2-0:2.31-1.fc13.x86_64 wmdrawer-0:0.10.5-11.fc16.x86_64 wmfire-0:1.2.3-4.fc15.x86_64 xaos-0:3.5-2.fc15.x86_64 (The reason I've got my eye on these is that they'd be what breaks if I remove libpng-compat and/or libtiff-compat, which I'd seriously like to do before F18 ships. Those were never intended to be more than a short-term workaround while people got their dependent packages rebuilt for the libpng and libtiff major version upgrades. I don't want to carry them just to support packages that are long-term FTBFS offenders.) regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Accidental soname bump in libdbi
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 I'll > re-rebuild. Done in libdbi-0.8.4-2, which looks like it's in the rawhide buildroot now. Sorry again for the wasted effort. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Accidental soname bump in libdbi
Last night I updated libdbi from 0.8.3 to 0.8.4, without paying much
attention since a tarball diff showed that upstream hadn't done anything
except update the configure script and supporting files. However, this
morning the broken-deps script whinged about it. Looking more closely,
it appears that the new script causes it to build "libdbi.so.1.0.0"
instead of "libdbi.so.0.0.0". Given that the upstream major version
number has not changed, it seems to me this is bogus and the package
should continue to use "0" as the soname major version.
So I'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
Re: Support for legacy init script actions for systemd services
Mathieu Bridon writes:
> Especially since it handles multiple postgresql instances with an
> optional parameter.
> Tom, can you try to make sure the script
> in /usr/libexec/initscripts/legacy-actions allows the same?
Unless Bill hacked /sbin/service to pass additional parameters through
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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for legacy init script actions for systemd services
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 the only one that prefers your separate postgresql-setup > script over the call to service. IMHO "service" is dead. Well, I wouldn't remove postgresql-setup, since it's now been there long enough to have possibly acquired some fans. But it's the non-fans who are complaining... regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for legacy init script actions for systemd services
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= writes: > On 06/26/2012 10:12 PM, Miloslav TrmaÄ wrote: >> Breaking "service foo action" reason was just an unnecessary >> regression that shouldn't have happened in the first place. > Agreed and honestly this sudden turnaround now smells a bit like RHEL > "7" was a big contributing factor to that decision since this has been a > know problem from the start.. I think you're right, and the reason why that's an issue is that people who were previously on RHEL6 are being exposed to systemd for the first time. And they don't like it. >> Asking upstreams to "adopt" things that used to be done in >> distributions (and therefore were consistent within a distribution) >> without suggesting a good convention to follow (suggesting a high >> probability that they will not be consistent, and distributions will >> not be "allowed" to make them consistent) sounds like a change for the >> worse from the original state (it is, after all, one of the primary >> roles of a distribution to collect various differing upstreams and >> make a consistent OS from them) - but, well, the result will not be >> different from any other inter-project inconsistencies, so I don't >> view this as a "problem". > I would rather argue that various upstreams should reach agreement on > how things should properly be done and moved forward I don't presume to speak for all upstreams, but I can tell you that postgresql in particular is not likely to want to get involved here. They have other things to worry about, and have always thought that things like initscripts are mainly a packager's province anyway. But the big picture from our point of view is that "service postgresql initdb" has been the way to initialize a postgresql database for quite a few years, on many platforms besides Red-Hat-based ones. *We* are the ones who are out of step, and only somebody 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't get his wrist slapped by FPC, I'll be implementing this for postgresql tomorrow, because I'm tired of hearing complaints about it. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for legacy init script actions for systemd services
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= writes: > On 06/26/2012 08:49 PM, Miloslav TrmaÄ wrote: >> The preferred new way is that upstream implements the action in a way >> that is same across all distributions. Which, in some sense, does not >> answer your question. > First and foremost how big of a problem do you guys believe this? > Secondly cant we add the rule that packager are required to request > permission from fesco to follow what is suggested before they implement > it so it can be ensured that it's actually required/necessary for them > to do this and at the same time a list gets created and populated with > the relevant packages? The idea seems to be that you'd only implement actions that exist in non-systemd initscripts. As long as people adhere to that, I don't see that we need controls or per-package permissions. And I don't really see why people wouldn't. There are two possibilities here: a given action is commonly performed via "service special-verb" on non-systemd platforms, or it's done some other way. If it's done some other way elsewhere there is no very good reason not to do it the same way in systemd-land. On the other hand, if people are used to "service special-verb", the only likely result of taking that away is that they will think systemd sucks and try to avoid platforms that use it. Personally, having gotten beat up repeatedly 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
Re: Support for legacy init script actions for systemd services
Bill Nottingham writes: > Better late than never (and thanks to Michal Schmidt), I've added support to > /sbin/service for running legacy actions if specified. I'm confused. Only 2 months ago I was told that this was firmly against policy and I should get rid of code that assumed it worked (which, btw, it already did): http://lists.fedoraproject.org/pipermail/packaging/2012-April/008314.html Did that packaging guideline get reverted already? > For each legacy option (such as "xyzzy") supported by your init script (such > as "frobozz"), package 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 https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service restart question
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 >> sure that enabling restart is safe. So while recommending that services >> enable this after suitable testing *might* be a good idea, turning it on >> by default seems like a horribly bad one. > Since 832029 is not a public bug, can you give the gist of the issue? Ah, sorry about that. The deal is that mysqld has historically been automatically restarted after crashes by a supervisor script mysqld_safe. When we went over to systemd-land we said "hey, systemd can do that, and we'll have one less process required". However, it's not working so well: (1) systemd is not able to distinguish a crash that should be restarted from, say, failure due to misconfiguration in /etc/my.cnf. (It's not clear whether restart settings other than "always" would help here, but in general it seems obvious that there are likely to be service- specific reasons for restarting after some failures and not others.) (2) Right now it appears that there is a bug in systemd that causes it to ignore its respawn limits, such that if mysqld is indeed exiting immediately due to misconfiguration, it gets restarted immediately. Lather, rinse, repeat. Indefinitely. (3) Even if StartLimitInterval/StartLimitBurst were operating properly, there are scenarios where mysqld will fail to start up, but be slow enough about it (like a couple of seconds) that systemd's respawn suppression logic would not get triggered, so it'd keep on restarting it. So we'd probably need custom-tuned values of those settings if we decide to stay with using systemd for restart logic. I assume that (2) is just a bug that's going to get fixed pretty quick. But (1) and (3) seem like likely risk spots for other services. In the meantime I'm seriously considering reverting to mysqld_safe. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service restart question
Lennart Poettering writes: > On Mon, 25.06.12 16:57, Gary Kotton (gkot...@redhat.com) wrote: >> My understanding is that if there is a entry in the "Service" section >> "Restart=always", then we can rely on systemd to restart the service if >> it dies. >> >> Can someone please explain or clarify why this is not the default value? >> I can understand that this should not be set if there is another >> "watcher" process that can restart a failed service. > Well, simply because we have no policy about it. 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 sure that enabling restart is safe. So while recommending that services enable this after 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
Re: multilib conflict with doxygen generated pdf
Xavier Bachelot writes:
> Does anyone have any pointer on how to fix a multilib conflict with a
> doxygen generated pdf file ? I was able to fix the same multilib issue
> with the html files by modifying the footer to not include the
> timestamp, but I don't find any pointer on how to proceed for the pdf file.
Yeah, I find that the sgml to pdf toolchain also likes to put timestamps
into the PDF file. The solution I've used for many years is to build
the PDF doc once during package preparation, and upload it as an
additional sources file. This eliminates the timestamp skew problem
and also greatly reduces the BuildRequires footprint of the package.
You can look into the postgresql package if you want to borrow any
details (the generate-pdf.sh script is probably pretty postgresql
specific, but the packaging details around its use might be worth
stealing).
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Setting up Koji question - postgres
Mathieu Bridon writes: > On Sat, 2012-06-02 at 10:14 +0200, Dan Horák wrote: >> as it seems the koji sql files are not packaged you must get them from >> the koji source package > Not packaged? > $ yum whatprovides \*koji\*sql > [... snip ...] > koji-1.6.0-3.fc17.noarch : Build system tools > Repo: fedora > Matched from: > Filename: /usr/share/doc/koji-1.6.0/docs/schema.sql > Filename: /usr/share/doc/koji-1.6.0/docs/schema-upgrade-1.4-1.5.sql > Filename: /usr/share/doc/koji-1.6.0/docs/schema-upgrade-1.3-1.4.sql > Filename: /usr/share/doc/koji-1.6.0/docs/schema-upgrade-1.2-1.3.sql Why is that sort of thing being kept in %doc? I always thought that doc files should be those that aren't required in the operation of the software, which is surely not the case if these are needed to set up the database. 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.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stop the git abuse
Kevin Kofler writes:
> Remi Collet wrote:
>> For me, the %changelog "must" stay branch specific.
>> p.e, I don't want the f16 branch polluted by "mass rebuild" entry from
>> rawhide.
> You're just too pedantic about that. I stopped caring about this issue eons
> ago, even in CVS days, where I'd just "sync from devel", i.e. overwrite the
> branch specfile with the one from devel. And I wasn't the only one doing
> that. Everything else is just unmaintainable.
> Just keep the branches in sync. If the changelog 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.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging issue: what to do about debuginfo after arch->noarch change?
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, and you upgrade, >> the old debuginfo will still be there even though it's now irrelevant. >> Is this a bug, and if so what should I do about it? > Hmm. I'm inclined to say that we ought to resolve this either in > anaconda or preupgrade by running some sort of "cleanup" script that > looks for orphan debuginfo and flushes them down the drain, as opposed > to carrying Obsoletes. Note that the case Martin was concerned about was a plain old "yum update" of the package, not an OS-wide upgrade. I'm unsure to what extent yum knows about debuginfo, but that's where smarts would need to be added to address his concern. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Packaging issue: what to do about debuginfo after arch->noarch change?
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, and you upgrade,
the old debuginfo will still be there even though it's now irrelevant.
Is this a bug, and if so what should I do about it?
It seems to me that it's not a bug, because AFAICS there has never been
any attempt to enforce that only relevant debuginfo packages are
installed. For instance, there isn't any Requires: at all from a
debuginfo package to its base package, let alone an exact-version-match
Requires:.
It was suggested that I could add an Obsoletes: line to the specfile
to get rid of the old debuginfo package, but this seems a bit weird
to me, and inconsistent with the fact that there aren't Requires:
linkages.
I don't see anything in 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
Re: New libtiff version in rawhide, requires dependent packages rebuild
Ralf Corsepius writes: > On 05/07/2012 10:08 AM, Michael Schwendt wrote: >> On Mon, 07 May 2012 08:07:22 +0200, RC (Ralf) wrote: >>> Digging BZ, koji and googling did not turn up any formal FTBFS, however >>> when trying to rebuild OSG, it indeed fail to build due to an issue >>> which seems unrelated to libtiff. >> Which, IMO, is exactly what Tom wants to point out. > Thanks, then I likely misunderstood him. Yes, I just said that I observed a failure that seemed unrelated to libtiff. > Makes me wonder what actually has broken building OSG. > Must be a recent change in of OSGs numerous build-deps, because it had > been rebuilt several times without major changes for ca. a year[1] What I'm seeing looks like something in pthreads changed: Linking CXX executable ../../bin/osgversion cd /builddir/build/BUILD/OpenSceneGraph-3.0.1/BUILD/applications/osgversion && /usr/bin/cmake -E cmake_link_script CMakeFiles/application_osgversion.dir/link.txt --verbose=1 /usr/lib64/ccache/c++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wparentheses -Wno-long-long -Wno-import -pedantic -Wreturn-type -Wmissing-braces -Wunknown-pragmas -Wunused -fpermissive -Wl,-z,relro CMakeFiles/application_osgversion.dir/osgversion.o -o ../../bin/osgversion -rdynamic ../../lib/libOpenThreads.so.2.6.0 ../../lib/libosg.so.3.0.1 ../../lib/libosgDB.so.3.0.1 ../../lib/libosgUtil.so.3.0.1 ../../lib/libosg.so.3.0.1 ../../lib/libOpenThreads.so.2.6.0 -lm -lrt -ldl -lz -lGL -Wl,-rpath,/builddir/build/BUILD/OpenSceneGraph-3.0.1/BUILD/lib: /usr/bin/ld: ../../lib/libOpenThreads.so.2.6.0: undefined reference to symbol 'pthread_cancel@@GLIBC_2.2.5' /usr/bin/ld: note: 'pthread_cancel@@GLIBC_2.2.5' is defined in DSO /lib64/libpthread.so.0 so try adding it to the linker command line /lib64/libpthread.so.0: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status If you are expecting this app to use 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
New libtiff version in rawhide, requires dependent packages rebuild
I have pushed libtiff 4.0.1 into rawhide, replacing libtiff 3.9.5.
This entails a library soname bump and a few small source-level
incompatibilities, as detailed at
http://www.remotesensing.org/libtiff/v4.0.0.html
By my count there are about a hundred dependent packages (see list
below), so to avoid breaking rawhide until everything can be rebuilt,
I have put the old 3.9.x library into a temporary subpackage
"libtiff-compat". (We used the same trick a few months ago for libpng
and it seemed to work all right.)
I did trial rebuilds of all these packages against libtiff 4.0.1,
and found only three that appear to need any source-code changes;
though another dozen have pre-existing FTBFS problems which means
I can't tell for sure if they would build against the new libtiff.
If any of these packages are yours, please rebuild at the soonest
opportunity. If you need advice 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 openslide
agoode vips
alexlan mapnik
ankursinha aeskulap
athimm vtk pre-existing FTBFS
awjbWindowMaker
awjbaterm
awjblcms
awjblibAfterImage pre-existing FTBFS (libpng related)
awjbscribus
bpostle enblend
bpostle hugin
bpostle libpano12 pre-existing FTBFS (libpng related)
bpostle libpano13
bpostle vigra
bruno ocaml-camlimages
bruno sear
chitleshLabPlot
chkrgthumb
corsepiuOpenSceneGraph pre-existing FTBFS
corsepiuk3d
dejigrads
dejitracker
devrim gdalpre-existing FTBFS
devrim grass
duffy cmyktool
ellert root
fab gipfel
fab vifir
fcomida luminance-hdr
giallu rawstudio
hobbes1069 OpenImageIO
hubbitusImageMagick
hubbitusfotoxx
ixs GraphicsMagick
jcapik openjpeg
jcollie spandsp
jjames xemacs
jnovy netpbm
jwrdegoede DevIL
jwrdegoede MagicPoint
jwrdegoede adanaxisgpl
karlik tesseract pre-existing FTBFS
kevin fontforge
kklic emacs
kwizart Pixie
kwizart aqsis
kwizart cinepaint
laxathomlibgdiplus pre-existing FTBFS (libpng related)
limbIo-language
limbSDL_image
limbargyllcms
lkundraklinks pre-existing FTBFS (libpng related)
lkundrakxteddy
madko darktable
mclasen gdk-pixbuf2
mclasen gtk2
mdomsch photoprint
mkasik evince
mrceresadcmtk pre-existing FTBFS
mtasaka xplanet
nphilippgimp
nphilippsane-backends
nphilippufraw
nphilippxsane
orion paraview
orion pslib
oronlibhocr
pghmcfc imlib
rakesh djvulibre
rakesh freeimage needs work for new libtiff
rakesh linphone
rakesh opencv
rathann dx
rdieter calligra
rhughes gnome-color-manager
rhughes lcms2
romaxpaint
s4504kr blender
s4504kr gnustep-gui
sharkcz podofo
sharkcz wxGTK
spotR
spotevas
spottkimg needs work for new libtiff
spotxloadimage needs work for new libtiff
steve perl-Imager
terjerosgle
terjerosmtpaint
thankdegraphics-strigi-analyzer
thankdelibs3pre-existing FTBFS
thanokular
thanqt
tnorth GREYCstoration
tnorth rawtherapee
tomhlibgxps
tsmetanaimlib2
tsmetanapfstools
tuxbrewrdigikam
twaugh cups
twaugh ghostscript
volter libgaiagraphics
volter libgeotiff
wolfy qfaxreader
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
John Reiser writes: > gdb nicely gives the work-around for denyPtrace, but the work-around > requires privileges to implement. So far the implementation history > of the denyPtrace feature leads me to fear loss of Functionality and > Usability for software developers. Indeed. This "feature" isn't going to make people more secure if the first thing on everyone's Fedora installation checklist is to turn it off. And that certainly will be on my checklist, if it goes in like this. A possible compromise that might allow software developers to live with the setting would be if the default excluded gdb (and any other tools that normally need ptrace) from its effects. I can see the point of disallowing ptrace from security-exposed things like firefox, but I'm not very worried about gdb being compromised. And, as I said, the alternative is that this 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
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
Mark Wielaard writes:
> Previously https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace
> implied that this feature could be turned on by an administrator,
> but recently it was changed to be on by default. Was that intended?
I certainly hope that's a mistake. If it's 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
Re: ARM as a primary architecture
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 for > such an obsolescent architecture. PPC stopped being relevant the day Apple > switched to x86. That opinion is flat out ridiculous. Or maybe it makes sense if you think consumer desktops are the be-all and end-all; but they are not. (If you do think that Apple's decisions are an important factor here, why are you so much not on board with pushing ARM? Apple's certainly doing their darndest to make ARM a mainstream arch.) >> But now that we've done that, putting in another one should be a high >> priority wish-list item. > I strongly disagree on that point. Non-x86 primary architectures are a major > pain that really needs to be avoided. And that opinion is simply wrong. You have provided no justification for allowing Fedora to get boxed in on a single architecture, which is the inevitable end result of the thinking you espouse. Pointing at individual deficiencies of individual arches is not a justification; especially not in view of all the problems x86 itself has got. The Linux community has slowly worked around x86's limitations, the same could happen for any other arch. The only reason this doesn't happen is people trying to justify not putting in the work by rationalizing that "that architecture is obsolete" or "Intel is the top of the heap today, so I don't need to bother thinking about anything else". Or in other words: you sir are not part of the solution, you are part of the problem. I'm not saying that I think ARM is the ideal other primary arch, but it seems to have more momentum than most of the other choices. We should be looking for ways to make it a PA, or make something else a PA. We should not be looking for excuses for monoculturalism. If we settle for that, we'll have only ourselves to blame when we become irrelevant, not too many years down the road. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
Kevin Kofler writes: > IMHO, if even in the future only x86 will fit the speed criteria to be a > primary architecture for Fedora, then so be it. I do not see a need for any > other primary architecture(s). Why do we absolutely have to support an > architecture with inferior practical performance as a primary architecture? To put it as succinctly as possible: monocultures are bad. Focusing on just one arch is dangerous; you end up with non-portable code, and non-portable code is more often than not inferior on more measures than just the fact that it only works on one arch. But even if that's the only thing wrong with the code, you're still boxing yourself in if you don't strive to make it portable. Do you really think that x86 will be the most desirable architecture forever? Things change fast in this business, and that arch is weighted down by enough bad ancient decisions that I think it's eventually going to lose out. I thought it was a serious error to drop PPC from primary-arch status. But now that we've done that, putting in another one should be a high priority wish-list item. I'm as concerned as anyone about whether we 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
Re: Does systemd expose any unit-file-parsing functionality?
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, understanding that later entries override >> earlier ones. And the really nasty problem with it is that the layout >> is simply broken by environment variable names or values that contain >> spaces. I don't mind so much needing to implement a "take the last >> match" rule, but it'd be nice if I didn't have to tell people they can't >> use a PGDATA path that includes spaces. I don't have an immediate >> proposal for making it better though. > This is shell? If it wasn't shell the clean way would be to simply go to > the bus and ask for this raw. Which is trivial and not prone to parsing > problems. Yeah, it's shell. > But you are right, we should drop the duplicate entry. I will fix > this. Added to the TODO list. What would be more useful is to fix the format ambiguity. After some thought, one possibility is to emit a separate Environment= line for each env var: Environment=PGPORT=5432 Environment=PGDATA=/var/lib/pgsql/data which is both unambiguous (at least, as long as there are not newlines in the variable values) and natural given the input language. If you wanted it to not be order-sensitive then yes you'd need to get rid of duplicates internally; don't know if that's important to you. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Does systemd expose any unit-file-parsing functionality?
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, but I guess I can pick it apart with some careful >> sed'ing. Better than trying to handle .include for myself, anyway. >> Thanks for the suggestion! > Hmm, what are you mising in the output format? We are always interested > in suggestions for imprvoement. The case that I was interested in was for postgresql, which needs to scrape the PGPORT port number setting and the PGDATA data directory path out of postgresql.service. Assuming that somebody has overridden the PGPORT setting by using a custom service file that .include's the standard one, 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, understanding that later entries override earlier ones. And the really nasty problem with it is that the layout is simply broken by environment variable names or values that contain spaces. I don't mind so much needing to implement a "take the last match" rule, but it'd be nice if I didn't have to tell people they can't use a PGDATA path that includes spaces. I don't have an immediate proposal for making it better though. > Note that this command will not show you the environment inherited by > the PID 1 or any other env that is passed on that is not explicitly > configured in the unit files. No, that's not a problem, I just need to know what's configured in the unit file(s). BTW, while I'm thinking about it: I found in testing that any editing of the on-disk files was reflected immediately in "systemctl show"'s output. Which was exactly what I wanted, but it surprised me quite a bit --- I was expecting that what this command shows is systemd's internal state and thus I'd have to do daemon-reload to make it update after an edit. Can I expect that that behavior will persist, or am I relying on something that's going to change? regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Does systemd expose any unit-file-parsing functionality?
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 such things, finds >> the file, and greps for the right lines. This seems unduly friendly >> with the file format, 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? > You can try > systemctl show -p Environment [ experiments with that ... ] Hm, the output format seems pretty ill-designed, but I guess I can pick it apart with some careful sed'ing. Better than trying to handle .include for myself, anyway. Thanks for the suggestion! regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Does systemd expose any unit-file-parsing functionality?
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 such things, finds
the file, and greps for the right lines. This seems unduly friendly
with the file format, 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 mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION NO LONGER REQUIRED] Retired packages for F-17
Peter Robinson writes: > On Wed, Mar 7, 2012 at 7:06 PM, Bill Nottingham wrote: >> If there aren't FTBFS bug reports in the future, that's going to make >> doing FTBFS-blocking tricky. Did you generate your list merely from >> "things with older dist tags, so they obviously didn't rebuild", or from >> some more canonical source? > Things with older dist tags that I then cross checked because they > were also not building on ARM. Most of them were ftbfs in both the > F-15 and F-17 mass rebuilds, some even in the F-12 mass rebuild! Matt > stepped down from his ftbfs some time ago and I've never seen anything > done about it since. I thought all along that that was something that should be done officially, using project resources, rather than having some volunteer do it on personal resources. Now it's time 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
Re: Detecting Postgres version during build
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "master" branch still invokes build in f17-candidate??
Jesse Keating writes:
> On 2/28/12 12:58 AM, VÃt Ondruch wrote:
>> If you say to Koji that it should checkout master at remote machine,
>> build a SRPM etc, why the Koji can't determine the proper %{?dist} at
>> remote machine? Why it takes the %{?dist} from local machine instead? It
>> makes no sense. It might work for other branches, but master is bit
>> different, so it should be handled differently.
> For the pure "build" command case, sure, we let koji decide. In fact,
> the way I've re-written the backend to fedpkg to make more use of python
> properties and lazy loading, the build command may not actually try to
> get this data. It's only the local commands that really matter.
Oh? In the complaint that started this thread, I showed an example of
launching "fedpkg build" in master branch and getting an fc17-candidate
result. That seems to me to prove that it isn't koji deciding.
In the particular case here it was harmless, since I would've just gone
and built the identical SRPM in f17 a bit later anyway, and (I trust)
rawhide will inherit the new f17 package too.
I can see the argument why "fedpkg srpm" and friends should produce
similar results to what you get from "fedpkg build", because I have lost
count of the number of times I've cursed the fact that it's impossible
to reproduce the koji build environment elsewhere. 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
Re: "master" branch still invokes build in f17-candidate??
Kevin Kofler writes:
> VÃt Ondruch wrote:
>> If you say to Koji that it should checkout master at remote machine,
>> build a SRPM etc, why the Koji can't determine the proper %{?dist} at
>> remote machine? Why it takes the %{?dist} from local machine instead? It
>> makes no sense. It might work for other branches, but master is bit
>> different, so it should be handled differently.
> Yes, for fedpkg build, the client should not have to care about what
> %{?dist} is at all. It should just ask Koji to build the current git hash in
> Rawhide 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
branches besides the one I have checked out.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "master" branch still invokes build in f17-candidate??
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 all my package directories after the branch, but I think
that it failed in this one due to uncommitted changes.)
So you're saying that fedpkg's behavior depends on the existence of
other, un-checked-out, branches in my local repo? This seems a
tad ... unreliable. Not to say surprising.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
"master" branch still invokes build in f17-candidate??
I'm definitely checked out in the master branch:
[tgl@rh3 master]$ git push
Counting objects: 11, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 1.13 KiB, done.
Total 6 (delta 3), reused 0 (delta 0)
To ssh://t...@pkgs.fedoraproject.org/postgresql
d44dce3..2e73ff7 master -> master
but:
[tgl@rh3 master]$ fedpkg build
Building postgresql-9.1.3-1.fc17 for f17-candidate
Created task: 3822862
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=3822862
Watching tasks (this may be safely interrupted)...
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?
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for a package maintainer for flam3
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.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
Michael Cronenworth writes:
> Kevin Kofler wrote:
>> PostgreSQL requires manual intervention at each upgrade (dump BEFORE you
>> upgrade, restore afterwards)
> As of PostgreSQL 9.0, there is an upgrade utility[1] that doesn't
> require a dump/restore.
But it does still require manual intervention, and there are still the
macro issues of whether you really want people to have to acquire some
DBA skillz to read their mail. I was *not* proposing this approach.
I remain of the opinion that mysql is also too heavyweight for this,
though. If the akonadi folk don'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.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
