[MovieZen] - Check out this website!

[Ankur Gupta]

Hi debian-devel@lists.debian.org 

Ankur Gupta has invited you to join as a friend at MovieZen.

http://www.moviezen.com/connect/6621460-da33dfc2-74856577 

About MovieZen:
MovieZen is a website where you can rate movies, share reviews with
friends, and meet people that have similar taste.


You have received this email because Ankur Gupta ([EMAIL PROTECTED])
directly invited you to join his/her community on MovieZen.


MovieZen - http://www.moviezen.com/


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

Re: Backport of debhelper

[Joerg Jaspert]

On 11286 March 1977, Thomas Goirand wrote:

> I saw that there is now a new debhelper package version 6 in SID. I have
> been told by my sponsor to have a dependency to it, and set my
> compatibility level to 6. This is quite ok, but I need to maintain my
> package for Etch. I did a quick backport of debhelper from SID on my
> laptop, and it doesn't seems to be causing any trouble.

Do not follow the advice of that sponsor, look for a different sponsor
instead. Only ever update the debhelper dependency if you really use a
feature of the new version.


-- 
bye Joerg
graphviz (old license)
[...]
Changes
  * Burn it! Burn it all!! 


pgpyOv8CyXGbM.pgp
Description: PGP signature

shlibs vs symbols?

[Paul Wise]

Hi all,

I was reviewing a library package RFS (libthai) and I noticed that the
shlibs pointed at version X and all the symbols in the symbols file
pointed at an earlier version. Here I assume that the shlibs should be
changed to point to the earlier version?

Then I had a look at the 26 (out of ~5944) library packages on my system
using symbols and found similar things:

libffi4: shlibs 4.3, symbols max 4.2.1
libaa1: shlibs 1.2, symbols all 1.4p5
libgomp1: shlibs 4.3, symbols max 4.2.1
libgpewidget1: shlibs no version, symbols max 0.115 min 0.88
libgstreamer-plugins-base0.10-0: shlibs 0.10.17, symbols max 0.10.16
libgstreamer0.10-0: same as ^^
libgtkspell0: shlibs 2.0.2, symbols all 2.0.10
libogg0: shlibs 1.1.3, symbols max 1.1.0, 2 removed symbols 
libqof-backend-qsf0: shlibs no version, symbols all 0.7.3, changelog goes way 
back
libqof1: shlibs no version, symbols all 0.7.2, changelog goes way back
libtheora0: shlibs no version, symbols min 0.0.0.alpha7.dfsg-1.1 max 1.0~beta1-1
libvorbisenc2: shlibs 1.2.0.dfsg, symbols all 1.1.2

Am I correct in thinking that either the shlibs or the symbols for some
of these are wrong?

If so, I guess I should file wishlist bugs for lintian tests for some of
these situations?  Like shlibs too cautious, shlibs too relaxed, symbols
not produced from enough versions.

Also, does mole use packages from oldstable or the morgue or
snapshot.d.n to create the symbols file it distributes?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

debhelper compat levels (was: Backport of debhelper)

[Joerg Jaspert]

[forced change to debhelper v6 compat]
> Do not follow the advice of that sponsor, look for a different sponsor
> instead. Only ever update the debhelper dependency if you really use a
> feature of the new version.


Now, as this raised some comments on IRC, lets clarify it a bit:

- compat mode v1 to v3 is definitely something to change away from, they
  are deprecated

- everything above:
  - try to stick to the highest compat level that was supported in the
last stable release. You make live of backporters[1] a whole lot
easier.

  - use newer compat levels only if the used level gets deprecated
or if you use a feature only available in newer debhelpers.

- New packages should start with the latest recommended version.

The same can be said about versioned dependencies on debhelper.

[1] No matter if its for backports.org or someone rebuilding a package
for own usage somewhere else. and while its possible to backport
debhelper too or change the compat level in the backport, that just adds
an extra burden to the backporter, which is MANY times unneeded.


At least that are my 2¢ to this.

-- 
bye Joerg
Die Dicke zum Spiegel: Spieglein, Spieglein an der Wand, wer ist die
Schönste im ganzen Land?
Der Spiegel: Geh doch mal weg, ich kann ja gar nichts sehen!


pgp0nTGPUgAIf.pgp
Description: PGP signature

Re: shlibs vs symbols?

[Raphael Hertzog]

Hi,

On Tue, 05 Feb 2008, Paul Wise wrote:
> I was reviewing a library package RFS (libthai) and I noticed that the
> shlibs pointed at version X and all the symbols in the symbols file
> pointed at an earlier version. Here I assume that the shlibs should be
> changed to point to the earlier version?

No. It's quite common for maintainers to use dh_makeshlibs -V and always
generate a dependency on the latest upstream version. The dependency is
too strong most of the times, but's it's not a bug. Furthermore, if they
have a symbols file, it's even less important since the information from
symbols files take precedence.

> libaa1: shlibs 1.2, symbols all 1.4p5

Given that 1.4p5 is the version in oldstable too, this doesn't change
anything.

> libgpewidget1: shlibs no version, symbols max 0.115 min 0.88
> libtheora0: shlibs no version, symbols min 0.0.0.alpha7.dfsg-1.1 max 
> 1.0~beta1-1

Here one could argue that the shlibs file is broken since >= 0.115 ought
to be used in the shlibs (since some symbols have been introduced by
0.115). Same for libtheora.

> libgtkspell0: shlibs 2.0.2, symbols all 2.0.10

2.0.10 is in oldtsbale => non-issue

> libogg0: shlibs 1.1.3, symbols max 1.1.0, 2 removed symbols

Removed symbols ought to be stripped by the maintainers in the symbols
files that they provide...

> libqof-backend-qsf0: shlibs no version, symbols all 0.7.3, changelog goes way 
> back
> libqof1: shlibs no version, symbols all 0.7.2, changelog goes way back

Strange, stable has 0.7.1... and lack of version in shlibs is probably a
bug, but one that can't be triggered except by building on etch with a
dpkg-dev that doesn't support symbols files yet.

> Am I correct in thinking that either the shlibs or the symbols for some
> of these are wrong?

In theory yes, in practice it's useless to require both to be in sync.
What's important is that symbols files match reality. 

And symbols file can have too high versions, it doesn't hurt much when the
given version is already in oldstable/stable.

> If so, I guess I should file wishlist bugs for lintian tests for some of
> these situations?  Like shlibs too cautious, shlibs too relaxed, symbols
> not produced from enough versions.

IMO this is a bad idea. There's no requirement that symbols files include
history up to oldstable... and like I said, shlibs are no more used when
you have symbols files, so a too-strong shlibs is ok given that it's only
used in the rare cases when an old dpkg-dev is used (backports).

> Also, does mole use packages from oldstable or the morgue or
> snapshot.d.n to create the symbols file it distributes?

No.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: How to cope with patches sanely

[Adam Borowski]

On Tue, Feb 05, 2008 at 12:34:08AM -0600, Manoj Srivastava wrote:
> >> On Thu, 2008-01-31 at 10:54:11 +0100, Pierre Habouzit wrote:
> >> >   Of course, that would mean that the few debian/rules (hi Manoj)
> >> > in Debian not being makefiles [...]
> What do you mean, still? I have never used anything but make in
>  my rules files; indeed, I was the one who has (over the objections of a
>  few people) maintained that the policy of requiring Make files make
>  sense.
> 
> I do have Perl maintainer scripts, though.

Hmm... I think that maybe Joey Hess uses such scripts, too.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: How to cope with patches sanely

[Matthew Johnson]

On Tue Feb 05 00:51, Manoj Srivastava wrote:
> > If we can't figure out a good and clean way to keep a large stack of
> > long-lived patches in the vcs then I firmly believe we should
> > standardize on quilt.
> 
> I think I have indeed solved the issue of long standing feature
>  sets using feature branches, integration branches, and sloppy branches
>  while upgrading, and would not want to be forced to regress to a patch
>  system. 
> 
I don't think anyone is talking about forcing DVCS users to regress to a
patch system, merely to change the interchange format; which all
DVCS-based maintenance methods can easily export to/import from. The
only reason which you would have to interact with it would be a more
standard interface for NMUs, which can only be a good thing.

I am against patch system users being forced to changed to a DVCS
system, however, which _has_ been suggested. (It may be technically
superior, but let me change when I'm ready by demonstrating the
virtues and providing tutorials, don't force me to use it because it's
the new source format)

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: How to cope with patches sanely

[Miles Bader]

Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Umm. Why would any distributed version control system always
>  need history truncation?  I am not even sure that arch has such a
>  thing; and I have never felt the need for such a beast.
>
> A distributed VCS that bundles in the whole archive in every
>  checkout might well need that, but not all distributed VCS systems do
>  that.

I wouldn't be surprised if arch took as much room to store log files
({arch}/...) as e.g. git takes to store the actual content of historical
revisions.  Deleting those log files is arch's version of "history
truncation".

[Not that I've actually felt the need to do so, but they do take up a
lot of room...]

-Miles

-- 
.Numeric stability is probably not all that important when you're guessing.


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

Re: Intend to hijack rrdtool

[Sebastian Harl]

Hi,

On Tue, Feb 05, 2008 at 12:41:24AM +0100, Bernd Zeimetz wrote:
> If there are no objections I want to upload a new and heavily overworked
> package in about two weeks

