Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 168190 - Review Request: gpsim - A simulator for Microchip (TM) PIC (TM) microcontrollers
Summary: Review Request: gpsim - A simulator for Microchip (TM) PIC (TM) microcontrollers
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jose Pedro Oliveira
QA Contact: David Lawrence
URL: http://www.dattalo.com/gnupic/gpsim.html
Whiteboard:
Depends On: 168189
Blocks: FE-ACCEPT
TreeView+ depends on / blocked
 
Reported: 2005-09-13 11:59 UTC by Alain Portal
Modified: 2014-11-17 13:01 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-10-10 15:10:28 UTC
Type: ---
Embargoed:
gwync: fedora-cvs+


Attachments (Terms of Use)
specfile patch - removes the rpmlint messages (deleted)
2005-09-29 19:22 UTC, Jose Pedro Oliveira
no flags Details | Diff

Description Alain Portal 2005-09-13 11:59:30 UTC
Spec Name or Url: http://linuxelectronique.free.fr/download/fedora/4/SPECS/gpsim.spec
SRPM Name or Url: http://linuxelectronique.free.fr/download/fedora/4/SRPMS/gpsim-0.21.4-2.src.rpm
Description: gpsim is a simulator for Microchip (TM) PIC (TM) microcontrollers.
It supports most devices in Microchip's 12-bit, 14bit, and 16-bit
core families. In addition, gpsim supports dynamically loadable
modules such as LED's, LCD's, resistors, etc. to extend the simulation
environment beyond the PIC.

Comment 1 Alain Portal 2005-09-15 09:04:28 UTC
Spec Name or Url:  
http://linuxelectronique.free.fr/download/fedora/4/SPECS/gpsim.spec  
SRPM Name or Url:  
http://linuxelectronique.free.fr/download/fedora/4/SRPMS/gpsim-0.21.4-3.src.rpm  
  
* Thu Sep 15 2005 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 0.21.4-3 
  - Exclude .la file 
  - Add examples 
 

Comment 2 Alain Portal 2005-09-19 08:42:02 UTC
%changelog     
* Mon Sep 19 2005 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 0.21.4-4     
  - Add missing a rm -rf RPM_BUILD_ROOT statement in the install section     
     
Spec Name or Url:   
http://linuxelectronique.free.fr/download/fedora/4/SPECS/gpsim.spec   
SRPM Name or Url: 
http://linuxelectronique.free.fr/download/fedora/4/SRPMS/gpsim-0.21.4-4.src.rpm 

Comment 3 Jose Pedro Oliveira 2005-09-29 19:22:37 UTC
Created attachment 119432 [details]
specfile patch - removes the rpmlint messages

Alain,

The attached patch removes the rpmlint errors (two new commands in the %prep
section) and reformats a couple of lines.  Everything else looks good and the
package builds in mock.

Comment 4 Alain Portal 2005-09-30 07:46:17 UTC
%changelog  
* Fri Sep 30 2005 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 0.21.4-5  
  - Improve prep section to make rpmlint happy  
  - Contributions of Jose Pedro Oliveira <jpo[AT]di[DOT]uminho[DOT]pt>  
    Thanks to him.  
  
Spec Name or Url:    
http://linuxelectronique.free.fr/download/fedora/4/SPECS/gpsim.spec    
SRPM Name or Url:  
http://linuxelectronique.free.fr/download/fedora/4/SRPMS/gpsim-0.21.4-5.src.rpm 

Comment 5 Jose Pedro Oliveira 2005-09-30 09:15:35 UTC
APPROVED

MD5SUMS:
1323d4df3780ba85deefcf1a8eda836d  gpsim-0.21.4-5.src.rpm

42dafc3ce0b1dba8f9d2daa2a3708baf  gpsim-0.21.4.tar.gz
b1f6335c24e1d1bb2cd0d2131510b106  gpsim.spec


Good:
* Package name follows standard
* Source taball MD5 digest verified
* URL and Source url are valid
* License verified
* License text included
* File permissions are ok
* post/postun scripts present and valid
* Builds without problems in FC3
* Builds without problems in mock (FC4)
* Installs/uninstalls without problems in FC3


Comment 6 Michael Schwendt 2005-10-02 21:53:23 UTC
> Requires:	gtk+extra = 1.1.0

What is the reason for requiring this strict version?

