On Thu, Feb 6, 2014 at 12:33 AM, Jean-Michel Philippe <[email protected]> wrote: > 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 :).
Indeed, finally! >> 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. Ok, I will look at that. >> 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! 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. > 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. I am an expert in bugging upstream to include or fix stuff. ;-) What are these derivatives tools? Is it tools for pure blends? >> 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). I would say that is the way to go. >> 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. Great! Maybe you can suggest a few easy packages, or something that would help you if it was uploaded. >> 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. It is probably wise to bundle them together into one simple-sessions package or something. >> 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! Ok. I'll keep that in mind. >> 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? Of course, it all depends on how big the change is and if the change is relevant for upstream. What are the typical changes that are made? > 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. Yeah, that would be a huge benefit. > 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... Or just generate patches when translations are done. :-) 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. -- Per > -- > Cheers, > JM. > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/cabyrxsqyo0c8ohqn3r8mklowoykbu00x7fjnumwdurtmw2g...@mail.gmail.com
