Kernel 2.4 in Etch (was: Re: Re: /run vs /var/run)

[Filipus Klutiero]

Are we seriously expecting to ship etch with 2.4
kernels? Is anyone still doing active security support for it?

This point isn't too bad yet. As you've seen 2.4 had a security update a 
few days ago. Sure, it's from August, but 2.6 isn't doing better anyway. 
Some Debian kernel team people (such as Horms) seem to be dedicated to 
backport upstream's security work. A better question is whether there 
will be active security support for 2.4 if it sticks in Etch. This is 
unlikely to be much the case, considering that with the number of 
regressions in 2.6 continually dropping, when Etch releases 2.4 will 
probably look nearly as bad as 2.2 did when Sarge released (that was, no 
upstream release since over a year). So if we want 2.4 in Etch and 
decent  security, the kernel team may have to do better than upstream...
Another more interesting question is whether it's worth keeping 2.4 in 
Etch (which should mean about 3 years of backporting) assuming that the 
stable security infrastructure isn't fixed before Etch releases. 3.1r1 
was delayed due to kernel updates, and when it's ready to be released it 
has a 4 months old package. 3 months of updatedness gained, 4 lost.
In this context, if the security team doesn't change, removing half of 
the kernels would be a real help for the security of the rest of stable.


But for the first question, if there isn't a decision (and I don't know 
by who and how this decision will be made) about this in the few next 
monthes, the not so long schedule for Etch may make it impossible to do 
such a large change IMO.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Closing bugs due to removed code (was Re: Re: c2a transition: libraries still needing transition)

[Filipus Klutiero]

BTW: there are in bts some translations of fuse's debconf templates... may
I close these bugs with the upload which will remove templates at all or
should I close them manually with explanation that there won't be any
questions since now?




As you want. See for example 
http://packages.qa.debian.org/b/base-config/news/1.html



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: removal of svenl from the project

[Filipus Klutiero]

He were slandering somebody and others were listening/reading without
telling him that the behaviour is impolite? Well, then maybe it shows us
all (or at least the readers) in a bad light.
 

I'm pretty sure Sven recognized himself that he was impolite, but others 
certainly made him realize that his behaviour was not appropriate on 
several occasions too. Unfortunately, logs of Debian IRC channels are 
usually (always?) not available to public, but I follow #debian-kernel 
at times and didn't miss some of these occasions in the last weeks.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: removal of svenl from the project

[Filipus Klutiero]

I want to see you leave the Project if the expulsion process of both dilinger 
and svenl fails.

Seriously, it's strange that you state that without explanation. dilinger 
started a process to expulse svenl.
If the expulsion "suceeds", hopefully we'll be coherent and recognize dilinger 
for doing something good.
But if it fails, does that make dilinger someone that harmed the Project beyond 
the limits? Sure, the process already generated a painful thread, but does that 
balance dilinger's hundreds or thousands of commits and thousands of hours 
spent for the Project?
I think if the process fails we should rather conclude that dilinger made an 
honest error, and found a nice and (potentially) productive alternative to 
threatening someone physically.
There is a gray area between Sven is evil and Andres is evil, namely Andres and 
Sven are both imperfect but productive developers, and the Debian Project can 
handle their imperfections.

The only way I can make sense of what you said is that either Sven will stay 
and Andres is expulsed, or Sven will be expulsed and you will leave the Project 
by yourself in disagreement.

I hope the options are wider.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

No insulting messages?

[Filipus Klutiero]

But do you think that anything i said in those is insulting in some way, or a
reason for me to be expelled from debian ? 




Referring to what came after that, I guess "jonas going on with his bullshit" is pretty 
close to an insult. I am also natively French-speaking, but I think you will agree that "jonas 
replying with more erroneous arguments" would be safer.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Expulsion of Andres, GR against expulsion process

[Filipus Klutiero]

When you start an expulsion process with such a poor rationale, it's
pretty obvious it's going to fail. 2 small IRC logs do not constitute
a rationale for starting this process. Starting an expulsion process
against someone working in the same team is a strong indication that
the problem isn't as important as an expulsion would warrant, and that
the said team just can't deal with its internal problems.
 

I don't see why this would be the case. If you would be in the kernel 
team, would you keep yourself from suggesting dilinger's 
expulsion...because you would be in his team? More importantly, what 
would you do if someone in your teams happened to have problems with 
social behavior beyond what's acceptable...after trying to moderate that 
person had too limited effect? Keep in mind that in the kernel team's 
case at least, just making everyone but one person leave the team would 
certainly harm the kernel's quality too much.



Fact is, quite a few people, including myself, are working with Sven
and have good relations with him, be it for Debian-related work or
not. He's indeed easier to deal with IRL, but that's not an excuse for
not trying harder to deal with him on the lists/IRC. DDs traditionally
have strong opinions on technical subjects, Sven is no exception.

Sven is very competent and knowledgeable, especially when it comes to
PowerPC. He is a valuable DD, and his expulsion would really be a loss
for the Project.
 

I suspected that your original reply was in support of Sven and not just 
a reaction against trying to expulse anyone, but this was really not 
clear. Thanks for clarifying, this part of the mail I'm replying to is 
certainly what dilinger tried to generate (although he probably expected 
to hear the opposite opinion).




So, this expulsion process looks more like a good way to hurt Sven
than anything else. If it fails (hint: it will) Andres will be kind of
singled-out, and this whole thing will turn into "I can't bear this
guy, please kick him out".

In the meantime, we are wasting precious DD and DAM time to satisfy
Andres' need for a revenge on Sven.
 

This loops back to your original reply, which seems to exclude any 
possibility other than Andres being evil or Sven being evil, ignoring 
the possibility that Andres did an honest error trying to benefit the 
Project if the process fails.



The failure of this process means "we're not kicking Sven out, you'll
have to work together". Both Sven and Andres will have to cope with
that in whatever way, which may include leaving the Project.


My statement was expressing this: getting singled-out as Andres will
get once this process will have officially failed is a strong
indication that maybe, just maybe, you'd better leave now.
 

Yet, if this process fails, Sven and Jonas will have to work together. 
Perhaps not as much as Sven and Andres as kernel team members, but that 
depends on whether Andres resumes his activities in that team. If Andres 
keeps from getting involved (as usual) again in the kernel team, the 
potential for conflicts should be similar to the one between Sven and 
Jonas. Before Andres started the expulsion procedure, it looked like 
Sven and Jonas would stay in the same project, so I don't see why it's 
impossible to picture that Andres and Sven would stay in the same 
project too.




I consider this whole thing as a harsh and rude way to badly hurt
Sven, and he doesn't deserve that. He's the second DD to suffer from
this process, and at this point I am seriously considering a GR to
withdraw the whole expulsion process as decided by the DAMs. To date,
it has done more harm than good.

As someone else said, this expulsion request should not even have
passed the DAM.
 

It's a bit strange that you blame the expulsion process in the same 
message you say you think it's going to fail, but I also doubt that such 
a GR would be a good idea. I'll let you go ahead instead of commenting 
at this point though.



I essentially agree with Daniel's reply.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Discussing or working for Etch?

[Filipus Klutiero]

It seems that the project is splitting in two groups basically: The
people that wants to work together and release Etch, and the people
that with a reason or not wants to see it delayed. The minute after
the release team announces that we're going to delay our next release,
we will stop with these weird threads and keep arguing that we're all
volunteers and are doing our best. oh, the humanity!

I'm asking myself what's behind all that ? Ubuntu ? Probably no.
Subconcious fear to delivery in time ? Probably yes. Stop thinking
about who you're going to ask to be expelled next and spend some time
considering not my words, but just Etch.


Sorry Gustavo, but I think you're missing the end of dilinger's initial post:



So, if you are interested in seconding the expulsion request, please let
me know.  Please do not turn this into a flamewar; I don't care about
your reasons why people should not be forcefully removed from the
project.  Those who feel this way probably have not had to work w/ Sven
on a team for the past 2 years.



This is not meant to be a flamewar about whether expulsing anyone is 
working for Etch or not, but a discussion about Sven's contribution to 
the Project.


But it is funny that you place dilinger's proposition in the perspective 
of releasing Etch. It happens that both of our RMs are involved in the 
technical commitee, and bringing the dispute involving Sven to the ctte 
certainly takes a bunch of their time. Also, as already mentionned, Sven 
requested Andreas Barth to personally mediate the issue. Whether or not 
Sven is responsible for leading this dispute to the ctte, letting our 
RMs spend their time on such issues is not going to help releasing Etch 
much.
Of course, opening this thread will also take a lot of time from DDs, 
this time not just from the kernel team, the RMs and the technical 
committee, but it remains to be seen what outcome this thread will have.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: removal of svenl from the project

[Filipus Klutiero]

Hi Pierre,

just so that we are clear, I consider your first mail a personal insult 
already, especially given that your decision is based on irc logs.




dilinger's proposition is certainly personal, as it targets only Sven 
and fortunately not the whole Project. It doesn't have to be an insult 
though. Should someone feel insulted to be rejected from NM? I don't 
think so, it's merely an indication that the person lacks either 
technical or social skills to contribute to Debian positively. I think 
that being expulsed from the Project is the same thing, except that it 
happens after NM failed to identify the issue at the ideal moment, or 
after something in the developer's personal life placed him in an 
psychological state where his social skills become inadequately low for 
participation in Debian.


But even if it's an insult, dilinger's decision is not (solely) based on 
IRC logs. I won't learn you that both Andres and Sven are members of the 
kernel team since a long time, so you can guess that Andres interacted 
with Sven on more than two occasions. As clarified by dilinger's second 
post, the IRC logs mentionned are only examples.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: Release update: minor delay; no non-RC fixes; upgrade reports

[Filipus Klutiero]

Hah...document a distribution's bugs in a wiki page is one funny idea 
that Knoppix used at the time I still used it, about a year ago. And it 
was one major reason I didn't wait to switch to Debian. It can be 
considered for tracking RC issues, but Roger still has a point that all 
bug reports may be useful doc for users.
Plus, it's being honest about the "real" current state of the software 
(again to users).



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: Desktop task(sel) in Etch? (Bug #389092)

[Filipus Klutiero]

If you have opinions on what
packages to use to complete a particular task, why are you using tasksel?

If people who have opinions on what packages to use to complete a 
particular task shouldn't use tasksel, does this mean that people who 
think that GNOME should be used as a desktop shouldn't use tasksel, but 
rather install GNOME and the rest "manually"? It would be more geeky, 
wouldn't it?


Anyway, I would also appreciate a lot to see an improved handling of the 
desktop environment by tasksel, but I'm not sure if adding "(GNOME)" is 
a good idea. Considering GNOME's popularity versus "other desktops", I 
think it's worth considering.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: Desktop task(sel) in Etch? (Bug #389092)

[Filipus Klutiero]

What I would expect at least:
Rename the task from "Desktop" to "Desktop (Gnome)" so more experienced
users know what's coming up.
   


I think it could be done in 'expert' mode, but not in the normal
installation mode. The next step will be that somebody else will
suggest "Desktop (KDE)" listed too (in normal mode).

Mentioning that the desktop installed will be GNOME is more useful for a 
non-expert, who can wonder which desktop Debian will choose, than to an 
expert which most likely already knows what Debian chooses by default. 
So I disagree; it could be done independent of the mode.
Listing kde-desktop in normal mode was *already* suggested, so 
implementing Christoph's proposal isn't a bad idea for that reason.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Mass closing of bugs ?

[Filipus Klutiero]

Do you have an estimation of the proportion of bugs that should be open? If 
less than half of bugs not found in a version ulterior to some version should 
be open, closing these bugs sounds like an idea. It would be less rude to 
first warn about the upcoming closure and ask owners to mark these bugs as 
found in the current version if they're reproducible there. To make it easier 
for owners to test iceape, please wait for it to be in testing before sending 
these messages (if you decide to procede this way).


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: utnubu-desktop for the masses

[Filipus Klutiero]

I'm interested in a "utnubu desktop/minimal/standard" now in sid so
you see my metapackage upload. With Etch, i would like to add a
"utnubu desktop task" yes, but as i pointed out above it seems that we
will need more than a simple task. I can help with code if -boot
agree.

What do you intend to add exactly? Would that task show by default, or 
what? If it doesn't, how will users get aware of its existence, so it 
can be useful?



Closing, i don't think we should discard utnubu-meta in sid now. It
would be a good test and will show us how much work needs to be done
in utnubu front until Etch.

What kind of work do you expect will need to be done in "utnubu front" 
until Etch?



Btw, i already received some 'off blog'
feedback from Ubuntu users that would like to move from Ubuntu Dapper
(that will be released in June) to Debian Sid back again. They're all
power users, of course.

When I saw your upload in NEW, I was curious, but looked at the ITP, and 
agreed that it could help migrate from Ubuntu to have metapackages 
ensuring that you get most packages you were used to in Ubuntu.
But, if we don't expect this to transition to testing, what will be the 
use of providing these packages to sid users? I'm not saying that power 
users should denigrate the use of metapackages. I use for myself 
kde-core everytime I install Debian. But I can't imagine myself 
installing kde, which provides a ton of software I don't need, among 
which many which have similar functions. So, I couldn't imagine a sid 
user installing an even bigger monster with over 200 dependencies. At 
this point, rather add an --optional switch to tasksel.
I agree with joeyh: if a sid user misses something to facilitate desktop 
installs, he'll want sane desktop task(s) (with possibly several levels 
of priorities), not utnubu tasks.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: BTS tag proposal "faq"

[Filipus Klutiero]

Bugs that were fixed or are to be fixed (even in unstable) shouldn't be tagged 
wontfix.

What's the problem with simply marking the bugs as fixed in the right version?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

"Button voting" can't be implemented anyway

[Filipus Klutiero]

The web interface to the BTS is read-only. You couldn't have "button 
voting" anyway (and of course that would be a mess without requiring 
registration, which isn't implemented neither...).


---Rant---
I guess the way to go with the BTS is to switch to Bugzilla/other 
packaged BTS.
That doesn't mean the recent implementation of version tracking wasn't a 
good idea. As long as there are people to work on doing all the rest... :/



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: Which CD is a package on?

[Filipus Klutiero]

While I was going to add this to #debian's "cd contents" factoid, which 
used to also only mention jigdo, I noticed that someone had added an 
effective solution.


(00:58:29) *cheal:* cd contents
(00:58:29) *dpkg:* To find out what is on what cd, download the .jigdo 
template, and zless fooimage.jigdo. In the [Parts] section you will see 
the list of packages that are contained in the cd. stew has created a 
searchable index of the sarge cds: http://vireo.org/~stew/jigdo 



stew is a regular on #debian. I just tested the interface quickly, and 
it's not bad. While the interface doesn't point to the code used, I 
guess he would accept to give anyone his code if asked by email. Perhaps 
a DD will want to use the code instead of starting from scratch.
In any case, I think work on this issue would have a high use/effort 
ratio ;)

It will be great if building an index can be part of the CD build process.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: How to install Suggested (Was: Are all recommended modules equally important?)

[Filipus Klutiero]

On Wed, 19 Mar 2008, Don Armstrong wrote:

  


So you do something like:

apt-get -o APT::Install-Suggests=true install foo; or similar.

[Though it probably should be an easier option, it is possible to do.]



Well, this hint was given now in the initial thread on Debian-Med
and well, this actually would be an option - but if I fail to find
this documented in the man pages I posted I think it is not
apropriately documented.  I also was sure that it is _possible_,
but IMHO this is (1) a quite difficult option for a feature that might
be needed by users who do not want to dive into details of apt and
(2) not properly documented.

