Orphaned libvtemm
Hi, I orphaned libvtemm package. Currently Haïkel Guémar is a co-maintainer. I advise against claiming the ownership of this package. It's old and unmaintained. Nothing depends on it, AFAIK. I assume that the package will be retired automatically at some point. Cheers, Krzesimir ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Intent to retire libvtemm
Hi, I'm the "upstream maintainer" of libvtemm. In quotes, because last change I have made to the project was 8 years ago. It depends on an orphaned package vte (which is based on gtk2). It's also a leaf package. I don't think it makes sense to even orphan it. I intend to retire the package within the week. It is also first time I'll do anything related to fedora packaging since years, so hopefully I won't break anything. Cheers, Krzesimir ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: fedora-review complains about gschema files in an RPM package
On Feb 25, 2017 16:15, "Michael Catanzaro" wrote: On Sat, 2017-02-25 at 07:57 +, Andrew Toskin wrote: > > > * if the package includes *precompiled* gschema... remove it? > > > > No, because these don't exist (at least I don't think so). All > > installed gschemas are compiled at once based on the schemas > > installed > > on the system, and there are no precompiled schemas. > > A few of packages' sources include a gschemas.compiled file. > > $ file schemas/gschemas.compiled > schemas/gschemas.compiled: GVariant Database file, version 0 Interesting... guess I'm wrong then! I think that can be deleted? It's possible that the extension searches for the schema source (not sure if I'm getting the terminology right) in a specific directory. Something like some extension did it until we patched it to try the default directory too - https://github.com/endlessm/coding-shell-extensions/commit/45e5c2b3bfaf86b29aaecc93b9180bfc8c6966a0 Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: /usr/etc?
2013/8/4 Lennart Poettering > I noticed this: > > $ rpm -qf /usr/etc > filesystem-3.2-12.fc19.x86_64 > > $ repoquery --whatprovides '/usr/etc/*' > mirall-common-0:1.3.0-1.fc19.x86_64 > mirall-common-0:1.3.0-1.fc19.i686 > > Since when do we have /usr/etc, and what is it for? > > Maybe I am the only one but I see very little benefit in introducing a > new Fedoraism like this... > That rather looks like CMakeism, which is strange in this case as Mirall has its own fix for that ( https://github.com/owncloud/mirall/blob/master/CMakeLists.txt#L35). Maybe that fix is not working here. > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Making rygel build in rawhide
2013/1/26 Nathaniel McCallum > Could someone apply this patch to rygel so at least we can get a > successful build? > http://git.gnome.org/browse/rygel/commit/?h=wip/new-gupnp-dlna&id=118af0f588879703e0dd7d01787897b5893032e0 > > That won't do. Gupnp-dlna 0.9.4 has to hit rawhide first. Then instead of patching, packaging Rygel 0.17.7 should be enough. > Thanks, > Nathaniel > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New gcc 4.7 c++ error
2012/1/30 Orion Poplawski :
> On 01/30/2012 11:49 AM, Kalev Lember wrote:
>>
>> On 01/30/2012 08:24 PM, Orion Poplawski wrote:
>>>
>>> I am getting the following error building paraview with gcc 4.7:
>>>
>>> In file included from
>>> /builddir/build/BUILD/ParaView-3.12.0/Qt/Core/pqAnimationScene.cxx:57:0:
>>>
>>> /builddir/build/BUILD/ParaView-3.12.0/Qt/Core/pqServerManagerSelectionModel.h:75:30:
>>> error: calls to overloaded operators cannot appear in a
>>> constant-expression
>>>
>>> code snippet:
>>>
>>> class PQCORE_EXPORT pqServerManagerSelectionModel : public QObject
>>> {
>>> Q_OBJECT
>>> public:
>>> /// Supported selections flags. These are a subset of
>>> /// QItemSelectionModel::SelectionFlags.
>>> enum SelectionFlag {
>>> NoUpdate = QItemSelectionModel::NoUpdate,
>>> Clear = QItemSelectionModel::Clear,
>>> Select = QItemSelectionModel::Select,
>>> Deselect = QItemSelectionModel::Deselect,
>>> ClearAndSelect = Clear | Select
>>
>>
>> Looks like gcc cannot resolve Clear and Select to a
>> constant-expression and you'll need to spell out the
>> scope. Try changing the line above to:
>> ClearAndSelect = QItemSelectionModel::Clear |
>> QItemSelectionModel::Select
>>
>>
>
> I did try that, but no go. I think the | operator is overloaded somewhere.
>
I guess that Q_DECLARE_FLAGS macro for QItemSelectionModel overrides
this operator.
Possible workaround for it would be:
ClearAndSelect = static_cast(Clear) | static_cast(Select)
>
> --
> Orion Poplawski
> Technical Manager 303-415-9701 x222
> NWRA, Boulder Office FAX: 303-415-9702
> 3380 Mitchell Lane or...@cora.nwra.com
> Boulder, CO 80301 http://www.cora.nwra.com
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/share/gtk-doc status
2011/2/21 80 : > As for /usr/share/devhelp/books, since a similar issue raised by > gtk-doc, guidelines should allow us now to own > /usr/share/devhelp/books since devhelp is an optional functionality. > >> http://fedoraproject.org/wiki/PackagingGuidelines#Conditional_dependencies >> The directory is owned by a package which is not required for your package >> to function > > best regards, > H. > I see, so I suppose that no moving/seding/whatnot should be done with documentation now. I'll try to fix it in my free time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/share/gtk-doc status
2011/2/21 80 : > @krzesimir: thank you, if we settle to /usr/share/doc, then you should > move devhelp index to /usr/share/devhelp/books. I moved devhelp2 file to directory owned by gtk-doc because avoiding dependency on devhelp application seemed sensible to me - it is not necessary to read doxygen docs. > Another issue is that > gtkmm doc subpackages should require base package documentation > packages (for libvtemm, at least gtkmm24-doc, glibmm24-doc, > libsigc++20-doc) so that hyperlinks are not broken. > I suppose that in such case those hyperlinks linked to library.gnome.org, but should be checked. > > H. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/share/gtk-doc status
2011/2/21 80 : > Hi, i'm co-maintaining part of the gtkmm stack and a documentation > location issue has been raised > (https://bugzilla.redhat.com/show_bug.cgi?id=678981) > By default, gtkmm-related packages put their documentation in > /usr/share/doc, but for historical reason, fedora packages move them > to /usr/share/gtk-doc. > Since it's quite error-prone (you have to move documentation and fix > devhelp index files), and not uniformized, if we don't have any > mandatory rule to move documentation > to /usr/share/gtk-doc (technically, gtkmm documentation is generated > by doxygen and not gtk-doc), i'd like to stick to default location > (/usr/share/doc). > Other distro seems to use /usr/share/doc for gtkmm documentation. > > Either way, we need to fix all doc subpackages, but i'd like to gather > your opinions before doing anything. I'm maintaining (sort of) libvtemm, which is also a part of mm stack. In this package I decided to keep docs in /usr/share/doc, but the only change I did is moving .devhelp2 file from /usr/share/devhelp/... to /usr/share/gtk-doc. For details, see libvtemm.spec [1]. [1] http://pkgs.fedoraproject.org/gitweb/?p=libvtemm.git;a=blob;f=libvtemm.spec#l58 > best regards, > H. Hope this helps, Krzesimir Nowak > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: documentation on Bugzilla bug lifecycle/developer procedures?
On Fri, 2010-02-12 at 10:38 +0100, Till Maas wrote: > If you need/use it and want to maintain it, you are free to do so. If > the kernel team knows a better alternative that you should consider, > then the package should be retired instead of just orphaned and an > explanation about why it was retired should be added to a dead.package > file in the CVS devel branch. Usually the latter is not done, so you can > only ask the previous maintainers. Nevertheless, having a "copy that's > maintained there" sounds like bad packaging practice. > > Regards > Till Maybe it was retired or orphaned because unifdef was superseded by sunifdef (which is packaged in fedora), which is now superseded by coan [1] (which is not yet packaged in fedora)? Krzesimir [1] http://coan2.sourceforge.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