I cannot image that there are any real objections. There was only a
single non-NMU upload since the beginning of 2005 and that upload
happened almost one year ago while there is plenty of work to do (as you
already stated in Bernd's E-mail).

Please go ahead and hijack it.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Re: How to cope with patches sanely

[Ben Finney]

Matthew Johnson <[EMAIL PROTECTED]> writes:

> I am against patch system users being forced to changed to a DVCS
> system, however, which _has_ been suggested.

I've not seen that suggested in this thread. Can you give a reference,
please?

What I've seen, that might be confused with the above, is:

  * arguments against patch systems on the basis of forcing others to
use those specific tools; followed by requests;

  * arguments for DVCS workflows on the basis that they provide the
advantages of tracking changes without forcing others to know the
specific tool used;

  * requests from, and responses to, people wanting to know how a DVCS
workflow can do this.

-- 
 \   "Everything you read in newspapers is absolutely true, except |
  `\for that rare story of which you happen to have first-hand |
_o__) knowledge." —Erwin Knoll |
Ben Finney


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

Re: Backport of debhelper

[Roberto C . Sánchez]

On Tue, Feb 05, 2008 at 09:41:56AM +0100, Joerg Jaspert wrote:
> On 11286 March 1977, Thomas Goirand wrote:
> 
> > I saw that there is now a new debhelper package version 6 in SID. I have
> > been told by my sponsor to have a dependency to it, and set my
> > compatibility level to 6. This is quite ok, but I need to maintain my
> > package for Etch. I did a quick backport of debhelper from SID on my
> > laptop, and it doesn't seems to be causing any trouble.
> 
> Do not follow the advice of that sponsor, look for a different sponsor
> instead. Only ever update the debhelper dependency if you really use a
> feature of the new version.
> 
I was the one who provided that advice.  (Thomas, do feel free to ignore
the advice and stick with debhelper 5).

Joerg, I developed the opinion that debhelper level 6 should be used
about the time I started helping out with pkg-perl team package uploads.
Debhelper 6 had come out it was discussed in #debian-perl that perhaps
the team should updated its packages as new uploads were performed.
Additionally, the changelog of debhelper [0] seems to recommend using
the new compatibility level.  I figured since it was fine for the Debian
Perl Group, it should be OK for others.  In any event, perhaps the
advice you provide in your other mail in this thread should be included
in the Debian developer reference.

Regards,

-Roberto

[0] 
http://packages.debian.org/changelogs/pool/main/d/debhelper/debhelper_6.0.5/changelog#versionversion6.0.0

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: How to cope with patches sanely

[Lars Wirzenius]

On ti, 2008-02-05 at 12:07 +, Matthew Johnson wrote:
> Also: * The package format should be standardised such that the same
> workflow works for everyone.

If that's a reference to my first post to this discussion, it's not
accurate. I don't care about standardizing package formats, but I do
want to have one, simple sequence of operations to work on all packages.
Specifically I want "dpkg-source -x" to unpack a source package so that
it is ready for modification, and "dpkg-source -b" to build a new source
package after it's been edited. Patch systems can and should conform to
that, since it's important for those doing archive-wide QA.



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

Re: How to cope with patches sanely

[Matthew Johnson]

On Tue Feb 05 22:43, Ben Finney wrote:
> Matthew Johnson <[EMAIL PROTECTED]> writes:
> 
> > I am against patch system users being forced to changed to a DVCS
> > system, however, which _has_ been suggested.
> 
> I've not seen that suggested in this thread. Can you give a reference,
> please?
> 
> What I've seen, that might be confused with the above, is:
> 
>   * arguments against patch systems on the basis of forcing others to
> use those specific tools; followed by requests;
> 
>   * arguments for DVCS workflows on the basis that they provide the
> advantages of tracking changes without forcing others to know the
> specific tool used;

Also: * The package format should be standardised such that the same
workflow works for everyone.

This implies to me that those who dislike patch systems and like DVCS
workflows wish to standardise on the latter. I don't see how someone who
wants to deal with patches can do that, whereas I can see how DVCS users
can continue their workflow, but still have a patch system in the source
format.

(I would go through and get references, but it's a long thread, and I
 should be working. Sorry)

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Bug#457263: dialog: Please build with -fPIC

[Santiago Vila]

Hello.

Policy says I should ask here before I add -fPIC to dialog.

So: May I build libdialog using -fPIC?

My idea is to do this now, document which packages use it in a README,
and if athe number of packages using it grows, consider the shared library.

Thanks.


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

Re: How to cope with patches sanely

[Matthew Johnson]

On Tue Feb 05 14:16, Lars Wirzenius wrote:
> On ti, 2008-02-05 at 12:07 +, Matthew Johnson wrote:
> > Also: * The package format should be standardised such that the same
> > workflow works for everyone.
> 
> If that's a reference to my first post to this discussion, it's not
> accurate. I don't care about standardizing package formats, but I do
> want to have one, simple sequence of operations to work on all packages.
> Specifically I want "dpkg-source -x" to unpack a source package so that
> it is ready for modification, and "dpkg-source -b" to build a new source
> package after it's been edited. Patch systems can and should conform to
> that, since it's important for those doing archive-wide QA.

I agree with that, however the discussion following that had lots of
people (at least to me) saying that this set of operations should be a
DVCS workflow. If I've misinterpreted that then I'm sorry to whoever
I've inadvertently maligned (-:

Standardising NMU/QA workflow is good. I just don't think it should
involve invoking any sort of VCS and knowing how the merging works.

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: How to cope with patches sanely

[Pierre Habouzit]

On Tue, Feb 05, 2008 at 06:34:08AM +, Manoj Srivastava wrote:
> On Mon, 04 Feb 2008 22:24:09 +0100, Pierre Habouzit <[EMAIL PROTECTED]> said: 
> 
> > On Mon, Feb 04, 2008 at 08:02:42PM +, Guillem Jover wrote:
> >> On Thu, 2008-01-31 at 10:54:11 +0100, Pierre Habouzit wrote:
> >> >   Of course, that would mean that the few debian/rules (hi Manoj)
> >> > in Debian not being makefiles [...]
> 
> >> You were probably thinking about Josip (and now the VDR team):
> >> 
> 
> >   Damn, I was pretty sure Manoj still had some custom perl things, but
> > I stand corrected :)
> 
> What do you mean, still? I have never used anything but make in
>  my rules files; indeed, I was the one who has (over the objections of a
>  few people) maintained that the policy of requiring Make files make
>  sense.
> 
> I do have Perl maintainer scripts, though.

  Yeah I got confused with that, nvm
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpw39h5WmUlM.pgp
Description: PGP signature

Re: How to cope with patches sanely

[Ben Finney]

Matthew Johnson <[EMAIL PROTECTED]> writes:

> Also: * The package format should be standardised such that the same
> workflow works for everyone.

Not necessarily the pacakge *format*. The request you seem to be
referring to was that of Lars, when he requested that a specific
sequence of operations should work for every source package. That's an
issue of the *interface*, much more than the format.

Currently, that request is fullfillable with either of "don't track
changes, mix everything into foo.diff.gz" or "track changes in a VCS,
use automated tools to build foo.diff.gz when building the source
package". It is not met by patch bundle systems.

> This implies to me that those who dislike patch systems and like
> DVCS workflows wish to standardise on the latter.

Not that I've seen, no. What I have seen is the argument that a
VCS-based workflow doesn't impose the internal workings on the
one-time source modification contributor the way that patch bundle
workflows do.

This has accordingly been held up as an advantage of VCS-based
workflow, with which I agree.

I've not seen it held up as an argument to force anyone to use a
specific tool or workflow, and with that I would disagree.

-- 
 \  "Whatever you do will be insignificant, but it is very |
  `\important that you do it." —Mahatma Gandhi |
_o__)  |
Ben Finney


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

Re: Proposition: 'NMU' upload of wxwidgets 2.8

[Richard Hartmann]

On Feb 4, 2008 6:24 PM, Ron <[EMAIL PROTECTED]> wrote:


> Richard, please don't profess to speak for me -- especially not couched
> in terms such as "more or less".  There were several things that people
> tried to explain to you in that discussion that you 'more or less'
> refused to accept, so please don't muddy the waters further by spreading
> more misunderstanding.

I did not profess to speak for you, I am well aware you can do so,
yourself.
What I did was summarize the proceedings of a discussion for the benefit
of the people who did not see it or even knew it took place. If both
sides, being mainly represented by you and me respectively, walk away
from a discussion unhappy, 'more or less' is a valid and helpful
qualifier that emphasizes the disagreement while not blaming either
party.

That being said, let me address your points a last time as I fear we
are seeing the same patterns that have led into the current situation.

Namely, a total block of any progress related to wxwidgets 2.8, no
matter how many other packages would depend on it or have not even been
ITP'ed because of the 2.8 situation (I know of several).


>  1) People who have an interest in 2.8 contact Ron to work together.
>
> As we discussed, as I've said previously, and as Myon already announced
> once again, lets just start with this step shall we.  We can let the
> people actually doing the work make judgements on where it will go from
> there -- once some work actually gets done and is suitably reviewed.

To quote myself for the benefit of people reading this mail:

> 2) People are free to upload 2.8 as a separate package without him
>minding the fact that his namespace is impacted, as he does not
>currently plan to package 2.8 anyway, preferring to wait for 3.0.

To quote Myon:

< Myon> RichiH, Ron: I think we are seeing a classical case of talking
cross purposes
< Myon> so let's step back and see if people will actually do stuff
< Myon> RichiH: let's accept Ron's word that he's trying people to
help. The "problem" now is that he does BTS-cleaning by closing bugs
which annoyed some people. Good faith, bad impression
< Myon> or something, I don't think there's anything left to discuss
now and here
< Myon> we just need someone (Ron and/or others) to do the work

This implies both option 1) and 2).
Option 2) was the consensus of the majority of people involved in
#debian-devel at this time, by my count.


> I don't think many people were in agreement with your proposal that this
> should be some sort of open-slather free for all.  It is going to take
> quite an investment of time and effort for anyone who wants to attempt
> this to get (and more importantly, keep) it in a state where it might
> become part of the distro.

After going through my logs once more, I can say that that more people
were in favour of 'If it's not packaged, there is no way to actually
find out how it impacts Debian' and 'If someone is not willing to do
the work, someone else needs to be found', contrary to what you claim.

You imply that it is either you controlling all effort towards a goal
you do not want to achieve or an anarchistic congregation of people,
everyone commited to make things break. I resent that implication.
Especially as there are packages, created by other DDs, that work just
fine, at least for me and others I talked to.


> But anyone who thinks they are up for that, is indeed most welcome to
> get in touch with myself and the others who've shown an interest to
> date, to co-ordinate what they would like to do and how best to do it.
> I don't think having some random number of people acting in isolation
> will be sufficient to turn this into something usable.  If they exist,
> they need to get together and all help each other.

As you can see in your bug reports, several people claimed to be willing to
package outside of your control.

The main problem I see is that while you state you want to want to wait
for 3.0 and not package 2.8 at all, you still claim the right to
coordinate each and every effort to do just this, as can be seen by your
reply to grand-parent mail.  The only public effort in this direction I
could see is you removing all blocks from the RFP bug on wxwidgets 2.6
[1].

This has a chilling effect on potential uploaders, especially as this
situation needs something close to a NMU.


> Y'all know where to find us if you feel the itch.

Actually, at least I only know where to find you. Any other people you
are saying are working with you did not pipe up, yet.


In any case, this discussion is becoming pointless. The call for people
to upload this outside of your control has gone out, both on this list
and via private email. People will either follow it or not. I wouldi
just ask you to not try to keep others from doing the work you
repeatedly said you were unwilling to do.


If I do not reply to a potential reply by you, please do not
misunderstand this as an agreement from my side. I simply think that
everything t

Re: How to cope with patches sanely

[Matthew Johnson]

On Tue Feb 05 23:34, Charles Plessy wrote:
> Case 1: It is because all the changes were in the diff.gz.
> 
> Case 2: It is because a clean way of applying the contents of
> debian/patches has been developped and used.
> 
>   In that case, unless "dpkg-source -b" has been similarly engineered to
>   turn the new changes into a new patch, things will fail when
>   "debian/rules clean" calls the unpatch rule and the changes overlap an
>   existing patch.
> 
> Case 3: It is because the sources have been packed patched.
> 
>   In that case, "dpkg-source -b" is expected to work.

Don't forget:

Case 4: Some wig&pen or patches.tar.gz source format which can apply the
patches on unpack (maybe this is Case 2.5).

It solves the "don't trust debian/rules" problem.

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: How to cope with patches sanely

[Charles Plessy]

Le Tue, Feb 05, 2008 at 02:16:09PM +0200, Lars Wirzenius a écrit :

> Specifically I want "dpkg-source -x" to unpack a source package so that
> it is ready for modification, and "dpkg-source -b" to build a new source
> package after it's been edited. Patch systems can and should conform to
> that, since it's important for those doing archive-wide QA.

Hi Lars,

thank you for keeping us focused on the real problem. I have been trying
to think about it and still did not find an elegant solution. Suppose
that, as discussed earlier, "dpkg-source -x" provides source ready for
modification:

Case 1: It is because all the changes were in the diff.gz.

Case 2: It is because a clean way of applying the contents of
debian/patches has been developped and used.

  In that case, unless "dpkg-source -b" has been similarly engineered to
  turn the new changes into a new patch, things will fail when
  "debian/rules clean" calls the unpatch rule and the changes overlap an
  existing patch.

Case 3: It is because the sources have been packed patched.

  In that case, "dpkg-source -b" is expected to work.

Now, let's remember the use case for these scenarii: it is when the
packages is modified for NMU or QA. If the NMU'ed package is to go back
in the hands of its maintainer (not MIA or so busy that he can not do
more than one upload per year, of course), as I wrote earlier, why not
simply send a diff in a bug report? Then the work overhead of
integrating the changes in the source package goes to the person who
chose the packaging workflow.

Otherwise, let's sees what happens with Cases 2 and 3. In Case 3, the
changes that you would make would be hidden in a diff.gz file that would
be bloated by design: it would already contain a mixture of
modifications to the source and patches shipped as patches to a patch.
For the maintainer, the most efficient tool to recover your changes from
this would be a debdiff with the old version, which then calls the
question of why just sending a diff instead of producing a new source
package would not be enough.

The easier scenario is of course the variant of Case 2 in which where a
automagic dpkg-source would take care of detecting the patch system and
turn your modifications into a new patch. But I have not seen any person
volunteer for working on such a modification.

So maybe the simplest solution would be the following :

 - Standardize the name of the patch rule so that "debian/rules patch"
   does the job.
 - dpkg-source -b && debian/rules patch
 - make a diff and send it to the BTS.

or, in the case of unmaintained packages:

 - get rid of the patch system if you think that it is not good for QA
   work on it.

It leaves the problem of trusting the command "debian/rules patch" when
working on non-official packages, but as I wrote before, the other
targets of debian/rules would have to be audited anyway, so why not
checking them first, and then run "debian/rules patch" ? (or decline to
sponsor the work of persons storing their changes in debian/patches).


Of course, I would be very interested to hear better solution, because
as I wrote, this one is not particularly elegant.

Have a nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan


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

Re: Bug#464159: ITP: ktsuss -- gtk wrapper for su

[David Paleino]

Hi Yves-Alexis,

Il giorno Tue, 05 Feb 2008 16:09:27 +0100
Yves-Alexis <[EMAIL PROTECTED]> ha scritto:

> * Package name: ktsuss
>   Version : 1.2
>   Upstream Author : David B. Cortarello <[EMAIL PROTECTED]>
> * URL : http://developer.berlios.de/projects/ktsuss
> * License : BSD
>   Programming Lang: C
>   Description : gtk wrapper for su
> 
> ktsuss stands for "keep the su simple, stupid", and as the name says, is a
> graphical version of su written in C and GTK+ 2

And the main differences with gtksu are...? Just keeping simple?

David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Bug#464159: ITP: ktsuss -- gtk wrapper for su

[Yves-Alexis]

Package: wnpp
Severity: wishlist
Owner: [EMAIL PROTECTED]


* Package name: ktsuss
  Version : 1.2
  Upstream Author : David B. Cortarello <[EMAIL PROTECTED]>
* URL : http://developer.berlios.de/projects/ktsuss
* License : BSD
  Programming Lang: C
  Description : gtk wrapper for su

ktsuss stands for "keep the su simple, stupid", and as the name says, is a
graphical version of su written in C and GTK+ 2


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)



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

Re: Bug#464159: ITP: ktsuss -- gtk wrapper for su

[Yves-Alexis Perez]

On Tue, Feb 05, 2008 at 03:41:46PM +, David Paleino wrote:
> And the main differences with gtksu are...? Just keeping simple?

Not depending on gnome stuff. See thread on -release (about su-to-root).
-- 
Yves-Alexis


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

Re: Bug#464159: ITP: ktsuss -- gtk wrapper for su

[David Paleino]

Il giorno Tue, 05 Feb 2008 16:54:52 +0100
Yves-Alexis Perez <[EMAIL PROTECTED]> ha scritto:

> On Tue, Feb 05, 2008 at 03:41:46PM +, David Paleino wrote:
> > And the main differences with gtksu are...? Just keeping simple?
> 
> Not depending on gnome stuff. See thread on -release (about su-to-root).

Thank you for clarifying, I'm going to read that thread.

David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Bug#464169: ITP: vagalume -- A GTK+-based Last.fm client

[Alberto Garcia]

Package: wnpp
Severity: wishlist
Owner: Alberto Garcia <[EMAIL PROTECTED]>


* Package name: vagalume
  Version : 0.5
  Upstream Author : Alberto Garcia <[EMAIL PROTECTED]>
* URL : http://people.igalia.com/berto/
* License : GPL 3
  Programming Lang: C
  Description : A GTK+-based Last.fm client

Vagalume is a Last.fm client designed for the Gnome desktop
environment. It's small and provides the basic Last.fm features, such
as scrobbling, tags, recommendations, etc. Vagalume is also designed
to work in the Maemo platform, used by some Nokia devices such as the
Nokia 770, N800 and N810

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.23.14
Locale: LANG=pt_PT, LC_CTYPE=pt_PT (charmap=ISO-8859-15) (ignored: LC_ALL set 
to [EMAIL PROTECTED])



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

Re: Backport of debhelper

[Joerg Jaspert]

On 11286 March 1977, Roberto C. Sánchez wrote:

> In any event, perhaps the advice you provide in your other mail in
> this thread should be included in the Debian developer reference.

Want to write the wishlist bugreport?

-- 
bye Joerg
Debian is about free speech. beer once brewed can no longer be changed.


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

Bug#464182: ITP: librest-application-perl -- framework for building RESTful web-applications

[Frank Lichtenheld]

Package: wnpp
Severity: wishlist
Owner: Frank Lichtenheld <[EMAIL PROTECTED]>

* Package name: librest-application-perl
  Version : 0.992
  Upstream Author : Matthew O'Connor <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/REST-Application/
* License : Perl
  Programming Lang: Perl
  Description : framework for building RESTful web-applications

Module that acts as a base class for applications which implement a
RESTful interface, similar to CGI::Application.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (900, 'testing'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.23-1-686 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Re: How to cope with patches sanely

[Sven Mueller]

Simon Huggins wrote on 29/01/2008 02:51:

[wig&pen]

The meta data can easily be in these version control systems that
everyone on these threads seems to love so much.

If you want to keep more patches than you expose through wig&pen then
just don't publish them in the dsc.


That won't work well for one of the packages I (co-)maintain (and I 
assume for some other packages, too): I want a patch to be included in 
the Debian source, since it implements an often requested feature, but 
it can break other things. In other words: It conflicts with another 
patch (or maybe even two), but I want somebody who does apt-get source 
on the package to be able to do a (trivial) modification to the unpacked 
source and rebuild the package to have that feature (though knowing that 
this breaks something else).