Do you think that I should file (1) and (2) as different wishlist
bug reports or is it rather one single problem.

Different problems, though fixing 1 may make the fix for 2 useless...

  Or am I the only
one who thinks this is a real problem.
...but I don't think it's a "real" problem. If someone is looking for 
such an option, that must be because selecting suggestions is not 
implemented. Which would be because apt-get is rather deprecated in 
favor of aptitude. So I think the right fix would be to implement a way 
to select suggestions in aptitude (if that's not already done, I don't 
use it).

  I'm a little bit reluctant
to add a further bug to apt which just has gathered anough that
might be considered as hot air.

Kind regards

   Andreas.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Handling bugs properly (Was: Bug#474964: ...)

[Filipus Klutiero]

I want to hear your opinion about the following question:  If you think
a bug does not belong to your package, do you think it is your duty as a
maintainer to reassign to bug to the package it belongs to or do you
think just closing the bug is fine?
Closing a report merely because it is assigned to the wrong package is 
wrong.


On the other hand, I know nothing about the bug, but one can't expect 
any team to handle normal bug reports in 10 days. This is particularly 
true for the Linux team, which has an important lack of manpower.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: Handling bugs properly (Was: Bug#474964: ...)

[Filipus Klutiero]

Closing valid bugs which were merely assigned to the wrong package
isn't acceptable (though admitedly, it *is* better than just ignoring
them entirely.)
Closing a valid bug without fixing is generally wrong, like in this 
case, whether there is enough manpower to treat it or not.
And if you have enough manpower to close a bug (once, twice, or 18 
times), you probably could afford the extra manpower possibly needed to 
reassign it instead.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: Handling bugs properly

[Filipus Klutiero]

What is an ordinary bug submitter's recourse when a bug report
 is closed without resolution?  The response sent to the poster is that
 a reasonable response must have been received (or a paraphrase); what
 happens then the response is missing?
  

The exact phrasing is


Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact bug closer foo by
replying to this email.
I'm not sure what you mean. If you mean what to do the first time this 
happens, just do that. If you mean what to do when the maintainer hides 
his head in the sand, this is more complicated.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: heimdal and testing

[Filipus Klutiero]

One of the things you could do is wait one day, after which 
cyrus-imapd-2.2 would be old enough to transition. cyrus-imapd-2.2 needs 
to be updated, otherwise cyrus-common-2.2 would become uninstallable due 
to its dependency on libkrb5-22-heimdal in testing.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: heimdal and testing

[Filipus Klutiero]

Le April 28, 2008 06:17:10 pm Brian May, vous avez écrit :
> Filipus Klutiero wrote:
> > One of the things you could do is wait one day, after which
> > cyrus-imapd-2.2 would be old enough to transition. cyrus-imapd-2.2
> > needs to be updated, otherwise cyrus-common-2.2 would become
> > uninstallable due to its dependency on libkrb5-22-heimdal in testing.
>
> Another day, and nothing happened. I can't help think it is more
> complicated then that.
>
> <http://release.debian.org/migration/testing.pl?package=cyrus-imapd-2.2>
>  says cyrus-imapd is now 10 days old and is waiting for Heimdal.
>
> e.g. have a look at
> <http://release.debian.org/migration/testing.pl?package=libsasl2-modules-gs
>sapi-heimdal>.
>
> Then this is only one day old
> <http://release.debian.org/migration/testing.pl?package=kolab-cyrus-pop3d>.
>
> It seems like Heimdal can't get moved unto testing until every package
> that links against the libkrb5 also gets moved into testing, and these
> have to be moved at the same time Heimdal is moved. Am I correct?
Yes. So heimdal is still waiting for cyrus-imapd-2.2 to be ready to 
transition.

> I thought the rules were that libkrb5-22-heimdal (and the corresponding
> source) would remain in testing until is is no longer used by testing.
> As such a Heimdal source package that only build libkrb5-24-heimdal
> could still enter testing without updating all users of the library at
> the same time. Maybe this has changed.
It has never been like that. There can't be multiple versions of a source in a 
given suite simultaneously. The only way to workaround the impact when there 
are soname bumps is to have several source packages.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: being released from the hot seat

[Filipus Klutiero]

Le May 2, 2008 05:37:00 pm Andreas Barth, vous avez écrit :
> Hi,
>
> good news for me that Marc 'HE' Brockschmidt didn't become DPL (though I
> think he would've been a good DPL), so I managed to convince him to
> become Release Manager. Of course, Luk stays Release Manager, and I will
> also continue to help releasing Lenny as release wizard.

Thanks for the announcement. Nevertheless, I reiterate my question about 
release team roles 
(http://lists.debian.org/debian-devel/2007/06/msg00900.html).
If role changes are going to be announced on d-d-a, the difference between 
them should be well documented.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: Will nvidia-graphics-drivers ever transition to testing?

[Filipus Klutiero]

On Sat May 10 2008 12:14:22 Julien Cristau wrote:
> On Sat, May 10, 2008 at 12:09:52 -0700, Mike Bird wrote:
> > On Sat May 10 2008 11:03:40 Julien Cristau wrote:
> > > On Sat, May 10, 2008 at 10:59:44 -0700, Mike Bird wrote:
> > > > How should a package depend on a package built by module-assistant?
> > >
> > > It shouldn't.
> >
> > Are you saying the dependent package should install successfully
> > and then fail at runtime?  If not, what are you saying?
>
> I'm saying that, and I'm also saying that this is utterly off-topic on
> this list.

[Moved from debian-release to debian-devel]

WHY ON EARTH should we intentionally require that packages install
successfully with known unmet dependencies which will cause failure
at runtime?

--Mike Bird
We shouldn't. I'm sorry if your question was specifically for Julien, 
that wasn't clear.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: Will nvidia-graphics-drivers ever transition to testing?

[Filipus Klutiero]

On Sat, May 10, 2008 at 12:38:29PM -0700, Mike Bird wrote:
> [Moved from debian-release to debian-devel]
> 
> WHY ON EARTH should we intentionally require that packages install

> successfully with known unmet dependencies which will cause failure
> at runtime?

Well nvidia-kernel should soon be built from linux-modules-nonfree-2.6,
so perhaps that will ensure that a complete set of modules are in
unstable so that everything can move to testing together.
The set of modules can already be updated if someone has the time and 
experience needed to update nvidia-graphics-modules-i386 and company. 
Merging nvidia-graphics-modules-i386 with linux-modules-nonfree-2.6 
would only complicate or delay more testing transition of nvidia LKM 
packages, like for any LKM.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Will nvidia-graphics-drivers ever transition to testing?

[Filipus Klutiero]

Le May 11, 2008 10:45:49 am Lennart Sorensen, vous avez écrit :
> On Sat, May 10, 2008 at 09:08:32PM -0400, Filipus Klutiero wrote:
> > The set of modules can already be updated if someone has the time and
> > experience needed to update nvidia-graphics-modules-i386 and company.
> > Merging nvidia-graphics-modules-i386 with linux-modules-nonfree-2.6
> > would only complicate or delay more testing transition of nvidia LKM
> > packages, like for any LKM.
>
> There is no merging happening.  linux-modules-nonfree-2.6 simply build
> depends on nvidia-kernel-source package, and then proceeds to build the
> modules for each kernel variant.  That is how the linux-modules-*-2.6
> packages work.  linux-modules-nonfree-2.6 simply lists nvidia-kernel os
> a module package to build.  nvidia-kernel-source has to provide the
> appropriate Makefile for linux-modules-nonfree-2.6 to work with (which I
> just finished writing).
Merging source package foo in source package bar means that bar is modified to 
build foo's binary packages,

> So everytime debian does a new kernel version, they will do a new
> linux-modules-*-2.6 package listing the new kernel version, which will
> cause all the supported modules to be built.
>
> If a new nvidia-kernel-source version comes out, then it will get
> rebuilt too (quite how that is made to happen I am still not quite sure
> of).

Yes, the problems with conglomeration packages are the same as you'd get by 
merging 2 somewhat related source packages together, say iceweasel with 
icedove. Although the source packages would probably share a bit of code, if 
there's a libpng transition and only iceweasel is ready, you need to drop 
icedove, but your only choices are to drop icedove and iceweasel or re-upload 
with a disabled icedove. Transitions get longer and/or versions are bumped 
constantly. For example, linux-modules-extra-2.6 was uploaded 7 times to 
unstable in 2008, while iceweasel was only uploaded 5 times. 
linux-modules-extra-2.6 only did one Linux ABI transition during that time.
If nvidia prebuilt modules are merged in linux-modules-nonfree-2.6, they'll be 
tied to kqemu prebuilt modules. This would hurt both nvidia LKM-s and kqemu 
LKM-s, which are already in bad enough shape.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Will nvidia-graphics-drivers ever transition to testing?

[Filipus Klutiero]

Le May 12, 2008 09:39:25 am Lennart Sorensen, vous avez écrit :
> On Sun, May 11, 2008 at 03:39:15PM -0400, Filipus Klutiero wrote:
> > Yes, the problems with conglomeration packages are the same as you'd get
> > by merging 2 somewhat related source packages together, say iceweasel
> > with icedove. Although the source packages would probably share a bit of
> > code, if there's a libpng transition and only iceweasel is ready, you
> > need to drop icedove, but your only choices are to drop icedove and
> > iceweasel or re-upload with a disabled icedove. Transitions get longer
> > and/or versions are bumped constantly. For example,
> > linux-modules-extra-2.6 was uploaded 7 times to unstable in 2008, while
> > iceweasel was only uploaded 5 times.
> > linux-modules-extra-2.6 only did one Linux ABI transition during that
> > time. If nvidia prebuilt modules are merged in linux-modules-nonfree-2.6,
> > they'll be tied to kqemu prebuilt modules. This would hurt both nvidia
> > LKM-s and kqemu LKM-s, which are already in bad enough shape.
>
> linux-modules-extra-2.6 was uploaded many times since more and more
> modules were getting added to its list to build.
Well, yes, that's a bit what I wrote.

> It is only changed when new module packages should be supported by it,
> and when a new kernel comes out so that it can explicitly build modules
> for that new kernel.
No, a more frequent change is disabling/enabling modules [on some arch]. Even 
if you were right, adding new module packages doesn't "justify" updating 
other modules. Reusing the ice* example, suppose that Debian would have such 
an icezoo source package and Mozilla would release a new IRC client. Adding, 
say, icebear, to the packages generated by icezoo wouldn't make me happy, 
because I'd have to update iceweasel even if I wouldn't use icebear. 
Otherwise, I wouldn't like iceweasel updates to be blocked just because 
icebear has a serious regression.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: Will nvidia-graphics-drivers ever transition to testing?

[Filipus Klutiero]

Filipus Klutiero wrote:
> If nvidia prebuilt modules are merged in linux-modules-nonfree-2.6, they'll be 
> tied to kqemu prebuilt modules. This would hurt both nvidia LKM-s and kqemu 
> LKM-s, which are already in bad enough shape.


you seem to have no idea how conglomeration packages work.

I have a good idea how they work.

 please stop
writing false things about it before you've informed your self, thanks.

I'd be happy to inform myself better by reading what false things I wrote.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

conglomeration packages (Re: Will nvidia-graphics-drivers ever transition to testing?)

[Filipus Klutiero]

Le May 13, 2008 09:39:38 am Lennart Sorensen, vous avez écrit :
> On Mon, May 12, 2008 at 09:42:31PM -0400, Filipus Klutiero wrote:
> > No, a more frequent change is disabling/enabling modules [on some arch].
> > Even if you were right, adding new module packages doesn't "justify"
> > updating other modules. Reusing the ice* example, suppose that Debian
> > would have such an icezoo source package and Mozilla would release a new
> > IRC client. Adding, say, icebear, to the packages generated by icezoo
> > wouldn't make me happy, because I'd have to update iceweasel even if I
> > wouldn't use icebear. Otherwise, I wouldn't like iceweasel updates to be
> > blocked just because icebear has a serious regression.
>
> You can't compare something stupid like that, with something useful like
> building the kernel modules.
Packaging icebear wouldn't necessarily be useless. I defined it as yet another 
IRC client for the sake of the example. You can imagine it as yet another 
media player if you think that's more useful.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: conglomeration packages (Re: Will nvidia-graphics-drivers ever transition to testing?)

[Filipus Klutiero]

Le May 13, 2008 09:54:46 pm Lennart Sorensen, vous avez écrit :
> On Tue, May 13, 2008 at 09:27:31PM -0400, Filipus Klutiero wrote:
> > Packaging icebear wouldn't necessarily be useless. I defined it as yet
> > another IRC client for the sake of the example. You can imagine it as yet
> > another media player if you think that's more useful.
>
> You can't compare packaging two unrelated and independant programs which
> can be built completely independantly [...]
I don't follow you. iceweasel, for example, is not independent from, say, 
libnspr.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: conglomeration packages (Re: Will nvidia-graphics-drivers ever transition to testing?)

[Filipus Klutiero]

Le May 14, 2008 09:41:02 am Lennart Sorensen, vous avez écrit :
> On Tue, May 13, 2008 at 10:32:07PM -0400, Filipus Klutiero wrote:
> > I don't follow you. iceweasel, for example, is not independent from, say,
> > libnspr.
>
> If they come from one source package, then they all build together.  If
> they do not, then it's a dynamicly linked library and each can be built
> and updated independantly.  kernel modules have to be rebuilt if the
> sources change (just like any application of course) but also if the
> kernel is changed (which an application does not, not even when
> libraries change) which is hence a rebuild requirement external to the
> package itself.
Your second parenthesis is wrong. Just like LKM-s when the stock kernels' 
ABINAME is bumped, applications need to be rebuilt when the ABI of one of the 
libraries they link to changes in a way which is not backwards-compatible. 
You can check http://wiki.debian.org/OngoingTransitions for examples of 
library transitions.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: conglomeration packages (Re: Will nvidia-graphics-drivers ever transition to testing?)

[Filipus Klutiero]

Le May 15, 2008 09:55:40 am Lennart Sorensen, vous avez écrit :
> On Wed, May 14, 2008 at 08:13:53PM -0400, Filipus Klutiero wrote:
> > Your second parenthesis is wrong. Just like LKM-s when the stock kernels'
> > ABINAME is bumped, applications need to be rebuilt when the ABI of one of
> > the libraries they link to changes in a way which is not
> > backwards-compatible. You can check
> > http://wiki.debian.org/OngoingTransitions for examples of library
> > transitions.
>
> The old libraries don't go away right away though.  With the kernel you
> can only be running one at a time, so you have to recompile the modules
> to make them work.
I don't see your point.

> libraries also change ABI versions a lot less often 
> than the kernel changes.
We were talking about nvidia-graphics-drivers. Prebuilt nvidia LKM packages 
are already built by dedicated source packages.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: conglomeration packages (Re: Will nvidia-graphics-drivers ever transition to testing?)

[Filipus Klutiero]

Le May 16, 2008 09:10:35 am Lennart Sorensen, vous avez écrit :
> On Thu, May 15, 2008 at 06:28:36PM -0400, Filipus Klutiero wrote:
> > I don't see your point.
>
> I can have libfoo1 and libfoo2 installed and used at the same time so
> both applications compiled for libfoo1 and libfoo2 can be used at the
> same time.  I can recompile my applications for libfoo2 as I get around
> to it.  When everything is recompiled libfoo1 can be removed.
>
> For kernel modules, I have to recompile all the kernel modules in order
> to move to a new kernel since I can't use a mixture of kernel modules
> for two different kernel versions since I can only be running one kernel
> at a time.
I still don't see your point.
>
> > We were talking about nvidia-graphics-drivers. Prebuilt nvidia LKM
> > packages are already built by dedicated source packages.
>
> No, the nvidia package generates nvidia-glx, nvidia-glx-dev,
> nvidia-kernel-source and such.  It does NOT know anything about building
> modules for specific kernel variants.  That is done manually by someone
> so far (and hence seems to be a bit infrequent).  The
> linux-modules-*-2.6 package makes it possible to simply have the
> buildd's take care of that job.
There are several nvidia* source packages. Those that contain "modules" are 
dedicated for prebuilt nvidia LKM-s. The nvidia* source packages are included 
in those shown on 
http://qa.debian.org/[EMAIL PROTECTED]&comaint=yes


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Filipus Klutiero]

I'm not sure whether you mean bug in the strict sense or in the BTS's 
sense. Do you think a divergence is a minor bug or a wishlist "bug"? I 
disagree that any divergence is a bug, but there may be a request to get 
rid of a divergence.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Use origin (Handling of removed packages)

[Filipus Klutiero]

Yes, this could be solved by having APT (probably) store the origin of the 
package when installing. Then, for example, if an APT front-end realizes 
while updating package index files that a package coming from Debian is not 
available anymore from Debian sources, the user could be prompted.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Did the number of installations really increase by a half in one month?

[Filipus Klutiero]

In "The number of etch installations is rocketing" Joey Hess linked to a 
useful graph showing the evolution of the number of installations reporting 
to popcon:
http://popcon.debian.org/stat/sub-i386.png

Petter Reinholdtsen was wondering how long the rate of increase would keep up, 
and it seems the rate is getting back to normal now, after an increase of 
about a half in one month. This is probably material for some kind of 
announcement, but I would like to verify if I'm missing something. Does this 
graph reveal an increase of installations by about a half in one month? Or 
did the proportion of installations reporting to popcon increase 
significantly?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Release team structure (was Release Team Meeting results (the Juelich Edition))

[Filipus Klutiero]

Le vendredi 15 juin 2007 19:19, Andreas Barth a écrit :
> Release team structure
> ~~
> Steve Langasek, who served as Release Manager for the past two cycles,
> doesn't want to be on the hot seat anymore. As he is still an active member
> of the release team, we decided to have him titled with "Release Wizard"
> now. Luk will become a Release Manager, so that we have again two
> Release Managers.
Actually, it seems that Luk is already a Release Manager since a few days 
according to intro/organization in CVS. I would appreciate if the release 
team would start to announce changes in its membership.

Also, is there a difference between a Release Manager and a release assistant?

It would be great to find answers to such questions from the Teams wiki 
page(s) started by buxy. Using a release team page could also help 
getting "Recent release updates" more up-to-date.

>  * The linux kernel was a source of some delays for Etch. This was
>due to an unexpected high number of (critical) bugs and the
>problems around Debian's handling firmware images in the kernel.
>To solve this better next time, we want to start looking at the kernel
>earlier in the cycle and talking with the kernel team(s) more often.

I think the main problem has been the lack of manpower in the Linux team.

Opposed (Re: Debian release versioning)

[Filipus Klutiero]

I was in favour at first sight, but not anymore. I agree with Adeodato 
that in general, the second integer of a software version is more 
meaningful that a stable update means. Also, as he wrote, it used to 
mean something entirely different in Debian itself, less than 4 years ago.


But at least equally importantly, a stable update is not really a new 
Debian version. When you're running software foo version X.Y and X.Y+1 
comes out, you'd expect to have an update to do. This is generally not 
the case with Debian, or it shouldn't. "stable" rather evolves 
progressively, and a machine updating regularly may see no update or new 
package in a stable update. The main meaning of a stable update is that 
installation media is updated. This is quite similar to d-i releases, 
which aren't reflected in debian_version.


So, I think the Debian version should be simply X. Installation media 
should reflect the build, with something appended to the Debian version, 
similar to how it's done now. Maybe "Debian 6 image build X"? revision 
is not too clear, but I'm not sure how it could be improved. This is 
basically what we're already doing, except the ".0" is dropped. The only 
disadvantage with keeping ".0" is that some users will wonder what it 
means. Perhaps lenny+1 will be announced as "Debian 6".



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: feature: to add explanations of recommendations and suggestions dependencies

[Filipus Klutiero]

So there's some positive response. Where is a good place to pursue this 
further? Is this a debian policy change?

I think there's no need for a Debian policy change to start.
You should start by finding a proper way to put the recommendation and 
suggestion explanations in package control files.

One way which might work would be to add a "Recommendation" field defined as
Recommendation: package, explanation
but this would require using the same field name several times. I 
believe this wasn't done yet. I don't know if the field names should be 
unique. If putting the same field name twice is seen as a redeclaration, 
this is a problem that would need to be investigated.
Otherwise, you can choose binary package control file user-defined 
fields, such as XB-Recommendation and XB-Suggestion and start using it...
Get a few packages to use the fields and add support for them to package 
management tools.

Start advertising the fields.
If it's successful, request the fields to be added to Debian policy.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: RFC: DKMS - Dynamic Kernel Module Support

[Filipus Klutiero]

This is achieved through the installation of a script in:

/etc/kernel/header_postinst.d/
/etc/kernel/postinst.d/
/etc/kernel/prerm.d/

A quick search with apt-file didn't return any result.
Is this approach supported by Debian?

/etc/kernel/header_postinst.d/ isn't supported.

 I remember grub updating itself when a
new kernel is installed: is that a postinst by the kernel package itself?
  

Yes.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: RFC: DKMS - Dynamic Kernel Module Support

[Filipus Klutiero]

So, DKMS is being run after the installation of a kernel. Am I right?
  

Yes.

Btw, is all this documented anywhere?
  

I guess it isn't.

Kindly,
David
  



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: RFC: DKMS - Dynamic Kernel Module Support

[Filipus Klutiero]

So, what's the final status of this thread?
Should I continue working on the package? Should I drop it?

I wouldn't want to drop it -- if there's no consensus or, at least, someone
wanting it -- and wanting to *sponsor* it, or someone that will actually
*use* it, I believe I'll put that on my private repository.

Should I continue working on DKMS for Debian, or is that all wasted time?
  
From the 6 advantages you mentioned, I believe after the discussion 5 
and 6 survived. These aren't advantages that would convince easily 
everyone used to module-assistant to switch, but converts from 
distributions using DKMS could want it instead of module-assistant. I 
guess I'd personally give DKMS a try.

So it shouldn't be all wasted time.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug sprint !

[Filipus Klutiero]

Hi,

there are currently 122 RC bugs remaining that affect both testing and
unstable. We need to fix them NOW.

However, in the permanent BSP state that has lasted for quite some time,
people seem to lose focus on this urgent need for the release. So the
idea is:
122 developers × 5 days = 122 RC bugs fixed

The rules are : at the end of a 5-day period, the bug you are assigned
must be closed in unstable or have a lenny-ignore tag. Otherwise this is
a free-for-all.

The first 5 developers to fix their bugs will be sent a box of home-made
cookies. Those who can’t fix their bugs in 5 days will receive the visit
of a release manager who will hit them with a rusty shovel.

All we need is 122 skilled developers willing to sign in this contract
(with their blood).

Does it sound like a realistic idea?
Not to me. First, we're already doing good on RC bug fixing. We already 
missed the original schedule, and AFAIK this time nobody announced that 
lenny would be released according to the release schedule in an official 
medium.


Second, several of these 122 bugs are either new or pending, so they're 
likely already on the way of being fixed. After that, the list of bugs 
need to be triaged. Then the release team will deal with some of the 
remaining bugs by removing the packages from testing. Some can be 
downgraded by documenting them. Some aren't regressions from Etch, some 
are duplicates.


The about 50 bugs remaining won't be much for the number of developers 
with free time willing to work on releasing lenny. It's unrealistic to 
ask a random developer to fix an RC bug in a random package in 5 days. 
If I'm assigned a bug in a GNOME package I never used, as a KDE user, 
and which is coded in Perl, which I don't know, my motivation to fix the 
bug will be low, and the chances I get the bug off the RC radar in 5 
days very low, unless you actually plan to send cookies and beat me if I 
fail. AFAIK, most of those participating in recent BSP-s didn't get any 
particular reward for their work.


I think it's better for few bug and many developers, to let developers 
work on the bugs they care about. Another way to increase the rate RC 
bugs are dealt with would be to give particular reward to BSP 
participants by crediting them in news. In the long-term, it would help 
to create a ranking of Debian contributors according to the value of 
their contributions to Debian, which would take RC bugs dealt with into 
consideration.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

debian-kernel (Re: kernel 2.6.27 in lenny?)

[Filipus Klutiero]

For kernel-related discussions, ask on debian-kernel.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

debian-kernel (Supporting 2.6.27 in Lenny? - Long term support)

[Filipus Klutiero]

For kernel-related discussions, ask on debian-kernel.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: debian-kernel (Supporting 2.6.27 in Lenny? - Long term support)

[Filipus Klutiero]

On ven, 2008-10-17 at 21:39 -0400, Filipus Klutiero wrote:
> For kernel-related discussions, ask on debian-kernel.

And for lenny-related discussions, isn't the release team concerned? :)
  
It is, but the first team that should approve a Linux upgrade in lenny 
is the kernel team. After that the d-i team would be contacted.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: debian-kernel (Supporting 2.6.27 in Lenny? - Long term support)

[Filipus Klutiero]

Le October 19, 2008 04:04:58 am Thomas Viehmann, vous avez écrit :
> Filipus Klutiero wrote:
> > It is, but the first team that should approve a Linux upgrade in lenny
> > is the kernel team. After that the d-i team would be contacted.
>
> Could you just stop handing out bad advice on the development list, please?
As much as you could stop asking rhetorical questions and start expressing 
yourself clearly.
> The answer to the kernel question is "No" and there is no use asking
> people to bug busy teams.
My point was that asking on debian-devel was suboptimal. This does not mean 
that the question will be useful on debian-kernel, but it's likely 
that -kernel contains a more useful and convincing answer than "No" from some 
random person, and that Kushal won't even have to ask.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Include justification in tagging bugs ‘$FOO-ignore’

[Filipus Klutiero]

In other words, if a tag indicates a special case, that special case
should be justified with a specific explanation.

I would like to see such justification expected for every such tag,
enforced by the convention that tags with *no* justification provided
can be summarily removed by anyone. This would place the burden of
argument in the correct place, as I see it, while not needing anything
as heavy-handed as a policy requirement.

Is that feasible? Is it reasonable?
  
Anyone can certainly remove the tag, but I don't think it's a good idea 
that such a tag be removed without the release team's approval. I see 
these tags as being for the release team's use; hence the team should 
determine by itself whether these tags should be applied. Maybe the tags 
should also be moved from the main namespace to the release team's 
"usertags".



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: Include justification in tagging bugs ‘$FOO-ignore’

[Filipus Klutiero]

Filipus Klutiero <[EMAIL PROTECTED]> writes:

> > In other words, if a tag indicates a special case, that special case
> > should be justified with a specific explanation.
> >
> > I would like to see such justification expected for every such tag,
> > enforced by the convention that tags with *no* justification provided
> > can be summarily removed by anyone. This would place the burden of
> > argument in the correct place, as I see it, while not needing anything
> > as heavy-handed as a policy requirement.
> >
> > Is that feasible? Is it reasonable?
> >   
> Anyone can certainly remove the tag, but I don't think it's a good

> idea that such a tag be removed without the release team's approval.

Notice that I only advocate removing the tag when it's not accompanied
by a clear, explicit justification.
  
I'm advancing something wider than this, but it also covers the case you 
brought up.

> I see these tags as being for the release team's use

I disagree; the ‘foo-ignore’ bug tags have an explicit mechanical
effect on how the corresponding package will be treated by the tools.
  
Which tools? I can think of britney, which is already under the release 
team's control anyway.

> hence the team should determine by itself whether these tags should
> be applied.

All I propose is that the ‘foo-ignore’ tags by themselves communicate
nothing to the (human) reader about why this particular bug is
special-cased, and that without an explicit justification accompanying
the tag it should be removed by anyone who finds it in that state.
Yes...and all I was saying is that I don't think your proposal is a good 
idea.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Possibility for dependencies against specific kernel modules

[Filipus Klutiero]

Hi folks

Because of some recent events, I thought about the possibility for
packages to depend against kernel module packages. As we don't want to
dictate the usage of Debian provided kernels, we need a last resort
fallback to the modules source.

My first solution was something like the following:

| Package: test
| Depends: test-modules | test-source
|
| Package: test-modules
| Depends: linux-image-2.6.26-1-powerpc | linux-image-2.6.26-1-powerpc64
|
| Package: test-source

Both apt and aptitude would always try to install test-modules. The
problem is that neither apt nor aptitude are smart enough to find the
best solution in the dependency tree, both only evaluate deps of depth 1
at one time.
I don't understand why APT would always try to install test-modules. 
Suppose you're on lenny and you have speex installed, then APT won't 
propose to install vorbis-tools when you request to install abcde, 
despite its dependency on vorbis-tools (>= 1.0beta4-1) | lame | flac | 
bladeenc | speex


Are you saying there's a difference in your example? If so, what is it?


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: Possibility for dependencies against specific kernel modules

[Filipus Klutiero]

On Sat, Nov 01, 2008 at 07:29:16PM -0400, Filipus Klutiero wrote:
>> | Package: test
>> | Depends: test-modules | test-source
>> |
>> | Package: test-modules
>> | Depends: linux-image-2.6.26-1-powerpc | linux-image-2.6.26-1-powerpc64
>> |
>> | Package: test-source
>>
>> Both apt and aptitude would always try to install test-modules. The
>> problem is that neither apt nor aptitude are smart enough to find the
>> best solution in the dependency tree, both only evaluate deps of depth 1
>> at one time.
> I don't understand why APT would always try to install test-modules.  
> Suppose you're on lenny and you have speex installed, then APT won't  
> propose to install vorbis-tools when you request to install abcde,  
> despite its dependency on vorbis-tools (>= 1.0beta4-1) | lame | flac |  
> bladeenc | speex

>
> Are you saying there's a difference in your example? If so, what is it?

Yes. You have speex already installed and is therefor prefered to
resolve the dependency. My example was for a fresh installation without
anything installed yet.

Bastian
  
Hum, if the problem is APT's behavior when no test* package is 
installed, I don't understand what problem you're talking about. Could 
you give an example of a non-optimal solution?



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Translation debs (Re: Debconf 8 internationalization sessions report)

[Filipus Klutiero]

Le November 8, 2008 09:46:48 am Christian Perrier, vous avez écrit :

>
> i18n work session 2: tdebs
> --
> (notes taken by Marc Hymers)
>
> "tdebs" or "translation debs" are an attempt to achieve two goals, by
> splitting localization material out of packahes:
>
> - reduce space usage on systems with low resources (goal pushed from
> EmDebian) - allow desynchronized updates of translations without requiring
> a full upload or package recompile (therefore potentially allowing l10n
> updates to stable, for instance)
>
> Various constraints and desirable characteristics were discussed:
>  - Out-of-band translation updates
>  - Only installing useful translations on systems
>  - Reducing bandwidth usage
>  - Avoiding archive bloat
>
> Discussion noted that "Reducing bandwidth usage" by providing small,
> individual tdebs per package per architecture and "Avoiding archive
> bloat" were contradictory. Instead it was suggested that one .tdeb per

Small note, I was confused at first when I red about TDebs and thought that 
those proposing them wanted to create a new file format (.tdeb). This is not 
actually the case, so unless a reason appears to make a new format desirable, 
TDebs can be assumed to be simple Debian packages and can be called "tdeb"-s, 
but not .tdeb-s, which is confusing. "Translation Debs" refers to the concept 
of addressing translation data distribution issues through changes in APT 
and, depending on the implementation, archive maintenance tools, dpkg and/or 
APT front-ends.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: problems with the concept of unstable -> testing

[Filipus Klutiero]

The other way round works, too: Removing people who don't have that
minimal commitment from the project and their packages from the archive
would also allow us to release (a lot less) in a timely fashion.
  



Right... And it would also help releasing timely to remove all buggy 
packages.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re: problems with the concept of unstable -> testing

[Filipus Klutiero]

That works both ways - those who do contribute and help Debian across a
wide range of areas should be valued and supported, even if they show
that frustration from time to time. Everyone makes mistakes but why
must the most active contributors be the first target of criticism when
they criticise others who do little to help Debian? What about those who
simply obstruct other developers? Isn't there any wider consideration
that uploading packages that are unfit for purpose and refusing to fix
problems identified by more active, more respected members is only
going to frustrate those who do care?

What packages do you have in mind?

Where's the criticism of the original post that brings nothing useful
or new to the discussion and comes from someone who has done nothing
positive to further the release of Lenny? It's laughable. Why must we
always blame the responder and not the initiator?
  

Your questions assume several things I disagree with:

the original post comes from someone who has done nothing positive to 
further the release of Lenny


we always blame the responder and not the initiator

Overly long freezes are a pain but the solution is not to complain, the
solution is to fix the RC bugs, help with the debian-installer, help
with the translation team and get the release finished. That's what I'm
trying to do, that's what Thomas was doing.

I didn't realize either mail did that.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re: problems with the concept of unstable -> testing

[Filipus Klutiero]

The single largest factor in making the atmosphere unpleasant is people who
aren't contributing to Debian running their mouths on our development lists.
  
I disagree, though I know relatively well how much people contribute. 
I'd rather blame the mailing lists if simple enthusiasts caused too much 
noise.
What bores me more than non-contributors running their mouths is people 
choking during a marathon.

http://lists.debian.org/debian-devel/2008/12/msg00229.html


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re: Sections - especially section:kde and section:gnome

[Filipus Klutiero]

 


On ven, 2009-01-02 at 16:55 +0100, Joerg Jaspert wrote:
> I guess we actually need to consider what the sections are good for.
> > Asking in a random irc channel at least didn't reveal any real
> answers.
> > So what about killing the concept of sections entirely ?
> 
> Sure, if at some point a replacement is suitable and *well integrated*

> into those Debian tools that currently have sections.

Humanly speaking, what are sections used for, currently? I know that the
frontpage in packages.d.o uses them, but what an user thinks about the
section concept?
  
I don't remember using sections in over 4 years of Debian usage, though 
I had already used GNU/Linux for a few months before I switched to 
Debian. But I doubt even a user new to GNU/Linux would use them much.

We especially have a problem with “multiple sections” packages. I talked
with Sune on this, and for Xfce (if there was an Xfce section) I
couldn't say which packages would be in there and which ones wouldn't.

I guess that problem (and maybe one solution) leads to tags?
  
Yes, debtags solves this problem completely and is already partially 
implemented. I don't see why another solution would be needed.

Cheers,
--
Yves-Alexis



BTW, I can confirm what William Pitcock wrote about Synaptic. It 
implements sections pretty well. It doesn't support debtags currently.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Usefulness of sections (Re: Sections - especially section:kde and section:gnome)

[Filipus Klutiero]

Le January 7, 2009 02:32:24 am Joerg Jaspert, vous avez écrit :
> > I don't remember using sections in over 4 years of Debian usage, though
> > I had already used GNU/Linux for a few months before I switched to
> > Debian. But I doubt even a user new to GNU/Linux would use them much.
>
> Everyone that uses a tool like aptitude does use them much. I guess
> similar is true for a graphical ting like synaptic and whatnot else we
> have.

aptitude may feature sections more proeminently (I never really used it). For 
Synaptic and what else, this is false (Synaptic is the package manager I use 
the most). Synaptic has pretty good sections support since I started using 
Debian.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

debtags facet for sections (Re: Sections - especially section:kde and section:gnome)

[Filipus Klutiero]

IMO, it would make sense to merge Debian sections into a debtags facet
so that you can have multiple sections when it makes sense. The facet
could still be controlled by ftpmasters if that was desired.
I don't understand why you suggest creating a debtags facet replacing 
sections, except if you plan to give exclusive control on it to the 
archive maintenance team as opposed to the rest of the tags. Most 
sections seem to have already a corresponding tag (but it would be good 
to check that all useful sections have a corresponding tag if that was 
not done already).

 And aptitude
could use that facet to keep a logical tree but a package could then
appear in multiple sections.

Cheers,
--
Raphaël Hertzog
  



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: debtags facet for sections (Re: Sections - especially section:kde and section:gnome)

[Filipus Klutiero]

Le January 8, 2009 05:50:02 pm Charles Plessy, vous avez écrit :
> Le Thu, Jan 08, 2009 at 03:02:23PM -0500, Filipus Klutiero a écrit :
> > I don't understand why you suggest creating a debtags facet replacing
> > sections, except if you plan to give exclusive control on it to the
> > archive maintenance team as opposed to the rest of the tags.
>
> Hi Filipus and all
>
> now that the "base" section has been removed (Policy 3.8.0.0), is it still
> necessary to override the management of the Section field instead of simply
> trusting the maintainers?
>
> Have a nice day,

Hi Charles,
I can't see why it would be necessary, no. I can't see any more reason for 
overriding the section and debtags than for overriding some other package 
attributes.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re: Sections - especially section:kde and section:gnome

[Filipus Klutiero]

On Fri, 2009-01-02 at 09:34 +, Sune Vuorela wrote:
> Hi!
> 
> I have been wondering over the last months about Section: kde.

> What is the correct usage of this section?
..

I have tried to summarised some of the ideas of this thread in  
 http://wiki.debian.org/DiscussionsAfterLenny/Sections

Franklin
  
It seems that section additions are more in need of someone processing 
the requests than of discussion.


The part

Dropping Sections in favor of Debtags facets (Lenny +2)


mixes 2 things:
1. Replacing sections with Debtags
2. Introducing *one* Debtags facet to merge sections.

I saw little backing for 2.


In general, I do not see how discussing these topics could create new 
problems for Lenny's release, nor how the supposedly turbulent 
pre-release environment could affect this discussion.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re: Google Summer of Code 2009: Debian's Shortlist

[Filipus Klutiero]

> On 2009-04-11, Filipus Klutiero  wrote:
> > Obey Arthur Liu wrote:
> >> === And the details: ===
> >
> > [...]
> > These descriptions are very short. Assuming these are the abstracts,
> > that's not the students' fault. The abstracts were shortened this year
> > to 500 characters. I struggled to shorten mine to fit this. At this
> > length, it's probably impossible to fit a decent summary of most
> > projects. It would normally make sense to use abstracts for this use
> > case. Maybe Google should be asked to change the limit. Otherwise I'd
> > like to see a custom description which describes a little further. I
> > currently can't comment on all projects presented.
> > That said, this shortlist remains useful, and I thank you for this great
> > jump in transparency.
>
> Mind to tell us what your proposed project was?  For more transparency?
>
> Kind regards,
> Philipp Kern

Here is my application, stripped only from the personal section. I will not 
submit this idea anymore. Students should feel free to use this application as 
they wish. The project needs a student with a good understanding of Debian 
package management. Most importantly, a mentor familiar with APT should be 
found. This was a very scarce resource in the last 3 years.


= Project Title =
Improved package management of language packs

= Origins =
There are currently two methods to distribute localized data:
* Bundling localized data for all languages with the application package. The 
main issue with this approach is the size of the package.
* Architecture-independent packages associated with the application packages 
providing localized data. There is typically one package per language. Since 
they 'enable' the language translation for that software when installed they 
are called language packages or language packs. The main issue with this 
approach is that the language package for an application is not installed 
automatically.

The first method is suboptimal while the second is less usable.

For more information, see 
http://wiki.debian.org/i18n/TranslationDataDistribution/Chealer

= Project =
The intention is to optimize distribution of localized data by improving the 
usability of the second method, which should encourage its use and diminish 
the usage of the first method.

Concretely, the first goal is that installation of language packs happens 
automatically. For example, French people should get openoffice.org-l10n-fr 
installed automatically when openoffice.org is installed.

The second goal is to control the effects of growing the number of packages. 
The growth of the Packages file and the number of packages returned by searches 
should be avoided or limited.

= Benefits to Debian =

The Debian groups which would benefit from this project are users and mirror 
providers. Administrators of non-English systems are particularly targeted.

== Direct benefits (improvements to language packs handling) ==
The first direct benefit to users is that administrators will no longer need to 
specifically select the language packages they want to install in order to make 
translations available.
The second direct benefit is that the size of Packages and the number of 
packages matching a search should be reduced. Note that the actual secondary 
direct benefits will depend on how exactly controlling the effects of growing 
the number of packages will be done.

== Indirect benefits (avoiding packages bundling l10n data) ==
The indirect benefit of this project is that increasing the interest in 
language packs should reduce the number of application packages bundling 
localized data. Concretely, the issues of this method will be avoided:

 * Localized data increases (for all architectures) the binary package size.
  * On multi-architecture mirrors, architecture-specific packages increase disk 
usage and bandwidth usage for synchronizations.
  * Increases bandwidth usage for users and uploading mirrors.
  * Increases disk space usage for users. localepurge, considered a hack, 
exists to diminish this issue.
  * Time for installs is increased due to getting and unpacking a larger .deb.
 * Localized data is in the same binary package and therefore has to be built 
from the same source package as the application.
  * Localized data can not be handled by different maintainers.
  * Translation updates can not be made independently from the application 
binary package and could cause a regression in the application package. It is 
risky to do translation updates during a freeze.
  * A translation update means that the application binary package needs to be 
rebuilt. This causes larger updates (mostly more bandwidth usage) and 
increased buildd usage, so maintainers tend to wait for a new software release 
before providing the translation updates. The delay for translator's work to 
reach users tends

Bug#580643: [general] Chicony KU-0420 (Targus Slim Internet Media USB Keyboard) generates two incorrect symbols

[Filipus Klutiero]

Package: general
Severity: minor

The media player and my computer keys on the Chicony KU-0420 (aka Targus Slim 
Internet Media USB Keyboard) are
generating wrong symbols (with XKeyboardConfig 1.8). The first generates
XF86Tools instead of XF86AudioMedia and the second generates XF86Explorer
instead of XF86MyComputer.

The keys generate keycodes 179 and 152. This once worked with 
XKeyboardConfig 1.5. I reported the bug as a regression in 1.8, but here 
is the answer from XKeyboardConfig's maintainer: 
https://bugs.freedesktop.org/show_bug.cgi?id=27606


This system is different from the one on which I verified things were 
working. The "regression" (on my system's side) may be due to switching 
from kbd to evdev, if I understand Sergey correctly. But I don't 
remember which keyboard driver I was using, and trying to use the kbd 
driver doesn't help (all special keys don't work). If I understand 
Sergey correctly, this should be assigned to Linux.


--- System information. ---
Architecture: i386
Kernel: Linux 2.6.32-4-686

Debian Release: squeeze/sid
990 testing security.debian.org
990 testing ftp.ca.debian.org
500 unstable ftp.ca.debian.org
500 stable deb.opera.com
1 experimental ftp.ca.debian.org



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4be40cc0.3070...@gmail.com

Re: Re: Google Summer of Code 2010 Debian Report

[Filipus Klutiero]

 Obey Arthur Liu wrote:

On Mon, Sep 20, 2010 at 12:47 PM, Adrian von Bidder
  wrote:
>  Hi Arthur,
>
>  On Monday 20 September 2010 11.37:04 Obey Arthur Liu wrote:
>  [GSoC report]
>
>  Hmm.  It would have been nice to hear about what the students did and how
>  far they got in their GSoC projects instead of what they did at DC10.

The report is an aggregation of joint reports from students and
mentors ([1]). I combined and posted what I received. Some pairs
didn't send me their blurbs on time, but I suppose that some students
being back to school already is a reason.

Note that I have complete data as part of official GSoC evaluations
but their content is private to mentors by GSoC rule, so I'm still
keeping tabs on things, don't worry :)
I do worry. Unless I'm missing something, this is not the fourth Debian 
GSoC, but the fifth, and again, it's hard to believe this SoC was 
reasonably useful. The report we get has some information on 7 projects, 
although 8 are supposed to have been successful, and as Adrian and 
Olivier mentioned, no project results in most cases. And what about the 
unsuccessful projects? Their faith may not be relevant for d-d-a, but 
not documenting what happened, perhaps somewhere else, will not help new 
Debian GSoC admins to start with a good understanding of the challenges.


I would recommend requiring candidate mentors to agree to share 
evaluations with GSoC admins, so admins can at least pick information on 
results when a report has to be made.


At its current scale, the summer of code is approximately equivalent to 
a potential indirect subsidy of 50 000 USD and a direct subsidy of 5000 
USD. 5000 may not be a lot, but if we don't have enough volunteers to 
complete missing administrative manpower, then we should be honest about 
it and ask for more involvement... instead of having a misleading tone 
of optimism in the report. Yes, the SoC is surely a positive thing for 
Debian, but considering the resources granted, I almost feel ashamed to 
see how modest the results have been so far. (Note that I have not 
extensively monitored the SoC. The results may be greater than I 
imagine, but this is worryingly non-obvious.)


I must still thank you for sending a report. My first reaction was 
"Finally", I am just disappointed by the content.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c9b1153.3060...@gmail.com

Re: Google Summer of Code 2010 Debian Report

[Filipus Klutiero]

 On 2010-09-23 05:32, Obey Arthur Liu wrote:

On Thu, Sep 23, 2010 at 10:35 AM, Filipus Klutiero  wrote:

[...]
I would recommend requiring candidate mentors to agree to share evaluations
with GSoC admins, so admins can at least pick information on results when a
report has to be made.

Mentors are usually restricted by their spare time. Remember that
contrary to students, they usually have an actual job.
Which is why I'm suggesting that admins get allowed to use their 
reports, so if any individual mentor is too busy to give a report on the 
results and the students also fails to do it, the admins will be able to 
do it easily.

I do not think that we need a constraining agreement with mentors on
that point. They would usually happily do it.

...then why did most of them fail to do it here :-?

At its current scale, the summer of code is approximately equivalent to a
potential indirect subsidy of 50 000 USD and a direct subsidy of 5000 USD.
5000 may not be a lot, but if we don't have enough volunteers to complete
missing administrative manpower, then we should be honest about it and ask
for more involvement... instead of having a misleading tone of optimism in

Breaking news: people are welcome to help out for managing the Summer
of Code at Debian. There's plenty of work to do, even outside of the
summer period. (This is serious.)
I'm not sure I get exactly your intended message, but if this is 
serious, this is the kind of information that would be actually relevant 
on d-d-a next time the SoC team sends a mail there.

the report. Yes, the SoC is surely a positive thing for Debian, but
considering the resources granted, I almost feel ashamed to see how modest
the results have been so far. (Note that I have not extensively monitored
the SoC. The results may be greater than I imagine, but this is worryingly
non-obvious.)

I think the issue is that you're confusing Summer of Code participants
with paid consultants. They are not. They are just students, most
often newbies at free software, whose summer happen to have been
cleared out of another summer job by the GSoC stipend.
Heh, it would be hard to confuse SoC students with consultants when 
they're being paid 5000 USD for 12 weeks of works...

As such, you
should have similar survival rate expectations for a Debian GSoC
project as for any other Debian project that you or any DD would
happen to be working on. Perhaps a bit higher, but not much.
This hits an extremely interesting point. The reference to a "survival 
rate" betrays what I think is a major error GSoC administration has 
made. It seems the projects selected are in large part new projects, 
rather than improvements to existing software.


When projects are selected, admins need to keep in mind that those 
working on them are not professional and experienced developers, but 
students (who may not even study computer science). Furthermore, these 
students will have only 12 summer weeks, during which they'll work from 
home, most certainly away from the resources they need, with as only 
somewhat reliable guide their mentor, which may not even get 500 USD for 
the whole mentoring process. For these projects to survive, or even have 
a chance to be born, their scope needs to be very limited.


When giving a quick look at this year's projects, this problem seems to 
be a lot lesser than it has been in the past. However, this problem is 
in fact part of a wider one, the tendency to pick big projects. Of 
course, big projects are more attractive at first sight, but we're not 
that stupid. Even with a considerate selection, big projects are more 
interesting, because they should get more work done than a project which 
would possibly be completed before then end of summer.


But we must not forget a big advantage of smaller projects. Not only are 
their results more likely to be useful, but the fact that the students 
will have completed them is a good thing per se, because the SoC is also 
about recruiting future Debian contributors. As you must know, big 
project students always say they're going to complete the work after the 
end of the summer, but they're going back to school and obviously give 
up at some point, which leaves them with a feeling of guilt that will 
not help their perception of being further involved in Debian.


And in fact, this big project / small project division is in good part a 
false dichotomy. In reality, even if the project would be finished 
half-term, there is always room for improvement, and often surrounding 
things that can be done to make use of the project's results.


I'm stopping here, but mentioning that despite this, there *could* be 
ways to tackle big projects, like going in phases (something similar was 
tried already).

Regarding projects management, well, if you expect a level of
accountability on par with what you'd have in a business, then you
need to have the appropri

Re: Google Summer of Code 2010 Debian Report

[Filipus Klutiero]

 On 2010-09-23 21:26, David Kalnischkies wrote:

2010/9/23 Filipus Klutiero:

  On 2010-09-23 05:32, Obey Arthur Liu wrote:

On Thu, Sep 23, 2010 at 10:35 AM, Filipus Klutiero
  wrote:

[...]
I would recommend requiring candidate mentors to agree to share
evaluations
with GSoC admins, so admins can at least pick information on results when
a
report has to be made.

Mentors are usually restricted by their spare time. Remember that
contrary to students, they usually have an actual job.

Which is why I'm suggesting that admins get allowed to use their reports, so
if any individual mentor is too busy to give a report on the results and the
students also fails to do it, the admins will be able to do it easily.

Maybe, in this case you should also motivate the students to do the extra
work you expect from them. They all were required to fill in two rather
longish evaluations in the gsoc process - repeating the same again is,
lets say, boring. Given that we (as in students) prepared all a few debconf
slides relatively near the end of gsoc most of it is already said - even
by the respective student in person… (video is available).
And these slides should be better than the evaluations as these are rather
gsoc organizational orientated questions and not so much about the
project itself…
Really, if writing a paragraph on what you did during 12 weeks is 
significant extra work for you, I wonder why you bothered writing this 
reply.

And more personal - as I don't know about the others and non-attending
debconf doesn't help a lot - I revised very few (as in no) "gimme more info"
requests, so writing a whole lot into the blue which is maybe never read
(or given that nobody requested it - very likely never read) isn't very
motivating - or at least I can find a bunch of more motivating tasks
including university stuff, helping my uncle making (and drinking) wine
or such boring things as fixing bugs or even writing emails…
(and yes, I have writing something on my todo list, just not high-priority)
I don't think you really understand our concerns. Nobody talked about 
writing "a whole lot". We're disappointed that most project do not have 
*a single word* published on the results. There is room for a middle 
ground between a word and a whole lot.


Besides, I'm not talking about getting students to write this, but 
making sure there's an easy backup solution if they don't.

At its current scale, the summer of code is approximately equivalent to a
potential indirect subsidy of 50 000 USD and a direct subsidy of 5000
USD.
5000 may not be a lot, but if we don't have enough volunteers to complete
missing administrative manpower, then we should be honest about it and
ask
for more involvement... instead of having a misleading tone of optimism
in

Breaking news: people are welcome to help out for managing the Summer
of Code at Debian. There's plenty of work to do, even outside of the
summer period. (This is serious.)

I'm not sure I get exactly your intended message, but if this is serious,
this is the kind of information that would be actually relevant on d-d-a
next time the SoC team sends a mail there.

Come on, can you name even one team in debian (or any open source project)
which has too many active members? Being understaffed is the norm,
not something you need to mention explicitly in every mail you write…
(okay, this paragraph is a bit too depressive, but I am out of time to
reword it - at bit ironic in this context… ;) )


