Re: unwanted devel-dependencies (currently perl)
On Thu, Jan 05, 2012 at 09:42:24AM +0200, Ville Skyttä wrote: > On 2012-01-05 03:25, Reindl Harald wrote: > > why in the world introducing updates the installation > > of devel-packages? > > Packaging bugs, in this case https://bugzilla.redhat.com/748362 . And https://bugzilla.redhat.com/show_bug.cgi?id=695239 . It has been known for months. D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rebuild for GCC-4.7
On 01/05/2012 11:55 PM, Adam Jackson wrote: On Thu, 2012-01-05 at 22:38 +0100, Ralf Corsepius wrote: They do not mean the resulting packages are more or less broken than those having been built by predecessors of the toolchains. Neither does an "ordered rebuild". Even assuming the concept of ordering was any more well defined than tsort. In general, I agree. But ... if there are changes in central places which are explictily or implicitly introducing API/API changes, you won't get far without an "ordered rebuild". That said, in case of a "dot null" GCC release like this, hidden ABI/API issues and "miscompiled" packages are likely to occur. E.g. in this particular GCC release, the changes to g++/libstdc++ it comes along with, are not unlikely to trigger chains of API/ABI changes cause by "fixing c++" packages (== silent/hidden API/ABI changes inside of these packages). Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
New cfitsio (3.290) in rawhide
Hi, a new cfistio package (3.290) as landed in rawhide. Packages depending on cfitsio should be rebuilt. Regards, Sergio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rebuild for GCC-4.7
On 01/05/2012 03:10 PM, Brendan Jones wrote: I've seen nils' list and a few of my packages are on it. What can we do now to fix it? I've noticed some koji builds for the new compiler but other than that, should I wait for the FTB.. to come in? One of my packages was on the list, it had a simple patch of two headers. I used mock to have it build locally and fail, rebuild and fail till I had it building again, then submitted the patch upstream and had it 'officially' built using koji. If you already know it will fail no point in waiting for the mass-rebuild to re-confirm that you have work to do on it. My 2cs -- Nathanael d. Noblet t 403.875.4613 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rebuild for GCC-4.7
On Thu, 2012-01-05 at 22:38 +0100, Ralf Corsepius wrote: > They do not mean the resulting packages are more or less broken than > those having been built by predecessors of the toolchains. Neither does an "ordered rebuild". Even assuming the concept of ordering was any more well defined than tsort. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
Tom Lane wrote: > 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. mysql-server is actually installed by default on the KDE spin, because Akonadi uses it. (The systemwide instance is not enabled by default and not used by Akonadi though, Akonadi starts its own per-user instance.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rebuild for GCC-4.7
On 01/04/2012 06:27 PM, Dennis Gilmore wrote: starting immediatly there is going to be a mass rebuild of rawhide for gcc-4.7 that landed yesterday. as approved by FESCo (https://fedorahosted.org/fesco/ticket/739) packagers will have just over a week, until Thursday Jan 12 to build packages themselves. After that date releng will kick off an automated mass rebuild of everything else. So please get building as Fedora 17 branching is less than 5 weeks away. we need all built by then Thanks I've seen nils' list and a few of my packages are on it. What can we do now to fix it? I've noticed some koji builds for the new compiler but other than that, should I wait for the FTB.. to come in? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
On 01/05/2012 09:03 PM, Kevin Kofler wrote: Brendan Jones wrote: Can understand that this is a hot topic but ... Surely for a single user desktop you don't need a concurrent DB backend. Try reading your existing mail while fetching new one. (Just one example.) (And that hasn't worked with KMail 1 ever, AFAIK KMail 2 finally fixes this, but it only really works if Akonadi has a concurrent database, otherwise the UI responds, but can only show you a "waiting for Akonadi lock" message.) Kevin Kofler I'm sorry but that's just bad design. I develop and deploy many applications which run under much more stringent restrictions, ie. do not have the luxury to run mysql. And yes, these are challenging issues, but its not that hard to provide a solution for a single user. Obviously, if I had the choice as to the backend I'd prefer, it would not be sqlite. But in the case of the desktop? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
On Thu, Jan 5, 2012 at 5:51 PM, Tom Lane wrote: > Peter Robinson writes: >> On Thu, Jan 5, 2012 at 5:36 PM, Tom Lane 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. mysql the server isn't, but mysql-libs is used by a lot. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rebuild for GCC-4.7
On 01/05/2012 10:06 PM, Jon Masters wrote: On Thu, 2012-01-05 at 21:47 +0100, Ralf Corsepius wrote: I guess you are referring an "ordered rebuild", not a "simple sequential rebuild". The latter would be mostly useless. For bootstrapping, ideally there would be ordered rebuilds, but even any mass rebuild assists more than having none at all :) Well, all these sequential "mass rebuilds" are useful for, is to check whether the current toolchain can build a previously buildable package :) They do not mean the resulting packages are more or less broken than those having been built by predecessors of the toolchains. [Remember, in recent years, we have several times been hit by cases when rebuilts inherited bugs from e.g. rpm, glibc, or GCC.] Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rebuild for GCC-4.7
On Thu, 2012-01-05 at 21:47 +0100, Ralf Corsepius wrote: > I guess you are referring an "ordered rebuild", not a "simple sequential > rebuild". > > The latter would be mostly useless. For bootstrapping, ideally there would be ordered rebuilds, but even any mass rebuild assists more than having none at all :) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
Fixed my broken packages in rawhide: * libjingle - http://koji.fedoraproject.org/koji/taskinfo?taskID=3623092 * rekall - http://koji.fedoraproject.org/koji/taskinfo?taskID=3623152 * xbase - http://koji.fedoraproject.org/koji/taskinfo?taskID=3623229 * xsupplicant - http://koji.fedoraproject.org/koji/taskinfo?taskID=3623256 Thanks to Jakub for the very useful test and diagnosis. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Adding links to the changeset from ticket update
When you commit and push a patch to the git repo, and you add the git commit message to the ticket comment, you can easily make the commit a link to the changeset in the trac source browser - just change commit 20ab029c0f0309838 to commit changeset:20ab029c0f0309838/389-ds-base the trac wiki parser will turn this into a link to the changeset viewer in the source browser for an example, see https://fedorahosted.org/389/ticket/1#comment:6 If the commit was for a different package, e.g. 389-admin, use /389-admin on the end of the commit hash -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Rebuild for GCC-4.7
On 01/05/2012 09:21 PM, Jon Masters wrote: On Thu, 2012-01-05 at 11:18 -0600, Dennis Gilmore wrote: El Thu, 05 Jan 2012 10:37:41 -0500 Tom Callaway escribió: On 01/05/2012 09:40 AM, Richard Shaw wrote: I just didn't know if there was any "filtering" going on for the mass rebuild or if all packages, regardless of dependence on gcc were going to be rebuilt. My understanding is that we traditionally rebuild everything at the time of a mass rebuild, because it is a good excuse to do it. Im planning to just rebuild everything. ideally drop all the disttags prior to fc17 since people get antsy about that at times. those packages that still have anything before .fc15 really need rebuilt. since we had reasons then to rebuild everything +1 This is a great time to rebuild everything. I guess you are referring an "ordered rebuild", not a "simple sequential rebuild". The latter would be mostly useless. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
Stijn Hoop wrote: > Well it also took them two years to consider 'NFS mounted home' a valid > use case, during which the whole 'you really need MySQL!!!' was broken > for our site. It's easy to switch (maybe I should blog about it... ) per user: kcmshell4 akonadi per machine/site: create/edit /etc/xdg/akonadi/akonadiserverrc to contain: [%General] Driver=QSQLITE3 -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rebuild for GCC-4.7
On Thu, Jan 5, 2012 at 2:21 PM, Jon Masters wrote: > On Thu, 2012-01-05 at 11:18 -0600, Dennis Gilmore wrote: > > El Thu, 05 Jan 2012 10:37:41 -0500 > > Tom Callaway escribió: > > > On 01/05/2012 09:40 AM, Richard Shaw wrote: > > > > I just didn't know if there was any "filtering" going on for the > > > > mass rebuild or if all packages, regardless of dependence on gcc > > > > were going to be rebuilt. > > > > > > My understanding is that we traditionally rebuild everything at the > > > time of a mass rebuild, because it is a good excuse to do it. > > > Im planning to just rebuild everything. ideally drop all the disttags > > prior to fc17 since people get antsy about that at times. > > > > those packages that still have anything before .fc15 really need > > rebuilt. since we had reasons then to rebuild everything > > +1 > > This is a great time to rebuild everything. Not only does it assist with > the gcc 4.7 switchover but it also proves that everything builds. And > that turns out to be very useful when bootstrapping new architectures. I > was planning (and still am) to make a formal proposal that Fedora > require a mass rebuild every 2 releases if none is done for incidental > reasons, just to help with ensuring the whole thing does still build. > > Jon. > > > Don't we do this anyway whenever we get a new major GCC release? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
On Thu, 05 Jan 2012 20:20:55 +0100 Kevin Kofler wrote: > Rex Dieter wrote: > > I'm of a mind to revisit this (again). > > NO, not again!!! > > Can we please stop this nonsense? > > Upstream defaults to MySQL for a reason, and strongly recommends NOT > using the SQLite backend by default. SQLite doesn't support > concurrency (i.e. any Akonadi operation blocks all others) and is > slower. > > I think overriding the upstream default is a very bad idea in this > case, and I'm surprised you are pushing for it that much, you're > otherwise always the "upstream, upstream, upstream" guy. > > Kevin Kofler > Well it also took them two years to consider 'NFS mounted home' a valid use case, during which the whole 'you really need MySQL!!!' was broken for our site. I'm not exactly sure that blindly following upstream recommendations on a topic that has been contested before, with good reason, is a good idea either. --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
Dennis Gilmore wrote: > considering that mysql couldnt cope with my email and i had to stop > using kmail all together going to sqlite im sure would be worse. but > thats my 2c Flipping defaults doesn't mean other backends cannot be used. We've helped make sure that switching backends (to/from sqlite, mysql) is relatively easy (both per user and per machine/site). -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rebuild for GCC-4.7
On Thu, 2012-01-05 at 11:18 -0600, Dennis Gilmore wrote: > El Thu, 05 Jan 2012 10:37:41 -0500 > Tom Callaway escribió: > > On 01/05/2012 09:40 AM, Richard Shaw wrote: > > > I just didn't know if there was any "filtering" going on for the > > > mass rebuild or if all packages, regardless of dependence on gcc > > > were going to be rebuilt. > > > > My understanding is that we traditionally rebuild everything at the > > time of a mass rebuild, because it is a good excuse to do it. > Im planning to just rebuild everything. ideally drop all the disttags > prior to fc17 since people get antsy about that at times. > > those packages that still have anything before .fc15 really need > rebuilt. since we had reasons then to rebuild everything +1 This is a great time to rebuild everything. Not only does it assist with the gcc 4.7 switchover but it also proves that everything builds. And that turns out to be very useful when bootstrapping new architectures. I was planning (and still am) to make a formal proposal that Fedora require a mass rebuild every 2 releases if none is done for incidental reasons, just to help with ensuring the whole thing does still build. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving xine-lib and dependent apps to RPM Fusion Free for F17?
On Thursday 05 January 2012, Michael J Gruber wrote: > I don't know anything about rpmfusion packaging and infrastructure, so > I'd be happy if someone picks up xine-ui there. In fact, xine-ui gets > most xine related abrt reports, it seems, and I always found it > difficult to decide whether those are really xine-ui or xine-lib issues. > So, xine-ui would best be put into the xine-lib maintainer's hands > anyways ;) Well, to be honest, I'd be glad if xine-lib also got a new maintainer. (Xavier? :-) ) As I wrote, I only really maintain xine-lib because of Kaffeine, and I'll stop caring about xine-lib the day Kaffeine releases its MPlayer-based code (or something else not based on xine-lib). In particular, I also really don't want to maintain xine-ui… Note that xine-lib-extras-freeworld can be merged back into xine-lib when it moves to RPM Fusion, and the new xine-lib can Obsolete/Provide it. That'll allow making the packaging a bit less of a wicked mess than it is now. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
Kevin Kofler wrote: > Rex Dieter wrote: >> I'm of a mind to revisit this (again). > > NO, not again!!! > > Can we please stop this nonsense? > > Upstream defaults to MySQL for a reason, and strongly recommends NOT using > the SQLite backend by default. SQLite doesn't support concurrency (i.e. > any Akonadi operation blocks all others) and is slower. > > I think overriding the upstream default is a very bad idea in this case, > and I'm surprised you are pushing for it that much, you're otherwise > always the "upstream, upstream, upstream" guy. 1. I'm a sysadmin at a site with ~200 client machines, and have site-local customizations to use sqlite here anyway (mostly because of NFS homes). For this use-case, as well as our live media, this makes very good sense. 2. sqlite is also the akonadi default on mobile platforms. I'm guessing largely due to far less runtime (cpu and disk) baggage. 3. similar to 2, less runtime dependencies. Given that, don't be *too* surprised. :) -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
Brendan Jones wrote: > Can understand that this is a hot topic but ... Surely for a single user > desktop you don't need a concurrent DB backend. Try reading your existing mail while fetching new one. (Just one example.) (And that hasn't worked with KMail 1 ever, AFAIK KMail 2 finally fixes this, but it only really works if Akonadi has a concurrent database, otherwise the UI responds, but can only show you a "waiting for Akonadi lock" message.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving xine-lib and dependent apps to RPM Fusion Free for F17?
Kevin Kofler venit, vidit, dixit 05.01.2012 20:56: > Hi, > > the current xine-lib maintainer speaking. :-) > > The Xine project: > http://www.xine-project.org/home > has recently released a new major version, version 1.2.0. > > Unfortunately, among the list of changes: > http://sourceforge.net/projects/xine/files/xine-lib/1.2.0/README.txt.asc/view > there are these new "features": > * Use libavutil-provided implementations for CRC, SHA1 and BASE64 algorithms, > this makes use of libavutil even outside the FFmpeg decoding plugin, > but avoid duplication of algorithms between different plugins. > * Use av_mallocz() when xine_xmalloc_aligned() wouldn't be needed. > * FFmpeg is now required as an external dependency; if you want to build > xine-lib from source, please download a copy of FFmpeg from their SVN > server. > which basically mean that xine-lib now has a global, non-optional dependency > on FFmpeg's libavutil library. > > So there are 4 possible ways forward: > (a) Stick with 1.1.x forever. I don't think that's a good idea in the long > run, upstream won't be providing security fixes for the old branch > forever. > (b) Package libavutil (and only libavutil) from FFmpeg in Fedora. (I don't > think libavutil, as opposed to libavcodec, is actually patent-encumbered, > though that'd also have to be checked.) The issue there is that FFmpeg > upstream obviously doesn't support this. It would need some more black > packaging magic of the kind already done in xine-lib, and more legal > auditing. I don't think I want to investigate going down that road. > (c) Bundle parts or all of libavutil with xine-lib. Yuck!!! > (d) Move the whole thing (back) to RPM Fusion (where it originally was, before > we started needing xine-lib for Amarok and Phonon, which both no longer > use it). It would go to the Free section, of course. > My proposal is to go with (d). > > The following packages currently depend on xine-lib: > * gxine > * (k9copy – already in RPM Fusion, not affected) > * kaffeine (my package, the reason why I maintain xine-lib in the first place) > * oxine > * xine-plugin > * xine-ui > These packages would have to move to RPM Fusion along with xine-lib. > > In Kaffeine's case, upstream is switching from xine-lib to MPlayer in their > git > repository, so it will likely have to move to RPM Fusion sooner or later > anyway. This means the affected packages are basically *xine*. > > So my plan is to retire (for my packages, resp. have the respective > maintainer > retire) the listed packages in Fedora for Fedora ≥ 17 and get (or have the > respective maintainer get) them into RPM Fusion Free instead. (I'd take care > of xine-lib and kaffeine myself, I hope the maintainers of the other packages > will take care of them.) > > Comments? Objections? [xine-ui maintainer speaking] No objection, d is clearly the best option. I don't know anything about rpmfusion packaging and infrastructure, so I'd be happy if someone picks up xine-ui there. In fact, xine-ui gets most xine related abrt reports, it seems, and I always found it difficult to decide whether those are really xine-ui or xine-lib issues. So, xine-ui would best be put into the xine-lib maintainer's hands anyways ;) Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
Reindl Harald wrote: > > > Am 05.01.2012 20:22, schrieb Kevin Kofler: >> Akonadi ships its own default MySQL configuration, which is per user. It >> does not use or require the systemwide instance (by default; it can be >> configured to connect to a systemwide or even remote MySQL server, but >> the default is a local per-user instance). There's no administration >> required at all, Akonadi fires up everything automatically. > > does it also run "mysql_upgrade" automatically yes, iirc. -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
Reindl Harald wrote: > does it also run "mysql_upgrade" automatically or is it > supposed to be the road of dead two mysql-major-releases > later? AFAIK, it does run mysql_upgrade when needed. > somehow strange that amarok was crippled down from optional > mysqld-usage to sqlite and now KDE introduces a new mysqld > instance Amarok actually uses MySQL-embedded, not SQLite. SQLite support was dropped permanently with 2.0. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
qt accessibility, anyone interested?
Being the avid package monkey I am, I whipped up some initial packaging for http://gitorious.org/qt-at-spi/ in my space at http://rdieter.fedorapeople.org/rpms/qt-at-spi/ Hoping someone with more interest in this area would be able to pick this up to maintain officially. Be happy to help with sponsoring or reviews if required. In the end, I may end up doing it myself, but would rather this find a happier home that could care for it more than I would or could. -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
El Thu, 05 Jan 2012 20:20:55 +0100 Kevin Kofler escribió: > Rex Dieter wrote: > > I'm of a mind to revisit this (again). > > NO, not again!!! > > Can we please stop this nonsense? > > Upstream defaults to MySQL for a reason, and strongly recommends NOT > using the SQLite backend by default. SQLite doesn't support > concurrency (i.e. any Akonadi operation blocks all others) and is > slower. > > I think overriding the upstream default is a very bad idea in this > case, and I'm surprised you are pushing for it that much, you're > otherwise always the "upstream, upstream, upstream" guy. > > Kevin Kofler > considering that mysql couldnt cope with my email and i had to stop using kmail all together going to sqlite im sure would be worse. but thats my 2c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Moving xine-lib and dependent apps to RPM Fusion Free for F17?
Hi, the current xine-lib maintainer speaking. :-) The Xine project: http://www.xine-project.org/home has recently released a new major version, version 1.2.0. Unfortunately, among the list of changes: http://sourceforge.net/projects/xine/files/xine-lib/1.2.0/README.txt.asc/view there are these new "features": * Use libavutil-provided implementations for CRC, SHA1 and BASE64 algorithms, this makes use of libavutil even outside the FFmpeg decoding plugin, but avoid duplication of algorithms between different plugins. * Use av_mallocz() when xine_xmalloc_aligned() wouldn't be needed. * FFmpeg is now required as an external dependency; if you want to build xine-lib from source, please download a copy of FFmpeg from their SVN server. which basically mean that xine-lib now has a global, non-optional dependency on FFmpeg's libavutil library. So there are 4 possible ways forward: (a) Stick with 1.1.x forever. I don't think that's a good idea in the long run, upstream won't be providing security fixes for the old branch forever. (b) Package libavutil (and only libavutil) from FFmpeg in Fedora. (I don't think libavutil, as opposed to libavcodec, is actually patent-encumbered, though that'd also have to be checked.) The issue there is that FFmpeg upstream obviously doesn't support this. It would need some more black packaging magic of the kind already done in xine-lib, and more legal auditing. I don't think I want to investigate going down that road. (c) Bundle parts or all of libavutil with xine-lib. Yuck!!! (d) Move the whole thing (back) to RPM Fusion (where it originally was, before we started needing xine-lib for Amarok and Phonon, which both no longer use it). It would go to the Free section, of course. My proposal is to go with (d). The following packages currently depend on xine-lib: * gxine * (k9copy – already in RPM Fusion, not affected) * kaffeine (my package, the reason why I maintain xine-lib in the first place) * oxine * xine-plugin * xine-ui These packages would have to move to RPM Fusion along with xine-lib. In Kaffeine's case, upstream is switching from xine-lib to MPlayer in their git repository, so it will likely have to move to RPM Fusion sooner or later anyway. This means the affected packages are basically *xine*. So my plan is to retire (for my packages, resp. have the respective maintainer retire) the listed packages in Fedora for Fedora ≥ 17 and get (or have the respective maintainer get) them into RPM Fusion Free instead. (I'd take care of xine-lib and kaffeine myself, I hope the maintainers of the other packages will take care of them.) Comments? Objections? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
On Thu, Jan 05, 2012 at 02:08:02PM -0500, Tom Lane wrote: > Toshio Kuratomi writes: > > On Thu, Jan 05, 2012 at 01:13:47PM -0500, Bill Nottingham wrote: > >> We could consider having pkgdb e-mail the owner when the critpath bit for > >> the package gets flipped. Toshio, is that possible? > > > It is if we decide we want to do that. > > Just let me know and I'll generate a hotfix for it. > > If it's not too much work, this package maintainer for one would > appreciate that. > https://fedorahosted.org/fedora-infrastructure/ticket/3083 I'm going to try to use that as my example in the FUDCon workshop on python programming I said I'd give so it will hopefully be done in early February. -Toshio pgppcVMWAwbep.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
On 01/05/2012 08:20 PM, Kevin Kofler wrote: Rex Dieter wrote: I'm of a mind to revisit this (again). NO, not again!!! Can we please stop this nonsense? Upstream defaults to MySQL for a reason, and strongly recommends NOT using the SQLite backend by default. SQLite doesn't support concurrency (i.e. any Akonadi operation blocks all others) and is slower. I think overriding the upstream default is a very bad idea in this case, and I'm surprised you are pushing for it that much, you're otherwise always the "upstream, upstream, upstream" guy. Kevin Kofler Can understand that this is a hot topic but ... Surely for a single user desktop you don't need a concurrent DB backend. If upstream recommends this then I would recommend upstream to reconsider their design. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
Kevin Kofler (kevin.kof...@chello.at) said: > Bill Nottingham wrote: > > kdepim is in critical path as part of 'critical-path-apps', which is > > essentially mail & web. The change that caused this to get added is that > > the script prior to early December wasn't actually iterating over the > > proper critpath groups, including critical-path-apps. > > I think we should reconsider including these things (also critical-path-kde) > in critpath. We've been working fine for years without those actually being > marked critpath. The critpath process is just an annoyance for these > packages. > > I'd suggest removing all of kde* from critpath, and I think most if not all > of KDE SIG agrees with me on this (if you want an official statement, I can > put it up for the next KDE SIG meeting). Sure, the KDE SIG can file any proposals/requests as a FESCo ticket and we'll look at them, much as in https://fedorahosted.org/fesco/ticket/699. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
Am 05.01.2012 20:22, schrieb Kevin Kofler: > Akonadi ships its own default MySQL configuration, which is per user. It > does not use or require the systemwide instance (by default; it can be > configured to connect to a systemwide or even remote MySQL server, but the > default is a local per-user instance). There's no administration required at > all, Akonadi fires up everything automatically. does it also run "mysql_upgrade" automatically or is it supposed to be the road of dead two mysql-major-releases later? somehow strange that amarok was crippled down from optional mysqld-usage to sqlite and now KDE introduces a new mysqld instance signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
Bill Nottingham wrote: > kdepim is in critical path as part of 'critical-path-apps', which is > essentially mail & web. The change that caused this to get added is that > the script prior to early December wasn't actually iterating over the > proper critpath groups, including critical-path-apps. I think we should reconsider including these things (also critical-path-kde) in critpath. We've been working fine for years without those actually being marked critpath. The critpath process is just an annoyance for these packages. I'd suggest removing all of kde* from critpath, and I think most if not all of KDE SIG agrees with me on this (if you want an official statement, I can put it up for the next KDE SIG meeting). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
Tom Lane wrote: > I'd recommend it. mysql is kind of a heavyweight requirement to have > underneath a desktop component: it raises the ante in terms of what has > to be installed and running, and in terms of required sysadmin-ish > know-how. (Does the average user have a clue how to configure mysql > securely, or even realize that it's not very secure out-of-the-box? > If there are multiple users on the machine, what about information > leakage via access to other users' tables?) Akonadi ships its own default MySQL configuration, which is per user. It does not use or require the systemwide instance (by default; it can be configured to connect to a systemwide or even remote MySQL server, but the default is a local per-user instance). There's no administration required at all, Akonadi fires up everything automatically. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
Rex Dieter wrote: > I'm of a mind to revisit this (again). NO, not again!!! Can we please stop this nonsense? Upstream defaults to MySQL for a reason, and strongly recommends NOT using the SQLite backend by default. SQLite doesn't support concurrency (i.e. any Akonadi operation blocks all others) and is slower. I think overriding the upstream default is a very bad idea in this case, and I'm surprised you are pushing for it that much, you're otherwise always the "upstream, upstream, upstream" guy. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
On Thu, 2012-01-05 at 14:08 -0500, Tom Lane wrote: > Toshio Kuratomi writes: > > On Thu, Jan 05, 2012 at 01:13:47PM -0500, Bill Nottingham wrote: > >> We could consider having pkgdb e-mail the owner when the critpath bit for > >> the package gets flipped. Toshio, is that possible? > > > It is if we decide we want to do that. > > Just let me know and I'll generate a hotfix for it. > > If it's not too much work, this package maintainer for one would > appreciate that. This one too. In both directions, in fact, I'm just as happy to see my packages fall off critpath. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
Toshio Kuratomi writes: > On Thu, Jan 05, 2012 at 01:13:47PM -0500, Bill Nottingham wrote: >> We could consider having pkgdb e-mail the owner when the critpath bit for >> the package gets flipped. Toshio, is that possible? > It is if we decide we want to do that. > Just let me know and I'll generate a hotfix for it. If it's not too much work, this package maintainer for one would appreciate that. 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?
On Thu, Jan 05, 2012 at 01:13:47PM -0500, Bill Nottingham wrote: > Tom Lane (t...@redhat.com) said: > > 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, > > The dependency solver. It's not a manual process. > > > and would it not have been polite to involve > > or at least notify the package maintainer? > > http://lists.fedoraproject.org/pipermail/devel-announce/2011-December/000868.html > > We could consider having pkgdb e-mail the owner when the critpath bit for > the package gets flipped. Toshio, is that possible? > It is if we decide we want to do that. Just let me know and I'll generate a hotfix for it. -Toshio pgpfxJ9aTnpwn.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
Rex Dieter writes: > Bill Nottingham wrote: >> As to where it came from, the dep chain is: >> >> kdepim >> -> akonadi >> -> qt-mysql, mysql-server >> >> kdepim is in critical path as part of 'critical-path-apps', which is >> essentially mail & web. > Sorry Tom, didn't foresee all the implications when we flipped f16's default > akonadi backend sqlite -> mysql late(ish) in the cycle. > I'm of a mind to revisit this (again). I'd recommend it. mysql is kind of a heavyweight requirement to have underneath a desktop component: it raises the ante in terms of what has to be installed and running, and in terms of required sysadmin-ish know-how. (Does the average user have a clue how to configure mysql securely, or even realize that it's not very secure out-of-the-box? If there are multiple users on the machine, what about information leakage via access to other users' tables?) If sqlite works for you it's probably a better choice for this. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rebuild for GCC-4.7
On 2012-01-05 20:34, Rex Dieter wrote: > Ville Skyttä wrote: > >> On 2012-01-05 19:18, Dennis Gilmore wrote: >> >>> ideally drop all the disttags prior to fc17 >> >> I hope I'm just having trouble parsing this correctly. Could you >> rephrase? > > Rebuild all packages, so they end up with fc17 disttags, to help avoid the > "why do I have a fc15 package on my f17 box" type questions. Ok, that's not how I parsed it. BTW, the answer to that type of questions would be "Because we do not rebuild stuff for fun -- doing so would cause potentially a lot to download and install for people upgrading from earlier distro versions just to get a number in some package release tags changed.". -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
Brendan Jones wrote: On 01/05/2012 07:32 PM, Rex Dieter wrote: Sorry Tom, didn't foresee all the implications when we flipped f16's default akonadi backend sqlite -> mysql late(ish) in the cycle. I'm of a mind to revisit this (again). -- rex Just my 2c, I'm also of the opinion something lighter than mysql is more appropriate for the desktop. Why does this sound so familiar? I want to say I remember many e-mails to devel/users about problems with akonadi and MySQL a year or so ago and requests for KDE to switch to something lighter. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
Bill Nottingham writes: > http://lists.fedoraproject.org/pipermail/devel-announce/2011-December/000868.html > ... The change that caused this to get added is that the > script prior to early December wasn't actually iterating over the proper > critpath groups, including critical-path-apps. Ah. So it's not a recent dependency addition, but just the result of following critpath dependencies more correctly. Thanks for the clarification. 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?
On 01/05/2012 07:32 PM, Rex Dieter wrote: Sorry Tom, didn't foresee all the implications when we flipped f16's default akonadi backend sqlite -> mysql late(ish) in the cycle. I'm of a mind to revisit this (again). -- rex Just my 2c, I'm also of the opinion something lighter than mysql is more appropriate for the desktop. Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rebuild for GCC-4.7
Ville Skyttä wrote: > On 2012-01-05 19:18, Dennis Gilmore wrote: > >> ideally drop all the disttags prior to fc17 > > I hope I'm just having trouble parsing this correctly. Could you > rephrase? Rebuild all packages, so they end up with fc17 disttags, to help avoid the "why do I have a fc15 package on my f17 box" type questions. -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
Bill Nottingham wrote: > Tom Lane (t...@redhat.com) said: >> 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, > > The dependency solver. It's not a manual process. > >> and would it not have been polite to involve >> or at least notify the package maintainer? > > http://lists.fedoraproject.org/pipermail/devel-announce/2011- December/000868.html > > We could consider having pkgdb e-mail the owner when the critpath bit for > the package gets flipped. Toshio, is that possible? > > As to where it came from, the dep chain is: > > kdepim > -> akonadi >-> qt-mysql, mysql-server > > kdepim is in critical path as part of 'critical-path-apps', which is > essentially mail & web. Sorry Tom, didn't foresee all the implications when we flipped f16's default akonadi backend sqlite -> mysql late(ish) in the cycle. I'm of a mind to revisit this (again). -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rebuild for GCC-4.7
On 2012-01-05 19:18, Dennis Gilmore wrote: > ideally drop all the disttags prior to fc17 I hope I'm just having trouble parsing this correctly. Could you rephrase? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
Tom Lane (t...@redhat.com) said: > 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, The dependency solver. It's not a manual process. > and would it not have been polite to involve > or at least notify the package maintainer? http://lists.fedoraproject.org/pipermail/devel-announce/2011-December/000868.html We could consider having pkgdb e-mail the owner when the critpath bit for the package gets flipped. Toshio, is that possible? As to where it came from, the dep chain is: kdepim -> akonadi -> qt-mysql, mysql-server kdepim is in critical path as part of 'critical-path-apps', which is essentially mail & web. The change that caused this to get added is that the script prior to early December wasn't actually iterating over the proper critpath groups, including critical-path-apps. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
Peter Robinson writes: > On Thu, Jan 5, 2012 at 5:36 PM, Tom Lane 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
Re: mysql is now a critpath package? WTF?
El Thu, 05 Jan 2012 12:36:25 -0500 Tom Lane escribió: > Dennis Gilmore writes: > > El Thu, 05 Jan 2012 12:16:34 -0500 > > Tom Lane 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 http://koji.fedoraproject.org/mash/rawhide-20120105/logs/critpath.log indicates its qt or akonadi likely both. Its likely been critical path for quite some time. Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
On Thu, Jan 5, 2012 at 5:36 PM, Tom Lane wrote: > Dennis Gilmore writes: >> El Thu, 05 Jan 2012 12:16:34 -0500 >> Tom Lane 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. Your not the only one with the problem. Its not that bad. > How would I find out exactly where the dep came from, so I can have > a word with that package's maintainer? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
Dennis Gilmore writes: > El Thu, 05 Jan 2012 12:16:34 -0500 > Tom Lane 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?
El Thu, 05 Jan 2012 12:16:34 -0500 Tom Lane 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? > > regards, tom lane 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. Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using a macro in ExclusiveArch
El Thu, 5 Jan 2012 15:20:09 +0100 Michael Schwendt escribió: > On Thu, 5 Jan 2012 08:11:07 -0600, DG (Dennis) wrote: > > > > > Is it significant that all three filenames end in "-srpm"? Or > > > > should this be considered a bug in Koji? > > > > > > I think the -srpm in there is not important. > > > > > > $ ls /etc/rpm > > > macros.color macros.fjava macros.mono-srpm macros.systemd > > > macros.distmacros.gconf2macros.ocaml-srpm macros.texlive > > > macros.emacs macros.ghc-srpm macros.perl > > > macros.faldor macros.jpackage macros.prelink > > the -srpm is there because the langugaes can provide other language > > specific macros in a file without -srpm the -srpm is to define that > > the macros are needed at srpm creation time and are slightly special > > because of it. the idea of them is to make it pretty easy to add a > > arch to a language by modifying one place rather than hundreds. > > > > by having the macros.ghc-srpm a ghc-common or ghc-filesystem or > > some such package can provide macros.ghc which has macros for rpm > > createion and not for srpm creation > > So, it's just a namespace issue, a slightly more unique file name, > isn't it? To avoid file conflicts. > > RPM loads all files named macros.* correct. just to avoid file namespace conflicts Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rebuild for GCC-4.7
El Thu, 05 Jan 2012 10:37:41 -0500 Tom Callaway escribió: > On 01/05/2012 09:40 AM, Richard Shaw wrote: > > I just didn't know if there was any "filtering" going on for the > > mass rebuild or if all packages, regardless of dependence on gcc > > were going to be rebuilt. > > My understanding is that we traditionally rebuild everything at the > time of a mass rebuild, because it is a good excuse to do it. > > ~tom > > == > Fedora Project Im planning to just rebuild everything. ideally drop all the disttags prior to fc17 since people get antsy about that at times. those packages that still have anything before .fc15 really need rebuilt. since we had reasons then to rebuild everything Dennis -- 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: using a macro in ExclusiveArch
> I'll try to get a macros.gnat-srpm into redhat-rpm- config. I have filed this request: https://bugzilla.redhat.com/show_bug.cgi?id=772012 Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using a macro in ExclusiveArch
Petr Pisar wrote: > I've already written suggestion to redhat-rpm-config owner to plug > dependencies maintained by particular SIGs (like perl or ada) to get > them controll over macros in minimal build root. However he has never > replied. > > I think this is inevitabla to allow smooth upgrades and boot-strapping > of big package ecosystems (like perl or ada). If you are interrested in > this area, I can resend the (quite long) mail to fedora-devel, where we > can discuss more and get some resolution. E.g. a ticket to FPC/FESCo to > allow/force this solution. In the Ada case it's really the GCC maintainers who decide what architectures to build GNAT on, but it would indeed be useful if we who work on Ada packages could adjust the list of architectures ourselves. The simplest solution seems to be to let SIG members co-maintain redhat-rpm-config. Did you have some more elaborate solution in mind? Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rebuild for GCC-4.7
On 01/05/2012 09:40 AM, Richard Shaw wrote: > I just didn't know if there was any "filtering" going on for the mass > rebuild or if all packages, regardless of dependence on gcc were going > to be rebuilt. My understanding is that we traditionally rebuild everything at the time of a mass rebuild, because it is a good excuse to do it. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swaps
On 12/15/2011 07:14 PM, Brendan Jones wrote: I would like to swap reviews for the following. All are very tiny so feel free to swap 2 for one. Listed in descending priority: https://bugzilla.redhat.com/show_bug.cgi?id=760270 lv2-ams-plugins - LV2 port of the Alsa Modular Synth modules https://bugzilla.redhat.com/show_bug.cgi?id=766154 lv2-kn0ck0ut - An LV2 spectral subtraction plugin (linux audio) https://bugzilla.redhat.com/show_bug.cgi?id=754004 lv2-abGate - an LV2 Noise Gate plugin I will be able to commence reviews from next Wednesday, unless anyone anyone responds this evening. Thanks! Brendan I've knocked one of my list but the 3 above are still outstanding. lv2 plugins are REALLY easy to review. 2 for one offer still stands, and have others ready to package. Brendan (bsjones) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using a macro in ExclusiveArch
Thanks Michael and Dennis! I'll try to get a macros.gnat-srpm into redhat-rpm- config. Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rebuild for GCC-4.7
On Thu, Jan 5, 2012 at 4:21 AM, Petr Pisar wrote: > On 2012-01-04, Richard Shaw wrote: >> I assume this is only required for packages that use gcc? So any other >> packages (perl, python, java, etc.) are excluded from this, correct? >> > A lot of modules in interpreted languages use compiled glue to access > C libraries. They result into architecture specific packages. So they > need to be recompiled too (after the main interpreter). So noarch packages should be fine and all arch specific packages should be rebuilt. I just didn't know if there was any "filtering" going on for the mass rebuild or if all packages, regardless of dependence on gcc were going to be rebuilt. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using a macro in ExclusiveArch
On Thu, 5 Jan 2012 08:11:07 -0600, DG (Dennis) wrote: > > > Is it significant that all three filenames end in "-srpm"? Or > > > should this be considered a bug in Koji? > > > > I think the -srpm in there is not important. > > > > $ ls /etc/rpm > > macros.color macros.fjava macros.mono-srpm macros.systemd > > macros.distmacros.gconf2macros.ocaml-srpm macros.texlive > > macros.emacs macros.ghc-srpm macros.perl > > macros.faldor macros.jpackage macros.prelink > the -srpm is there because the langugaes can provide other language > specific macros in a file without -srpm the -srpm is to define that > the macros are needed at srpm creation time and are slightly special > because of it. the idea of them is to make it pretty easy to add a arch > to a language by modifying one place rather than hundreds. > > by having the macros.ghc-srpm a ghc-common or ghc-filesystem or some > such package can provide macros.ghc which has macros for rpm createion > and not for srpm creation So, it's just a namespace issue, a slightly more unique file name, isn't it? To avoid file conflicts. RPM loads all files named macros.* -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using a macro in ExclusiveArch
El Thu, 5 Jan 2012 13:22:34 +0100
Michael Schwendt escribió:
> On Thu, 5 Jan 2012 13:08:21 +0100, BP (Björn) wrote:
>
> > I need some advice on how to fix this build failure. The GtkAda
> > package builds fine in Mock, but fails in Koji with the error "No
> > matching arches were found":
> >
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=3621310
> >
> > Several Ada packages need an ExclusiveArch directive to prevent
> > attempts to build them on secondary architectures where GNAT isn't
> > available. I thought it would be a good idea to keep the list of
> > architectures in a macro to get closer to a single point of truth.
> > I defined the macro in /etc/rpm/macros.gnat in the package
> > fedora-gnat-project-common:
> >
> > %GNAT_arches %{ix86} x86_64 ia64 ppc ppc64 alpha
> >
> > GtkAda uses the macro like this:
> >
> > BuildRequires: fedora-gnat-project-common >= 3.3
> > ExclusiveArch: %{GNAT_arches}
> >
> > I *think* the reason why the build fails in Koji might be that Koji
> > reads the ExclusiveArch directive to figure out which build server
> > should handle the build, and it doesn't pull in buildrequired
> > packages before doing that, so GNAT_arches is undefined. Does this
> > analysis seem correct?
>
> Yes.
>
> $ rpm -qp GtkAda-2.18.0-2.fc17.src.rpm --qf "%{exclusivearch}\n"
> %{GNAT_arches}
>
> > If so, what should I do about it? Should macros simply not be used
> > in the ExclusiveArch directive? I see ghc_arches, mono_arches and
> > ocaml_arches in other files in /etc/rpm. Those files all belong to
> > redhat-rpm-config. Would this work if GNAT_arches were defined in
> > redhat-rpm-config instead of fedora-gnat- project-common?
>
> Sounds plausible, because with redhat-rpm-config in the buildroot, the
> src.rpm would be fine with a defined macro.
>
> > Is it significant that all three filenames end in "-srpm"? Or
> > should this be considered a bug in Koji?
>
> I think the -srpm in there is not important.
>
> $ ls /etc/rpm
> macros.color macros.fjava macros.mono-srpm macros.systemd
> macros.distmacros.gconf2macros.ocaml-srpm macros.texlive
> macros.emacs macros.ghc-srpm macros.perl
> macros.faldor macros.jpackage macros.prelink
the -srpm is there because the langugaes can provide other language
specific macros in a file without -srpm the -srpm is to define that
the macros are needed at srpm creation time and are slightly special
because of it. the idea of them is to make it pretty easy to add a arch
to a language by modifying one place rather than hundreds.
by having the macros.ghc-srpm a ghc-common or ghc-filesystem or some
such package can provide macros.ghc which has macros for rpm createion
and not for srpm creation
Dennis
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need some advice on best packaging practices for a tricky package?
Kevin Kofler wrote: > Just ignore rpmlint there. :-) If you have proper Requires in place to > ensure the symlink targets will actually be installed, it's fine. I do, so I'll just ignore them. > Yes, it's called noarch subpackages and has been supported in Fedora for a > while. Just declare the subpackage as: > BuildArch: noarch > > Note that the main package MUST be arch-specific if you have any arch- > specific subpackages, you cannot have arch-specific subpackages of a noarch > package, only noarch subpackages of an arch-specific package. Ah. That's where I was going wrong. > /usr/ is the standard location for cross toolchains, and cross > toolchains (and ONLY cross toolchains) are allowed to use such a location > (though IIRC it never got officially codified in our guidelines because the > cross-compiler guidelines never got formalized; but de facto, the existing > cross compiler packages already use this). > > /usr/cross/ is entirely non-standard and IMHO a bad idea. Yeah. I was trying to avoid clashing with other toolchains, but I guess the name of the binary in /usr/bin/ is likely to do that anyway. Can rpmlint be altered to accept apparent -named directories in /usr/? > There is no requirement that binaries have manpages in Fedora. Though in > this case, just link the manpage. > > The purpose of ld.bfd is that this is always the regular BFD-based GNU ld > whereas just ld can be e.g. gold. I see. > > (8) The package installs gpl.7.gz and similar common-looking manpages in > > man7. > > Is this a bad idea, just in case there's a conflict with another > > package wanting to do the same? > > Yes. Don't package this. We don't normally ship licenses as manpages. See > the next paragraph for what to do instead. > > > Is there/ should there be a common GPL licence text RPM with these > > files in it that RPMs can be made dependent on? > > Ship the license with %doc COPYING, in a package which is required by all > the other subpackages. (If given only a file name without a path, %doc > automatically creates a unique path for the package to ship the text file > in.) For legal reasons, every package MUST carry its license in at least one > subpackage, and ALL subpackages must either carry the license or Require one > of the subpackages which do. A common license package for the whole > distribution (like Debian does it) does NOT comply with the GPL. The > packages are not necessarily distributed as part of the distribution, and > the GPL explicitly requires every GPLed package to carry a copy of the GPL, > no matter whether the distribution already has one. Fair enough. Interestingly, the core binutils does not seem to comply with this: warthog>rpm -ql binutils-devel binutils | grep -i gpl warthog1>rpm -ql binutils-devel binutils | grep -i licen[cs]e warthog1>rpm -ql binutils-devel binutils | grep -i COPYING warthog1> David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using a macro in ExclusiveArch
I've already written suggestion to redhat-rpm-config owner to plug dependencies maintained by particular SIGs (like perl or ada) to get them controll over macros in minimal build root. However he has never replied. I think this is inevitabla to allow smooth upgrades and boot-strapping of big package ecosystems (like perl or ada). If you are interrested in this area, I can resend the (quite long) mail to fedora-devel, where we can discuss more and get some resolution. E.g. a ticket to FPC/FESCo to allow/force this solution. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using a macro in ExclusiveArch
On Thu, 5 Jan 2012 13:08:21 +0100, BP (Björn) wrote:
> I need some advice on how to fix this build failure. The GtkAda package
> builds
> fine in Mock, but fails in Koji with the error "No matching arches were
> found":
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=3621310
>
> Several Ada packages need an ExclusiveArch directive to prevent attempts to
> build them on secondary architectures where GNAT isn't available. I thought
> it
> would be a good idea to keep the list of architectures in a macro to get
> closer to a single point of truth. I defined the macro in
> /etc/rpm/macros.gnat
> in the package fedora-gnat-project-common:
>
> %GNAT_arches %{ix86} x86_64 ia64 ppc ppc64 alpha
>
> GtkAda uses the macro like this:
>
> BuildRequires: fedora-gnat-project-common >= 3.3
> ExclusiveArch: %{GNAT_arches}
>
> I *think* the reason why the build fails in Koji might be that Koji reads the
> ExclusiveArch directive to figure out which build server should handle the
> build, and it doesn't pull in buildrequired packages before doing that, so
> GNAT_arches is undefined. Does this analysis seem correct?
Yes.
$ rpm -qp GtkAda-2.18.0-2.fc17.src.rpm --qf "%{exclusivearch}\n"
%{GNAT_arches}
> If so, what should I do about it? Should macros simply not be used in the
> ExclusiveArch directive? I see ghc_arches, mono_arches and ocaml_arches in
> other files in /etc/rpm. Those files all belong to redhat-rpm-config. Would
> this
> work if GNAT_arches were defined in redhat-rpm-config instead of fedora-gnat-
> project-common?
Sounds plausible, because with redhat-rpm-config in the buildroot, the
src.rpm would be fine with a defined macro.
> Is it significant that all three filenames end in "-srpm"? Or
> should this be considered a bug in Koji?
I think the -srpm in there is not important.
$ ls /etc/rpm
macros.color macros.fjava macros.mono-srpm macros.systemd
macros.distmacros.gconf2macros.ocaml-srpm macros.texlive
macros.emacs macros.ghc-srpm macros.perl
macros.faldor macros.jpackage macros.prelink
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
using a macro in ExclusiveArch
I need some advice on how to fix this build failure. The GtkAda package builds
fine in Mock, but fails in Koji with the error "No matching arches were found":
http://koji.fedoraproject.org/koji/taskinfo?taskID=3621310
Several Ada packages need an ExclusiveArch directive to prevent attempts to
build them on secondary architectures where GNAT isn't available. I thought it
would be a good idea to keep the list of architectures in a macro to get
closer to a single point of truth. I defined the macro in /etc/rpm/macros.gnat
in the package fedora-gnat-project-common:
%GNAT_arches %{ix86} x86_64 ia64 ppc ppc64 alpha
GtkAda uses the macro like this:
BuildRequires: fedora-gnat-project-common >= 3.3
ExclusiveArch: %{GNAT_arches}
I *think* the reason why the build fails in Koji might be that Koji reads the
ExclusiveArch directive to figure out which build server should handle the
build, and it doesn't pull in buildrequired packages before doing that, so
GNAT_arches is undefined. Does this analysis seem correct?
If so, what should I do about it? Should macros simply not be used in the
ExclusiveArch directive? I see ghc_arches, mono_arches and ocaml_arches in
other files in /etc/rpm. Those files all belong to redhat-rpm-config. Would
this
work if GNAT_arches were defined in redhat-rpm-config instead of fedora-gnat-
project-common? Is it significant that all three filenames end in "-srpm"? Or
should this be considered a bug in Koji?
Björn Persson
signature.asc
Description: This is a digitally signed message part.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rebuild for GCC-4.7
On 2012-01-04, Richard Shaw wrote: > On Wed, Jan 4, 2012 at 11:27 AM, Dennis Gilmore wrote: >> starting immediatly there is going to be a mass rebuild of rawhide >> for gcc-4.7 that landed yesterday. >> >> as approved by FESCo (https://fedorahosted.org/fesco/ticket/739) >> packagers will have just over a week, until Thursday Jan 12 to build >> packages themselves. After that date releng will kick off an >> automated mass rebuild of everything else. >> >> So please get building as Fedora 17 branching is less than 5 weeks >> away. we need all built by then > > I assume this is only required for packages that use gcc? So any other > packages (perl, python, java, etc.) are excluded from this, correct? > A lot of modules in interpreted languages use compiled glue to access C libraries. They result into architecture specific packages. So they need to be recompiled too (after the main interpreter). -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Cache-FastMmap] update to 1.40
commit 7cda3d0eb50785cf0b341565e530f1b23a91908e
Author: Iain Arnell
Date: Thu Jan 5 11:11:12 2012 +0100
update to 1.40
.gitignore |1 +
perl-Cache-FastMmap.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a8e202a..a7c6274 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
Cache-FastMmap-1.35.tar.gz
/Cache-FastMmap-1.36.tar.gz
/Cache-FastMmap-1.39.tar.gz
+/Cache-FastMmap-1.40.tar.gz
diff --git a/perl-Cache-FastMmap.spec b/perl-Cache-FastMmap.spec
index 311c6cb..74963ba 100644
--- a/perl-Cache-FastMmap.spec
+++ b/perl-Cache-FastMmap.spec
@@ -1,5 +1,5 @@
Name: perl-Cache-FastMmap
-Version:1.39
+Version:1.40
Release:1%{?dist}
Summary:Uses an mmap'ed file to act as a shared memory interprocess
cache
License:GPL+ or Artistic
@@ -46,6 +46,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Jan 05 2012 Iain Arnell 1.40-1
+- update to latest upstream version
+
* Tue Jul 26 2011 Iain Arnell 1.39-1
- update to latest upstream
- clean up spec for modern rpmbuild
diff --git a/sources b/sources
index 9a02629..bbdc1d5 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-988a3aa2d9c0dd96bb39c68d7330618b Cache-FastMmap-1.39.tar.gz
+e0929ba556c629a43f5d65a2b6cb9a2f Cache-FastMmap-1.40.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Cache-FastMmap-1.40.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Cache-FastMmap: e0929ba556c629a43f5d65a2b6cb9a2f Cache-FastMmap-1.40.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Bad coding practices in Fedora packages
On Thu, Jan 05, 2012 at 09:17:16AM +0100, Tomasz Torcz wrote: > ~ without recurse, and standard XDG directories in ~ with recurse. > In ~/Documents I have 4GiB of mostly .c source files in various revisions, > for a total of 189833 files. In other directories I have 5 photos in .jpg, > and couple of manuals in PDF format. > After about two or three hours of IO after login I noticed > ~/.cache/tracker/meta.db-wal had grown to 31GiB. At this point I killed > tracker processes, removed this file and disabled tracker for this session. > This was all on 5400 RPM 2,5" laptop drive. So it was very likely indexing those .c files right? Could you file a tracker bug about this? Going from 4GiB to 31+GiB is weird. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad coding practices in Fedora packages
On Wed, Jan 04, 2012 at 12:22:12PM +0100, Olav Vitters wrote: > On Tue, Jan 03, 2012 at 05:47:11PM +0100, Tomasz Torcz wrote: > > Also, 30 GiB in .cache/tracker is a bit extreme when rest of my ~ is 4 > > GiB. > > Tracker should only index a few standard directories ($HOME without > subdirectories, ~/Documents, etc). What does it index on your machine? ~ without recurse, and standard XDG directories in ~ with recurse. In ~/Documents I have 4GiB of mostly .c source files in various revisions, for a total of 189833 files. In other directories I have 5 photos in .jpg, and couple of manuals in PDF format. After about two or three hours of IO after login I noticed ~/.cache/tracker/meta.db-wal had grown to 31GiB. At this point I killed tracker processes, removed this file and disabled tracker for this session. This was all on 5400 RPM 2,5" laptop drive. > Is that the default F16 config? Default as F13 preupgraded twice a year up to F16. -- Tomasz Torcz "Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
