> Do you mean that some of your Wheezy packages have patches from Squeeze? > What is the benefit of that? I don't understand how it becomes more generic > because of that. > > I don't think that I fully understand what you mean. I mean that some patches written for Squeeze were still needed for Wheezy because what we need was still not implemented in Wheezy. This is not exactly the same as I understand your notice. For example the background image patch for LxLauncher was still needed in Wheezy. > I am an expert in bugging upstream to include or fix stuff. ;-) Ok nice, you're the right man then! > What are these derivatives tools? Is it tools for pure blends? I finally managed to find the URL: http://dex.alioth.debian.org/census/DoudouLinux/patches/ This page collects all our patches. This is very useful to quickly analyze all the things we needed to change. As soon as a Debian repository is available, this page is available for a given derivative. > Great! > > Maybe you can suggest a few easy packages, or something that would > help you if it was uploaded. I can see two kinds of packages you should probably consider in first position: * DoudouLinux-specific packages that we are sure to maintain in the long term (eg. live-related ones, system-related one) * third party software that is not currently in Debian or obsolete (eg. TBO, Songwrite2) I must say that what would really help us in the end, would be to be able to have our repository totally managed by the Debian infrastructure. This way our packages would automatically get built for any architecture. But the way is still long since this also means including all our work into Debian as well as sticking to the Debian development cycle (we are still based on old-stable…). > It is probably wise to bundle them together into one simple-sessions package > or something. Sounds good, you're right. > Of course, it all depends on how big the change is and if the change is > relevant for upstream. Yes, it is hard to decide for them how relevant what we are doing is. > What are the typical changes that are made? It depends on the role of the software. Most of changes are very small and may not meet strong adhesion from upstream! Few examples: * in alsa-utils, just changed the default sound volume from 80% to 50% * in apertium-dbus, a quick and dirty fix for an issue concerning Python environment variables when creating a child process (I think we reported the fix on the Debian bug report page, without success upstream) * in dansguardian, just removed the hard dependency with clamav by recompiling the package without clamav support (and changed the binary package name) * in freealchemist, just added an exit key to be able to quit the application without mouse * in gamine, forced letters to be printed uppercase on screen, just as they are written on keys > Or just generate patches when translations are done. :-) Good idea. This is probably not so strong an effort and easier to include upstream. We recently had a discussion on the list about our translation process, upstream and motivation: https://mail.gna.org/public/doudoulinux-lang/2014-01/msg00005.html > As a last note, and I think my main focus, it would be good to start of > with having some package work done and uploaded. When that is > started I think we can have a better view of what lies ahead. Yes, getting one's hand dirty is often the best way to evaluate the difficulty! -- Cheers, JM.
Attachment:
signature.asc
Description: This is a digitally signed message part