Ohai! On Wed, Feb 23, 2011 at 12:18 AM, Loïc Minier <l...@dooz.org> wrote: > Hey again > > I prepared an u-boot upload which ships fw_printenv and a fw_setenv > symlink in u-boot-tools and which takes over uboot-envtools (dummy > transitional package) in git at: > git://git.debian.org/collab-maint/u-boot.git > > I'd prefer hearing from the maintainer, Per Andersson, to confirm it's > ok for me to proceed to an upload; it would be towards experimental for > now, but I'd move to unstable with the 2011.03 release of u-boot (or a > pre-release).
This is totally fine for me. I have asked earlier about merging uboot-envtools and uboot-mkimage into the u-boot package. [0] > Some implementation notes: > > * I opted not to install the tools/env/README as it was mostly aimed > towards people building the tools rather than using them > * I have a warning with crc32()'s signature with gcc-4.5, but not with > 4.4; I'll file a bug to look into the warnings; my preference would > be to use the same prototype as zlib (as uboot-envtools does in a > Debian patch), but I'm not sure what this entails upstream; for now, > this is built against the builtin crc32 in u-boot; I've opened a bug > against the u-boot source package to remember about this > * I copied over the examples and man pages (need to submit these > upstream); perhaps the configs should be generated during the build > instead; one important issue is copyright of the examples; I found a > couple of authors via debian/changelog, but I decided that the data > was publicly available and that the config files were mechanically > derived from the factory hardware layout; concerning comments, most > had no difference with upstream's; I found the following differences: > * typos (redundand vs redundant) > * qnap_ts101.config: explains primary versus secondary environment; I > need to figure out what to do with this; I've included a stripped > down version in the mean time > * qnap_ts119-219.config: documents machine names; I decided this > information was also mechanical > * I checked the Vcs-Git packaging repo and rescued a fix from there; > there are two things I didn't pick up: > * uboot-envedit script; this does indeed make sense within u-boot, > but I don't want to track multiple upstreams; maybe this should be > sent upstream? I have sent uboot-envedit to upstream IIRC. [1] > * debconf / automatic configuration: I'm not too happy with more > and more packages maintaining a list of board Hardware: names :-/ > I have some ideas to fix this on the long term, but it will take > time; also, I'm not too hot on debconf myself: I'd rather see d-i > install the correct config, perhaps in flash-kernel or some udeb > with board-specific knowledge Wouldn't this be suited for a u-boot-udeb? > * I checked the BTS and picked configs from #582832 and #582913 and > commented on #591604 which should be kept open and moved to u-boot > * I looked at debian/TODO; I am not sure I understood points 1 and 2 > being made there; Section/Priority seemed correct > * I'm using a specially crafted Version: field for u-boot's > uboot-envtools as u-boot's source version was lower > > Suggestions on the above are very welcome! Thanks for the work you do! [0] http://lists.debian.org/debian-release/2010/08/msg00805.html [1] http://lists.alioth.debian.org/pipermail/pkg-fso-maint/2009-August/001653.html -- Per > Thanks > -- > Loďc Minier > _______________________________________________ pkg-fso-maint mailing list pkg-fso-maint@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-fso-maint