Comment 7 Alain Portal 2005-10-03 07:06:18 UTC
That is because the development of gtk+extra freeze during more than 3 years 
(http://gtkextra.sourceforge.net/ last release 0.99.17 on 12/04/2001) and the 
gpsim maintener need some improvements in gtk+extra. So he provide a release 
he need (gtk+extra 1.1.0). 
But gtk+extra development restart on 05/17/2005, last release is 2.1.1 on 
06/24/2005 which is incompatible with current version of gpsim. 

Comment 8 Ralf Corsepius 2005-10-03 07:50:16 UTC
(In reply to comment #7)
> That is because the development of gtk+extra freeze during more than 3 years 
> (http://gtkextra.sourceforge.net/ last release 0.99.17 on 12/04/2001) and the 
> gpsim maintener need some improvements in gtk+extra. So he provide a release 
> he need (gtk+extra 1.1.0). 
> But gtk+extra development restart on 05/17/2005, last release is 2.1.1 on 
> 06/24/2005 which is incompatible with current version of gpsim. 

What you say above is multiple troublesome:
1. The gtk+extra 1.1.0 gpsim requires, is not an official version of gtk+extras.
=> We should _not_ ship gtk+extra-1.1.0 under the name "gtk+extra", as shipping
something unofficial/derived under the original name, IMO is truely bad idea.
I think we should consider to withdraw the current gtk+extra-1.1.0.

2. gtk+extra > 2.x is incompatible to gtk+extra < 1.0
=> All 3 versions must be installable in parallel, should there be a
corresponding demand for all 3 versions.

What to do in detail, depends on packaging details of all 3 versions.

3. Requires: gtk+extra = 1.1.0
doesn't make any sense, because, to be able to ship all 3 versions, the package
names must be chosen in such a way they do not conflict, e.g.
gtk+extra (1.0.x)
gtk+extra11 (1.1.x)
gtk+extra2 (>= 2.0)

Comment 9 Michael Schwendt 2005-10-03 09:34:30 UTC
> So he provide a release he need (gtk+extra 1.1.0). 

There has been an official 1.0.0 release. How does the 1.1.0 unofficial
release compare with the official 1.0.0? What exactly is this 1.1.0
version? Where does it come from? Who is the one who came up with
that version number? Is it a CVS snapshot? Did the gpsim maintainer
create this version number out of thin air?

WRT Ralf's points: Full ACK.

We cannot offer an unofficial release with an unofficial version number
unless it is assured that the official release, regardless of how old it
may be, can be shipped conflict-free and using its original version and
official package name.

In addition to the explicit versioned Requires being both too strict
and too fragile, does the package provide any SONAMES which would
conflict with the official gtk+extra versions?


Comment 10 Alain Portal 2005-10-03 11:14:01 UTC
(In reply to comment #9)   
> > So he provide a release he need (gtk+extra 1.1.0).    
>    
> There has been an official 1.0.0 release. How does the 1.1.0 unofficial   
> release compare with the official 1.0.0? What exactly is this 1.1.0   
> version? Where does it come from? Who is the one who came up with   
> that version number? Is it a CVS snapshot? Did the gpsim maintainer   
> create this version number out of thin air?   
   
As the gtk+extra development was stopped (last released was 0.99.17 on   
12/04/2001 gtk1 based), Scott Dattalo, gpsim maintener, decided to port   
gtk+extra to gtk2 and released this port as 1.0.0 (unofficial), then 1.1.0,   
released on 04/29/2005.   
   
Official gtk+extra development restart and port to gtk2, and the new release   
was 1.0.0 on 05/17/2005. Last release is 2.1.1, on 06/24/2005.   
   
> WRT Ralf's points: Full ACK.   
>    
> We cannot offer an unofficial release with an unofficial version number   
> unless it is assured that the official release, regardless of how old it   
> may be, can be shipped conflict-free and using its original version and   
> official package name.   
>    
> In addition to the explicit versioned Requires being both too strict   
> and too fragile, does the package provide any SONAMES which would   
> conflict with the official gtk+extra versions?   
   
No, on unofficial gtk+extra, sonames are libgtkextra-x11-1.1.so*, on official  
gtk+extra, sonames are libgtkextra-x11-2.0.so*  
 
What should I have to do? 
Create a package as gtk+extra11 for unofficial version and gtk+extra for 
official? 
   

Comment 11 Ralf Corsepius 2005-10-03 11:58:00 UTC
(In reply to comment #10)
> (In reply to comment #9)   

> No, on unofficial gtk+extra, sonames are libgtkextra-x11-1.1.so*, on official  
> gtk+extra, sonames are libgtkextra-x11-2.0.so*  
>  
> What should I have to do?
>
> Create a package as gtk+extra11 for unofficial version and gtk+extra for 
> official? 
That won't help, because other packages potentially to be submitted could
require the official gtk+extra-1.x.

So you are facing several problems at once:
1. You must replace the current gtk+extra with an official package, either 2.0
or 1.0.
2. The unofficial version must not conflict with any official package.

I.e. you have to provide a solution that allows a clean, parallel installation
of all 3 packages, 'official old', 'official new' and 'inofficial', both devel
and run-time variant packages.

If following the gtk+/gtk2 naming conventions, you could to
1) Put the latest official gtk+extra-1 sources into "gtk+extra" packages and
increment the epoch. 
2) Ship gtk+extra >2.0 as "gtk2+extra" or "gtk+extra2"
3) Put the unofficial stuff into an arbitarily named package (say gpsim-libs)
and hack the package in such a way that this version doesn't conflict with any
of the official versions (Neither includes nor SONAMEs).

Instead of 3) you could merge the "unofficial gtk+extras" with the gpsim package
and link statically against it.

Many other possibilities are possible. As usual things depend on details.

The cleanest solution would be to push upstream gpsim to using the current
gtk+extra2. If they can provide such a solution in not too distant future,
upgrading gtk+extra to 2 and waiting with gpsim probably would be best.

Comment 12 Alain Portal 2005-10-03 13:28:45 UTC
(In reply to comment #11) 
> (In reply to comment #10) 
> > (In reply to comment #9)    
>  
> > No, on unofficial gtk+extra, sonames are libgtkextra-x11-1.1.so*, on 
official   
> > gtk+extra, sonames are libgtkextra-x11-2.0.so*   
> >   
> > What should I have to do? 
> > 
> > Create a package as gtk+extra11 for unofficial version and gtk+extra for  
> > official?  
> That won't help, because other packages potentially to be submitted could 
> require the official gtk+extra-1.x. 
>  
> So you are facing several problems at once: 
> 1. You must replace the current gtk+extra with an official package, either 
2.0 
> or 1.0. 
> 2. The unofficial version must not conflict with any official package. 
>  
> I.e. you have to provide a solution that allows a clean, parallel 
installation 
> of all 3 packages, 'official old', 'official new' and 'inofficial', both 
devel 
> and run-time variant packages. 
>  
> If following the gtk+/gtk2 naming conventions, you could to 
> 1) Put the latest official gtk+extra-1 sources into "gtk+extra" packages and 
> increment the epoch.  
> 2) Ship gtk+extra >2.0 as "gtk2+extra" or "gtk+extra2" 
 
I have to ask the gtk+extra maintener what are the real differences between 
his 1.0.0 and 2.0.0 version. I am not sure that is gtk1 and gtk2, so perhaps 
packaging 1.0.0 won't be needed. 
 
 
> 3) Put the unofficial stuff into an arbitarily named package (say 
gpsim-libs) 
> and hack the package in such a way that this version doesn't conflict with 
any 
> of the official versions (Neither includes nor SONAMEs). 
>  
> Instead of 3) you could merge the "unofficial gtk+extras" with the gpsim 
package 
> and link statically against it. 
>  
> Many other possibilities are possible. As usual things depend on details. 
>  
> The cleanest solution would be to push upstream gpsim to using the current 
> gtk+extra2. If they can provide such a solution in not too distant future, 
> upgrading gtk+extra to 2 and waiting with gpsim probably would be best. 
 
Sure, this is the best solution. I asked for that on the gpsim-devel list. As 
soon I get an answer, I'll feedback. 
 
Can we wait several days before doing something or should I have to do 
something immediatly? 
 

Comment 13 Alain Portal 2005-10-05 07:43:48 UTC
As latest gpsim cvs compile with the last official version of gtk+extra 
(2.1.1), gpsim maintener release a new version today. 
 
gtk+extra maintener comfirm me that gtk+extra-1.0.0 is gtk1 based and 
gtk+extra-2.1.1 is gtk2 based. 
The unofficial version is no more needed. 
 
To name these packages, I purpose gtk+extra for the 1.0.0 version and 
gtk2+extra for the 2.1.1 version. 
 
What to do with the current package named gtk+extra-1.1.0 on the cvs? 
Because it will seems newer than gtk+extra-1.0.0. 

Comment 14 Ralf Corsepius 2005-10-05 07:59:41 UTC
(In reply to comment #13)
> To name these packages, I purpose gtk+extra for the 1.0.0 version and 
> gtk2+extra for the 2.1.1 version. 
OK with me.
  
> What to do with the current package named gtk+extra-1.1.0 on the cvs? 
> Because it will seems newer than gtk+extra-1.0.0. 
I see 3 approaches:

1. package the official gtk+extra-1.x into gtk+extra and increment this
package's epoch. This way, the new gtk+extra package will drive the "inofficial
version" out of systems.

2. Ask one of the release managers to remove the already released *rpms.
Unfortunately I don't know who is able to do so.

3. Do nothing, and let gtk+extra-1.1 die out (discontinue the package). 
As it already had been released for devel, this would imply the package would
vanish for FC6 (!). However if another package should require gtk+extra-1.x you
probably will have to switch to item 1. above.

To me, 1. seems to be the cleanest solution.

Comment 15 Alain Portal 2005-10-05 08:53:30 UTC
(In reply to comment #14) 
> (In reply to comment #13) 
> > To name these packages, I purpose gtk+extra for the 1.0.0 version and  
> > gtk2+extra for the 2.1.1 version.  
> OK with me. 
>    
> > What to do with the current package named gtk+extra-1.1.0 on the cvs?  
> > Because it will seems newer than gtk+extra-1.0.0.  
> I see 3 approaches: 
>  
> 1. package the official gtk+extra-1.x into gtk+extra and increment this 
> package's epoch. This way, the new gtk+extra package will drive the 
"inofficial 
> version" out of systems. 
 
I never use the Epoch tag. Should I have to put "Epoch: 1" in the spec? 
Should I have to do the same thing with the gpsim spec because 0.21.4 requires 
the inofficial gtk+extra package? gpsim version is now 0.21.11. 
Should I have to get a review request for the gtk2+extra package? 

Comment 16 Michael Schwendt 2005-10-05 10:36:09 UTC
Different option:

Put gtk+extra 2.x into package name "gtk+extra" version 2.x, which will
upgrade the existing packages for the unofficial 1.1.0 version.

Is gtk+extra 1.x needed by anything? Or would it be packaged just for
fun/completeness? If so, it could be packaged as gtk+extra1 any time.
Just make sure that it doesn't conflict _if_ it were packaged.

> Should I have to do the same thing with the gpsim spec
> because 0.21.4 requires the inofficial gtk+extra package? 

No. You would build the new gpsim version against your latest
gtk+extra packages, and it would be seen as an upgrade. Mind you,
dependencies on the new/different gtk+extra SONAMES are automatic.

Comment 17 Alain Portal 2005-10-05 11:32:17 UTC
(In reply to comment #16) 
> Different option: 
>  
> Put gtk+extra 2.x into package name "gtk+extra" version 2.x, which will 
> upgrade the existing packages for the unofficial 1.1.0 version. 
>  
> Is gtk+extra 1.x needed by anything? 
 
Not in Fedora at the moment, since that's me that want to introduce it because 
it was needed by gpsim (for previous releases). 
 
> Or would it be packaged just for 
> fun/completeness? 
 
I just listened Ralf. 
 
> If so, it could be packaged as gtk+extra1 any time. 
> Just make sure that it doesn't conflict _if_ it were packaged. 
 
No conflict. Both are currently installed on my box. 
 
> > Should I have to do the same thing with the gpsim spec 
> > because 0.21.4 requires the inofficial gtk+extra package?  
>  
> No. You would build the new gpsim version against your latest 
> gtk+extra packages, and it would be seen as an upgrade. Mind you, 
> dependencies on the new/different gtk+extra SONAMES are automatic. 
 
OK. 
 

Comment 18 Alain Portal 2007-07-20 18:35:07 UTC
Package Change Request
======================
Package Name: gpsim
Updated Fedora Owners: alain.portal

Please, add my home email in comps because I'm on vacation for 6 weeks.

Comment 19 Jens Petersen 2007-07-24 14:00:11 UTC
added

Comment 20 Roy Rankin 2009-06-06 23:10:27 UTC
Package Change Request
======================
Package Name: gpsim
New Branches: EL-5
Owners: rrankin

Comment 21 Jason Tibbitts 2009-06-08 16:22:37 UTC
CVS done.

Comment 22 Roy Rankin 2009-07-06 22:34:05 UTC
Package Change Request
======================
Package Name: gtk+extra
New Branches: EL-5
Owners: rrankin  

Note: gtk+extra is required to build gpsim and I cannot find a separate review request for gtk+extra  which has been in Fedora since FC-3.

Comment 23 Kevin Fenzi 2009-07-07 04:27:31 UTC
cvs done.

Comment 24 Roy Rankin 2010-07-01 10:55:39 UTC
Package Change Request
======================
Package Name: gtk+extra
New Branches: EL-6
Owners: rrankin

 Note: gtk+extra is required to build gpsim, which already has a CVS tag in El-6, and I cannot find a separate review
request for gtk+extra  which has been in Fedora since FC-3 and is in EL-5

Comment 25 Jason Tibbitts 2010-07-01 17:29:57 UTC
CVS done (by process-cvs-requests.py).

Comment 26 Roy Rankin 2014-10-26 04:04:47 UTC
Package Change Request
======================
Package Name: gpsim
New Branches: EPEL-7
Owners: rrankin

 Note; already in EPEL-5 EPEL-6 and Fedora

Comment 27 Roy Rankin 2014-10-26 04:06:58 UTC
Package Change Request
======================
Package Name: gtk+extra
New Branches: EPEL-7
Owners: rrankin

 Note: gtk+extra is required to build gpsim and I cannot find a separate review
request for gtk+extra  which has been in Fedora since FC-3 and is in EL-5, EL-6

Comment 28 Gwyn Ciesla 2014-11-17 13:01:02 UTC
Git done (by process-git-requests).


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