Bug 737399 - Rename Review: gedit-latex - gedit plugin for editing latex documents
Summary: Rename Review: gedit-latex - gedit plugin for editing latex documents
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Matěj Cepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-11 21:02 UTC by Ignacio Casal Quinteiro (nacho)
Modified: 2018-04-11 06:58 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-11-29 00:32:28 UTC
mcepl: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)

Description Ignacio Casal Quinteiro (nacho) 2011-09-11 21:02:22 UTC
Spec URL: http://people.gnome.org/~icq/gedit-latex.spec
SRPM URL: http://people.gnome.org/~icq/gedit-latex-3.1.1-1.fc16.src.rpm
Description: gedit-latex is the latex integration for gedit. It allows to simple
edit latex documents, providing auto-completion, templates, bibtex integration
and features to make it easier to edit this kind of documents.

Comment 1 Ignacio Casal Quinteiro (nacho) 2011-09-11 21:05:01 UTC
Here is the built for x86_64:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3343462

rpmlint info:

gedit-latex.x86_64: W: summary-not-capitalized C gedit plugin for editing latex documents
that's fine the name is gedit not Gedit
gedit-latex.x86_64: E: changelog-time-in-future 2011-09-12
well, I'm counting it will be tomorrow the review ;)
gedit-latex.x86_64: E: no-binary
yeah that's fine, it is a python plugin
gedit-latex.x86_64: W: only-non-binary-in-usr-lib
fine
gedit-latex.x86_64: E: non-executable-script /usr/lib64/gedit/plugins/latex/util/eps2png.pl 0644L /usr/bin/perl
fine
gedit-latex-debuginfo.x86_64: E: changelog-time-in-future 2011-09-12
said
gedit-latex-debuginfo.x86_64: E: empty-debuginfo-package
fine
gedit-latex.src: W: summary-not-capitalized C gedit plugin for editing latex documents
said
gedit-latex.src: W: spelling-error %description -l en_US bibtex -> exhibit
fine
gedit-latex.src: E: changelog-time-in-future 2011-09-12
said
3 packages and 1 specfiles checked; 6 errors, 4 warnings.

Comment 2 Mohamed El Morabity 2011-09-11 23:30:03 UTC
This package is in fact already available in the Fedora repositories and theoritically still maintained:
   https://admin.fedoraproject.org/pkgdb/acls/name/gedit-latex-plugin
You should contact its current maintainer and plan a real update of this package.

Comment 3 Ignacio Casal Quinteiro (nacho) 2011-09-12 08:21:00 UTC
ouch! my fault just looked for gedit-latex in koji.

Comment 4 Ignacio Casal Quinteiro (nacho) 2011-09-13 10:33:10 UTC
Reopening as we need to change the name of the package. I'll provide updated info.

Comment 5 Ignacio Casal Quinteiro (nacho) 2011-09-13 11:08:34 UTC
The previous links are updated now.

Build in koji:

http://koji.fedoraproject.org/koji/taskinfo?taskID=3348057

rpmlint:

gedit-latex.x86_64: W: summary-not-capitalized C gedit plugin for composing and compiling LaTeX documents
it is gedit not Gedit.
gedit-latex.x86_64: E: no-binary
that's fine
gedit-latex.x86_64: W: only-non-binary-in-usr-lib
not binary there.
gedit-latex-debuginfo.x86_64: E: empty-debuginfo-package
that's fine.
gedit-latex.src: W: summary-not-capitalized C gedit plugin for composing and compiling LaTeX documents
said
3 packages and 1 specfiles checked; 2 errors, 3 warnings.

Comment 6 Matěj Cepl 2011-09-13 16:24:23 UTC
Let me add couple of quick notes before doing a proper review:

First of all, who is sergiopr and what's his role in maintaing this package? Is he still the official maintainer of nor, or what?

