Hi Per, It's nice to see that you finally found the time to dive into our packages! As I told during the DebConf, the more we, Debian and DoudouLinux, share the effort, the best it is for us two. Of course this requires to allocate time and ressources on your side, but we hope and think Debian can really benefit in the end of this work :). > Do you have a list of packages that are in DouDouLinux but not (yet) > in Debian? There are several people that would like to help with > package and upload DouDouLinux software to Debian. The full, raw list of packages available is online: http://debian.doudoulinux.org/pkglist.php There are no descriptions though, this is a simple real-time file list. It is probably better if I take the time to write a short description somewhere. > I also saw some packages that seem to already be in Debian, like the > lxde packages (lxrandr, lxsession etc), python-editobj, songwrite, > gamine etc. > I assume there are some difference to the packages in Debian, can they > be merged? Yep! The derivatives guys did a great job on that topic. They've setup scripts that collect package diff's automatically. Unfortunately, hem, I can't find the URL anymore… Hope someone else has a better memory… Note that, working on our move from Squeeze to Wheezy, I saw in some Wheezy LXDE packages some of our patches written for Squeeze. This means there are probably people who use these diff's to get the most generic changes back to upstream. It's just good news! NB: I don't have enough time to be able to share with upstream. For this reason I find the tools of derivatives guys really useful since they give a single access point for upstream developers to the changes from all the derivatives. I fear they don't promote it enough though. > There are also some tweaks packages, can these go into Debian, > or, > possibly upstream? Yes, I think so, but they may also be integrated into existing packages. For example the package dansguardian-squid configures squid for use with dansguardian using an iptable redirection. It is maybe possible to include it in a package configuration process asking the user whether he wants this feature to be activated or not (and if squid is installed of course). > Maybe the system-tools packages is a candidate for upload to Debian? I agree to tell that if not all our packages can get into Debian as is, at least all of them should be considered as possible candidates as a start. However I have to purge the list from obsolete packages first, to avoid spending time on useless packages. > There are quite some session packages for starting a single > application, maybe these can go into Debian also? They should probably be merged into a single, generic package. > Not being particularly knowledgeable in either i10n nor l18n, is there > something stopping the burmese language and other font and language > packages from being uploaded/merged with Debian? Our l10n packages are updates of translations. I understood that package updates in Debian rarely include newer translations. For this reason I found more convenient to introduce our own l10n packages. Concerning kde-i18n packages, this was an attempt to provide smaller i18n packages for the Qt applications we're using and only them. I don't know why, this never worked as expected. You can forget them. Concerning Burmese, this is mainly a backport from Debian Wheezy to Squeeze. That said, in our package doudoulinux-burmese there are system settings for this language. It is a complicated subject because they use a dedicated alphabet that can require 4-5 bytes for a single character. As I understood things, there are different ways to store these characters in files, which then makes more or less easy to turn them into characters on screen. Some fonts are adapted to the way data is stored in files while other fonts are more compliant regarding to Unicode. Of course Burmese people may not all agree on the best way to do things… If there are Burmese contributors in Debian, you should probably contact them before. In any case our Burmese contributor would explain you the issues better than me! > You probably have lots of ideas and thoughts about sending stuff > upstream or uploading to Debian. Please share them! Sending stuff upstream for a derivative is likely complicated because many projects are involved and it would then require a lot of time. Maybe upstream project could be alerted automatically using email information of packages, when a patched package is being tracked by the derivatives tools? We are also facing this issue for translations. Contributing them back to either upstream or Debian is time consuming and nobody in our team has decided to take this role, although this question is regularly asked by our translators on our lists. The ideal situation would be a single, global translation repository for all the free projects, what Transifex is finally trying to do. Aggregating translations from upstream, to avoid redoing the work twice, was a recent discussion in DoudouLinux team and seems quite feasible. Dispatching them back to upstream is likely much more difficult since we would need write access to upstream repositories if we don't want to spend too much time into repetitive tasks. We would probably not get such write access for a machine… -- Cheers, JM.
Attachment:
signature.asc
Description: This is a digitally signed message part