Hi Wookey On Sunday 04 October 2015 02:34:23 Wookey wrote: > +++ Wookey [2015-10-03 14:05 +0100]: > > +++ Gudjon I. Gudjonsson [2015-10-03 13:48 +0200]: > > > Changes since the last upload: > > > * New upstream release (Closes: #789831) > > > * Improve manpages asxxxx and sdcc > > > * Add manpages sdar, sdas390, sdasrab, sdasstm8, sdastlcs90, > > > > > > sdldstm8, sdnm, sdobjcopy, sstm8 > > > > > > * Remove manpage savr > > > * Remove patches, 02_fix_spelling and 03_fix_compilation. Fixed > > > > > > in upstream. > > You also removed 01_disable nonfree. Is that no longer relevant? No, upstream improved the disable parameters --disable-non-free \ --disable-pic14-port \ --disable-pic16-port \ does the work > > > > * Bump standards version to 3.9.6 > > > * Remove unneeded lines from clean target in rules file > > > * Update description i control file (Closes: #766325) > > > * Move sdar from sdcc-ucsim to sdcc > > > * Add binary file sdldstm8 to sdcc > > > * Add provides c-compiler to control file (Closes: #768307) > > I'm not quite sure about this one. Yes sdcc is a c-compiler, but it's > not a 'standard' one and if something is depending on c-compiler > because it doesn't care whether gcc or clang is used, it may not be > expecting to get sdcc instead? > > On the other hand bcc and tcc and gcc-avr also provide it. > > There seem to be 8 packages in the archive tha thave this dep: > icecc, ikiwiki-hosting-web, intercal, ksplice, laby, libinline-c-perl, > libtool, pmk > > How many of those work with sdcc instead of gcc? > > The string c-compiler does not appear in policy, so I must admit that > I'm not quite sure what exactly it is intended to mean/be used for. > > I've added this to the bugreport. Thanks. I am not sure about this either. > > > > * Add huge memory model libraries (Closes: #768307) > > > * Add deoendency on graphicsmagick-imagemagick-compat > > > * Exclude example code from compression > > Any reason why you didn't apply 766478 (use autotools-dev to update > config.* files for new arches) too? Doing this is in general good > practice (and as a porter I like to see such bugs fixed :-) I was not sure about the patch so I wanted to work on the bug after upload of 3.5.0. But since you recommend the patch I will apply it. > > > Apart from those queries I don't see anything amiss. > I've not checked a clean build due to desperate shortage of disk space. > > Assuming that goes OK, I could upload what you have, but I'd prefer to > see 766478 fixed too, and a bit more discussion abut whether 768307 is > actually 'right'. (maybe skip that until a conclusion is reached, > rather than delay uploading what is done). > > Wookey Great. Thanks I will apply the patch and wait for result on the c-compiler discussion.
Regards Gudjon