(In reply to comment #5)
> gedit-latex.x86_64: E: no-binary
> that's fine

No, it isn't ... if gedit-latex is noarch (which I suspect it is), it should be noarch.

Actually when looking through the build gedit-latex-3.1.1-1.fc16.x86_64.rpm I don't see anything arch-specific, so this package should be noarch IMHO. The only problem is that there is a bug in spec not using standard Python macros. Specifically %{python_sitelib} should be used.

See http://fedoraproject.org/wiki/Packaging/Python for more details.

> gedit-latex.x86_64: W: only-non-binary-in-usr-lib
> not binary there.

ditto

> gedit-latex-debuginfo.x86_64: E: empty-debuginfo-package
> that's fine.

ditto ... no debuginfo should happen, because this shouldn't be arch-specific package.

Comment 7 Ignacio Casal Quinteiro (nacho) 2011-09-13 16:32:48 UTC
ah! ok, first time I make a noarch package. I'll fix it next week thanks a lot for the review.

Comment 8 Ignacio Casal Quinteiro (nacho) 2011-09-13 16:41:16 UTC
I think the reason this is not noarch is because we need to use the libdir macro.

Comment 9 Matěj Cepl 2011-09-13 20:55:30 UTC
(In reply to comment #8)
> I think the reason this is not noarch is because we need to use the libdir
> macro.

a) why?
b) I think %{_libdir} is available everywhere, for arch as well as for noarch. Try it.

Comment 10 Sergio Pascual 2011-09-13 21:09:59 UTC
Hi, I'm sergiopr :)

This review is for a package rename, from gedit-latex-plugin to gedit-plugin in F-17 and F-16. 

Ignacio, does the plugin work in F-15 or not? 

F-14 will continue providing gedit-latex-plugin

Comment 11 Sergio Pascual 2011-09-16 19:03:38 UTC
I would like to comaintain this package once it's approved. The old package (gedit-plugin-latex) will be available in Fedora-14, that ships with a 2.x gedit

Comment 12 Susi Lehtola 2011-09-20 08:32:24 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > I think the reason this is not noarch is because we need to use the libdir
> > macro.
> 
> a) why?
> b) I think %{_libdir} is available everywhere, for arch as well as for noarch.
> Try it.

This *needs* to be arch dependent, since %{_libdir} is /usr/lib on 32-bit and /usr/lib64 on (multiarched) 64-bit architectures. If you install to /usr/lib on 64-bit, the plugin won't work.

As to the spec: the statement 
 %dir %{_datadir}/gedit/plugins/latex
 %{_datadir}/gedit/plugins/latex/*
is a bit silly, since you can do the same thing with
 %{_datadir}/gedit/plugins/latex
or (somewhat more elaborately with)
 %{_datadir}/gedit/plugins/latex/

Comment 13 Ignacio Casal Quinteiro (nacho) 2011-09-20 08:49:33 UTC
(In reply to comment #12)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > I think the reason this is not noarch is because we need to use the libdir
> > > macro.
> > 
> > a) why?
> > b) I think %{_libdir} is available everywhere, for arch as well as for noarch.
> > Try it.
> 
> This *needs* to be arch dependent, since %{_libdir} is /usr/lib on 32-bit and
> /usr/lib64 on (multiarched) 64-bit architectures. If you install to /usr/lib on
> 64-bit, the plugin won't work.

Hey, sorry for the delay. Yeah that's what I wanted to say that it needs to be arch dependent. 
> 
> As to the spec: the statement 
>  %dir %{_datadir}/gedit/plugins/latex
>  %{_datadir}/gedit/plugins/latex/*
> is a bit silly, since you can do the same thing with
>  %{_datadir}/gedit/plugins/latex
> or (somewhat more elaborately with)
>  %{_datadir}/gedit/plugins/latex/

Sure I'll fix this thanks.

Comment 14 Ignacio Casal Quinteiro (nacho) 2011-09-20 09:24:07 UTC
Updated package. Sames links.

Comment 15 Susi Lehtola 2011-09-20 09:32:06 UTC
(In reply to comment #14)
> Updated package. Sames links.

Please bump the release and make a corresponding entry in the changelog every time you make changes to the spec file - also during the review.

Otherwise it is impossible for other people (including the reviewer) to see what has happened with the spec file.

Comment 16 Matěj Cepl 2011-09-20 12:12:59 UTC
- MUST: rpmlint must be run on the source rpm and all binary rpms the build
produces. The output should be posted in the review.

[matej@maceska task_3363917]$ rpmlint *.rpm
----------------- gedit-latex-debuginfo.i686: E: empty-debuginfo-package

Generation of debuginfo packages could be switched off (https://fedoraproject.org/wiki/Packaging/Debuginfo#Useless_or_incomplete_debuginfo_packages_due_to_other_reasons) by

%global debug_package %{nil}

----------------- gedit-latex.i686: E: no-binary
----------------- gedit-latex.i686: W: only-non-binary-in-usr-lib

This is OK (this is actually noarch package in arch's clothing).

3 packages and 0 specfiles checked; 2 errors, 11 warnings.
[matej@maceska task_3363917]$

+ MUST: The package must be named according to the Package Naming Guidelines.
There is a conflict with already existing package node, so rename is allowed.
+ MUST: The spec file name must match the base package %{name}, in the format
%{name}.spec unless your package has an exemption.
+ MUST: The package must meet the Packaging Guidelines.

tiny nitpicks
- %setup -q -n %{name}-%{version} === %setup -q
  (%{name}-%{version} is default)
- sed -i -e 1d latex/util/eps2png.pl
  I would prefer
  sed -i -e '/^#!\/.*bin\/perl/d' latex/util/eps2png.pl
  or something similar.

+ MUST: The package must be licensed with a Fedora approved license and meet
the Licensing Guidelines.
+ MUST: The License field in the package spec file must match the actual
license.
+ MUST: If (and only if) the source package includes the text of the license(s)
in its own file, then that file, containing the text of the license(s) for the
package must be included in %doc.
+ MUST: The spec file must be written in American English.
+ MUST: The spec file for the package MUST be legible.
+ MUST: The sources used to build the package must match the upstream source,
as provided in the spec URL. Reviewers should use md5sum for this task. If no
upstream URL can be specified for this package, please see the Source URL
Guidelines for how to deal with this.
MD5SUM: 262276187329b810143bdd712117ba87
+ MUST: The package MUST successfully compile and build into binary rpms on at
least one primary architecture.
Builds in koji http://koji.fedoraproject.org/koji/taskinfo?taskID=3363917
+ MUST: If the package does not successfully compile, build or work on an
architecture, then those architectures should be listed in the spec in
ExcludeArch. Each architecture listed in ExcludeArch MUST have a bug filed in
bugzilla, describing the reason that the package does not compile/build/work on
that architecture. The bug number MUST be placed in a comment, next to the
corresponding ExcludeArch line.
+ MUST: All build dependencies must be listed in BuildRequires, except for any
that are listed in the exceptions section of the Packaging Guidelines ;
inclusion of those as BuildRequires is optional. Apply common sense.
+ MUST: The spec file MUST handle locales properly. This is done by using the
%find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.
+ MUST: Every binary RPM package (or subpackage) which stores shared library
files (not just symlinks) in any of the dynamic linker's default paths, must
call ldconfig in %post and %postun.
+ MUST: Packages must NOT bundle copies of system libraries.
+ MUST: If the package is designed to be relocatable, the packager must state
this fact in the request for review, along with the rationalization for
relocation of that specific package. Without this, use of Prefix: /usr is
considered a blocker.
+ MUST: A package must own all directories that it creates. If it does not
create a directory that it uses, then it should require a package which does
create that directory.
+ MUST: A Fedora package must not list a file more than once in the spec file's
%files listings. (Notable exception: license texts in specific situations)
+ MUST: Permissions on files must be set properly. Executables should be set
with executable permissions, for example.
+ MUST: Each package must consistently use macros.
+ MUST: The package must contain code, or permissable content.
+ MUST: Large documentation files must go in a -doc subpackage. (The definition
of large is left up to the packager's best judgement, but is not restricted to
size. Large can refer to either size or quantity).
+ MUST: If a package includes something as %doc, it must not affect the runtime
of the application. To summarize: If it is in %doc, the program must run
properly if it is not present.
+ MUST: Header files must be in a -devel package.
+ MUST: Static libraries must be in a -static package.
+ MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1),
then library files that end in .so (without suffix) must go in a -devel
package.
+ MUST: In the vast majority of cases, devel packages must require the base
package using a fully versioned dependency: Requires: %{name}%{?_isa} =
%{version}-%{release}
+ MUST: Packages must NOT contain any .la libtool archives, these must be
removed in the spec if they are built.
+ MUST: Packages containing GUI applications must include a %{name}.desktop
file, and that file must be properly installed with desktop-file-install in the
%install section. If you feel that your packaged GUI application does not need
a .desktop file, you must put a comment in the spec file with your explanation.
+ MUST: Packages must not own files or directories already owned by other
packages. The rule of thumb here is that the first package to be installed
should own the files or directories that other packages may rely upon. This
means, for example, that no package in Fedora should ever share ownership with
any of the files or directories owned by the filesystem or man package. If you
feel that you have a good reason to own a file or directory that another
package owns, then please present that at package review time.
+ MUST: All filenames in rpm packages must be valid UTF-8.
+ SHOULD: If the source package does not include license text(s) as a separate
file from upstream, the packager SHOULD query upstream to include it.
+ SHOULD: The description and summary sections in the package spec file should
contain translations for supported Non-English languages, if available.
+ SHOULD: The reviewer should test that the package builds in mock.
builds in koji
+ SHOULD: The package should compile and build into binary rpms on all
supported architectures.
+ SHOULD: The reviewer should test that the package functions as described. A
package should not segfault instead of running, for example.
+ SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague,
and left up to the reviewers judgement to determine sanity.
+ SHOULD: Usually, subpackages other than devel should require the base package
using a fully versioned dependency.
+ SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and
this is usually for development purposes, so should be placed in a -devel pkg.
A reasonable exception is that the main pkg itself is a devel tool not
installed in a user runtime, e.g. gcc or gdb.
+ SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin,
/usr/bin, or /usr/sbin consider requiring the package which provides the file
instead of the file itself.
+ SHOULD: your package should contain man pages for binaries/scripts. If it
doesn't, work with upstream to add them where they make sense.

------------
Please fix the issue with the debuginfo indicated in the first point.
Otherwise, I think, we are almost there.

Comment 17 Susi Lehtola 2011-09-20 12:29:53 UTC
By the way, can you make this to work if you just put everything in /usr/share/gedit/plugins?

If not, you should file a bug against gedit, since it really shout support noarch plugins.

Comment 18 Susi Lehtola 2011-09-20 12:35:26 UTC
Matěj: https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages

also needs to be taken into account. If this is supposed to replace gedit-plugins-latex, then it should
 Obsoletes: gedit-plugins-latex < %{version}-%{release}
 Provides: gedit-plugins-latex = %{version}-%{release}

Comment 19 Sergio Pascual 2011-09-20 12:45:07 UTC
(In reply to comment #17)
> By the way, can you make this to work if you just put everything in
> /usr/share/gedit/plugins?
> 
> If not, you should file a bug against gedit, since it really shout support
> noarch plugins.

This problem was reported upstream here:
http://bugzilla.gnome.org/show_bug.cgi?id=554535


To remove empty debuginfo package, add this line to the specfile
%define debug_package %{nil}

Comment 20 Ignacio Casal Quinteiro (nacho) 2011-09-20 12:56:27 UTC
(In reply to comment #18)
> Matěj:
> https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages
> 
> also needs to be taken into account. If this is supposed to replace
> gedit-plugins-latex, then it should
>  Obsoletes: gedit-plugins-latex < %{version}-%{release}
>  Provides: gedit-plugins-latex = %{version}-%{release}

Fixed.

(In reply to comment #16)
> - MUST: rpmlint must be run on the source rpm and all binary rpms the build
> produces. The output should be posted in the review.
> 
> [matej@maceska task_3363917]$ rpmlint *.rpm
> ----------------- gedit-latex-debuginfo.i686: E: empty-debuginfo-package
> 
> Generation of debuginfo packages could be switched off
> (https://fedoraproject.org/wiki/Packaging/Debuginfo#Useless_or_incomplete_debuginfo_packages_due_to_other_reasons)
> by
> 
> %global debug_package %{nil}

fixed
> 
> ----------------- gedit-latex.i686: E: no-binary
> ----------------- gedit-latex.i686: W: only-non-binary-in-usr-lib
> 
> This is OK (this is actually noarch package in arch's clothing).
> 
> 3 packages and 0 specfiles checked; 2 errors, 11 warnings.
> [matej@maceska task_3363917]$
> 
> + MUST: The package must be named according to the Package Naming Guidelines.
> There is a conflict with already existing package node, so rename is allowed.
> + MUST: The spec file name must match the base package %{name}, in the format
> %{name}.spec unless your package has an exemption.
> + MUST: The package must meet the Packaging Guidelines.
> 
> tiny nitpicks
> - %setup -q -n %{name}-%{version} === %setup -q
>   (%{name}-%{version} is default)
> - sed -i -e 1d latex/util/eps2png.pl
>   I would prefer
>   sed -i -e '/^#!\/.*bin\/perl/d' latex/util/eps2png.pl
>   or something similar.

fixed
> 
> + MUST: The package must be licensed with a Fedora approved license and meet
> the Licensing Guidelines.
> + MUST: The License field in the package spec file must match the actual
> license.
> + MUST: If (and only if) the source package includes the text of the license(s)
> in its own file, then that file, containing the text of the license(s) for the
> package must be included in %doc.
> + MUST: The spec file must be written in American English.
> + MUST: The spec file for the package MUST be legible.
> + MUST: The sources used to build the package must match the upstream source,
> as provided in the spec URL. Reviewers should use md5sum for this task. If no
> upstream URL can be specified for this package, please see the Source URL
> Guidelines for how to deal with this.
> MD5SUM: 262276187329b810143bdd712117ba87
> + MUST: The package MUST successfully compile and build into binary rpms on at
> least one primary architecture.
> Builds in koji http://koji.fedoraproject.org/koji/taskinfo?taskID=3363917
> + MUST: If the package does not successfully compile, build or work on an
> architecture, then those architectures should be listed in the spec in
> ExcludeArch. Each architecture listed in ExcludeArch MUST have a bug filed in
> bugzilla, describing the reason that the package does not compile/build/work on
> that architecture. The bug number MUST be placed in a comment, next to the
> corresponding ExcludeArch line.
> + MUST: All build dependencies must be listed in BuildRequires, except for any
> that are listed in the exceptions section of the Packaging Guidelines ;
> inclusion of those as BuildRequires is optional. Apply common sense.
> + MUST: The spec file MUST handle locales properly. This is done by using the
> %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.
> + MUST: Every binary RPM package (or subpackage) which stores shared library
> files (not just symlinks) in any of the dynamic linker's default paths, must
> call ldconfig in %post and %postun.
> + MUST: Packages must NOT bundle copies of system libraries.
> + MUST: If the package is designed to be relocatable, the packager must state
> this fact in the request for review, along with the rationalization for
> relocation of that specific package. Without this, use of Prefix: /usr is
> considered a blocker.
> + MUST: A package must own all directories that it creates. If it does not
> create a directory that it uses, then it should require a package which does
> create that directory.
> + MUST: A Fedora package must not list a file more than once in the spec file's
> %files listings. (Notable exception: license texts in specific situations)
> + MUST: Permissions on files must be set properly. Executables should be set
> with executable permissions, for example.
> + MUST: Each package must consistently use macros.
> + MUST: The package must contain code, or permissable content.
> + MUST: Large documentation files must go in a -doc subpackage. (The definition
> of large is left up to the packager's best judgement, but is not restricted to
> size. Large can refer to either size or quantity).
> + MUST: If a package includes something as %doc, it must not affect the runtime
> of the application. To summarize: If it is in %doc, the program must run
> properly if it is not present.
> + MUST: Header files must be in a -devel package.
> + MUST: Static libraries must be in a -static package.
> + MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1),
> then library files that end in .so (without suffix) must go in a -devel
> package.
> + MUST: In the vast majority of cases, devel packages must require the base
> package using a fully versioned dependency: Requires: %{name}%{?_isa} =
> %{version}-%{release}
> + MUST: Packages must NOT contain any .la libtool archives, these must be
> removed in the spec if they are built.
> + MUST: Packages containing GUI applications must include a %{name}.desktop
> file, and that file must be properly installed with desktop-file-install in the
> %install section. If you feel that your packaged GUI application does not need
> a .desktop file, you must put a comment in the spec file with your explanation.
> + MUST: Packages must not own files or directories already owned by other
> packages. The rule of thumb here is that the first package to be installed
> should own the files or directories that other packages may rely upon. This
> means, for example, that no package in Fedora should ever share ownership with
> any of the files or directories owned by the filesystem or man package. If you
> feel that you have a good reason to own a file or directory that another
> package owns, then please present that at package review time.
> + MUST: All filenames in rpm packages must be valid UTF-8.
> + SHOULD: If the source package does not include license text(s) as a separate
> file from upstream, the packager SHOULD query upstream to include it.
> + SHOULD: The description and summary sections in the package spec file should
> contain translations for supported Non-English languages, if available.
> + SHOULD: The reviewer should test that the package builds in mock.
> builds in koji
> + SHOULD: The package should compile and build into binary rpms on all
> supported architectures.
> + SHOULD: The reviewer should test that the package functions as described. A
> package should not segfault instead of running, for example.
> + SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague,
> and left up to the reviewers judgement to determine sanity.
> + SHOULD: Usually, subpackages other than devel should require the base package
> using a fully versioned dependency.
> + SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and
> this is usually for development purposes, so should be placed in a -devel pkg.
> A reasonable exception is that the main pkg itself is a devel tool not
> installed in a user runtime, e.g. gcc or gdb.
> + SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin,
> /usr/bin, or /usr/sbin consider requiring the package which provides the file
> instead of the file itself.
> + SHOULD: your package should contain man pages for binaries/scripts. If it
> doesn't, work with upstream to add them where they make sense.
> 
> ------------
> Please fix the issue with the debuginfo indicated in the first point.
> Otherwise, I think, we are almost there.

Comment 21 Ignacio Casal Quinteiro (nacho) 2011-09-20 12:56:53 UTC
btw, spec in the same link and http://people.gnome.org/~icq/gedit-latex-3.1.1-2.fc16.src.rpm for the new srpm.

Comment 22 Susi Lehtola 2011-09-20 12:57:50 UTC
(In reply to comment #19)
> (In reply to comment #17)
> > By the way, can you make this to work if you just put everything in
> > /usr/share/gedit/plugins?
> > 
> > If not, you should file a bug against gedit, since it really shout support
> > noarch plugins.
> 
> This problem was reported upstream here:
> http://bugzilla.gnome.org/show_bug.cgi?id=554535

Then clearly you need to reopen the bug.

The Filesystem Hierarchy Standard states

4.11. /usr/share : Architecture-independent data
4.11.1. Purpose
The /usr/share hierarchy is for all read-only architecture independent data files. This hierarchy is intended to be shareable among all architecture platforms of a given OS; thus, for example, a site with i386, Alpha, and PPC platforms might maintain a single /usr/share directory that is centrally-mounted. Note, however, that /usr/share is generally not intended to be shared by different OSes or by different releases of the same OS.

Comment 23 Ignacio Casal Quinteiro (nacho) 2011-09-20 13:01:37 UTC
In any case this should be reopened under libpeas not gedit.

Comment 24 Matěj Cepl 2011-09-21 14:43:45 UTC
And in meanwhile, this review is APPROVED.

Comment 25 Ignacio Casal Quinteiro (nacho) 2011-09-21 14:49:46 UTC
New Package SCM Request
=======================
Package Name: gedit-latex
Short Description: gedit plugin for composing and compiling LaTeX documents
Owners: nacho sergiopr
Branches: f16
InitialCC:

Comment 26 Gwyn Ciesla 2011-09-24 15:51:08 UTC
Git done (by process-git-requests).

Comment 27 Matěj Cepl 2011-11-29 00:32:28 UTC
What about closing this bug when the package is built?

http://koji.fedoraproject.org/koji/packageinfo?packageID=12607


Note You need to log in before you can comment on or make changes to this bug.