Cross-posting on debian-desktop as some designers and artists might be lurking around.
Is there a starting point like an existing theme or documentation on the theming process where people can have a look and hack around ? Are there guidelines on the new design ? That it should somehow match other Debian web presence or existing Debian documentation themes ? I feel that the work on this will require iterations, improvements and bug/usability fixes, so people who are already regular or occasional contributors to Debian design and theming are welcome to help and voice their thoughts, whichever proposal ends up being selected. Cheers, --Aurélien Le 21 août 2017 23:46:17 GMT+02:00, Laura Arjona Reina <[email protected]> a écrit : >Hello designers! > >Quoting from the message below: > >"We are seeking volunteers to design a Debian documentation Sphinx >theme. The maintainers of other core pieces of Debian documentation >are >also looking to move to Sphinx, so such a theme would see wide use." > >Maybe somebody in this list can help on this? > >Thanks > > >-------- Mensaje Original -------- >De: Sean Whitton <[email protected]> >Enviado: 21 de agosto de 2017 23:35:39 CEST >Para: [email protected] >Asunto: Debian Policy 4.1.0.0 released > >Hello everyone, > >Debian Policy 4.1.0.0 is on its way into unstable. > >The source of the Policy Manual is now in reStructuredText, and the >Sphinx toolchain is used to produce our output formats. This has >enabled us to introduce new ePub and Texinfo output formats, so it's >now >more comfortable to read Policy on the beach, and in Emacs. > >Many thanks to Hideki Yamane for writing the rST conversion scripts and >pushing the project forward, and David Bremner for help proofreading. >Russ Allbery and I updated the build system. > >We are seeking volunteers to design a Debian documentation Sphinx >theme. The maintainers of other core pieces of Debian documentation >are >also looking to move to Sphinx, so such a theme would see wide use. > >Here are the changes from the previously announced version of Policy >(4.0.1): > >2.2.1 > Non-default alternative dependencies on non-free packages are > permitted for packages in main. > >4.11 > If upstream provides OpenPGP signatures, including the upstream > signing key as debian/upstream/signing-key.asc in the source > package and using the pgpsignurlmangle option in > debian/watch configuration to indicate how to find the upstream > signature for new releases is recommended. > >4.15 > Packages should build reproducibly when certain factors are held > constant; see 4.15 for the list. > >4.15 > Packages are recommended to build reproducibly even when build > paths and most environment variables are allowed to vary. > >9.1.1 > Only the dynamic linker may install files to /lib64/. > > No package for a 64 bit architecture may install files to > /usr/lib64/ or any subdirectory. > >11.8.3 > The required behaviour of x-terminal-emulator -e has been > clarified, and updated to replace a false claim about the > behaviour of xterm. > > Programs must support `-e command` where command may include > multiple arguments, which must be executed as if the arguments > were passed to execvp directly, bypassing the shell. > > If this execution fails and -e has a single argument, > xterm's fallback behaviour of passing command to the shell > is permitted but not required. > >-- >Sean Whitton > >Laura Arjona Reina >https://wiki.debian.org/LauraArjona > >-- >Design-devel mailing list >[email protected] >https://lists.alioth.debian.org/mailman/listinfo/design-devel
