Tag Archives: DEP

Tanglu status report

Tanglu Logo (Text)

Hello everyone! I am very excited to report about the awesome progress we made with Tanglu, the new Debian-based Linux-Distribution.

First of all, some off-topic info: I don’t feel comfortable with posting too much Tanglu stuff to Planet-KDE, as this is often not KDE-related. So, in future Planet-KDE won’t get Tanglu information, unless it is KDE-related ;-) You might want to take a look at Planet-Tanglu for (much) more information.

So, what happened during the last weeks? Because I haven’t had lectures, I nearly worked full-time on Tanglu, setting up most of the infrastructure we need. (this will change with the next week, where I have lectures again, and I also have work to do on other projects, not just Tanglu ^^) Also, we already have an awesome community of translators, designers and developers. Thanks to them, the Tanglu-Website is now translated to 6 languages, more are in the pipeline and will be merged later. Also, a new website based on the Django framework is in progress.

The Logo-Contest

We’ve run a logo-contest, to find a new and official Tanglu logo, as the previous logo draft was too close to the Debian logo (I asked the trademark people at Debian). More than 30 valid votes (you had to be subscribed to a Tanglu Mailinglist) were received for 7 logo proposals, and we now have a final logo:

I like it very much :)

Fun with dak

I decided to use dak, the Debian Archive Kit, to handle the Tanglu archive. Choosing dak over smaller and easy-to-use solutions had multiple reasons, the main reason is that dak is way more flexible than the smaller solution (like reprepro or min-dak) and able to handle the large archive of Tanglu. Also, dak is lightning fast. And I would have been involved with dak sooner or later anyway, because I will implement the DEP-11 extension to the Debian Archive later (making the archive application-friendly).

duckWorking with dak is not exactly fun. The documentation is not that awesome, and dak contains many hardcoded stuff for Debian, e.g. it often expects the “unstable” suite to be present. Also, running dak on Debian Wheezy turned out to be a problem, as the Python module apt_pkg changed the API and dak naturally had problems with that. But with the great help of some Debian ftpmasters (many thanks to that!), dak is now working for Tanglu, managing the whole archive. There are still some quirks which need to be fixed, but the archive is in an usable state, accepting and integrating packages.

The work on dak is also great for Debian: I resolved many issues with non-Debian dak installations, and made many parts of dak Wheezy-proof. Also, I added a few functions which might also be useful for Debian itself. All patches have of course been submitted to upstream-dak. ;-)

Wanna-build and buildds

<a target=_blank href="http://blog.tenstral.net/wp-content/uploads/2012/10/gear.png" rel="lightbox[1361]" title="Tanglu status …read more

Source: FULL ARTICLE at Planet KDE

Dmitrijs Ledkovs: Thoughts on Debian package policies

configure, Makefile.in, config.guess & config.sub
Are static, included copies of code that should always be rebuild during build. If they are not rebuild at build time, it should be documented/automated the relevant helpers that are needed to rebuild the package. If they are failing to rebuild it’s RC since source code is provided that is effectively cannot be modified in the preferred form. They also should not be modified in patch form, as editing generated code is not preferred form of modification. Also it constantly hurts us when bringing up new kernels and architectures (recently kfreebsd, armhf, aarch64). dh_autoreconf is a great tool to achieve thiis s.

no native packages
Generally if software is useful in Debian Project it can be useful for other debian-like and unlike projects. In particular native packages do not offer the same patching flexibility as 3.0 (quilt), thus forcing downstream distributions to inline modify packages without DEP-3 headers. This hurts us, when  trying to merge useful stuff from derivatives back into Debian, as changes are not split into individual patches.

shared maintainership
I’d like to put all my packages under “Debian Developers ” maintainership. There is no need for NMU, QA, TEAM upload. If you have a patch, I don’t want a bug in BTS nor commits, I’d like you to simply upload it into the archive. Especially blanket changes must be welcomed across the whole archive: translations, unit tests, porting to new debhelper versions, FTBFS fixes against next versions of compilers and interpreters, multiarch & cross-building fixes, porting to latest best packaging practices.

ps. comments are turned off. All further discussion is redirected to your choice of: debian-devel or my personal email.

Source: FULL ARTICLE at Planet Ubuntu