Read carefully - I was not sure I got Obey's message correctly. He wrote 
"Breaking news: [...] (This is serious.)"
If he means that [...] is seriously breaking news, I think my answer is 
appropriate.


If however "Breaking news" is sarcastic, and he means, as you say, that 
all teams welcome help, implying that asking for more involvement would 
be vain, then my answer is different:
Debian teams could be put on a spectrum of vitality. At one end, you 
have the security team, which just needs to keep a minimal manpower. At 
the other end, you have the vimim team, working on the next-generation 
beat-them-all text editor. The vimim team could be vacant for a decade 
without anyone noticing, however if an accident reduces the security 
team to a single person, that person needs to scream immediately and 
start recruiting new people before the funerals are over. Close to the 
critical end, you have the archive maintenance team, of which the 
breakage, although it would not cause an immediate threat to Debian, 
would severely affect development, making most other teams unproductive. 
I consider the GSoC admins on the side of the security team, not as 
critical as the archive maintenance team, but still a team whose 
performance is critical to the productivity of our GSoC project teams.

the report. Yes, the SoC is surely a positive thing for Debian, but
considering the resources granted, I almost fee

Re: Re: Re: Google Summer of Code 2010 Debian Report

[Filipus Klutiero]

Quoting Filipus Klutiero (chea...@gmail.com):