I think all Debian really needs is tools to generate a wig&pen source
package and the appropriate tools to then deal with it e.g. dak and
sbuild updates.


But still, wig&pen looks nice to me. I could include the necessary patch 
files (and short docs on how to get alternative build working) in the 
debian.tar.gz instead of the .patches.tar.gz IIUIC and reach the same 
goal I mentioned above. If wig&pen supported a series file (quilt) or 
00list file (dpatch) in the .patches.tar.gz archive, I wouldn't need to 
work around anything.
I don't mind getting the patches applied during unpack of the source 
package as long as the tool that is able to generate the source package 
from that unpacked source has a way to find out that someone changed the 
source after all patches were applied and handling that in a sane way 
(e.g. creating and enlisting an addition patch in .patches.tar.gz).


On another note, I have a slight problem with the (other) proposal of 
using a (git/$DVCS) repository as the form of source package 
distribution. Mainly because I think this will usually add bloat. While 
developing/packaging, I often see intermediate commits which need to be 
heavily modified or even reverted to finally build the patch I wanted to 
get working. Though these commits are fine in the Repository, I wouldn't 
want to see all the intermediate steps in the source package.


cu,
Sven



signature.asc
Description: OpenPGP digital signature

Re: How to cope with patches sanely --> Debian New Maintainers' Guide

[Patrick Schoenfeld]

Hi,

On Sat, Jan 26, 2008 at 12:40:14AM +0900, Osamu Aoki wrote:
> This seems to be much cleaner than dpatch or quilt.  Also with the help
> of gitk, history is much more visible.  I look forward to see it matured
> and accepted.

personally I am a fan of the diversity in the Debian project. Its really
fine, that developers are not forced to work with certain software
(besides the minimal common standardisation that is needed), while I
don't see a reason why they shouldn't be able to. However I also agree
that in some levels diversity is way too much.
The way patches to the upstream source is handled is one of these
points where the diversity is way to much, as I and obviously a lot of
other people think as well.

So, yes, there should be a common agreement of how we handle patches and
I am a fan of version control systems (for a number of reasons), but I
would not agree that forcing all developers to use git is a good idea.
Personally I would think that it makes more sense to keep version
control and patch management seperated. There could be a common
agreement on a patch system and that would be really fine. I'm using
dpatch so far, but it has its weakness, so I don't see a reason why I
shouldn't go with another patch system.

So, I would agree with those recommending quilt, if it has significant
pros besides dpatch. That would be forcing to a specific tool and so
giving up some diversity, but it would keep giving up freedom of choice
on a low level, while forcing everybody to a specific VCS wouldn't keep
it low.

Best Regards,
Patrick


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

Re: Bug#463973: ITP: deejayd -- A media player daemon

[Steve Greenland]

On 05-Feb-08, 01:10 (CST), Hamish Moffatt <[EMAIL PROTECTED]> wrote: 
> On Tue, Feb 05, 2008 at 07:34:06AM +0100, Alexandre Rossi wrote:
> > > > Yes. Apparently what's special about this is that it can be
> > > > controlled over the network. Probably not the only one but
> > > > noticeable enough to be mentioned in a short description.
> > >
> > > mpd also supports that (tcp/6600).
> > 
> > Yep this project is very similar to mpd. As far as I know, it improves
> > over mpd with the following features :
> > - play queue
> 
> mpd has a play queue.

No it doesn't. See SVN revision 7155. (Short version: the maintainer
didn't like the implementation, and ripped it out.)

> DSP in pure Python? Hopefully not.

No, the actual playback is via xine or gstreamer, as previously noted.

I think this is different enough from mpd to be worth including. I'll
probably switch when it's packaged.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: changing the default syslog daemon for lenny?

[Bernd Zeimetz]

> rsyslog could of
> course read configs from syslog.d and rsyslog.d, and admins could
> install those under /etc/rsyslog.d/ or edit /etc/rsyslog.conf to make
> use of those additional features.

This would also be a way to solve #311812.

Cheers,

Bernd


-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Re: Intend to hijack rrdtool

[Bernd Zeimetz]

Bernd Zeimetz wrote:
> [CCing [EMAIL PROTECTED] as he is listed as Uploader]
> 
> Hi,
> 
> as rrdtool is a vital part of a lot of system monitoring solutions and
> should not go into Lenny in its current unmaintained state, I intend to
> hijack it.

After a lot of positiv reactions on my intention to hijack rrdtool, and
several offers to co-maintain the package in a team, the package would
be maintained by (at least) Sebastian Harl ([EMAIL PROTECTED]), Alexander
Wirt (formorer) and me.

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Re: Backport of debhelper

[Roberto C . Sánchez]

On Tue, Feb 05, 2008 at 05:49:19PM +0100, Joerg Jaspert wrote:
> On 11286 March 1977, Roberto C. Sánchez wrote:
> 
> > In any event, perhaps the advice you provide in your other mail in
> > this thread should be included in the Debian developer reference.
> 
> Want to write the wishlist bugreport?
> 
Sure.  Against which package or pseudo package?  developers-reference?

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: s390 buildd?

[Steve Langasek]

On Tue, Feb 05, 2008 at 08:17:04PM +0100, Hakan Ardo wrote:
> Hi,
> 15/12 I released gcc-avr version 1:4.2.2-1, but acording to:

>http://buildd.debian.org/build.php?pkg=gcc-avr

> the s390 buildd has not yet tried to build it. What might be the problem?

The s390 buildd maintainer presumes to mark all packages as 'Not-for-us' if
he doesn't feel like building them for the arch, without bothering to reach
a consensus first together with the maintainer, the ftp masters, or the
maintainers of the P-a-s overrides.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


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

s390 buildd?

[Hakan Ardo]

Hi,
15/12 I released gcc-avr version 1:4.2.2-1, but acording to:

   http://buildd.debian.org/build.php?pkg=gcc-avr

the s390 buildd has not yet tried to build it. What might be the problem?

  Thanx.

-- 
Håkan Ardö

Re: s390 buildd?

[Michael Koch]

On Tue, Feb 05, 2008 at 08:17:04PM +0100, Hakan Ardo wrote:
> Hi,
> 15/12 I released gcc-avr version 1:4.2.2-1, but acording to:
> 
>http://buildd.debian.org/build.php?pkg=gcc-avr
> 
> the s390 buildd has not yet tried to build it. What might be the problem?

http://buildd.debian.org/pkg.cgi?pkg=gcc-avr says "Not for us" so the
s390 buildd admins decided to not build the package. You should contact
[EMAIL PROTECTED] for this.


Cheers,
Michael


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

Re: How to cope with patches sanely --> Debian New Maintainers' Guide

[Pierre Habouzit]

On Tue, Feb 05, 2008 at 06:24:38PM +, Patrick Schoenfeld wrote:
> So, I would agree with those recommending quilt, if it has significant
> pros besides dpatch. That would be forcing to a specific tool and so
> giving up some diversity, but it would keep giving up freedom of choice
> on a low level, while forcing everybody to a specific VCS wouldn't keep
> it low.

  Again, the discussion isn't (for me) about a tool, but an exchange
format. We are discussing having patches served in a quilt series, and
let people adapt their tools to be able to export their work as a quilt
series so that other can find it and import it in their own tool of
choice if needed.

  Enforcing maintenance tools is A Bad Idea™. The difference is huge:
having common interfaces means that there is One True Tool that everyone
can use if he doesn't know the Real Tools the Maintainer uses (apt-get
source versus $SCM clone/checkout/whatever).

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpTVJqKeUgIB.pgp
Description: PGP signature

Re: rebuilding the archive in a dirty chroot: results

[Lucas Nussbaum]

On 25/01/08 at 15:25 +0100, Lucas Nussbaum wrote:
> Hi,
> 
> I've done two rebuilds of sid on i386.
> - one in a perfectly clean chroot, as I usually do
> - one in a chroot, where as many build-dependancies as impossible were
>   installed (take the Sources file, extract the build-deps for all
>   packages, and install as many packages as possible) (the chroot is
>   named bdfh -- build daemon from hell)
> 
> It is important that packages build in the same way (same binary
> packages generated) in both cases, because:
> - some maintainers still don't build in clean chroot
> - buildds don't necessarly cleanup all build-deps after build,
>   so you don't know in which environment your packages are being
>   built
> 
> Then I compared the results, and I started crying. ;)
> 
> 236 packages built fine in the clean chroot, but failed to build in the
> dirty chroot.  In some cases, it's caused by automake1.4 being
> installed, and not being removed by sbuild.
> 
> 35 packages failed in both the clean and the dirty chroot, but with
> different reasons, apparently (I have a script that tries to "guess" the
> reason for a failed build, but it's far from being 100% reliable)
> 
> 938 packages produced different binary packages according to debdiff. Of
> those, 477 produced different Depends line (caused by some features not
> being explicitely enabled, but not being explicitely disabled, usually).

Hi,

I did another rebuild. Thanks to the Debian GNU/kFreeBSD cabal, the
results are available on io.debian.net. If you want shell access, read
http://io.debian.net/ssh.html . If web access is enough, go to
http://io.debian.net/~lucas/bdfh-20080202/

Interesting files/dirs:
failed-packages.txt: list of packages that failed in one or the
   other chroot, or which failed in both, but for a different reason.
failed-packages.dd-list.txt: same, dd-list sorted.
different-packages.txt: packages that generated different binary
   packages, using debcmp.
different-packages.dd-list.txt: same, dd-list sorted.
logs.*/: build logs
pkg.*/: the generated packages
debcmp/: the output from debcmp

debcmp is an home-made script I use to compare packages, looking more
deeply than what debdiff does. It's available from
http://svn.debian.org/wsvn/collab-qa/tools/debcmp/ , if you want to
double-check the results.

My plan is to start filing bugs on the packages that failed to build,
and on those that differ in important ways (less/more files, less/more
Depends). It's already a lot of work. Is someone interested in helping
me with those tasks? Or maybe someone has an NM, and doesn't know what
he should do for T&S? ;)

In the meantime, don't hesitate to fix your packages!
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

[update] Automatic mirror selection - feedback appreciated

[Leo "costela" Antunes]

Hi,

Thanks to the help of Adam Borowski we now got a working solution for an
automatic mirror selection scheme.

Please help us test this infrastructure so that I can convince the DSA
to add it to our servers or at least give us a delegation from a
debian.{net,org} subzone! ;)

Again: I have no intention of supplanting any current structure, only
adding some more functionality to what we already have.


How to make it work:


Simply change whatever mirror you're currently using on
/etc/apt/sources.list to:

-geomirror.debian.net

Where  is the output of "dpkg --print-architecture".

Please make sure the DNS propagation has hit you, since the debian.net
aliases were all created earlier today.


How it works:
-

The -geomirror.d.n addresses are manually added CNAMEs to a
PowerDNS server that manages the zone geomirror.angband.pl (helpfully
loaned by Adam Borowski). This server is running pdns-backend-pipe,
which simply runs a script to determine the best mirror based on the
contents of Mirrors.masterlist[0], the IP that originated the request
and the requested architecture.

The current logic for selecting mirrors is very crude and only makes
sure the selected mirror is on the user's country and has the selected
arch, prioritizing mirrors that are called 'ftp.*.debian.org' and leafs
over push mirrors.
One possible improvement would be fetching information from DMC[1] to
help the prioritizing of hosts based on freshness (this could also help
avoid temporarily downed mirrors).

The source code for the backend script is available at[2].

The name 'geomirror' was picked for lack of a better suggestion. Please
feel free to give one! ;)


Known problems:
--

Since it's based on CNAMEs, a mirror that works on a separate virtual
host than the server's default won't be usable by this scheme.

In a quick test scan (ignoring all non-related errors), about 84 of the
358 archive mirrors are affected by this issue, 9 of which are top-level
country mirrors (BR, CL, HK, IS, IT, PT, TR, UK and 2 of the 4
round-robins for CA).
Simply adding:
"ServerAlias *.geomirror.debian.org"
(or whatever the official address ends up being) to apache-based mirrors
should suffice, so I hope getting a delegation from DSA would be enough
to ask the mirror admins to add this alias to their mirrors. Please
correct me if I'm wrong and there's some other big problem I'm not seeing.

Another minor problem is that the use of some DNS resolver that's not on
the same country as the user (OpenDNS, for instance) will result in a
incorrect guess by the server.


Cheers

[0]
http://cvs.debian.org/*checkout*/webwml/english/mirror/Mirrors.masterlist
[1] http://www.de.debian.org/dmc/today/
[2] git://git.debian.org/~costela/mirror_picker.git

-- 
Leo "costela" Antunes
[insert a witty retort here]




signature.asc
Description: OpenPGP digital signature

Re: Automatic mirror selection

[Leo "costela" Antunes]

Raphael Geissert wrote:
> Besides that I'm interested in how your script works at DNS level and if it
> wouldn't be more suitable to just setup a server with BIND + GeoDNS[1].

That's exactly the idea, but I chose to use pdns-backend-pipe +
libgeo-perl, so that I could grep the Mirrors.masterlist file for info
on our mirrors and use other methods of prioritizing aside from just
geolocation, namely the type of mirror, architectures available and the
domain name of the mirror (assuming that mirrors that got promoted to
ftp.*.debian.org are somehow better than the rest).

Check the announce I just made[0] and the git repo for the script[1] for
more info.
Feel free to send any feedback.

Cheers

[0] http://thread.gmane.org/gmane.linux.debian.devel.general/124340
[1] git://git.debian.org/~costela/mirror_picker.git

-- 
Leo "costela" Antunes
[insert a witty retort here]




signature.asc
Description: OpenPGP digital signature

Re: rebuilding the archive in a dirty chroot: results

[Cyril Brulebois]

On 05/02/2008, Lucas Nussbaum wrote:
> I did another rebuild. Thanks to the Debian GNU/kFreeBSD cabal,

\o/

> debcmp is an home-made script I use to compare packages, looking
> more deeply than what debdiff does. It's available from
> http://svn.debian.org/wsvn/collab-qa/tools/debcmp/ , if you want to
> double-check the results.

Having a look at some packages of mine, some suggestions:
 - Please blacklist .pdf at least, timestamps stuff and so on are
   likely to be at fault here.
 - You could eventually no longer take the order of entries in shlibs
   file into account. I'm not sure this order matters anyway.
 - Harder, but you could try and ignore hunks where only a line
   changed, which contains “Generated on $date”, that's likely to be
   doxygen or a friend of its. Maybe ignoring .html files would do?
   There's also docbook-to-man.
 - I didn't check your script but I guess it might be enhanced WRT
   file type detection, see for example synfigstudio log in debcmp/.

I really suggest you postprocess your logs for the shlibs problem, it
would make it trivial to spot actual problem, also preventing from
missing some, hidden in an order modification.

> Or maybe someone has an NM, and doesn't know what he should do for
> T&S? ;)

Not yet, already passed, too late. :p

-- 
Cyril Brulebois


pgp2lM64Vk7g9.pgp
Description: PGP signature

Re: Bug#463973: ITP: deejayd -- A media player daemon

[Hamish Moffatt]

On Tue, Feb 05, 2008 at 12:13:29PM -0600, Steve Greenland wrote:
> On 05-Feb-08, 01:10 (CST), Hamish Moffatt <[EMAIL PROTECTED]> wrote: 
> > mpd has a play queue.
> 
> No it doesn't. See SVN revision 7155. (Short version: the maintainer
> didn't like the implementation, and ripped it out.)

Erm, that's unfortunate.

> > DSP in pure Python? Hopefully not.
> No, the actual playback is via xine or gstreamer, as previously noted.
> 
> I think this is different enough from mpd to be worth including. I'll
> probably switch when it's packaged.

I agree, especially having read the justifications on the deejayd wiki.

My apologies to Alexandre Rossi as my earlier reply was a bit harsh.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: package names for library modules (was: shlibs vs symbols)

[Neil Williams]

On Tue, 2008-02-05 at 09:37 +0100, Raphael Hertzog wrote:
> Hi,
> 
> On Tue, 05 Feb 2008, Paul Wise wrote:
> > I was reviewing a library package RFS (libthai) and I noticed that the
> > shlibs pointed at version X and all the symbols in the symbols file
> > pointed at an earlier version. Here I assume that the shlibs should be
> > changed to point to the earlier version?

> > libqof-backend-qsf0: shlibs no version, symbols all 0.7.3, changelog goes 
> > way back
> > libqof1: shlibs no version, symbols all 0.7.2, changelog goes way back
> 
> Strange, stable has 0.7.1... and lack of version in shlibs is probably a
> bug, but one that can't be triggered except by building on etch with a
> dpkg-dev that doesn't support symbols files yet.

Looks like old data - 0.7.5 is current in unstable and has:
libqof-backend-qsf0 
shlibs:Depends: libglib2.0-0 (>= 2.6.0), libqof1 (= 0.7.5-1), libxml2
(>= 2.5.10)
libqof1
shlibs:Depends=libgda3-3, libc6 (>= 2.7-1), libglib2.0-0 (>= 2.12.0)

True, the symbols version differs but, TBH, libqof-backend-qsf0|sqlite0
are a bit of an anomaly at the moment. I'm waiting for the transition to
libqof2 at which point the backend modules will be renamed and
repackaged as private libraries. I've decided to wait until after Lenny
to make the transition - the upstream code will not be ready until after
the main Lenny freeze has begun.

Symbols were only implemented in 0.7.3 and I saw no point going back to
0.7.1, just show that the symbols in 0.7.3 were compatible with 0.7.2.

After the transition, the backend modules will no longer be shlibs so
there will be no symbols for those, just libqof2 which will start at
0.8.0 (a lot of symbols are being removed in the transition).

Actually, this reminds me of a question for debian-devel:

Is there a convention for the package name for *library modules* ?

GDA has modules that are loaded by a library and which are optional -
the user can choose from one of a few backend modules.

QOF has a very similar mechanism - the backends are modular (GModule)
and entirely optional (as long as at least one is available). After the
transition, these will be private libraries and I'm thinking of using
the names:

libqof2-backend-qsf
libqof2-backend-sqlite

This is similar to the new package names for the GDA backends:
libgda3-mysql, libgda3-postgres, libgda3-odbc, libgda3-sqlite,
libgda3-freetds - which were changed from the equivalent packages for
libgda2.

QOF also supports modular object libraries to support a variety of
frontends. These are shlibs and are currently named as:
libqofexpensesobjects0
libqofcashobjects0 ...
(with -dev, -dbg etc. as normal)

Applications then mix-and-match object libraries (and/or their own
objects) at compile time and call routines in libqof1|2 to dynamically
load the backend module as requested by the user.

The transition is the perfect time to change the names of the other
components.

Comments?

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




signature.asc
Description: This is a digitally signed message part

Re: s390 buildd?

[Michael Tautschnig]

> On Tue, Feb 05, 2008 at 08:17:04PM +0100, Hakan Ardo wrote:
> > Hi,
> > 15/12 I released gcc-avr version 1:4.2.2-1, but acording to:
> > 
> >http://buildd.debian.org/build.php?pkg=gcc-avr
> > 
> > the s390 buildd has not yet tried to build it. What might be the problem?
> 
> http://buildd.debian.org/pkg.cgi?pkg=gcc-avr says "Not for us" so the
> s390 buildd admins decided to not build the package. You should contact
> [EMAIL PROTECTED] for this.
>

