Travis CI build could not compile

beginners
1

I have just tried to submit a new part via GitHub (https://github.com/fritzing/fritzing-parts/pull/230), but the checks fail with “Travis CI build could not compile”. This is the first time I’ve submitted anything through GitHub, so I’ve really no idea where my problem lies.

The critical part of the Job Log appears to be:

[0K$ go get github.com/fritzing/fzp/bin/fzp
# github.com/fritzing/fzp/bin/fzp
../fzp/bin/fzp/command-create.go:13:16: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
	cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
../fzp/bin/fzp/command-create.go:18:16: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
	cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
../fzp/bin/fzp/command-create.go:22:16: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
	cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
../fzp/bin/fzp/command-create.go:27:16: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
	cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
../fzp/bin/fzp/command-create.go:31:16: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
	cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
../fzp/bin/fzp/command-create.go:36:16: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
	cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
../fzp/bin/fzp/command-create.go:40:16: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
	cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
../fzp/bin/fzp/command-create.go:44:16: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
	cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
../fzp/bin/fzp/command-create.go:48:16: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
	cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
../fzp/bin/fzp/command-encode.go:15:16: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
	cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
../fzp/bin/fzp/command-encode.go:15:16: too many errors
travis_time:end:22c23b48:start=1577795887819766211,finish=1577795895145004674,duration=7325238463,event=install
e[0Ke[31;1mThe command "go get github.com/fritzing/fzp/bin/fzp" failed and exited with 2 during .e[0m

Your build has been stopped.

I do have a programming background, but I have no idea what these error messages might mean in relation to either my part or the submission process. Can anyone direct me to something like a Troubleshooting Guide that might help me work out what’s going wrong?

(I have actually tried to submit three new parts, and the submissions all fail in exactly the same way, so I am at least being consistent with what ever it is that I’m doing.)

Thanks

2

Welcome aboard! People making parts are always most welcome. Unfortunately documentation is a major lack. Questions in here or on github are the usual solution. It looks like you have hit a bug in the TravisCI checks (which are brand new, development had stopped around 2016 and is just restarting and the build chain had to be completely rebuilt.) It is likely caused by something invalid in the part .fzp file. The easiest fix is to post the .fzpz file for the part here and I’ll have a look at it and see what is wrong. To get a .fzpz file in Fritzing right click on the part in the mine parts bin and select export part which will write a .fzpz file. Upload is 7th button from the left in the reply menu. An alternative is to run your parts through the FritzingCheckPart.py script available here:

which will check for common errors and syntax errors in a part. However the output depends on you knowing what the correct xml should look like which is not necessarily easy.

Peter

3

Thanks Peter. I’ve had a quick look at the FritzingCheckPart.py stuff and I see that there’s a fair bit to get around there so let me take the easy way out this first time around and just post the part for you to look at.

As noted, I have three parts to begin with. They were all created, starting with the Fritzing templates, using Illustrator. The only thing I can see from reading the FritzingCheckPart documentation is that maybe I didn’t create the square PCB pads correctly (because there wasn’t one in the template). I also had to ‘fiddle’ with the ‘copper0’ and ‘copper1’ layer order to get the part accepted by Fritzing in the first place, so that is another deviation from the PCB template that might be a problem.

Anyway, I’ve just attached the one part for the moment. I’m pretty confident that any problem will be the same in all the parts I have created so far.

Thanks

Heltec WiFi LoRa 32.fzpz (38.1 KB)

4

I think this may be a tool chain problem rather than yours. Your part looks by and large fine, and I don’t see anything that should cause the errors you are seeing. One problem I didn’t correct is the pins are not in sequence (pin1 is missing, there is a bug in parts editor where it skips pins.) The only thing that may effect is the hover on the pin to get the label function. In (I think only subpart parts which this is not) that screws up if the numbers are not in sequence. Breadboard and schematic lack layerIds , but all that affects is svg export (the part won’t show in a svg export.) PCB looked fine (other than the holes are likely too small for .1in headers). In this part I rescaled all the svgs to be the standard (which will make no difference to Travisci, it doesn’t check scale), changed the pcb pads to have 0.038in holes suitable for .1in headers and removed one bus (gpio17 to connector pin 1 which doesn’t exist, gpio17 doesn’t look like it should be bused to anything.) I also ran it through FrtizingCheckPart.py which inlines styles (which Fritzing sometimes doesn’t support) and removes px from font-size (which causes font-size to be set to 0 on a parts editor edit). The original file only has these two errors and the second isn’t actually an error in this case, the lack of a terminalId will be ignored by Fritzing as will the missing bus member:

Error 53: File
‘part.HeltecWiFiLoRa320000_60af58a4a22947c531eac6e81f836375_22.fzp.bak’
At line 601

Bus nodeMember connector1 does’t exist

Error 18: File
‘part.HeltecWiFiLoRa320000_60af58a4a22947c531eac6e81f836375_22.fzp.bak’

Connector connector0terminal is in the fzp file but not the svg file. (typo?)

svg svg.breadboard.HeltecWiFiLoRa320000_6af188b3115e879b6ec332508a4ec538_3_breadboard.svg.bak

Here is the improved part, you can try running it through travisci and see if it is any happier, but I don’t see why it will be.

Heltec WiFi LoRa 32-improved.fzpz (37.0 KB)

Nice job on the part! If as I expect travisCI still complains, you need to log a bug on github to get the developers to look at why TravisCI is failing.

Peter

5

Thanks Peter, but whatever change has been made has had a knock-on effect in that the Stroke Weights are no longer correcetly interpreted by Illustrator. I had noticed this with other parts that I originally tried to use as a template for what I was doing and finally decided that I would be better off starting from scratch. At one level this is not a problem, because I don’t ever modify the .svg files when making changes, I generate new versions from the ‘parent’ Illustrator file, which then has me worrying that this problem is going to surface every time I amend a part (if I can’t work out what to do either up front in Illustrator, or within the Parts Editor during the creation process).

On the specific error noted, i.e. the absence of a ‘connector1’, I noted that when I created these parts, Fritzing would indeed start with ‘connector0’ when defining connectors, but would always skip ‘connector1’, so that while ‘pin1’ was always ‘connector0’, ‘pin2’ became ‘connector2’ and so on.

I’ve just checked this again now. I started defining a new part, as I believe was recommended somewhere, using a standard Fritzing part (the 8-pin IC) as the base. When I got to defining connectors, due a completely different problem I encountered early on, I didn’t just replace the 8 with the new number (36 in this case), I erased all the connector descriptions first by entering 1 (0 didn’t work), then I entered the desired number (36 in this case).

I do now note that if I just replace the 8 with 36 the new connectors are created and the sequence ‘connector0’, ‘connector1’ etc. is retained, but if I first enter 1, whereupon we end up with just a single connector, correctly identified as ‘connector0’, and then enter another number, 36 in our case, the new connectors that are created, after ‘connector0’, start with ‘connector2’ and skip over ‘connector1’.

Interestingly, I’ve also tried this with the first four parts in the ICs section of the Core Parts—IC, atmega168, LM 358 Dual Op-Amp and 555 Timer—and all but the atmega168 part display this behaviour. If I set the number of connectors to 1, then to 36, ‘connector1’ is skipped. Curiously, if I do the same with the atmega168 part, first enter 1 then 36, the correct numbering is retained. I’m using Fritzing 0.9.3 on OS X 10.11.6. if that makes any difference.

This behaviour seems to be repeatable, and may be where things need to be fixed.

Any comments?

6

I use Inkscape rather than Illustrator (mostly because as Inkscape is open source, most folks use it) and I normally don’t use parts editor because I find it easier to edit the fzp file directly. If I don’t have a suitable part I usually use a generic IC of the appropriate number of pins (because its svgs are the correct scale from Fritzing) or a generic header (whose scale is not correct) if it is an odd number of pins. In both cases the part factory will generate the pins with the correct sequence, it is only parts editor which will generate missing pins as far as I know. Illustrator may not be happy with something Inkscape did to the svgs, although I don’t know what exactly.

Peter

7

OK, having now looked at the structure, I think I’d be comfortable working with the .fzp file directly, but how are the ‘linkages’ between the .fzp and .svg files created? The .svg files I feed into the Parts Editor don’t have any connector labels as such, but I note that the ones extracted from the .fzpz file do. The Parts Editor presumably does something in the background when I ‘Select graphic’ for individual pins. Should I just go and read about that somewhere, or just keep askling quesitons here?

8

Your best bet is ask questions here, there is relatively little documentation. The fzp specifies pretty much everything, that is what the parts editor is modifying. For renumbering, I generally use this script to create the number of pins I need and then use a text editor to replace the current connector definitions. Then I just need to set the name and description fields.

The connector definition sets all the values in the svg. As an example here is the first connector from your fzp file:

   <connector type="male" id="connector0" name="pin 1">
     <description>Pin 21, SDA, GPIO21, V_SPI_HD</description>
     <views>
       <breadboardView>
         <p svgId="connector0pin" layer="breadboard"/>
       </breadboardView>
       <schematicView>
         <p terminalId="connector0terminal" svgId="connector0pin" layer="schematic"/>
       </schematicView>
       <pcbView>
         <p svgId="connector0pin" layer="copper0"/>
         <p svgId="connector0pin" layer="copper1"/>
       </pcbView>
     </views>
   </connector>

for each view svgId=“connector0pin” defines the pin name in the svg. If no terminalId=“connector0terminal” is present, the connection will be made in the center of the svgId element. In the breadboard case, since they are circles and that is where we want the connection we skip the terminalId. In schematic the pin is usually a line or rectangle, and we want the connection to be at one end or the other of the pin, so the terminalId is usually a rectangle that is centered on the end of the pin (that is what the Select graphic for pin does. As far as I know it needs the pins defined in the svg. It will then put the terminalId on the selected end of the pin, but I think only if there is already a terminalId defined. If you haven’t seen them this set of tutorials covers the current Fritzing versions (many of the others on the net are for older versions):

Part creation howto part 1 breadboard and pcb

there are currently 9 of them as I try and document all the stuff I have learned from folks in here (most of who are no longer posting.)

Peter

9

OK, I’ve started working through those tutorials, but there’s a lot more there than I really want to digest at the moment…

I have tried a couple of simple things, mainly just amending bits and pieces in the .fzp file, but I am unable to recreate a .fzpz file. I’ve read several posts supposedly describing what has to be done—correctly naming the relevant files, 'zip’ing them (taking care to exclude the .DS_Store files that OS X likes to insert everywhere) and renaming the archive. I believe that I am following those instructions to the letter, but while fzpzclean.py appears to recognise the content (and split the relevant files out exactly as expected), it issues warnings relating the .svg files:

$ python fzpzclean.py -f tempd -d tempc -o core -r
<part>.fzpz
WARNING reference could not be found: <part>0000_2_breadboard.svg
WARNING reference could not be found: <part>0000_2_icon.svg
WARNING reference could not be found: <part>0000_2_pcb.svg
WARNING reference could not be found: <part>0000_2_schematic.svg
$

Further, and more critically, the newly created .fzpz file will not load into Fritzing.

I’ve attached two files. The first Heltec CubeCell.fzpz (54.0 KB) is the part that I created, which still has the problems we’ve been discussing in relation to verifying its structure but which loads and is usable just fine in Fritzing. The second file Heltec CubeCell (reconstituted).fzpz (53.9 KB) is simply the result of ‘cleaning’ the original file (through fzpzclean.py) then reconstituting the .fzpz file by changing the names of the various files (no other changes) as required, 'zip’ing them, then renaming the .zip file .fzpz.

I can’t see any difference between the two (except for the extra ‘differentiating’ characters in the filenames, as would probably be expected) using the tools I’m using, but there’s obviously something seriously wrong with the reconstituted file. I’m hoping that the problem will be obvious to you and is something I can fix relatively easily. If I can successfully rebuild the .fzpz file from the necessary components, I should be able to work through the changes that I need to make to get the various components in order.

I don’t have FritzingCheckPart running yet becasue I’m using OS X and need to upgrade Python first, which was more than I wanted to worry about unless there was an end in sight. If I can’t make an .fzpz file successfully, I might just have to live with what I’ve got for the time being. My parts work just fine as they are for what I’m doing. There was just a request for a part that I had and I thought I’d oblige by putting it up on GitHub, but I only have so much time available…

Thanks for your help.

10

Yep, its an easy one. Your fzp file is incorrect. The file names in the fzp don’t match the real file names:

fzp file:

  <views>
   <iconView>
     <layers image="icon/HeltecCubeCell0000_2.svg">
       <layer layerId="icon"/>
     </layers>
</iconView>

the file system:

$ ls

…
svg.icon.HeltecCubeCell0000_2_icon.svg

In the fzp file the layer line needs to be

image="icon/HeltecCubeCell0000_2_icon.svg">

to match the name in the file system. (except for the svg.icon part which translates in to icon/ in the fzp file) and it does not so the svg file isn’t found:

Error 15: Can not rename

‘svg.icon.HeltecCubeCell0000_2.svg’

to

‘svg.icon.HeltecCubeCell0000_2.svg.bak’

‘svg.icon.HeltecCubeCell0000_2.svg’

No such file or directory (2)

As far as I know the .fzpz file format isn’t documented anywhere, I guess I should do that …

Peter

11

OK, thanks. I think that’s all sorted now, but I still can’t upload the files to GitHub. Travis CI is still failing to compile. Someone [KjellMorgenstern] has responded to my GitHub query stating that the problem appears to be with the ‘toolchain’. Do you have any idea what’s going on there? Should I just wait until someone says it’s fixed? Should I be worrying about putting parts up on GitHub at all, or just post them to this forum?

Thanks again.

12

Kjell is one of the official developers (I am not :slight_smile: ) which confirms what I suspected which is the fault is in the build system, not your code. They had to build a completely new build system over the past year as the one used for the 0.9.3b release in 2016 apparently no longer exists. The 0.9.4 release is a handful of pull requests made since 2016 and mostly a test of the new build system to make sure it all works. It looks like a change has been made that broke parts submit (it used to work correctly), so yes waiting a bit for the fault to get fixed and then submitting via github is the correct response. For a number of years now, pars submitted here in the forums were not being moved in to core parts (as it says somewhere in here will happen.) The only way parts make it in to core parts is via submission on github. Hopefully as we get development started again, that will change but for now github submission is it.

Peter