>  I must still thank you for sending a report. My first reaction was
>  "Finally", I am just disappointed by the content.

I am disappointed by your followup and insistance.

To make it clear (sorry readers, you'll need a translation tool but I
need to use the words I want to use and not my usual approximative English),
let's do this in my native language which you do read as well as Arthur:

Je suis extrêmement en colère, Philippe, et c'est rare. Je trouve tes
messages dans ce fil de discussion totalement déplacés . Tu voudrais
démotiver un de nos meilleurs contributeurs que tu ne t'y prendrais
pas mieux.
I see you're in anger and reject some of my comments. I'm sorry, I can't 
do much, but to promise I'll take note of your comments if you explain 
exactly what maddens you.
It seems this is basically what angers you: "I almost feel ashamed to 
see how modest the results have been so far"
Don't forget I immediately followed that by: "Note that I have not 
extensively monitored the SoC. The results may be greater than I 
imagine, but this is worryingly non-obvious."

Or, en plusieurs années de GSOC, je ne t'ai jamais vu participer à
celui-ci. J'espère donc qu'Arthur notamment saura faire la part des
choses et laisser tes commentaires à la place qu'ils n'auraient jamais
du quitter.
I did participate in the Debian SoC, and offered myself to take a 
prominent role more than once. Unfortunately things outside my control 
prevented me to enroll.

Je n'aime pas être en colère en public, mais je pense que là tu as
dépassé les bornes. Le travail du GSOC cette année a été un des plus
productifs pour Debian et Arthur a pris grand soin de
tenir le projet au courant. Il s'est notamment dépensé sans compter
son temps pour que les étudiants participent à Debconf et utilisent
cette occasion unique de parler de leur travaux. Etceux qui
étaient là à DC10le savent très bien.
I was not at DebConf, and only watched a few talks. So it's possible I 
just missed something. I don't know what happened at DebConf, but if you 
say Arthur put a lot of effort in promoting the SoC results, I guess 
there was too much emphasis on DebConf, and too little done outside. 
Keep in mind most Debian contributors don't attend DebConf.

Aller suggérer un manque de transparence ou de la négligence est
insultant.

I'll rewind and explain how I came to intervene in a concise way:

For several years, I consider the SoC management poor, and I've given 
signs that more transparency would be welcome at times. But this is a 
volunteer project, so we can't complain for a lack of transparency, we 
should be happy some work is done in the first place, right? Well, 
Google does give 5000 USD for management, so this is not entirely true, 
but given the amount, let's ignore.


What does make me fairly angry is to read a "Google Summer of Code 2010 
Debian Report", with some elementary issues, calling our 2010 GSoC the 
fourth when it was the fifth and announcing reports on 8 successful 
projects but only presenting 7. No link in the mail explains what 
happened to the 2 unsuccessful projects. Most importantly, even in the 7 
projects described, most don't have a single word on the results, but 
rather impressions on DebConf 2010 which are quite offtopic on d-d-a. 
And all that proeminently sent to d-d-a, with a slightly optimistic tone 
that seems to send the project the message "We're doing fine!".


Then, when 2 readers write very nice mails pointing out one of these 
issues, what do I see in the answer?

don't worry :)
That makes me angry. I wouldn't care about transparency if I was seeing 
GSoC results, but as I said, I'm not satisfied by the little I see, so I 
do not have enough trust to accept being just told to not worry. If your 
team has neither good performance nor transparency, at least don't act 
as if things were fine.


If I'm suggesting a lack of transparency or negligence, please don't 
take this as an insult, but as a challenge. Nothing here is personal, 
Arthur is not the only one involved in the SoC, and the goal is to make 
sure future SoC-s will also be "even" better.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c9cf14e.3040...@gmail.com

Bug#612330: [general] Debian Live fails to restart

[Filipus Klutiero]

Package: general
Severity: important

I downloaded debian-live-6.0.0-i386-kde-desktop.img and managed to write 
it on a USB stick. Shutting down generally works, but restarting 
doesn't. After the init scripts finish, the console prints
"Please remove the USB flash drive and press ENTER to continue:", as 
when shutting down, and immediately followed by "[ time ] Starting new 
kernel"
After removing the flash drive and pressing ENTER, nothing happens, for 
many minutes (presumably until one will manually shut down the system).




--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d504a92.3000...@gmail.com

Bug#612359: [general] Debian Live: some Boot menu options are invisible (Memory test)

[Filipus Klutiero]

Package: general
Severity: important

Debian Live 6's boot menu seems to contain 14 options. I used the image 
debian-live-6.0.0-i386-kde-desktop.img. There are 4 Live options, 4 Text 
options, 4 GUI options, and 2 more, the first being Memory test.
I tried the USB key on 3 PC, and I always only saw the first 8 before I 
used the arrow keys. The display was identical on the 3 PC-s. 2 are 
laptops with a 1366x768 resolution, one is a desktop with a 1440x900 LCD 
screen. They are all "widescreens".


First problem, nothing suggests there are 6 more options that will 
appear when going down. The menu seems to think its always showing 10 
options. Therefore if from the start I press the down arrow key 8 times, 
no option is highlighted but no scrolling happens. I have to press 10 
times. Then the options scroll by 4 and I see Text and GUI options. GUI 
Auto is the last option I can see. There is room in the screen to show 
one line below the last option shown, but not 2. Playing, it's possible 
to get the 13th option, Memory test, to flash, so I was able to use 
memtest anyway.


I guess if the fix is non-trivial, the most urgent thing is to be able 
to see the 2 last options. Ironically, the last option, the one truly 
invisible, seems to be the help.




--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d5088de.9060...@gmail.com

Should Debian Live be supported with lenny?

[Filipus Klutiero]

Hi,
according to the current lenny release notes, Debian Live is going to become 
official with lenny for x86. I tried Debian Live several times and always had 
issues with it. So, I decided to test Debian Live a bit and found that 
several issues still applied. I discussed with Daniel Baumann about some 
issues, and the following seem to be relevant:

Apparently innocuous error popup after KDE is started.
Fails to boot from hard disk (disk1).
Empty F8 screen.
The latest image I downloaded still has an old problem, failures at shutdown. 
Daniel replied this one would be fixed either for r0 or r1.

As for the rest:

The manual is under heavy construction.

The latest version, RC1, didn't receive much testing.

There is no bug tracker.

There is no integration in debian.org yet.
Quoting my discussion with Daniel:
I wrote:
> > > It seems there are infrastructure issues. The
> > > distribution servers don't seem redundant.
> >
> > cdimage.debian.org is the main distribution point. live.debian.net is
> > just for snapshots.
>
> Good, though I still don't see any link to cdimage.debian.org.


Since I only did moderate testing of 
http://live.debian.net/cdimage/lenny-builds/current/i386/iso-cd/debian-Lenny-Live-rc1-i386-kde-desktop.iso
(I didn't try live-helper or anything yet), I'm wondering if Debian Live 
already has the quality we want to associate with Debian. And since there's 
no bug tracker, it's hard to look at other people's experiences. Did others 
notice other important issues with Debian Live? Do you think it should become 
official? If you have an opinion, please give it on 
http://doodle.com/participation.html?pollId=rt5qfvmv3zuuauwe


Note on the decision to make Debian Live official
The Debian Live paragraph in the release notes can be seen here:
http://www.debian.org/releases/lenny/i386/release-notes/ch-whats-new.en.html#live
 
W. Martin Borgert added the paragraph coordinating with Daniel Baumann.

Daniel Baumann wrote:
> Filipus Klutiero wrote:
> > how/where was it decided that Debian Live would be official
> > (for x86) with lenny?
>
> it was declared as such when we released 5.0 beta1. before that,
> different people from different core teams did express their support for
> that at debconf8, and sam as DPL at debconf7 did the same as well.

Filipus Klutiero

P.S. In case this wouldn't be clear, I am totally in favor of the Debian Live 
Project, and my only concern is whether it is of sufficient quality *at this 
time*.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Should Debian Live be supported with lenny?

[Filipus Klutiero]

Le February 15, 2009 06:03:46 am Daniel Baumann, vous avez écrit :
> Filipus Klutiero wrote:
> > Hi,
>
> Hi,
>
> first of all: you are aware that you hit the *worst* possible time of
> sending that email when doing it on the *very* *evening* *when* *we*
> *are* *actually* *really* *releasing*, especially when everyone knows
> that the release is being made that evening.
You are aware that Debian Live lenny RC1 was released on *2009-02-09*? I did 
not see any announcement of that, so I had to find that it was released by 
myself before waiting after the images server pushing around 20 kB/s, and I 
still managed to test and open this thread on the *first* week-end day 
following the release. I'm not paid to do QA on Debian.
>
> second, it would have been more than appropriate to CC me for that mail,
> and of course also send a CC to debian-l...@lists.debian.org.
I meant to CC debian-live but sent the mail too fast.
>
> third, i've took the time to answer your questions when you approached
> me with them 10 days ago. however, this appears to have been wasted as
> you did not care to attach my answers to the questions you're repeating
> here and i apparently (since this post should not left be unanswered
> from our side), do have to reiterate it here.
I asked you 2 questions, one of which I didn't repeat in this thread. I quoted 
your answer to the other one at the end of my message.
>
> fourthly, apparently you lack the ability to communicate bugs you
> experiencing properly. most of your issues do lack any information to
> make something useful out of it. also, again, you have never tried to
> contact our mailinglist about it at all, nor did you submit any bug
> report. bugs do not get solved by mumbling about them in a private mail
> (and not following up with required information).
I didn't perceive any request for follow ups in your answers. If I missed one, 
I'd be happy to provide the required information if you tell me what you 
want.
>
[...]
>
> > according to the current lenny release notes, Debian Live is going to
> > become official with lenny for x86. I tried Debian Live several times and
> > always had issues with it. So, I decided to test Debian Live a bit and
> > found that several issues still applied. I discussed with Daniel Baumann
> > about some issues, and the following seem to be relevant:
> >
> > Apparently innocuous error popup after KDE is started.
>
> you did not mention that 10 days ago, so this one is new.
Indeed, though I see that more as a negative point.
>
> however, such a statement is as usefull as "doesn't work[tm]". feel free
> to send a *useful* bug report with the needed details so that we are
> able to understand it.
The purpose of this thread is not to improve Debian Live. At the time I opened 
the thread, time was running out to even take the decision of making Debian 
Live official or not.
>
> > Fails to boot from hard disk (disk1).
>
> you did not mention that 10 days ago, so this one is new.
I don't know, I tested RC 1 more than beta 2.
>
> dd'ing a usb-hdd image to a harddisk works the same way as to an usb
> stick. this has always been working. stating "doesn't work[tm]" doesn't
> help. feel free to send a *useful* bug report with the needed details so
> that we are able to understand it.
As above.
>
> > Empty F8 screen.
>
> you did not mention that 10 days ago, so this one is new.
As above, I hadn't tested this with beta 2.
>
> this is not actually a bug. in order to have debian-cd and debian-live
> images similar, we do use the same organisation of the help screens in
> syslinux. however, d-i's f8 content does not apply and we don't have any
> usefull content to fill in there, that's why it's nothing there. i'm
> sure i could put an 'empty' frame there if desired.
Yes. Or don't mention that screen when it's empty. Or both.
>
> > The latest image I downloaded still has an old problem, failures at
> > shutdown. Daniel replied this one would be fixed either for r0 or r1.
>
> that's not precise, i said:
>
> "should be fixed with current live-initramfs in sid/lenny. the last
> prebuilds do contain an older version. if not, for r1 then."
>
> for the records: i didn't saw "failures at shutdown" in the last two
> month on cd builds, and neither 10 days ago and neither are they today.
> if they have happened, they were fixed in newer live-initramfs in late
> december (i don't remember from regular builds from before).
You must have been thinking about different failures then.
>
> additionally, stating "failures" doesn't help. feel free to sen

Bug#515718: [general] live: failures at shutdown on USB flash drive

[Filipus Klutiero]

Package: general
Version: 5.0.0
Severity: normal

When shutting down Debian Live running from a USB flash drive, one gets a 
bunch of errors on tty1:

Cleaning up ifupdown
Unmounting temporary filesystems...umount: /live/cow: device is busy
umount: /live/cow: device is busy
umount: /live: device is busy
umount: /live: device is busy
failed.
Deactivating swap...done.
Unmounting local filesystems...umount2: No such file or directory
umount: /filesystem.squashfs: not found
umount2: Device or resource busy
umount: /dev/sda1 busy - remounted read-only
failed.
live-initramfs is resyncing snapshots and caching reboot files...

Please remove the USB flash drive and press ENTER to continue:

Apparently, Debian Live doesn't have persistence by default, so that's just 
not pretty.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#515721: [general] live: disk1 boot method fails

[Filipus Klutiero]

Package: general
Version: 5.0.0
Severity: normal

Debian Live's disk1 boot method (F4, Boot from the first hard disk) fails on 2 
PCs from 2 tested with

Could not find kernel image: disk1

I do not have any computer with 2 HDDs, so I didn't try disk2.
I got this with 
http://cdimage.debian.org/cdimage/release/5.0.0-live/i386/usb-hdd/debian-live-500-i386-kde-desktop.img
 
and the equivalent RC 1 image.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Should Debian Live be supported with lenny?

[Filipus Klutiero]

Le February 16, 2009 05:29:21 pm Daniel Baumann, vous avez écrit :
> Filipus Klutiero wrote:
> > You are aware that Debian Live lenny RC1 was released on *2009-02-09*?
>
> no, i didn't know that *kidding*
Eh, maybe I didn't know that lenny was about to be released then.
>
> > I did not see any announcement of that
>
> http://lists.debian.org/debian-live/2009/02/msg00070.html
Like most people, I don't follow the debian-live mailing list regularly.
>
> > I'm not paid to do QA on Debian.
>
> me neither.
And I don't think I criticized you for not doing QA properly.
>
> > The purpose of this thread is not to improve Debian Live.
>
> fair enough. i stop reading here then.
So the first post "should not left be unanswered", but the second one isn't 
even worth reading? Eh.

As lenny was already released, I reported the bugs except for the F8 issue and 
the KDE error popup, which I didn't reproduce.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Requirement for a “proper manpage” for every command

[Filipus Klutiero]

Ben Finney wrote:

Wording and tone aside, is that expectation reasonable?

Yes.

 What course of
action is open to a user of the package, with a maintainer who has
made it plain they're not interested in following (this part of)
policy?
  
There's nothing direct you can do as user. As a packager, you could 
propose adopting the package if the current maintainer is incompetent.
As a user, you'd have to report a bug each time the manual becomes 
incorrect due to lack of care.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Extended descriptions size (was Re: RFC: Better formatting for long descriptions)

[Filipus Klutiero]

On Fri, 20 Mar 2009 14:45:09 +0100 (CET)
Andreas Tille  wrote:

> I tried to find a clear advise how to reasonable format lists inside long
> descriptions of packages.  The only thing I know is that lines with two
> leading spaces is considered verbose. 


Packages.gz is already 26Mb - I'd like to find ways to shorten the
package descriptions, not lengthen it. :-(
  
Current squeeze main Packages.gz is 7 MB: 
http://ftp.ca.debian.org/debian/dists/squeeze/main/binary-i386/

Can the long description be trimmed to only such data necessary to
identify the package compared to similar packages? We have debtags for
lots of other facets of a package description, maybe it is time that
the long description itself is trimmed so that it does not repeat any
information already encoded as debtags?
  
debtags is not yet at a stage where this should be done (for one thing, 
Synaptic, for "example", does not support debtags). Even if it would be 
possible, I doubt this would help much.

> The rationale behind this is that with some
> better standard formating some tools which display descriptions on web
> pages might be enhanced to use ,  and  tags which finally
> makes a better reading.

Oh no, please don't let Packages.gz get to 40Mb or 50Mb or more. There
has to be a limit somewhere.
  
I don't understand the proposal as something affecting Packages's size 
significantly.

What about a way of having a really long, detailed, nicely formatted
description on packages.debian.org but a much shorter, more basic
version in the Packages.gz file?
  
The extended description needs to be available to APT, not only via 
packages.d.o. I seem to remember that Mandrake Linux (or some other 
RPM-based distribution) used two Packages-like files, a fat one about 5 
times our Packages and a slim one about a fifth of Debian's Packages. I 
remember finding the slim index cool, but now that there's 
Packages.diff, I think that developing Mandrake-like Packages files and 
seeing the results in, perhaps, 2 years, would not benefit much to the 
kind of hardware Debian will run on by then.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re: RFC: Better formatting for long descriptions

[Filipus Klutiero]

On Fri, 20 Mar 2009, martin f krafft wrote:

  


What we really should do, instead of clinging to the NIH-behaviour,
reinventing the wheel, and polishing it over and over again is ditch
the pseudo-RFC822 format we have and use Yaml instead.

http://www.yaml.org/start.html
http://yaml.org/spec/1.2/



And most probably somebody else will revive the "switch to XML" suggestion.
I know the pros and cons for different formats but I want a solution *now*
and that's the reason why I wrote:

  


>   2. Does not break any existing tool


I tend to agree with Martin. Do you have a particular reason making this 
change urge? At worst, a format for extended descriptions could be 
usable by Debian 7.
I noticed while checking if packages.debian.org rendered the current 
descriptions decently that acidlab's description is rendered pretty 
badly, but AFAICS that's just a packages.d.o bug. FWIW, I had never 
noticed such an issue.

Kind regards

   Andreas.
  



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re: Extended descriptions size (was Re: RFC: Better formatting for long descriptions)

[Filipus Klutiero]

Neil Williams wrote:

On Fri, 20 Mar 2009 19:15:00 -0400
Filipus Klutiero  wrote:

[...]

> > What about a way of having a really long, detailed, nicely formatted
> > description on packages.debian.org but a much shorter, more basic
> > version in the Packages.gz file?
> >   
> The extended description needs to be available to APT


Only for use by apt-search, the rest of apt doesn't care about it. apt
understands debtags, why duplicate that information? (Frontends can be
adapted or just rely on apt-cache search underneath.)
  
I don't understand what you mean. Where would apt-cache get the extended 
description from? Again, debtags is not mature enough yet to shrink 
descriptions.
>, not only via 
> packages.d.o. I seem to remember that Mandrake Linux (or some other 
> RPM-based distribution) used two Packages-like files, a fat one about 5 
> times our Packages and a slim one about a fifth of Debian's Packages. I 
> remember finding the slim index cool, but now that there's 
> Packages.diff, I think that developing Mandrake-like Packages files and 
> seeing the results in, perhaps, 2 years, would not benefit much to the 
> kind of hardware Debian will run on by then.


Debian is not exclusively for power-hungry servers and mega-powerful
workstations, Debian also runs on very small hardware and not
necessarily old stuff either. It is a mistake to think that Debian
should require more and more powerful hardware for the basic system.
  
Actually, I was only saying that I thought such a reduction of the 
hardware requirements would not help much.

Yes, there is software in Debian that needs a powerful machine, there
is also a LOT of software in Debian specifically designed for low
resource machines where the benefits of a <1Mb Packages.gz file are
appreciable.
I agree, after reading Paul's comment, that if we get a Translations-en 
file via DDTP, removing the extended description from Packages would be 
less work, and thus more interesting.


I tested the gain with
awk '$0 !~ /^(Description| )/'
and the result loses close to half of its compressed size.
-rw-r--r-- 1 chealer chealer  4224356 mar 21 20:12 nodesc.tar.gz
-rw-r--r-- 1 chealer chealer  7350583 mar 21 15:56 
debian.savoirfairelinux.net_debian_dists_testing_main_binary-i386_Packages.tar.gz



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re: grouping of alternative depends

[Filipus Klutiero]

Holger Levsen wrote:

Hi,

On Sonntag, 29. März 2009, Adeodato Simó wrote:
> Hm? Your original mail said you wanted:
> Depends: (pdns-backend-ldap + pdns-recursor) | bind9
> How does installing bind9 plus pdns-backend-ldap not satisfy the above?

Sure it does satisfy the depends, but installing pdns-backup-ldap is not 
needed in that case, thus I consider this buggy.
  

I don't understand what you mean. What do you consider buggy?

[...]

regards,
	Holger, who just skimmed over the dpkg bugs and was horrified by such gems as 
#1555 [w|  |  ] [dselect] dselect per-screen-half focus request 
#4448 [w|  |=] [dselect] [PERF] dselect performance gripe (disk method doing 
dpkg -iGROEB) 
#4989 [w|  |  ] [dselect] dselect conflict resolution screen should 
mention "replaces" 
#6019 [w|  |  ] [dselect] repeated identical conflicts messages 
#6486 [w|  |  ] [dselect] should have a Tk version, mention multiple available 
versions etc


Does dselect still have valid uses cases?
The dpkg maintainers may know better, but at least wajig depends on it 
(never used that). Regardless, it's still in the archive... Note that 
these reports should be assigned to the dselect package.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re: [GSoC] KDE4/Qt4 based package manager

[Filipus Klutiero]

Christian Perrier wrote:

Quoting Obey Arthur Liu (art...@milliways.fr):

> > synaptic or shaman (from Chakra). I think that aptitude-gtk and adept
> > are not userfriendly. Using these applications was quite difficult for
> Heartfelt thank yous! (I'm the guy responsible for aptitude-gtk.. :D )


Is this silly to think that, as most of the (good) work was made in
aptitude-gtk, an aptitude-qt development would be a better idea?
At first sight, it does sound silly to me. aptitude-gtk is a GTK+ GUI 
for Aptitude. Similarly, aptitude-qt would be a Qt UI for Aptitude. But 
Aptitude is an APT front-end. Which means aptitude-qt would be a 
front-end to a front-end. We only want a Qt/KDE APT front-end.


aptitude-foo was tried in last summer's GSoC, resulting in aptitude-gtk. 
It's only experimental, but it not only depends on aptitude, it's also 
part of the aptitude source package. I'm not convinced that an 
aptitude-qt would do much better.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Developing aptitude frontends (was Re: [GSoC] KDE4/Qt4 based package manager)

[Filipus Klutiero]

Obey Arthur Liu wrote:

Filipus Klutiero a écrit :

> Christian Perrier wrote:
>> Is this silly to think that, as most of the (good) work was made in
>> aptitude-gtk, an aptitude-qt development would be a better idea?

> At first sight, it does sound silly to me. aptitude-gtk is a GTK+ GUI
> for Aptitude. Similarly, aptitude-qt would be a Qt UI for Aptitude. But
> Aptitude is an APT front-end. Which means aptitude-qt would be a
> front-end to a front-end. We only want a Qt/KDE APT front-end.

To be exact, "aptitude-gtk" is as much a "front-end" of "aptitude" as
the ncurse version of aptitude is, or the console version for that
matter, is a "front-end" of "aptitude".
  

Well, the description of the 2008 GSoC aptitude project states:

I will create a GTK+ GUI for Aptitude [...]




Aptitude is much more than a bare APT front-end. It embarks its own
elaborate resolver and quite a few other things.
  
I agree that aptitude may have done more than it was supposed to in the 
past, but the current situation is better, and I seem to hear it's still 
improving. I'm not an aptitude user; these things may be good or not, 
but even if they're good, I think the factorization should continue 
rather than mangling things even more.

Also, aptitude-gtk is not just making calls to the aptitude binary or
libraries or whatever, it's an integral part of the code.

> aptitude-foo was tried in last summer's GSoC, resulting in aptitude-gtk.
> It's only experimental, but it not only depends on aptitude, it's also
> part of the aptitude source package. I'm not convinced that an
> aptitude-qt would do much better.

Aptitude-gtk is aptitude and aptitude is aptitude-gtk... The "aptitude"
package in experimental is actually "aptitude-gtk" with the -gtk parts
turned off at build-time.
According to aptitude's extended description, "aptitude is a 
terminal-based package manager". I'm far from being an aptitude expert, 
but my point is not terminological. I'm just saying that writing 
front-ends to a front-end is probably not the best way to go. If 
aptitude is as you say still much more than an APT front-end, this may 
be an issue worth considering before expanding it (or writing new 
software that depends on it, depending on the terminology).



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DEP-4: The TDeb specification.

[Filipus Klutiero]

Neil Williams wrote:

Primary Motivations (in order):
   1. Updates to translations should not require source NMU's.
  
I guess that means avoiding to NMU with new diff.gz -s? If so, what are 
the underlying motivations?


What is the purpose of creating a new binary package format for this (as 
opposed to reusing, say, the deb format)?



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re: DEP-4: The TDeb specification.

[Filipus Klutiero]

Neil Williams wrote:


On Tue, 31 Mar 2009 13:06:35 -0400
Filipus Klutiero  wrote:

> Neil Williams wrote:
> > Primary Motivations (in order):
> >1. Updates to translations should not require source NMU's.
> >   
> I guess that means avoiding to NMU with new diff.gz -s? If so, what are 
> the underlying motivations?


To prevent translation updates (particularly debconf ones) from
interfering with existing transitions and release cycles. There is no
need to rebuild the source of the package merely to update or add a new
translation. The current barriers to such rebuilds can be overcome with
adapted tools, as described in the DEP.

http://dep.debian.net/deps/dep4/#index10h2

There is no good reason to permit translation updates to cause the
binary packages to be changed by recompiling the source. Dependency
versions change, new bugs can be introduced, existing transitions get
more complicated and the one time when translation updates are most
useful is during a release freeze when the binaries must not change.
The whole point of i18n (the process of making a package support
localisation by internationalising the codebase) is to ensure that the
same compiled binary can operate with any compatible translation. This
allows users to set LANG= and get the localised version at runtime.
Requiring that translations can only be added or updated in Debian by
recompiling the source is a complete waste of effort and is something
that gettext and other l10n middle-ware are expressly designed to
avoid. Debian, currently, is simply not getting the best out of l10n
and is making life difficult for everyone by putting the translated
files in the same packages as the compiled binaries. Each release
cycle, this comes back to bite us. TDebs will remove this burden.
  
That would be a nice improvement, but let me suggest another 
implementation. To avoid introducing a second diff, why not updating the 
regular diff (in the case of non-native packages) but indicating that 
the package shouldn't be entirely rebuilt when uploading? This seems 
simpler.
> What is the purpose of creating a new binary package format for this (as 
> opposed to reusing, say, the deb format)?


To support easier management of the translations, including allowing
users to only install the translations that are needed for one
particular installation, instead of every user getting every
translation for every package they install, whether those translations
are even supported or not.
There are two ways to achieve this. One is per-language packages, the 
other is localization packages with multiple languages but using 
something like dpkg class support. Currently, the only way supported is 
language packages, but introducing a new package format will not 
necessarily allow the second way. Implementing this would take about the 
same amout of work as implementing something like dpkg class support for 
the deb file format.

 The current model is based on server
installations where lots of locales may be configured to support
localisation of web content. Installing all 90 locales does not
translate well to desktop installations with only a handful of users
and maybe 5 or 6 languages. On a typical Debian box, /usr/share/locale/
takes up 250Mb when each language only requires a maximum of 9Mb.
  
I'm not sure why you write that the current model is based on server 
installations. The current "model" I see is just the "natural" state of 
things, with no modularization WRT translations in the vast majority of 
packages. But yeah, it would be great to save this space.

TDebs are based on the .deb format, it is only a small change in the
organisation of the data.tar.gz but it simplifies various stages of
handling the resulting packages in the repository, in upload rules and
in other support tools.
Well, without details, I can't approve wholeheartedly, but if this isn't 
reinventing the wheel for no reason, the specification looks fine.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re: DEP-4: The TDeb specification.

[Filipus Klutiero]

On Fri, 03 Apr 2009 04:21:59 -0400
Filipus Klutiero  wrote:

> That would be a nice improvement, but let me suggest another 
> implementation. To avoid introducing a second diff, why not updating the 
> regular diff (in the case of non-native packages) but indicating that 
> the package shouldn't be entirely rebuilt when uploading? This seems 
> simpler.


That breaks the existing source package in Debian - the .dsc referring
to that .diff.gz has been signed by the maintainer and any changes will
break that signature.
  
Right - unless the .dsc is also updated. And if there is to be a tdiff, 
I don't see why .dsc-s wouldn't include the tdiff's digest.

TDebs are not related to source changes and
should not affect the existing source package. A TDeb upload needs to
sit alongside the existing files in the archive, not replace files
uploaded by the maintainer. This allows TDeb uploads during a release
freeze - even very late in a release cycle (which is the very time
that many debconf translations get updated currently).
  
That's the question. I don't see why adding a new diff would ease 
testing transition compared to updating the existing diff - given that 
the "traditional"/current binary packages aren't rebuilt when uploading 
translation updates.
> > > What is the purpose of creating a new binary package format for this (as 
> > > opposed to reusing, say, the deb format)?

> >
> > To support easier management of the translations, including allowing
> > users to only install the translations that are needed for one
> > particular installation, instead of every user getting every
> > translation for every package they install, whether those translations
> > are even supported or not.

> There are two ways to achieve this. One is per-language packages, the 
> other is localization packages with multiple languages but using 
> something like dpkg class support. Currently, the only way supported is 
> language packages, but introducing a new package format will not 
> necessarily allow the second way. Implementing this would take about the 
> same amout of work as implementing something like dpkg class support for 
> the deb file format.


? It's already implemented via a patch devised by Thomas Viehmann.
  

Great. Then it should be little work to implement the same for .deb.

[...]

> > TDebs are based on the .deb format, it is only a small change in the
> > organisation of the data.tar.gz but it simplifies various stages of
> > handling the resulting packages in the repository, in upload rules and
> > in other support tools.

> Well, without details, I can't approve wholeheartedly, but if this isn't 
> reinventing the wheel for no reason, the specification looks fine.


The DEP does describe the organisation of the data.tar.gz:
http://dep.debian.net/deps/dep4/#index5h2

Which details are missing from the DEP?
  
The data.tar.gz is correctly described, yes. The details I was referring 
to are the simplifications of "various stages of handling the resulting 
packages in the repository, in upload rules and in other support tools" 
you were talking about. These details don't need to be part of the 
specification, but could be somewhere in the DEP or in its presentation.

If you're actually asking to see the code, the changes were also put
into http://git.debian.org/?p=users/codehelp/dpkg.git;a=summary
  

No, I'm not asking to see the code...

[...]


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re: Gratituous dependences among packages

[Filipus Klutiero]

What purpose is served by the existence of kde (the metapackage)?
  
kde is the package which administrators who want to try KDE should 
generally install.

Is there a reason why not to clarify its meaning by renaming it as
'kde-full'
kde doesn't depend on the full KDE (for example, it doesn't depend on 
KDevelop).

 and having a 'kde-slim' package which includes the entire kde
minus development, games, texlive and other heavyweights?
I think it's late to suggest it.  For the development packages, that is 
kdewebdev, see #401862, which is solved in experimental. kde will 
recommend kdewebdev. Maybe it should be downgraded further to a 
suggestion. The tex issue will be resolved with okular replacing kdvi, 
which should happen during squeeze's development.



That leaves games, but I don't think it's worth creating a new 
metapackage for that.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re: DEP-4: The TDeb specification.

[Filipus Klutiero]

Neil Williams wrote:

On Fri, 03 Apr 2009 16:45:46 -0400
Filipus Klutiero  wrote:

[...] <http://www.emdebian.org/media/debian-media/>

> > > That would be a nice improvement, but let me suggest another 
> > > implementation. To avoid introducing a second diff, why not updating the 
> > > regular diff (in the case of non-native packages) but indicating that 
> > > the package shouldn't be entirely rebuilt when uploading? This seems 
> > > simpler.

> >
> > That breaks the existing source package in Debian - the .dsc referring
> > to that .diff.gz has been signed by the maintainer and any changes will
> > break that signature.

> Right - unless the .dsc is also updated. And if there is to be a tdiff, 
> I don't see why .dsc-s wouldn't include the tdiff's digest.


There will be a complementary dsc using the +t1 version suffix.

That can work, though I don't see what you were trying to say.

[...]

> > > > > What is the purpose of creating a new binary package format for this (as 
> > > > > opposed to reusing, say, the deb format)?

> > > >
> > > > To support easier management of the translations, including allowing
> > > > users to only install the translations that are needed for one
> > > > particular installation, instead of every user getting every
> > > > translation for every package they install, whether those translations
> > > > are even supported or not.
> >
> > > There are two ways to achieve this. One is per-language packages, the 
> > > other is localization packages with multiple languages but using 
> > > something like dpkg class support. Currently, the only way supported is 
> > > language packages, but introducing a new package format will not 
> > > necessarily allow the second way. Implementing this would take about the 
> > > same amout of work as implementing something like dpkg class support for 
> > > the deb file format.

> >
> > ? It's already implemented via a patch devised by Thomas Viehmann.
> >   
> Great. Then it should be little work to implement the same for .deb.


Package management tools need a way to tell a .deb from a .tdeb - the
two need to be handled differently by tools like dak, britney, apt,
dpkg, reprepro, deb-gview and others.
Do you mean that package management tools need a way to tell a 
traditional/current .deb from a package containing what the DEP proposes 
to put in a .tdeb? If you're only talking about the tdeb format per se, 
I don't understand your reasoning.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

tdiff (DEP-4: The TDeb specification.)

[Filipus Klutiero]

Neil Williams wrote:

On Mon, 06 Apr 2009 01:13:19 -0400
Filipus Klutiero  wrote:

> > > > > That would be a nice improvement, but let me suggest another 
> > > > > implementation. To avoid introducing a second diff, why not updating the 
> > > > > regular diff (in the case of non-native packages) but indicating that 
> > > > > the package shouldn't be entirely rebuilt when uploading? This seems 
> > > > > simpler.


That also involves separate handling for native vs non-native packages.
The DEP does not require that - the +t1.diff.gz is used for native and
non-native. Any changes to the .diff.gz (or .tar.gz for native
packages) uploaded by the maintainer would require a source rebuild in
order to maintain the integrity of the archive - that is precisely what
the DEP is trying to avoid. You can't have a source package in a state
that says "this isn't the source we actually used to build the binary".
The source to build the .deb needs to be unchanged.
Yes, but the source package contains more than the source used to build 
the "traditional" binary packages. It also contains (potentially) source 
for translation debs. As long as the only source changed is the source 
for the translation debs, the "traditional" binary packages don't need 
to be rebuilt.

The changes made to
generate the .tdeb need to sit alongside the existing source package
and have absolutely no effect on anything related to the binary
packages or the source package uploaded by the maintainer.
  
Per what I wrote above, I don't see anything preventing the source 
changes for translation debs to be integrated in the traditional diff 
(again, in the case of non-native packages).

> > > > That breaks the existing source package in Debian - the .dsc referring
> > > > to that .diff.gz has been signed by the maintainer and any changes will
> > > > break that signature.
> >
> > > Right - unless the .dsc is also updated. And if there is to be a tdiff, 
> > > I don't see why .dsc-s wouldn't include the tdiff's digest.

> >
> > There will be a complementary dsc using the +t1 version suffix.

> That can work, though I don't see what you were trying to say.

That there should be no update to the .dsc because the existing source
package must not be altered, therefore the second .dsc with the +t1
version suffix. In the case of a TDeb update during a release
freeze, the .dsc signed by the maintainer is already part of testing so
the TDeb upload to unstable must not change that .dsc.
I don't see a problem preventing the traditional .dsc to be changed. 
Changing the .dsc does not imply that the existing source package must 
be altered. The .dsc could be updated in testing.

(Whether the
+t1.dsc is retained is a different issue - I suspect that we only
actually need to retain the +t1.diff.gz but as any .dsc is tiny, it
isn't a big issue either way.)

I think it should be retained; small issue, indeed.


To sum up, I still don't see anything that imposes introducing a tdiff, 
even to avoid rebuilding the traditional binary packages. But, I'm 
starting to see tdiff is probably a good idea anyway for security reasons.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

.tdeb format (DEP-4: The TDeb specification.)

[Filipus Klutiero]

> > Package management tools need a way to tell a .deb from a .tdeb - the
> > two need to be handled differently by tools like dak, britney, apt,
> > dpkg, reprepro, deb-gview and others.

> Do you mean that package management tools need a way to tell a 
> traditional/current .deb from a package containing what the DEP proposes 
> to put in a .tdeb? 


In a similar way to udebs. The .tdeb needs to be handled differently by
package management tools (things like reprepro and dak) so that uploads
of TDebs can be made by translation teams, so that the existing source
package is not affected, so that TDeb uploads can more easily be made
during a release freeze without causing problems for archive management
software and without needing the tools to look inside the TDeb or rely
solely on a version suffix.
  
Yes. I think a translation package could simply be identified by a 
control field.

Say
Translates: foo
or, if Translates would only list the source package,
Translation: Yes
> If you're only talking about the tdeb format per se, 
> I don't understand your reasoning.


Other tools may need to support the locale roots in the .tdeb - these
changes will be easier if the tool can rely on these only existing in
a .tdeb instead of occurring in random .debs but not in others.
  
But these locale roots would only exist in .tdeb-s. In .deb-s, there 
wouldn't be such locale roots. If we're wondering whether we should 
introduce a .tdeb format, we shouldn't reason that that there will be a 
need for .tdeb if .tdeb is introduced.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re: tdiff (DEP-4: The TDeb specification.)

[Filipus Klutiero]

On Tue, 07 Apr 2009 09:57:30 -0400
Filipus Klutiero  wrote:

(Could you add a blank line between the quoted reply and your content?
It makes the content easier for me to read. Thanks.)
  


I'll try to.

> Neil Williams wrote:
> > On Mon, 06 Apr 2009 01:13:19 -0400
> > Filipus Klutiero  wrote:
> >
> > > > > > > That would be a nice improvement, but let me suggest another 
> > > > > > > implementation. To avoid introducing a second diff, why not updating the 
> > > > > > > regular diff (in the case of non-native packages) but indicating that 
> > > > > > > the package shouldn't be entirely rebuilt when uploading? This seems 
> > > > > > > simpler.

> >
> > That also involves separate handling for native vs non-native packages.
> > The DEP does not require that - the +t1.diff.gz is used for native and
> > non-native. Any changes to the .diff.gz (or .tar.gz for native
> > packages) uploaded by the maintainer would require a source rebuild in
> > order to maintain the integrity of the archive - that is precisely what
> > the DEP is trying to avoid. You can't have a source package in a state
> > that says "this isn't the source we actually used to build the binary".
> > The source to build the .deb needs to be unchanged.
>
> Yes, but the source package contains more than the source used to build 
> the "traditional" binary packages. It also contains (potentially) source 
> for translation debs. As long as the only source changed is the source 
> for the translation debs, the "traditional" binary packages don't need 
> to be rebuilt.


But the source package would still be the wrong source for the binaries
that exist. The archive needs to contain the unique source package for
the binaries that exist, modifying the source without modifying the
binaries is not an option for legal reasons, as I understand it.
  


I don't understand. If you have a source package which contains the 
source for a set of binary packages A, and the source for a set of 
binary packages B. You can change B's source without affecting A's 
source. This allows an infinity of source packages for the same source 
of A. Changing the source package does not imply a change in A's source.

> > The changes made to
> > generate the .tdeb need to sit alongside the existing source package
> > and have absolutely no effect on anything related to the binary
> > packages or the source package uploaded by the maintainer.
>
> Per what I wrote above, I don't see anything preventing the source 
> changes for translation debs to be integrated in the traditional diff 
> (again, in the case of non-native packages).


Why treat the two differently?


I'm not sure I understand your question. In the case of a native 
package, there is no diff, so you can't integrate the source changes for 
translation debs there. In the case of a non-native package, orig is 
upstream's business, so you can't integrate the source changes for 
translation debs there. Unless you introduce a new file avoiding that, 
you need to integrate changes to native packages in the source tarball, 
and to integrate changes to non-native packages in the diff.

> > > > > > That breaks the existing source package in Debian - the .dsc 
referring
> > > > > > to that .diff.gz has been signed by the maintainer and any changes 
will
> > > > > > break that signature.
> > > >
> > > > > Right - unless the .dsc is also updated. And if there is to be a tdiff, 
> > > > > I don't see why .dsc-s wouldn't include the tdiff's digest.

> > > >
> > > > There will be a complementary dsc using the +t1 version suffix.
> >
> > > That can work, though I don't see what you were trying to say.
> >
> > That there should be no update to the .dsc because the existing source
> > package must not be altered, therefore the second .dsc with the +t1
> > version suffix. In the case of a TDeb update during a release
> > freeze, the .dsc signed by the maintainer is already part of testing so
> > the TDeb upload to unstable must not change that .dsc.
>
> I don't see a problem preventing the traditional .dsc to be changed. 
> Changing the .dsc does not imply that the existing source package must 
> be altered. The .dsc could be updated in testing.


If the .dsc is modified, the source package no longer matches the
binaries that are in the archive that were built from the old .dsc.
  


Why?

Just who/what is supposed to modify 

Re: Re: .tdeb format (DEP-4: The TDeb specification.)

[Filipus Klutiero]

Neil Williams wrote:

On Tue, 07 Apr 2009 10:23:37 -0400
Filipus Klutiero  wrote:

> > In a similar way to udebs. The .tdeb needs to be handled differently by
> > package management tools (things like reprepro and dak) so that uploads
> > of TDebs can be made by translation teams, so that the existing source
> > package is not affected, so that TDeb uploads can more easily be made
> > during a release freeze without causing problems for archive management
> > software and without needing the tools to look inside the TDeb or rely
> > solely on a version suffix.
> >   
> Yes. I think a translation package could simply be identified by a 
> control field.


Then every file-based operation has to query the contents of the file
to know how to handle it. TDebs are sufficiently different internally
that other tools can handle them more easily if the filename is clearly
indicative.

This is more important where there are lots of TDebs, so that is how
.tdeb came into the Specification. In Emdebian, a package can have
dozens of .tdeb files, obscuring the .deb files in a simple directory
listing. With the modifications for Debian TDebs after DebConf and the
resulting single TDeb per source package, this is not a problem for
archive listings but it could still be a problem for other tools.

> Say
> Translates: foo
> or, if Translates would only list the source package,
> Translation: Yes

I'm working on the patches for dpkg at the moment, I'm extending
Thomas' code to support 'dpkg -c' etc. and it is looking like a field
in DEBIAN/control will be necessary. I'm looking at putting a Languages:
field inside DEBIAN/control that lists the locale roots supported by
that TDeb. (The name of the field isn't material, Locale-roots: is more
accurate than Languages: but not as suitable IMHO.) This field will
be generated by dpkg-deb --tdeb -b so that it is always up to date.
However, if I find a better way of obtaining the data that can be
gleaned from using: `ar -t` with relevant parsing, then there will be no
need for the field, at least on the part of dpkg.

There is also a Package-Type: tdeb field which is used by
dpkg-genchanges in the same way as Package-Type: udeb is done currently.
  


Ah, I never heard about that. That sounds better than my suggestions.

I don't see that either of those predicate against a .tdeb extension
when .udeb exists for the same reasons.
  


Neither do I. I'm sorry if I've been unclear, but I never meant to say 
anything about the naming of translation deb files. I was only 
questioning the introduction of a new package format.


[...]


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Google Summer of Code 2009: Debian's Shortlist

[Filipus Klutiero]

Obey Arthur Liu wrote:

=== And the details: ===
  

[...]

These descriptions are very short. Assuming these are the abstracts, 
that's not the students' fault. The abstracts were shortened this year 
to 500 characters. I struggled to shorten mine to fit this. At this 
length, it's probably impossible to fit a decent summary of most 
projects. It would normally make sense to use abstracts for this use 
case. Maybe Google should be asked to change the limit. Otherwise I'd 
like to see a custom description which describes a little further. I 
currently can't comment on all projects presented.


That said, this shortlist remains useful, and I thank you for this great 
jump in transparency.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

KDE/Qt Package Manager (Re: Google Summer of Code 2009: Debian's Shortlist)

[Filipus Klutiero]

Obey Arthur Liu wrote:

* KDE/Qt4 Adept 3.0 Package Manager *
-
Student: Mateusz Marek, Mentor: *NEEDS MENTOR, see below.*

Finish Adept 3.0, a fully integrated package manager for Qt4/KDE4.
Adept is currently the only viable path to a Debian native package
manager on KDE that would support modern features such as tags, indexed
search or good conflict resolving. With Aptitude-gtk still in
development and only available for GTK+ and (K)PackageKit having
fundamental problems, Debian needs this project to stay in control of
its package management on KDE after much neglect in the recent years.
  
At the risk of repeating myself, what are the fundamental problems in 
(K)PackageKit?


I have no issue with Adept, and I would love to see a good Qt/KDE 
package manager, but if we're to get KPackageKit, I'd like to be sure 
that we won't sponsor yet another APT front-end that won't be used.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Filed (Re: Preinstalled package manager(s) for PCs (wheezy))

[Filipus Klutiero]

This didn't generate as much feedback as I hoped, but I filed a ticket 
asking task-desktop to install synaptic: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667703



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f7e36d8.2080...@gmail.com

Re: Bug#671503: general: APT repository format is not documented

[Filipus Klutiero]

Could you clarify how this differs from #481129?


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fb3d965.5030...@gmail.com

Use cases for CD installs (Re: Wheezy release: CDs are not big enough any more...)

[Filipus Klutiero]

Steve Langasek wrote:

On Sun, May 13, 2012 at 10:26:13PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
>  On Dom 13 May 2012 21:40:10 Marco d'Itri escribió:
>  [snip]
>  >  Does anybody actually know that people routinely try to install desktop
>  >  systems with only a CD and no networking, and why?
>  >  What is the use case for this? Cheap DVD readers have been around for
>  >  over 10 years now.

>  Actually, I was going to ask exactly that. To the best of my knowledge,
>  CDROM players have been out of stock for a while (more than two years?)
>  Normally people will buy a DVDROM player.  Well, at least here in
>  Argentina :-/

>  Could it be reasonable to drop graphical desktops environments for one-CD
>  installs? If you want a GDE, get the DVD. Or two or more CDs.

As a data point, the 12.10 Ubuntu release, which is in about the same time
frame as wheezy, will not include a CD-sized desktop image.  After holding
this line for a long time, it's been decided that we've passed the point of
diminishing returns and that *slowly* allowing an increase in image size
(e.g., 800MB for this cycle instead of 736MB) allows us to define the
default install in terms of what's useful instead of just in terms of what
we can fit on a CD.

So to use the image you need either a DVD or a USB stick, and if you're
using a write-once DVD you're perhaps wasting the unused space; but the
download time and install footprint are still kept low and in the range of
what a CD would give.

Maybe worth considering something similar for Debian.


Interesting. I was going to suggest doing the same.

I do not know people regularly trying to install on desktop systems with 
only a CD drive and no (software) networking. I do use CD isos, however. 
I regularly download the KDE CD 1. The reason why I'm not using the 
netinst instead is that I save install time, and sometimes some download 
when I test the CD on several PCs. But, if I write the iso to a CD, 
that's only because I would need to stand up to reach the rewritable 
DVDs (due to an historical artifact of my desk's setup) and because I'm 
going to install to a machine where USB sticks are more painful to boot 
(but the last machine I had for which this was the case died recently).


So for me, the interest of CD 1 is that it approximates fairly well the 
package set I'm going to end up installing - more than either netinsts 
or DVD  1. If I had another media scoring equally well on that front, I 
would only consider fitting on a CD as an extremely marginally useful 
feature.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fb3efe4.2060...@gmail.com

Making mailing list discussions more viable (Re: Making -devel discussions more viable)

[Filipus Klutiero]

Hi Stefano, Russ and everyone,
thanks for your interest in this topic. I entirely agree that we should 
do better in this area. Since the discussion problem is not specific to 
debian-devel, I'm moving this to debian-project.


Stefano Zacchiroli wrote:

On Mon, Apr 30, 2012 at 10:11:23AM -0700, Russ Allbery wrote:
>  Given recent experiences, I'm also coming around to Ian's position that
>  aggressive and confrontational contributions from people who don't
>  otherwise seem to be contributing to Debian are part of the problem and
>  are not useful, and possibly should be banned.  I think that's been a
>  significant factor in the deterioration of the init system threads.

I agree that's a problem too and I share your feeling that it has been
particularly bad in recent discussions like the init system ones. To
look on the bright side, the problem seems concentrated in a few
specific topics rather than widespread to all discussions. But it is
still probably enough to keep some people from participating
constructively on -devel, which is a pretty serious problem.

>  I want our technical discussions to be welcoming to anyone who has
>  information to share and who can bring additional clarity and insight to
>  the discussion.  But once things start getting heated or people start
>  throwing around accusations or verge towards personal attacks, there's a
>  real psychological difference between people who are contributing to
>  Debian and people who aren't.


Agreed also on your reasoning about the psychological effects of non
constructive participation by non contributors.  Unfortunately, there
aren't many viable solutions to this kind of issues and all have
drawbacks.

1) our current solution: "don't feed the troll"

(even though the list participations we're talking about are not,
strictly speaking, trolling", that's basically our strategy)

It just doesn't work at this scale.

Sure, those who do respect the principle do reduce the noise (as
Bernhard pointed out), but you'll always have someone who will reply ---
maybe because they're new and accustomed to the list culture --- and it
is enough to have a few who do the feeding to make a discussion explode
and drive away people from it and, ultimately, decisions.

2) "don't feed the troll" + report abuses to listmasters and act
accordingly

I think we basically agree on the principle of this and IIRC we've even
discussed this about ~1 year ago without finding much opposition. But
either we're not doing this or it is not working.

Some of problems with this have been highlighted by Raphael. The
proposed fix, specifically for the "I don't know if I'm alone doing this
or not" part, sounds interesting.  But even with that fix, you still
have the social awkwardness problem: the feeling is that of "censoring"
someone and it's a hard to ignore feeling, because the act of doing that
is much more concrete than the perception of the long term benefits of
doing so. I've the impression that the bar for silencing someone will
always remain high, higher than what would be needed to avoid the
behavior we're discussing.

Another problem you'll have with this "solution" is that it consumes a
lot of community energy (the people reporting bad behavior, who will do
that only after reaching some high frustration level; and the
listmasters who'll need to put time and emotions in judging the
behavior, implementing and probably explaining the "sanction").

3) public, but contributors-only list

This has been implemented by other FOSS projects. A notable example is
Ubuntu who have a split between ubuntu-devel (project members only +
whitelisting) and ubuntu-devel-discuss (free for all). I've never asked,
but I have always suspected that they've done so in an attempt to
improve over the experience of debian-devel participants.

The obvious drawback of this "solution" is that non-contributors will
need someone to vouch for them to be whitelisted.

--

Each solution have advantages and disadvantages, but all in all I don't
think there aren't many other options. The question is blunt then: what
are we willing to give up of the current model in order to improve over
its defects?


There are many more approaches possible, and they can be combined.


 Improving what we write (educating)

The idea here is to help people avoid posting problematic content and/or 
to help people avoid posting content which tends to trigger problematic 
replies.



   General advice

This consists in writing guidelines which should be read by participants 
(for example "don't feed the troll").



   Specific advice

This is about offering customized advice to specific participants in need.


 Improving what we end up reading (filtering)

Here, we assume that problematic content will come and improve the 
discussion system to deal with it.


Approaches can be coercive or advisory. For example, excluding 
unapproved people from participating is coercive. Featuring messages 
from approved peop

Duplicate

[Filipus Klutiero]

reassign 481129 debian-policy
merge 481129 671503
thanks

On 2012-05-17 07:48, Michal Suchanek wrote:

Excerpts from Filipus Klutiero's message of Wed May 16 18:44:21 +0200 2012:

Could you clarify how this differs from #481129?

It's 4 years later.

Sorry, forgot that I filed the bug already. It's quite some time.



Merging the reports then.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fb52bc3.4090...@gmail.com

Mostly solved (was Re: Filed (Re: Preinstalled package manager(s) for PCs (wheezy)))

[Filipus Klutiero]

On 2012-04-05 20:20, Filipus Klutiero wrote:
This didn't generate as much feedback as I hoped, but I filed a ticket 
asking task-desktop to install synaptic: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667703


Joey Hess changed tasks to bring Synaptic in KDE, LXDE and Xfce. Only 
the GNOME situation is unchanged (Josselin Mouette alleged that gnome 
already pulls in Synaptic).

tasksel 3.10 should migrate to testing shortly.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4feb27ee.7060...@gmail.com

Apper instead of Synaptic for KDE (was Re: Mostly solved (was Re: Filed (Re: Preinstalled package manager(s) for PCs (wheezy))))

[Filipus Klutiero]

Hi Matthias,

On 2012-06-27 14:54, Matthias Klumpp wrote:

Hi!
How odd that I didn't notice that bug... (I'm the GPK/PK maintainer)
Well, I think pulling in Synaptic on KDE might be a bad idea, probably
KDE desktop packages should pull in Apper instead, a KDE package
manager based on PackageKit and fully integrated into the KDE desktop.
It does not provide all functions of Synaptic, but for most users it
will be good enough and KDE can avoid pulling in many GNOME packages.



Synaptic is at best just a little GNOME-ish, beyond its GTK-ness. In 
reality, installing Synaptic would install just a little more than Apper 
- perhaps. Apper probably does integrate with KDE, but this is a small 
advantage compared to the difference in maturity. I wouldn't be strongly 
against installing Apper by default, but replacing Synaptic is a bigger 
challenge.


[...]


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4feb7e59.7030...@gmail.com

MySQL is still in unstable (Re: Bug#593463 closed by Debian FTP Masters (Bug#680362: Removed package(s) from unstable))

[Filipus Klutiero]

Hi Alexander,

On 2012-07-05 11:58, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the mysql-server-5.1 package:

#593463: [phpmyadmin] Failed ALTER query reports success

It has been closed by Debian FTP Masters.

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Debian FTP 
Masters  by
replying to this email.




Although mysql-5.1 was indeed removed from unstable, MySQL wasn't. 
mysql-5.1 was simply removed because MySQL has a version number in 
source package names and the number changed. MySQL is now packaged as 
mysql-5.5: http://packages.qa.debian.org/m/mysql-5.5.html



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ffce8bd.3080...@gmail.com

NEWS.Debian entries intended for developers - backwards-incompatible changes in Perl HTML::Tree (Fwd: apt-listchanges news for vinci)

[Filipus Klutiero]

Hi,
Perl HTML::Tree 5 has backwards-incompatible interface changes. Version 
5.00-1 added a NEWS.Debian entry to warn about that. As the entry below 
shows, it is intended for developers (although it could actually make 
sense to warn users too that the interface is unversioned). But it also 
shows for simple users who have the library installed. I was in this 
case when libhtml-tree-perl migrated to testing and I upgraded my 
system. The operation was interrupted with a prompt which requested my 
intervention (I use apt-listchanges). I simply use Gnucash, and find 
this warning unnecessary. The problem is that this library doesn't have 
a binary package and a development package; everything is in the same 
package. The proportion of people with libhtml-tree-perl using the 
package for development must be very small, and I don't think this entry 
is worth the noise. On the other hand, it's not completely worthless. Do 
we have guidance on NEWS.Debian usage, giving advice for such situations?


 Original Message 











libhtml-tree-perl (5.00-1) unstable; urgency=low

  [THINGS THAT MAY BREAK YOUR CODE OR TESTS]
  * Use weak references to avoid memory leaks
See "Weak References" in HTML::Element for details.
  * new_from_file now dies if the file cannot be opened.  $! records
the specific problem.  (Previously, you got a tree with a few
implicit elements.)
  * Some methods normally returning a scalar could return the empty
list in certain circumstances.  This has been corrected.  The
affected methods are: address, deobjectify_text, detach, is_inside,
&  pindex.
  * deprecate the Version sub/method.  Use the VERSION method instead.

 -- gregor herrmann   Fri, 15 Jun 2012 14:50:32 +0200