Re: [Doudoulinux-dev] Uploading DouDouLinux packages to Debian
On Thu, Feb 6, 2014 at 12:33 AM, Jean-Michel Philippe <philipjm@free.fr> 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.
>
Reply to: