Tag Archives: Debian Developers

Linux

Have you heard of Tanglu?

Leave a comment

If not, read this. This sounds like it’s going to be an awesome project, and I’m going to contribute in any way I can.

To quote some highlights from the initial announcement:

Tanglu will be based on Debian Testing and follow the Debian development closely. It will have a 6-months release-cycle and it’s target audience are Linux desktop users. We will make installing and setting up the distro as easy as possible.

Tanglu will be usable for both developers of upstream software and the average Linux user and Linux newbie. This is possible because in our opinion developers and users don’t have different needs for a desktop system. Both kinds of users like a polished desktop which “just works”. We will, hwever, not apply any kind of fancy modification on upstream software, we will basically just distribute what upstream created, so users can get an almost “pure” GNOME and KDE experience.

Tanglu is designed to be able to solve the issue that Debian is frozen for a long time and Debian Developers can’t make new upstream versions available for testing easily. During a Debian freeze, DDs can upload their software to the current Tanglu development version and later start the new Debian cycle with already tested packages from Tanglu. The delta between Tanglu and Debian should be kept as minimal as possible. However, Tanglu is not meant as experimental distribution for Debian, so please upload experimental stuff to Experimental. Only packages good enough for a release should go into Tanglu.

And the best part (to me, anyway 🙂 ):

Which desktop will you use?

Everyone can add a new desktop to Tanglu, as long as the desktop-environment is present in Debian. Long term, we will have to offer Linux-newbies a default flavour, probably by setting a default download on the website. But as long as there is a community for a given desktop-environment, the desktop is considered as supported.
At the beginning, we will focus on KDE, as many people have experience with it. But adding vanilla GNOME is planned too.

Yay for another option for a Debian based, pure KDE distro. I’m running both openSUSE and Kubuntu now on different machines. I’m surely more comfortable with Debian, but Kubuntu is simply more up-to-date, and KDE is really well integrated. I’m trying openSUSE, but having used Debian based distros for going on 10 years now, I still don’t have the level of comfort, so it lives on my (less critical) Laptop.

I see this as great because it will help the overall Debian ecosystem, which feeds not only Debian, but The ‘buntu’s, Mint CrunchBang and many others.

I just think it’s awesome to have something with a pure KDE more closely aligned with Debian coming soon.

Does this all sound as exciting to you as it does to me? Because, man, I’m pumped!

If so, do like I did and sign up for the mailing list, join the Freenode …read more
Source: FULL ARTICLE at Planet KDE

Linux

Tanglu

Leave a comment
A new logo?

Hi everyone!

Today I make an announcement I thought I would never ever make. But things changed.

Discussion about this has a long history, starting as a non-serious suggestion at DesktopSummit 2011, continued with people on IRC, but it was decided back then that it wouldn’t be worth the effort. This has changed too, and a small team has formed to work on it.

We hereby announce Tanglu, a new Debian-based-Linux distribution.

Why do we need another one? Let me explain the concepts of that distro:

Tanglu will be based on Debian Testing and follow the Debian development closely. It will have a 6-months release-cycle and it’s target audience are Linux desktop users. We will make installing and setting up the distro as easy as possible.

Tanglu will be usable for both developers of upstream software and the average Linux user and Linux newbie. This is possible because in our opinion developers and users don’t have different needs for a desktop system. Both kinds of users like a polished desktop which “just works”. We will not apply all kinds of fancy modifications on upstream software, we will basically just distribute what upstream wrote.

Tanglu is designed to be able to solve the issue that Debian is frozen for a long time and Debian Developers can’t make new upstream versions available for testing easily. During a freeze, DDs can upload their software to the current Tanglu development version and then start the new Debian cycle with tested packages from Tanglu. The delta between Tanglu should be kept s minimal as possible. However, Tanglu is not meant as experimental distribution for Debian, so please upload experimental stuff to Experimental. Only packages good enough for a release should go into Tanglu.

Ideally, Tanglu and Debian should be working well together in mixed environments, where you for example have Debian servers and multiple Tanglu desktops with the new software, targeted at desktop user. Since the differences between Tanglu and Debian should not be very high, administering both systems should be very easy (if you know Debian).

Tanglu will be an open project, driven by community. At the beginning of each cycle, people can make suggestions for release goals they want to implement (Similar to Fedora, but without FESCo). These proposals are discussed in public and are rejected if there are major technical concerns. If consensus about a certain proposal is lacking, a vote is done for it. The proposal can be accepted with absolute majority. If this does not happen, the proposal is postponed for the next release, where people can vote for it again. If nobody wants that function, it is rejected. In general, decisions made by Debian are superior and have to be followed.

We don’t think we know every package and every software better than the original upstream. That’s why it makes much sense to rely on feedback from others and to have a community-based and peer-reviewed distribution, instead of secretly developing stuff and dumping it on the community. Tanglu will have a highly predictable set of features, defined at …read more
Source: FULL ARTICLE at Planet KDE

Linux

Dmitrijs Ledkovs: Thoughts on Debian package policies

Leave a comment
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