Good luck.

Michael, who has tried that for ages.



pgpn382W3F0zV.pgp
Description: PGP signature

Re: [update] Automatic mirror selection - feedback appreciated

[Raphael Geissert]

Hello,

Leo "costela" Antunes wrote:
> 
> Another minor problem is that the use of some DNS resolver that's not on
> the same country as the user (OpenDNS, for instance) will result in a
> incorrect guess by the server.

Thanks for the clarification, I was about to say that it failed to detect my
country as USA instead of MX.

Besides that it seems to work great :)

PD. What do you think about adding a built-in list of addresses which 'work'
for OpenDNS so they are excluded and some kind of http redirection is used
instead?

> 
> 
> Cheers
> 

Cheers,
Raphael


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

[RFC] Changing priority of selinux back to optional

[Frans Pop]

The priority of selinux packages was changed from optional to standard, 
fairly shortly before the release of Etch.

I propose to revert that change before Lenny. The basic reason is that the 
selinux packages have basically been unmaintained since the release of 
Etch. Because of that current SeLinux just cannot be expected to work.

An additional reason is that the installation of selinux packages adds 
significantly to the size of the base system and accounts for a significant 
part of the time it takes to install the "standard" task, especially on 
slower architectures. This would be OK if there were real benefits in 
having SeLinux, but ATM that benefit is just not there.

Packages (both tools and policy packages) currently available in unstable 
and testing are seriously outdated when compared with their upstream 
versions. This also means that, with the soft freeze for Lenny starting 
fairly soon, that there is little time left to substantially improve the 
SeLinux support in Debian, which was one of the arguments for making it 
standard in the first place.

Some facts.

Package etchlenny/sid   upstream
policycoreutils 1.32-3  2.0.16-12.0.42 (?)
setools 2.4-3   2.4-3   3.3.2
refpolicy   0.0.20070507-5  0.0.20070507-5  20071214
libsepol1.14-2  2.0.3-1 2.0.20 (?)
libselinux  1.32-3  2.0.15-22.0.50 (?)

None of the packages in Debian has been updated since June/July 2006.

There are also some longstanding bugs, including fairly simple packaging 
errors in Etch, none of which have been addressed. Examples:
- #440474: chcat: syntax errors
- #405975: semodule_deps and semodule have alignment issues
- #427906: postinst: policy package name to deb name, lacks glob support
- #438604: selinux-basics: Invalid test for dynamic motd updating
- #438706: selinux-doc: Error in doc-base definition
- #438887: refpolicy: Spurious "+" causes warnings when building modules

None of these bugs has seen any reaction from the package maintainers.

I spent quite a bit of time on SeLinux back around September, with the 
intention of learning more about how it worked and its state in Debian, and 
to maybe contribute. At that time I filed a few bugs and asked for help 
with some issues I encountered (as so kindly offered by Manoj during his 
2007 Debconf talk), but never received any reaction. In the end I gave up.

My experience then was that SeLinux was fairly complex to set up and needed 
a lot of custom policy tweaks for even basic things to work. I.e, not 
something that deserves to be installed by default.

I have also for some time followed selinux upstream development, and it was 
very high paced. Not keeping up means getting left _far_ behind and 
especially for policy it means that tweaks needed for selinux to work well 
on standard Debian just won't be there.

Cheers,
FJP


signature.asc
Description: This is a digitally signed message part.

Re: rebuilding the archive in a dirty chroot: results

[Alexander Schmehl]

Hi!

* Lucas Nussbaum <[EMAIL PROTECTED]> [080205 21:57]:
> I did another rebuild. Thanks to the Debian GNU/kFreeBSD cabal, the
> results are available on io.debian.net. If you want shell access, read
> http://io.debian.net/ssh.html . If web access is enough, go to
> http://io.debian.net/~lucas/bdfh-20080202/
[..]
> In the meantime, don't hesitate to fix your packages!

I thought I did with fillets-ng 0.8.0-2, but now I'm slightly confused.

If I see correclty, the contents and dependencies are the same, but in 
different order,
so I think I fixed the libfridi problem successfully.

But I don't understand the following differences:

The normal buildlog has:
Files: 
 b96a42b062fd019fef7b37be44d6e784 818 games optional fillets-ng_0.8.0-2.dsc
 4b56ebb7ed2ae32c2e409d0d3dc9e1e5 6752 games optional fillets-ng_0.8.0-2.diff.gz
 52b045d74a42f364d69642da602f97f3 293038 games optional 
fillets-ng_0.8.0-2_i386.deb

While the bdfh buildlog lists:
Files: 
 f8b0f31fb8358cb43ab436ea1f524c10 818 games optional fillets-ng_0.8.0-2.dsc
 254864c6a092d0f6cf07795e4b3f27ba 8780 games optional fillets-ng_0.8.0-2.diff.gz
 3182e8fcaf977c11e4e81d4b7a191acb 293086 games optional 
fillets-ng_0.8.0-2_i386.deb

Okay, since the content of the .deb has a different order, the md5sum is
of course changed.  The dsc changed it's md5sum, because the diff.gz
changed, looks like some autofoo stuff?

Why that?  Both, the diff.gz and the .dsc, are part of the source
package, so why did they change at all?


Yours sincerely,
  Alexander


signature.asc
Description: Digital signature

Re: rebuilding the archive in a dirty chroot: results

[Cyril Brulebois]

On 05/02/2008, Alexander Schmehl wrote:
> Why that?  Both, the diff.gz and the .dsc, are part of the source
> package, so why did they change at all?

