Re: Bundled copies of the Porter stemmer library
Florian Weimer fwei...@redhat.com 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?
Dhiru Kholia dhiru.kho...@gmail.com 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
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: PIE breaks detection of available stack depth with getrlimit?
John Reiser jrei...@bitwagon.com 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
Re: MySQL and MariaDB in Fedora
Kevin Kofler kevin.kof...@chello.at 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
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: bison, flex have broken deps in rawhide
Bruno Wolff III br...@wolff.to 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
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 br...@wolff.to writes: On Fri, Apr 05, 2013 at 00:53:25 +0900, Mamoru TASAKA mtas...@fedoraproject.org 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
Re: bison, flex have broken deps in rawhide
Kevin Fenzi ke...@scrye.com writes: Tom Lane t...@redhat.com 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: Expanding the list of Hardened Packages
Jakub Jelinek ja...@redhat.com 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
Jared K. Smith jsm...@fedoraproject.org writes: On Mon, Mar 11, 2013 at 11:41 AM, Michael Catanzaro mike.catanz...@gmail.com 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: MySQL-libs conflicts with mariadb-libs-5.5.29-7.fc19.x86_64
Honza Horak hho...@redhat.com 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
Adam Williamson awill...@redhat.com 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: Should MariaDB touch my.cnf in %post?
Rahul Sundaram methe...@gmail.com 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 norvald.ry...@oracle.com writes: On Thu, 14 Feb 2013 08:07:22 +0100, Rahul Sundaram methe...@gmail.com 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 liangsuil...@gmail.com 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 den...@ausil.us 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 james.hoga...@gmail.com writes: On 6 February 2013 13:15, Chris xchris...@googlemail.com 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 methe...@gmail.com 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: Proposed F19 Feature: Replace MySQL with MariaDB
Peter Robinson pbrobin...@gmail.com 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: drop inheritance at f19 branch point?
Bruno Wolff III br...@wolff.to writes: On Wed, Jan 23, 2013 at 22:38:30 +0100, Lennart Poettering mzerq...@0pointer.de 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
Bill Nottingham nott...@redhat.com 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: Proposed F19 Feature: Replace MySQL with MariaDB
Kevin Fenzi ke...@scrye.com 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 nott...@redhat.com 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: MariaDB in Fedora
Henrique Junior henrique...@gmail.com 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: Fwd: [Libjpeg-turbo-users] jpeg-9, API/ABI compatibility, and the future role of this project
Michael Stahl mst...@redhat.com 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: Packagers needed
Kevin Fenzi ke...@scrye.com 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 or...@cora.nwra.com 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 nus...@fedoraproject.org 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 zn...@znmeb.net 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)))
Panu Matilainen pmati...@laiskiainen.org 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)))
Simon Lukasik isim...@fedoraproject.org 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: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Stanislav Ochotnicky sochotni...@redhat.com 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))
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johan...@gmail.com 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))
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johan...@gmail.com 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: 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 awill...@redhat.com 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: 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 awill...@redhat.com 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: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Adam Williamson awill...@redhat.com 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 awill...@redhat.com 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 h.rei...@thelounge.net 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 facts 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. /facts opinion 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. /opinion regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd macros (f18+)
Lennart Poettering mzerq...@0pointer.de 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 br...@wolff.to writes: MichaÅ Piotrowski mkkp...@gmail.com 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: PostgreSQL 9.2 for F18?
Bruno Wolff III br...@wolff.to writes: On Mon, Sep 10, 2012 at 10:24:40 -0400, Tom Lane t...@redhat.com 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: Mass changes to packaging
Scott Schmit i.g...@comcast.net 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 hdego...@redhat.com 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 tcall...@redhat.com 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
Lennart Poettering mzerq...@0pointer.de 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 (was: Re: New: Introduce new systemd-rpm macros in [...])
Richard W.M. Jones rjo...@redhat.com 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: Mass changes to packaging
Bruno Wolff III br...@wolff.to writes: On Tue, Aug 21, 2012 at 11:59:29 -0400, Bill Nottingham nott...@redhat.com 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
Bruno Wolff III br...@wolff.to writes: Tom Lane t...@redhat.com wrote: Bruno Wolff III br...@wolff.to 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 21 || : /bin/systemctl enable sm-client.service /dev/null 21 || : /bin/systemctl daemon-reload /dev/null 21 || : 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: PostgreSQL 9.2 for F18?
=?ISO-8859-2?Q?Micha=B3_Piotrowski?= mkkp...@gmail.com 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
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
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
Re: Insane results from mock rawhide build
Jesse Keating jkeat...@j2solutions.net 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
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: [ACTION REQUIRED v4] Retiring packages for F-18
Bruno Wolff III br...@wolff.to writes: On Thu, Jul 26, 2012 at 20:13:18 -0400, Tom Lane t...@redhat.com 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
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
Re: Provenpackager help needed to complete libpng/libtiff transition
Adam Williamson awill...@redhat.com 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
Re: redhat-lsb-desktop versus transition to current libpng
Adam Williamson awill...@redhat.com 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: redhat-lsb-desktop versus transition to current libpng
Tom Callaway tcall...@redhat.com 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: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18
Kevin Kofler kevin.kof...@chello.at 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
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: Suggestion: Continuous mass rebuild
Richard W.M. Jones rjo...@redhat.com 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
Jesse Keating jkeat...@redhat.com 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 v4] Retiring packages for F-18
Bruno Wolff III br...@wolff.to writes: On Wed, Jul 25, 2012 at 18:24:52 -0400, Bill Nottingham nott...@redhat.com 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 v3] Retiring packages for F-18
Bill Nottingham nott...@redhat.com 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
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: Accidental soname bump in libdbi
Jon Ciesla limburg...@gmail.com writes: On Mon, Jul 23, 2012 at 1:52 PM, Tom Lane t...@redhat.com 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
Re: Support for legacy init script actions for systemd services
Bill Nottingham nott...@redhat.com 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: Support for legacy init script actions for systemd services
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johan...@gmail.com 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
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johan...@gmail.com 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
Michael Cronenworth m...@cchtml.com 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
Mathieu Bridon boche...@fedoraproject.org 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: service restart question
Lennart Poettering mzerq...@0pointer.de 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 xav...@bachelot.org 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 boche...@fedoraproject.org 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 kevin.kof...@chello.at 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
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: Packaging issue: what to do about debuginfo after arch-noarch change?
Tom Callaway tcall...@redhat.com 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
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?
Mark Wielaard m...@redhat.com 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: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
John Reiser jrei...@bitwagon.com 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: Does systemd expose any unit-file-parsing functionality?
Lennart Poettering mzerq...@0pointer.de writes: On Sat, 17.03.12 11:41, Tom Lane (t...@redhat.com) wrote: Tomasz Torcz to...@pipebreaker.pl writes: You can try systemctl show -p Environment unit [ 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?
Lennart Poettering mzerq...@0pointer.de 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: ARM as a primary architecture
Kevin Kofler kevin.kof...@chello.at 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: ARM as a primary architecture
Kevin Kofler kevin.kof...@chello.at 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
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: Does systemd expose any unit-file-parsing functionality?
Tomasz Torcz to...@pipebreaker.pl 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 unit [ 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
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: [ACTION NO LONGER REQUIRED] Retired packages for F-17
Peter Robinson pbrobin...@gmail.com writes: On Wed, Mar 7, 2012 at 7:06 PM, Bill Nottingham nott...@redhat.com 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: master branch still invokes build in f17-candidate??
Jesse Keating jkeat...@redhat.com 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 kevin.kof...@chello.at 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
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: master branch still invokes build in f17-candidate??
Orion Poplawski or...@cora.nwra.com 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
Re: Looking for a package maintainer for flam3
Bruno Wolff III br...@wolff.to 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 m...@cchtml.com 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
mysql is now a critpath package? WTF?
So I submitted a routine bodhi request for updating mysql, and was astonished to find that it's marked as critpath. It was never that before. Who decided this, and would it not have been polite to involve or at least notify the package maintainer? 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?
Dennis Gilmore den...@ausil.us writes: El Thu, 05 Jan 2012 12:16:34 -0500 Tom Lane t...@redhat.com escribió: So I submitted a routine bodhi request for updating mysql, and was astonished to find that it's marked as critpath. It was never that before. Who decided this, and would it not have been polite to involve or at least notify the package maintainer? its an automated process. something in the package set that defines the critical path has added a dep on mysql so its been added. at least thats my guess as to whats happened. That answer doesn't make me any happier. I've got a problem with being saddled with an extra layer of bureaucracy without any say-so on my part, and I'm also quite nervous about the idea of something that is genuinely critpath depending on something as rickety as mysql. How would I find out exactly where the dep came from, so I can have a word with that package's maintainer? 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?
Peter Robinson pbrobin...@gmail.com writes: On Thu, Jan 5, 2012 at 5:36 PM, Tom Lane t...@redhat.com wrote: That answer doesn't make me any happier. I've got a problem with being saddled with an extra layer of bureaucracy without any say-so on my part, and I'm also quite nervous about the idea of something that is genuinely critpath depending on something as rickety as mysql. Your not the only one with the problem. Its not that bad. I've got other critpath packages, so I know exactly what kind of additional bureaucracy I'm getting into, thank you. But I'm not following how something that's not even installed by default can reasonably become marked critpath. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
