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

Reply via email to