See the build log:
,
| gpg: Signature made Tue Jan 29 21:33:22 2008 CET using DSA key ID 00D8CD16
| gpg: Can't check signature: public key not found
| dpkg-source: extracting fillets-ng in fillets-ng-0.8.0
| dpkg-source: unpacking fillets-ng_0.8.0.orig.tar.gz
| dpkg-source: applying ./fillets-ng_0.8.0-2.diff.gz
| dpkg-buildpackage: source package fillets-ng
| dpkg-buildpackage: source version 0.8.0-2
| dpkg-buildpackage: source changed by Alexander Schmehl <[EMAIL PROTECTED]>
| dpkg-buildpackage: host architecture i386
|  /usr/bin/fakeroot debian/rules clean
| QUILT_PATCHES=debian/patches quilt --quiltrc /dev/null pop -a -R || test $? = 
2 
| No patch removed
| rm -rf .pc debian/stamp-patched
| dh_testdir
| dh_testroot
| rm -f build-stamp 
| # Add here commands to clean up after the build process.
| [ ! -f Makefile ] || /usr/bin/make distclean
| dh_clean debian/fillets-ng.png
|  dpkg-source -b fillets-ng-0.8.0
| dpkg-source: building fillets-ng using existing fillets-ng_0.8.0.orig.tar.gz
| dpkg-source: building fillets-ng in fillets-ng_0.8.0-2.diff.gz
| dpkg-source: building fillets-ng in fillets-ng_0.8.0-2.dsc
|  debian/rules build
`

There you are. -b/-B aren't used, the source package gets (re)built,
and due to gzip magic, the diff.

Cheers,

-- 
Cyril Brulebois


pgpl07dlnpJBV.pgp
Description: PGP signature

Re: rebuilding the archive in a dirty chroot: results

[Frank Lichtenheld]

On Tue, Feb 05, 2008 at 09:57:16PM +0100, Lucas Nussbaum wrote:
> On 25/01/08 at 15:25 +0100, Lucas Nussbaum wrote:
> I did another rebuild. Thanks to the Debian GNU/kFreeBSD cabal, the
> results are available on io.debian.net. If you want shell access, read
> http://io.debian.net/ssh.html . If web access is enough, go to
> http://io.debian.net/~lucas/bdfh-20080202/

http://io.debian.net/~lucas/bdfh-20080202/logs.bdfh/libnet-ssh-perl-perl_1.30-1_sid32-bdfh.buildlog
ends with:
Manifying blib/man3/NeE: Caught signal 'Terminated': terminating immediately

Any idea what that is about?

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

Re: s390 buildd?

[Lucas Nussbaum]

On 05/02/08 at 11:43 -0800, Steve Langasek wrote:
> On Tue, Feb 05, 2008 at 08:17:04PM +0100, Hakan Ardo wrote:
> > Hi,
> > 15/12 I released gcc-avr version 1:4.2.2-1, but acording to:
> 
> >http://buildd.debian.org/build.php?pkg=gcc-avr
> 
> > the s390 buildd has not yet tried to build it. What might be the problem?
> 
> The s390 buildd maintainer presumes to mark all packages as 'Not-for-us' if
> he doesn't feel like building them for the arch, without bothering to reach
> a consensus first together with the maintainer, the ftp masters, or the
> maintainers of the P-a-s overrides.

I think that the following patch would solve this problem in a nice and
easy way:

--- update_out.py.orig  2008-02-05 15:29:47.0 -0700
+++ update_out.py   2008-02-05 15:30:16.0 -0700
@@ -25,8 +25,8 @@
 
 # Configuration information
 
-expected_arches = 11
-allarches = [ 'i386', 'sparc', 'alpha', 'powerpc', 'arm', 'hppa', 'ia64', 
'mips', 'mipsel', 's390', 'amd64' ]
+expected_arches = 10
+allarches = [ 'i386', 'sparc', 'alpha', 'powerpc', 'arm', 'hppa', 'ia64', 
'mips', 'mipsel', 'amd64' ]
 
 mindays = { "low" : 10, "medium" : 5, "high" : 2, "critical" : 0, 
"emergency" : 0 }
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: rebuilding the archive in a dirty chroot: results

[Lucas Nussbaum]

On 05/02/08 at 23:43 +0100, Frank Lichtenheld wrote:
> On Tue, Feb 05, 2008 at 09:57:16PM +0100, Lucas Nussbaum wrote:
> > On 25/01/08 at 15:25 +0100, Lucas Nussbaum wrote:
> > I did another rebuild. Thanks to the Debian GNU/kFreeBSD cabal, the
> > results are available on io.debian.net. If you want shell access, read
> > http://io.debian.net/ssh.html . If web access is enough, go to
> > http://io.debian.net/~lucas/bdfh-20080202/
> 
> http://io.debian.net/~lucas/bdfh-20080202/logs.bdfh/libnet-ssh-perl-perl_1.30-1_sid32-bdfh.buildlog
> ends with:
> Manifying blib/man3/NeE: Caught signal 'Terminated': terminating immediately
> 
> Any idea what that is about?
 
Yes, for some reason, that build just blocked for hours. I don't know
what happened. I'll try to reproduce it when filing bugs.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: rebuilding the archive in a dirty chroot: results

[Lucas Nussbaum]

On 05/02/08 at 23:32 +0100, Alexander Schmehl wrote:
> Hi!
> 
> * Lucas Nussbaum <[EMAIL PROTECTED]> [080205 21:57]:
> > I did another rebuild. Thanks to the Debian GNU/kFreeBSD cabal, the
> > results are available on io.debian.net. If you want shell access, read
> > http://io.debian.net/ssh.html . If web access is enough, go to
> > http://io.debian.net/~lucas/bdfh-20080202/
> [..]
> > In the meantime, don't hesitate to fix your packages!
> 
> I thought I did with fillets-ng 0.8.0-2, but now I'm slightly confused.
> 
> If I see correclty, the contents and dependencies are the same, but in 
> different order,
> so I think I fixed the libfridi problem successfully.
> 
> But I don't understand the following differences:
> 
> The normal buildlog has:
> Files: 
>  b96a42b062fd019fef7b37be44d6e784 818 games optional fillets-ng_0.8.0-2.dsc
>  4b56ebb7ed2ae32c2e409d0d3dc9e1e5 6752 games optional 
> fillets-ng_0.8.0-2.diff.gz
>  52b045d74a42f364d69642da602f97f3 293038 games optional 
> fillets-ng_0.8.0-2_i386.deb
> 
> While the bdfh buildlog lists:
> Files: 
>  f8b0f31fb8358cb43ab436ea1f524c10 818 games optional fillets-ng_0.8.0-2.dsc
>  254864c6a092d0f6cf07795e4b3f27ba 8780 games optional 
> fillets-ng_0.8.0-2.diff.gz
>  3182e8fcaf977c11e4e81d4b7a191acb 293086 games optional 
> fillets-ng_0.8.0-2_i386.deb
> 
> Okay, since the content of the .deb has a different order, the md5sum is
> of course changed.  The dsc changed it's md5sum, because the diff.gz
> changed, looks like some autofoo stuff?

It is. See
http://io.debian.net/~lucas/bdfh-20080202/debcmp/fillets-ng_0.8.0-2.log
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: [update] Automatic mirror selection - feedback appreciated

[Michal Čihař]

Hi

Dne Tue, 05 Feb 2008 22:13:48 +0100
"Leo \"costela\" Antunes" <[EMAIL PROTECTED]> napsal(a):

> The -geomirror.d.n addresses are manually added CNAMEs to a
> PowerDNS server that manages the zone geomirror.angband.pl (helpfully
> loaned by Adam Borowski). This server is running pdns-backend-pipe,
> which simply runs a script to determine the best mirror based on the
> contents of Mirrors.masterlist[0], the IP that originated the request
> and the requested architecture.

Hmm, looks like mine server IP address is not detected correctly - first
resolution ended up with Japan mirror, second one with UK and finally
the third used correct Czech ;-). Not using any proxy DNS.

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Re: [RFC] Changing priority of selinux back to optional

[Erich Schubert]

Hello Frans, Hello fellow DDs,
Yes, the SELinux stuff doesn't seem to have any currently active
developers. I haven't heard anything from Manoj in months.
I had to stop working on SELinux myself for various reasons; it's not
that things didn't work, but it was a mixture of personal reasons
(mostly lack of time, and no longer being responsible for the servers I
was using SELinux on) but also largely a motivational thing, that I
didn't feel people really cared much about it. Most of the time when
you'd just mention SELinux, people would basically be scared and run
away. This is largely due to FUD efforts by the AppArmor folks, who -
incorrectly - framed SELinux as being overly complex.
Just recently, at the Google Android Developer Thingy here in Munich,
someone (in the informal discussions around dinner) again suggested
something along the lines of automatically creating users to separate
applications that could easily be squashed using the SELinux stuff.
SELinux works the same way uid and gid work, so it just isn't really
that complex. All the difficulties lie in writing good restrictive
policies; and that doesn't get any easier if you do some uid/gid
magic...

Anyway, back to the original topic:
1. I agree that SELinux currently is not in shape for a release. The
packages are seriously outdated, there have been some major changes in
upstream. In particular, the 'targeted' and 'strict' policies have been
merged and only differ by having a 'targeted' module installed. AFAIK.
2. At least libselinux is linked by many of the core packages, and the
package REALLY should be updated nevertheless. However that might
require also updating most of the other packages; I'm not sure about API
compability.
3. In my experience, none of the SELinux librarys or applications were
particularly hard to package/maintain. All the hard work is in
fine-tuning the policy to support all the Debian-specific stuff.
Especially when you need the cooperation of other maintainers, such as
  initscripts: http://bugs.debian.org/390067
  cron: http://bugs.debian.org/333837
  liblzo1: http://bugs.debian.org/336138
All of which have been open in the range of 1.5-2.5 years.
I pushed fixes for some of these issues (e.g. amavis). Usually the best
way is to split out a specific part of the init script (such as the part
doing the backups of /etc/shadow) into a separate script. This is not a
particularly hard change, but you can face a lot of resistance.
So in fact, the situation for SELinux-related bugs not in the actual
SELinux packages is even worse.

So maybe it would be better to actually get some people involved in
SELinux again. It's a pity to see the AppArmor FUD work this well.
(Albeit AppArmor didn't make it into mainstream kernel or Debian, and I
remember having seen some news message last year that Novell stopped
development of AppArmor?)
The AppArmor WNPP bug has been open for months without any message, too:
http://bugs.debian.org/440680
This makes me wonder if we actually have enough developers working on
security infrastructure and the core system in general. Actually I have
the impression in general (not only with respect to security) that we're
losing developer share, but I can't tell you where people are going to
instead. Ubuntu didn't recently strike me as being more attractive, and
their SELinux and AppArmor stuff is as outdated/stalled as ours. It's
mostly Fedora/Gentoo (for SELinux) and SuSE (for AppArmor) that seem to
be doing progress here, but probably only because there are a few single
persons pushing the stuff for the distributions they use themselves.

best regards,
Erich Schubert
-- 
   erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_
 The future is here. It's just not evenly distributed yet.  //\
   Die Freunde nennen sich aufrichtig. Die Feinde sind es: DaherV_/_
 man ihren Tadel zur Selbsterkenntnis benutzen sollte, als
   eine bittere Arznei.  --- Arthur Schopenhauer


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

Re: [update] Automatic mirror selection - feedback appreciated

[Adam Borowski]

On Wed, Feb 06, 2008 at 08:57:52AM +0900, Michal Čihař wrote:
   ^
> Dne Tue, 05 Feb 2008 22:13:48 +0100
> "Leo \"costela\" Antunes" <[EMAIL PROTECTED]> napsal(a):
> 
> > The -geomirror.d.n addresses are manually added CNAMEs to a
> > PowerDNS server that manages the zone geomirror.angband.pl (helpfully
> > loaned by Adam Borowski). This server is running pdns-backend-pipe,
> > which simply runs a script to determine the best mirror based on the
> > contents of Mirrors.masterlist[0], the IP that originated the request
> > and the requested architecture.
> 
> Hmm, looks like mine server IP address is not detected correctly - first
> resolution ended up with Japan mirror, second one with UK and finally
> the third used correct Czech ;-). Not using any proxy DNS.

geoip is not perfect, but a glance at your mail headers suggest that there
may be some confusion from another source.

Received: from mort.cihar.com (mort.cihar.com [82.208.50.189])
by liszt.debian.org
Tue,  5 Feb 2008 23:58:07 + (UTC)
Received: from p1185-ipbfp704tokaisakaetozai.aichi.ocn.ne.jp ([125.207.87.185] 
helo=raptor.cic)
by mort.cihar.com
Wed, 06 Feb 2008 00:58:05 +0100
Received: from localhost ([127.0.0.1] helo=raptor.cic ident=nijel)
by raptor.cic
Wed, 06 Feb 2008 08:57:57 +0900

IPs, rev names and time zones seem to match.  The machine you sent the mail
from seems to be definitely in Japan, and geoip says so as well.  The mail
server, mort.cihar.com, looks Czechish (per its time zone and your name) --
again, geoip confirms that.

Assuming all machines use a nearby DNS, could you check again, using
"nslookup" or similar to avoid http proxies?  Travelling/sshing to the other
side of the world means you may use a resolver all the way at home. 
Accidentally mistaking a remote ssh session for a local one could be another
explanation.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: [update] Automatic mirror selection - feedback appreciated

[Michal Čihař]

Hi

On Wed, 6 Feb 2008 02:18:10 +0100
Adam Borowski <[EMAIL PROTECTED]> wrote:

> geoip is not perfect, but a glance at your mail headers suggest that there
> may be some confusion from another source.
> 
> Received: from mort.cihar.com (mort.cihar.com [82.208.50.189])
> by liszt.debian.org
> Tue,  5 Feb 2008 23:58:07 + (UTC)
> Received: from p1185-ipbfp704tokaisakaetozai.aichi.ocn.ne.jp 
> ([125.207.87.185] helo=raptor.cic)
> by mort.cihar.com
> Wed, 06 Feb 2008 00:58:05 +0100
> Received: from localhost ([127.0.0.1] helo=raptor.cic ident=nijel)
> by raptor.cic
> Wed, 06 Feb 2008 08:57:57 +0900
> 
> IPs, rev names and time zones seem to match.  The machine you sent the mail
> from seems to be definitely in Japan, and geoip says so as well.  The mail
> server, mort.cihar.com, looks Czechish (per its time zone and your name) --
> again, geoip confirms that.

This server was the place where I tried the lookup and it is really in
Czech. It has own DNS server which does not use any proxy and I flushed
it's cache before each attempt. Just tested it again to be sure:

# Flush of DNS server cache
[EMAIL PROTECTED] host i386-geomirror.debian.net
i386-geomirror.debian.net is an alias for i386.geomirror.angband.pl.
i386.geomirror.angband.pl is an alias for ftp2.jp.debian.org.
ftp2.jp.debian.org has address 210.157.158.33
# Flush of DNS server cache
[EMAIL PROTECTED] host i386-geomirror.debian.net 
i386-geomirror.debian.net is an alias for i386.geomirror.angband.pl.
i386.geomirror.angband.pl is an alias for ftp.cz.debian.org.
ftp.cz.debian.org has address 195.113.161.73

Any further resolutions seems to go correctly to ftp.cz.d.o.

Okay let's try it also another way - ask directly your server without
anything on the way. It seems that last reply is somehow cached even 
for different source addresses. If I do query first here in Japan and 
then over there in Czech, I get few results pointing to Japan mirror 
before it updates to Czech one. The same happens when I then start 
resolving in Japan - I get again the Czech server on first attempts.
Log follows, the time difference 8 hours is time zone shift:

[EMAIL PROTECTED] dig i386.geomirror.angband.pl @nurnen.angband.pl

; <<>> DiG 9.4.2 <<>> i386.geomirror.angband.pl @nurnen.angband.pl
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24505
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;i386.geomirror.angband.pl. IN  A

;; ANSWER SECTION:
i386.geomirror.angband.pl. 3600 IN  CNAME   ftp2.jp.debian.org.

;; Query time: 184 msec
;; SERVER: 212.160.145.27#53(212.160.145.27)
;; WHEN: Wed Feb  6 02:40:03 2008
;; MSG SIZE  rcvd: 75

[EMAIL PROTECTED] dig i386.geomirror.angband.pl @nurnen.angband.pl

; <<>> DiG 9.4.2 <<>> i386.geomirror.angband.pl @nurnen.angband.pl
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 16974
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;i386.geomirror.angband.pl. IN  A

;; ANSWER SECTION:
i386.geomirror.angband.pl. 3600 IN  CNAME   ftp.cz.debian.org.

;; Query time: 56 msec
;; SERVER: 212.160.145.27#53(212.160.145.27)
;; WHEN: Wed Feb  6 02:40:05 2008
;; MSG SIZE  rcvd: 74

[EMAIL PROTECTED] dig i386.geomirror.angband.pl @nurnen.angband.pl

; <<>> DiG 9.4.2 <<>> i386.geomirror.angband.pl @nurnen.angband.pl
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 11125
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;i386.geomirror.angband.pl. IN  A

;; ANSWER SECTION:
i386.geomirror.angband.pl. 3600 IN  CNAME   ftp.cz.debian.org.

;; Query time: 327 msec
;; SERVER: 212.160.145.27#53(212.160.145.27)
;; WHEN: Wed Feb  6 10:41:15 2008
;; MSG SIZE  rcvd: 74

[EMAIL PROTECTED] dig i386.geomirror.angband.pl @nurnen.angband.pl

; <<>> DiG 9.4.2 <<>> i386.geomirror.angband.pl @nurnen.angband.pl
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 18208
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;i386.geomirror.angband.pl. IN  A

;; ANSWER SECTION:
i386.geomirror.angband.pl. 3600 IN  CNAME   ftp2.jp.debian.org.

;; Query time: 332 msec
;; SERVER: 212.160.145.27#53(212.160.145.27)
;; WHEN: Wed Feb  6 10:42:31 2008
;; MSG SIZE  rcvd: 75


-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Re: [RFC] Changing priority of selinux back to optional

[Philippe Cloutier]

I agree. Regarding the installed size, on my not-so-barebone KDE lenny 
PC (1067 packages installed), installing standard selinux packages would 
require 40 MB more. Systems with old HDD-s and miniature systems could 
be bothered.



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

Bug#464250: ITP: libgcl -- Chinese lunar calendar library

[LI Daobing]

Package: wnpp
Severity: wishlist
Owner: LI Daobing <[EMAIL PROTECTED]>

* Package name: libgcl
  Version : 0.2.4
  Upstream Author : yetist <[EMAIL PROTECTED]>
* URL : http://code.google.com/p/liblunar
* License : GPL
  Programming Lang: C
  Description : Chinese lunar calendar library

A Chinese lunar calendar library, lunar-applet 2.0~r2 depends on this
library.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



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

Re: s390 buildd?

[Steve Langasek]

On Tue, Feb 05, 2008 at 11:35:30PM +0100, Lucas Nussbaum wrote:
> On 05/02/08 at 11:43 -0800, Steve Langasek wrote:
> > On Tue, Feb 05, 2008 at 08:17:04PM +0100, Hakan Ardo wrote:
> > > Hi,
> > > 15/12 I released gcc-avr version 1:4.2.2-1, but acording to:

> > >http://buildd.debian.org/build.php?pkg=gcc-avr

> > > the s390 buildd has not yet tried to build it. What might be the problem?

> > The s390 buildd maintainer presumes to mark all packages as 'Not-for-us' if
> > he doesn't feel like building them for the arch, without bothering to reach
> > a consensus first together with the maintainer, the ftp masters, or the
> > maintainers of the P-a-s overrides.

> I think that the following patch would solve this problem in a nice and
> easy way:

Which is not the same thing as deciding that s390 is no longer a release
candidate, so if s390 is *not* dropped as a release candidate it would then
become the release team's problem to clean up the resulting delta in
testing...

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


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

Re: rebuilding the archive in a dirty chroot: results

[Reinhard Tartler]

Lucas Nussbaum <[EMAIL PROTECTED]> writes:

> I did another rebuild. Thanks to the Debian GNU/kFreeBSD cabal, the
> results are available on io.debian.net. If you want shell access, read
> http://io.debian.net/ssh.html . If web access is enough, go to
> http://io.debian.net/~lucas/bdfh-20080202/

thanks for the rerun of the bdfh rebuilds. One of my packages ftbfs in
that chroot, because it failed to remove build-conflicts:
http://io.debian.net/~lucas/bdfh-20080202/logs.bdfh/pong2_0.1.2-2_sid32-bdfh.buildlog


I wonder why sbuild fails here, can someone explain that? I thought that
adding a build conflict on libssl-dev was a good idea, but it seems to
cause an FTBFS now?


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


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

Re: Bug#464169: ITP: vagalume -- A GTK+-based Last.fm client

[Christian Perrier]

Quoting Alberto Garcia ([EMAIL PROTECTED]):
> Package: wnpp
> Severity: wishlist
> Owner: Alberto Garcia <[EMAIL PROTECTED]>
> 
> 
> * Package name: vagalume
>   Version : 0.5
>   Upstream Author : Alberto Garcia <[EMAIL PROTECTED]>
> * URL : http://people.igalia.com/berto/
> * License : GPL 3
>   Programming Lang: C
>   Description : A GTK+-based Last.fm client

"Last.fm" isn't really clear for anybody. I suggest using a more
generic description and somehow say this is related to audio/media
playing.

Also drop the leading article, of course

"graphical GTK+-based client for Last.fm media service"


...or something similar, maybe. I'm not entirely sure of the most
appropiate description of Last.fm, not being a very active user there,
indeed.




signature.asc
Description: Digital signature

Re: [RFC] Changing priority of selinux back to optional

[Reinhard Tartler]

Erich Schubert <[EMAIL PROTECTED]> writes:

> This makes me wonder if we actually have enough developers working on
> security infrastructure and the core system in general. Actually I have
> the impression in general (not only with respect to security) that we're
> losing developer share, but I can't tell you where people are going to
> instead. Ubuntu didn't recently strike me as being more attractive, and
> their SELinux and AppArmor stuff is as outdated/stalled as ours.

*cough*

https://lists.ubuntu.com/archives/ubuntu-hardened/2008-February/000284.html

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


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

Re: rebuilding the archive in a dirty chroot: results

[Raphael Hertzog]

On Wed, 06 Feb 2008, Reinhard Tartler wrote:
> Lucas Nussbaum <[EMAIL PROTECTED]> writes:
> 
> > I did another rebuild. Thanks to the Debian GNU/kFreeBSD cabal, the
> > results are available on io.debian.net. If you want shell access, read
> > http://io.debian.net/ssh.html . If web access is enough, go to
> > http://io.debian.net/~lucas/bdfh-20080202/
> 
> thanks for the rerun of the bdfh rebuilds. One of my packages ftbfs in
> that chroot, because it failed to remove build-conflicts:
> http://io.debian.net/~lucas/bdfh-20080202/logs.bdfh/pong2_0.1.2-2_sid32-bdfh.buildlog
> 
> I wonder why sbuild fails here, can someone explain that? I thought that
> adding a build conflict on libssl-dev was a good idea, but it seems to
> cause an FTBFS now?

It looks like sbuild uses dpkg to remove build conflicting packages
instead of apt-get and obviously fails given that dozen of -dev packages
depend on it... (this is the build daemon from hell, remember ;)).

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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