Bug#687001: ITP: optional-dev -- fake (empty) dev package

2012-09-08 Thread Dmitry Smirnov 
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: optional-dev
Version: 20120908
 Author: Dmitry Smirnov 
License: GPL-3+
Description: fake (empty) dev package
 Purpose of this package is to provide an alternative for 
optional build
 dependencies which may not be available on some architectures.



There are situations when some of the libraries listed in Build-Depends
are optional i.e. build system is smart enough to avoid failure when
such library is missing.

Often some development libraries are not available on all architectures
in which case maintainer should know beforehand which architectures may
satisfy this dependency and maintain an up-to-date list of architectures
for such packages, like in the following example:

Build-Depends: libchamplain-gtk-0.12-dev [!m68k !sh4],
   libopenipmi-dev [!hurd-any !arm]

From time to time such lists should be re-checked in case library become
available on another architecture or when new architecture is added or
if package is removed from some architectures.

Another challenge is backporting package if some of its optional build
dependencies may not be available on target distribution. For instance
"libchamplain-gtk-0.12-dev" is not available for Squeeze so backporting
would require removing it from Build-Depends.

Finally maintainer might want to mark optional dependencies as such (can
be done with comments).

All the above problems may be addressed by using this package as
alternative to optional build dependency like in the example below:

Build-Depends: libchamplain-gtk-0.12-dev | optional-dev,
   libopenipmi-dev | optional-dev


--
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/201209081708.34882.only...@member.fsf.org

Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package

2012-09-08 Thread Adam Borowski 
On Sat, Sep 08, 2012 at 05:08:34PM +1000, Dmitry Smirnov wrote:
> Package: wnpp
>Package name: optional-dev
> 
> 
> 
> There are situations when some of the libraries listed in Build-Depends
> are optional i.e. build system is smart enough to avoid failure when
> such library is missing.
> 
> Often some development libraries are not available on all architectures
> in which case maintainer should know beforehand which architectures may
> satisfy this dependency and maintain an up-to-date list of architectures
> for such packages, like in the following example:
> 
> Build-Depends: libchamplain-gtk-0.12-dev [!m68k !sh4],
>libopenipmi-dev [!hurd-any !arm]
[...]
> All the above problems may be addressed by using this package as
> alternative to optional build dependency like in the example below:
> 
> Build-Depends: libchamplain-gtk-0.12-dev | optional-dev,
>libopenipmi-dev | optional-dev

(Using "Build-Depends: libfoo-dev | optional-dev" below.)

I'm afraid this is a bad idea for three reasons:

1. you'd get a misbuild if libfoo-dev happens to be temporarily
   uninstallable due to a transition of something it depends on,
   it or one of its dependencies happen to wait for a co-installed
   multiarch package, and so on

2. same, if libfoo-dev is not yet built.  It can happen if it has just been
   uploaded, we're in the middle of an archive rebuild (a new arch, some
   derivative), etc.

3. don't certain build modes (sbuild IIRC) ignore any alternatives in the
   first place?  If so, you'll cause a FTBFS.


-- 
Copyright and patents were never about promoting culture and innovations;
from the very start they were legalized bribes to give the king some income
and to let businesses get rid of competition.  For some history, please read
https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623


signature.asc
Description: Digital signature

Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package

2012-09-08 Thread Holger Levsen 
Hi,

"optional depends" - what?? Thats self contradictory. If a depends it's really 
optional, it's not a depends, thus that package is buggy and should not be 
fixed by introducing a nonsense package, but by removing this depends. 


cheers,
Holger


-- 
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/201209081137.34658.hol...@layer-acht.org

Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package

2012-09-08 Thread Simon McVittie 
On 08/09/12 08:08, Dmitry Smirnov wrote:
> Often some development libraries are not available on all architectures
> in which case maintainer should know beforehand which architectures may
> satisfy this dependency and maintain an up-to-date list of architectures
> for such packages, like in the following example:
> 
> Build-Depends: libchamplain-gtk-0.12-dev [!m68k !sh4],
>libopenipmi-dev [!hurd-any !arm]
[for which a proposed replacement is]
> Build-Depends: libchamplain-gtk-0.12-dev | optional-dev,
>libopenipmi-dev | optional-dev

This doesn't really give enough guarantees (even if sbuild followed
non-first branches in alternative-lists, which IIRC it doesn't). If
champlain happens to be temporarily uninstallable on (say) powerpc at
the time the empathy build happens, we don't want that to mean it
randomly loses features on powerpc, then gains those features back later.

It would perhaps make more sense if there was a way for the libchamplain
maintainer to nominate excluded architectures, so empathy could say
something like:

Build-Depends: libchamplain-...-dev |
   champlain-unavailable-on-this-arch

where champlain-unavailable-on-this-arch is arch:any, empty, and built
on exactly those architectures that deliberately don't build champlain.

(I don't think my example works either, again because sbuild only uses
the first alternative, but it seems closer to being right...)

S


-- 
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/504b26b5.4050...@debian.org

Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package

2012-09-08 Thread Arno Töll 
Hi,

On 08.09.2012 13:06, Simon McVittie wrote:
> It would perhaps make more sense if there was a way for the libchamplain
> maintainer to nominate excluded architectures, so empathy could say
> something like:
> 
> Build-Depends: libchamplain-...-dev |
>champlain-unavailable-on-this-arch
> 

As Adam previously said: buildds do not resolve alternatives. They use
the first dependency or fail to build from source if it isn't available.
Dmitry's proposal has the same problem. Thus, any "Build-Depends: A | B"
does not work for buildds if A is not installable.

The rationale is, that builds should unconditionally result in the same
binary package (I guess).


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package

2012-09-08 Thread Dmitry Smirnov 
On Sat, 8 Sep 2012 19:37:33 Holger Levsen wrote:
> "optional depends" - what?? Thats self contradictory. If a depends it's
> really optional, it's not a depends, thus that package is buggy and should
> not be fixed by introducing a nonsense package, but by removing this
> depends.

Not at all, it may appears "self contradictory" only because debian/control 
"language" doesn't have a right term for it. Or perhaps my wording is not 
perfect. If you got the idea, can you suggest a better word?

Imagine a software that builds without a certain -dev package. When present 
this package may be used to activate an additional (optional) feature.

When building for as many architectures as we have, situation when some 
dependencies are missing (or can't exist) on some architectures is not rare.

However we still want to build our packages with all features possible.

So here are two ideas -- one is to clearly see which build-dependencies are 
optional i.e. which packages are not critical for successful build;
and another is to nicely and easily handle unsatisfiable non-critical 
"dependencies".

The latter will make maintenance easier and may also be helpful for 
backporting or even for distributions who borrow our packages but may not have 
all their build-dependencies.

Regards,
Dmitry.


-- 
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/201209082201.18803.only...@member.fsf.org

Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package

2012-09-08 Thread Dmitry Smirnov 
On Sat, 8 Sep 2012 18:30:30 Adam Borowski wrote:
> I'm afraid this is a bad idea for three reasons:
> 
> 1. you'd get a misbuild if libfoo-dev happens to be temporarily
>uninstallable due to a transition of something it depends on,
>it or one of its dependencies happen to wait for a co-installed
>multiarch package, and so on
> 
> 2. same, if libfoo-dev is not yet built.  It can happen if it has just been
>uploaded, we're in the middle of an archive rebuild (a new arch, some
>derivative), etc.

Good points, thanks. I did't think of this. Perhaps this idea is not flawless 
but we might have a potential for improvement.

 
> 3. don't certain build modes (sbuild IIRC) ignore any alternatives in the
>first place?  If so, you'll cause a FTBFS.

You might know better if that's the case. But if build servers are ignoring 
alternatives, that's a (different) problem, right?

I recognise a potential for misuse of trivially satisfiable dependency but 
generally speaking you don't blame tool for those who misuse it...

Thanks for sharing your concerns.

Regards,
Dmitry.


-- 
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/201209082213.48035.only...@member.fsf.org

Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package

2012-09-08 Thread Dmitry Smirnov 
On Sat, 8 Sep 2012 21:06:29 Simon McVittie wrote:
> This doesn't really give enough guarantees (even if sbuild followed
> non-first branches in alternative-lists, which IIRC it doesn't). If
> champlain happens to be temporarily uninstallable on (say) powerpc at
> the time the empathy build happens, we don't want that to mean it
> randomly loses features on powerpc, then gains those features back later.

Right you're concerned that we may not always have all "optional" dependencies 
ready for build. 

I'm not quite sure this would be the case for generic unversioned 
dependencies. The assumption that "optional" packages are generally available 
from repository. If so sbuild may not build with the very latest version 
available but this is no different from current situation.

If we have an ongoing transition and some packages are temporary broken in  
"unstable" then indeed there might be a problem. 

Well, now I see it is a bit more complicated than I thought.


> It would perhaps make more sense if there was a way for the libchamplain
> maintainer to nominate excluded architectures, so empathy could say
> something like:
> 
> Build-Depends: libchamplain-...-dev |
>champlain-unavailable-on-this-arch
> 
> where champlain-unavailable-on-this-arch is arch:any, empty, and built
> on exactly those architectures that deliberately don't build champlain.
> 
> (I don't think my example works either, again because sbuild only uses
> the first alternative, but it seems closer to being right...)
> 

If only we could express that we want to build with libfoo-dev if it is 
available but avoid to demand it... :)

Regards,
Dmitry.


-- 
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/201209082234.09025.only...@member.fsf.org

Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package

2012-09-08 Thread gregor herrmann 
On Sat, 08 Sep 2012 22:01:17 +1000, Dmitry Smirnov wrote:

> On Sat, 8 Sep 2012 19:37:33 Holger Levsen wrote:
> > "optional depends" - what?? Thats self contradictory. If a depends it's
> > really optional, it's not a depends, thus that package is buggy and should
> > not be fixed by introducing a nonsense package, but by removing this
> > depends.
> Not at all, it may appears "self contradictory" only because debian/control 
> "language" doesn't have a right term for it. Or perhaps my wording is not 
> perfect. If you got the idea, can you suggest a better word?

Build-Recommends(-Indep)
 
Yes, this is a slippery slope and a can of worms (and probably some
other idioms).

But I see the use case, e.g. for packages that rebuild the
documentation if some tool is available and just skip it gracefully
and use the shipped version, if not.


Cheers,
gregor
 
-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Alanis Morisette: Head Over Feet


signature.asc
Description: Digital signature

Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package

2012-09-08 Thread Neil Williams 
On Sat, 8 Sep 2012 22:01:17 +1000
Dmitry Smirnov  wrote:

> On Sat, 8 Sep 2012 19:37:33 Holger Levsen wrote:
> > "optional depends" - what?? Thats self contradictory. If a depends it's
> > really optional, it's not a depends, thus that package is buggy and should
> > not be fixed by introducing a nonsense package, but by removing this
> > depends.
> 
> Imagine a software that builds without a certain -dev package. When present 
> this package may be used to activate an additional (optional) feature.

Builds need to be reproducible so that when there needs to be an NMU it
does not rebuild with different options merely because something extra
has been installed. DEB_BUILD_OPTIONS exists for that support.

Conditional builds are a bad idea. Specify the functionality for each
arch and ensure that a later build does not change the functionality.

This is where auto-detection in ./configure is also a bad idea -
packages should ensure that dependencies which are auto detected are
always available where supported via Build-Depends and [$arch], even
using Build-Conflicts if necessary.

> When building for as many architectures as we have, situation when some 
> dependencies are missing (or can't exist) on some architectures is not rare.

So specify that using the existing !$arch support.
 
> However we still want to build our packages with all features possible.

... but not surprise everyone when a simple binNMU for some other
reason results in a change of dependencies.

> The latter will make maintenance easier and may also be helpful for 
> backporting or even for distributions who borrow our packages but may not 
> have 
> all their build-dependencies.

Maintenance is not easier if builds at a later date give a completely
different package.

"Optional build-dependencies" are best supported via DEB_BUILD_OPTIONS
so that if the same options are always given, the build always prepares
the same package whatever else is installed on the system in question.

That is the only way to ensure that someone can safely do an NMU on the
package months after the last maintainer upload.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpSIqhQ8J3Ei.pgp
Description: PGP signature

Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package

2012-09-08 Thread Bastian Blank 
On Sat, Sep 08, 2012 at 02:43:47PM +0200, gregor herrmann wrote:
> But I see the use case, e.g. for packages that rebuild the
> documentation if some tool is available and just skip it gracefully
> and use the shipped version, if not.

How do you make sure that the uploaded packages are reproducible?

Bastian

-- 
It is undignified for a woman to play servant to a man who is not hers.
-- Spock, "Amok Time", stardate 3372.7


-- 
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/20120908130521.ga1...@wavehammer.waldi.eu.org

Re: Help me DTRT with upstream naming

2012-09-08 Thread Peter Samuelson 

[Russ Allbery]
> The problem is that the software is called wallet, both the software
> itself and the primary client binary that users invoke.  And, of
> course, we have a bunch of documentation and automation at Stanford
> that assumes that name.

That actually seems like a reasonable name to me.  I'm with Jeremy, I
guess, I think normal command-line programs have a little more reason
for shorter and simpler names than GUI and administrative software
does.

Besides, I doubt anybody would prefer that it be called WALL-Et.

(We're not really "helping you DTRT" at all, are we?)

If you rename it at all, I suggest 'nwallet', n for network.

Peter


-- 
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/20120908135334.ga6...@p12n.org

Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package

2012-09-08 Thread brian m. carlson 
On Sat, Sep 08, 2012 at 10:01:17PM +1000, Dmitry Smirnov wrote:
> On Sat, 8 Sep 2012 19:37:33 Holger Levsen wrote:
> > "optional depends" - what?? Thats self contradictory. If a depends it's
> > really optional, it's not a depends, thus that package is buggy and should
> > not be fixed by introducing a nonsense package, but by removing this
> > depends.
> 
> Not at all, it may appears "self contradictory" only because debian/control 
> "language" doesn't have a right term for it. Or perhaps my wording is not 
> perfect. If you got the idea, can you suggest a better word?
> 
> Imagine a software that builds without a certain -dev package. When present 
> this package may be used to activate an additional (optional) feature.

Debian users depend on the package being built in a consistent way.  For
example, some packages are built with Kerberos support.  While this is
generally optional for most packages, I'd be very upset if, say, the
Debian openssh-server package suddenly lost support for Kerberos because
the maintainer or someone doing an NMU didn't have the appropriate -dev
package installed, since it would mean that package would suddenly fail
to work in a major way for me.  Your proposed solution would remove an
important safety check.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package

2012-09-08 Thread gregor herrmann 
On Sat, 08 Sep 2012 15:05:21 +0200, Bastian Blank wrote:

> On Sat, Sep 08, 2012 at 02:43:47PM +0200, gregor herrmann wrote:
> > But I see the use case, e.g. for packages that rebuild the
> > documentation if some tool is available and just skip it gracefully
> > and use the shipped version, if not.
> How do you make sure that the uploaded packages are reproducible?

That's the problem I was alluding to in the paragraph before.

(In the case of docs the build result will probably not be identical
anyway, in the typical case where timestamps or tool versions are
included.)

Please note that I'm not proposing to go that way; I just wanted to
state that I understand the question of the original poster because
I've thought about something similar before.


Cheers,
gregor
 
-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: The Eagles: Take It To The Limit


signature.asc
Description: Digital signature

Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package

2012-09-08 Thread Paul Wise 
On Sat, Sep 8, 2012 at 8:43 PM, gregor herrmann wrote:

> Build-Recommends(-Indep)

I would be interested to see what real use-cases people wanted this
sort of thing for. Dimitry, which specific problem were you trying to
solve when you came up with optional-dev?

> But I see the use case, e.g. for packages that rebuild the
> documentation if some tool is available and just skip it gracefully
> and use the shipped version, if not.

We have the bootstrap stuff for that:

http://wiki.debian.org/DebianBootstrap

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/CAKTje6GgcYCVNZTcQcaH+ALav1LFHwMMn=qizxq3w3v1rnt...@mail.gmail.com

Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package

2012-09-08 Thread Guillem Jover 
Hi!

On Sat, 2012-09-08 at 17:08:34 +1000, Dmitry Smirnov wrote:
> All the above problems may be addressed by using this package as
> alternative to optional build dependency like in the example below:
> 
> Build-Depends: libchamplain-gtk-0.12-dev | optional-dev,
>libopenipmi-dev | optional-dev

As other have mentioned I don't think this package is a good idea, but
then some of the cases this tries to address (the “optional” nature of
dependencies for derivatives for example) would get covered by my
build-profiles proposal in #661538, which as stated there might need
proper discussion here, etc.

thanks,
guillem


-- 
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/20120908160648.ga12...@gaara.hadrons.org

Re: even root cannot read my symlinks!

2012-09-08 Thread jidanni 
I see.
Who knows what they'll break next.
Perhaps next time add a note to
/usr/share/doc/linux-image-486/NEWS.Debian.gz


-- 
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/87ligki2zp@jidanni.org

Bug#687057: ITP: androidsdk-tools -- A subset of the android sdk tools

2012-09-08 Thread Stefan Handschuh 
Package: wnpp
Severity: wishlist
Owner: Stefan Handschuh 

* Package name: androidsdk-tools
  Version : 14
  Upstream Author : The Android Open Source Project
* URL : https://android.googlesource.com/platform/sdk
* License : Apache 2.0
  Programming Lang: Java
  Description : A subset of the android sdk tools containing the
sdklib which is needed to 'compile' android resource files which is
a prerequisit to build apk packages.


The sdk tools are containing *some* of the android build tools. The
sources contain ddms and also the eclipse plugins. However for an
initial version, it might be sufficient to create a sdklib binary
package that is neede to 'compile' the static android resources of
an android application.


-- 
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/20120908233450.7676.4762.reportbug@m1330

Changes to cia.navi.cx -> cia.vc

2012-09-08 Thread Dmitrijs Ledkovs 
Dear all,

cia.navi.cx is deprecated, but now has stopped working.

You should use cia.vc instead.

Looking on vasks there are many team tooks that submit to cia.navi.cx
(mail mail or RPC), please update those to use cia.vc. hostname
instead.

Alioth SVN:

axel/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx
debianjr/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx
modconf/hooks/ciabot_svn.py:server = "c...@cia.navi.cx"
pgp-tools/hooks/ciabot_svn.py:server = "http://cia.navi.cx";
pkg-bet/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx
pkg-evolution/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx
pkg-freedesktop/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx
pkg-glibc/hooks/ciabot_svn.sh:cia_address="c...@cia.navi.cx"
pkg-grub/hooks/ciabot_svn.py:server = "http://cia.navi.cx";
pkg-gstreamer/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx
pkg-lighttpd/hooks/ciabot_svn.sh:cia_address="c...@cia.navi.cx"
pkg-multimedia/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx
pkg-multimedia/hooks/svnmailer.conf.bak:cia_rpc_server = http://cia.navi.cx
pkg-ocaml-maint/hooks/ciabot_svn.sh:cia_address="c...@cia.navi.cx"
pkg-parsix/hooks/svnmailer.conf.gnome:cia_rpc_server = http://cia.navi.cx
pkg-parsix/hooks/svnmailer.diff:-cia_rpc_server = http://cia.navi.cx
pkg-pulseaudio/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx
pkg-ruby-extras/hooks/ciabot_svn.py:server = "http://cia.navi.cx";
pkg-ruby/hooks/ciabot_svn.py:server = "http://cia.navi.cx";
pkg-utopia/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx
pkg-vim/hooks/ciabot_svn.sh:cia_address="c...@cia.navi.cx"
pkg-voip/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx
pkg-xfce/hooks/ciabot_svn.py:server = "http://cia.navi.cx";
pkg-xfce/hooks/svnmailer-corsac.conf:cia_rpc_server = http://cia.navi.cx
pkg-zenoss/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx
pkg-zope/hooks/ciabot_svn.py:server = "c...@cia.navi.cx"
ssmtp/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx

Are broken

Regards,

Dmitrijs.


-- 
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/canbhluhxqg_dk90oyvg7odoqtxv8ntjtvrixx+fa_kxv1kq...@mail.gmail.com

Re: greater popularity of Debian on AMD64?

2012-09-08 Thread Russell Coker 
On Sat, 8 Sep 2012, Henrique de Moraes Holschuh  wrote:
> If "64-bit PC" is too vague, the alternative designator for the amd64 arch
> is the vendor neutral "x86-64".  The vendor-neutral designator for all of
> i386, i486, i586, i686, amd64 and x32 is "x86" (i.e. it is for both 32-bit
> and 64-bit).  i286, i186 and 8086 are too old to bother with :-)

Why should we be vendor-neutral?  AMD invented the AMD64 instruction set.

Intel invented the 386 instruction set and we call it i386.

Why be vendor-neutral for things that AMD invents when we aren't vendor-
neutral for things that Intel invents?

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
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/201209091016.07379.russ...@coker.com.au

Feature suggestion: TCP-FIT congestion control

2012-09-08 Thread adm 
Hello.


I see, that Debian Wheezy comes with new congestion control named 'yeah', it's 
rather good innovation, but by my tests TCP-Fit congestion control should be 
the best for now.

More information about it you can get here: 
http://media.cs.tsinghua.edu.cn/~multimedia/tcp-fit/

It would be perfect if you'll innovate this into Wheezy. I am working with 
high-loaded machines which needs to answer properly to all millions of 
requests, tcp-fit might be useful for it. Wanna to see native support for it on 
Debian Wheezy, because for now I am using Debian Wheezy as the main platform.

You can reply me at ad...@mvpro.net.


Thanks in advance,

Alex.


-- 
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/398721347149...@web17d.yandex.ru

Re: even root cannot read my symlinks!

2012-09-08 Thread Ben Hutchings 
On Sun, 2012-09-09 at 06:06 +0800, jida...@jidanni.org wrote:
> I see.
> Who knows what they'll break next.

Do you use any particular obscure features that I could suggest?

> Perhaps next time add a note to
> /usr/share/doc/linux-image-486/NEWS.Debian.gz

I originally proposed to do this when discussing these changes on
debian-devel and debian-kernel.  However, these changes were previously
applied in other distributions and the only application found to be
affected was 'at' (which has been fixed in a stable update).

NEWS is not a listing of every change that could possibly cause a
regression.

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that everything doesn't happen at once.


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

Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package

2012-09-08 Thread Dmitry Smirnov 
On Sun, 9 Sep 2012 02:06:52 Paul Wise wrote:
> I would be interested to see what real use-cases people wanted this
> sort of thing for. Dimitry, which specific problem were you trying to
> solve when you came up with optional-dev?

Thanks Paul, primarily I was trying to address a problem when package build 
unnecessarily fails due to lack of "optional" dependency before an actual 
attempt to build.

Due to risk of FTBFS maintainer should be careful with introducing 
dependencies that are non-critical for upstream build.
In this case, enabling optional feature by adding dependency may make package 
build more fragile and create some difficulties for backporting as 
distinguishing required build-dependencies from optional ones may be not 
obvious.

Now it became clear that idea is not feasible because it creates more problem 
than it solves.

Thanks to feedback from Adam, Neil, Brian, Arno, Guillem, Simon, Geregor, 
Bastian and others I can summarise the flaws in the idea:

* buildd servers can't fall back to alternative so even if we can avoid
  FTBFS in pbuilder by providing a trivially satisfiable fallback
  dependency, that is not the case for our build servers.

* Rarely some packages may be not available for build due to transition,
  breakage or other circumstances. With silent fallback instead of FTBFS
  package may suddenly and unexpectedly lost some of its functionality.

* NMUs are not guaranteed to be the same as original package due to
  possibility of missing optional dependency packages in the environment
  where NMU is being prepared.


> > But I see the use case, e.g. for packages that rebuild the
> > documentation if some tool is available and just skip it gracefully
> > and use the shipped version, if not.
> 
> We have the bootstrap stuff for that:
> 
> http://wiki.debian.org/DebianBootstrap

Very interesting, thank you.

Regards,
Dmitry.


-- 
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/201209091109.29455.only...@member.fsf.org

Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package

2012-09-08 Thread Dmitry Smirnov 
On Sun, 9 Sep 2012 00:30:41 brian m. carlson wrote:
> Debian users depend on the package being built in a consistent way.  For
> example, some packages are built with Kerberos support.  While this is
> generally optional for most packages, I'd be very upset if, say, the
> Debian openssh-server package suddenly lost support for Kerberos because
> the maintainer or someone doing an NMU didn't have the appropriate -dev
> package installed, since it would mean that package would suddenly fail
> to work in a major way for me.  Your proposed solution would remove an
> important safety check.

Thanks for your brilliant explanation of problem.
You're certainly right but your example is also a case of possible abuse of an 
idea because you describe Kerberos as important feature which shouldn't be 
optional.


-- 
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/201209091109.51782.only...@member.fsf.org

Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package

2012-09-08 Thread Russ Allbery 
Dmitry Smirnov  writes:

> Due to risk of FTBFS maintainer should be careful with introducing 
> dependencies that are non-critical for upstream build.

I think the opposite is true for the Debian archive.  Local package builds
and derivatives may have other needs, but within the Debian archive it's
extremely important that every build of the package will produce the same
results, with the same optional features enabled and the same
configuration.  Otherwise, the package can vary in apparently random ways
between different platforms, or between one build and the next.

Therefore, for uploading packages to Debian, one should take the exact
opposite approach: be aggressive about introducing build dependencies to
ensure that the package build is reproducible and consistent, and that any
failure to produce a consistent package results in a FTBFS that preserves
the previous version until a human can look at the problem.

-- 
Russ Allbery (r...@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/87mx10vvyk@windlord.stanford.edu

Re: greater popularity of Debian on AMD64?

2012-09-08 Thread Henrique de Moraes Holschuh 
On Sun, 09 Sep 2012, Russell Coker wrote:
> On Sat, 8 Sep 2012, Henrique de Moraes Holschuh  wrote:
> > If "64-bit PC" is too vague, the alternative designator for the amd64 arch
> > is the vendor neutral "x86-64".  The vendor-neutral designator for all of
> > i386, i486, i586, i686, amd64 and x32 is "x86" (i.e. it is for both 32-bit
> > and 64-bit).  i286, i186 and 8086 are too old to bother with :-)
> 
> Why should we be vendor-neutral?  AMD invented the AMD64 instruction set.
> 
> Intel invented the 386 instruction set and we call it i386.
> 
> Why be vendor-neutral for things that AMD invents when we aren't vendor-
> neutral for things that Intel invents?

I don't know, and I don't care either way.  I am fine with amd64.

But I object to "32-bit PC" and "64-bit PC".  i686, amd64, x86-32, x86-64...
at least those are correct.  32-bit PC and 64-bit PC mean nothing, and it
will make the mess worse when we start shipping x32.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20120909014645.ga1...@khazad-dum.debian.net

Re: Changes to cia.navi.cx -> cia.vc

2012-09-08 Thread Paul Wise 
On Sun, Sep 9, 2012 at 7:39 AM, Dmitrijs Ledkovs  wrote:

> cia.navi.cx is deprecated, but now has stopped working.
>
> You should use cia.vc instead.
>
> Looking on vasks there are many team tooks that submit to cia.navi.cx
> (mail mail or RPC), please update those to use cia.vc. hostname
> instead.

If the Alioth admins (CCed) want to fix this in all repositories, they
could just run this sed command that I pasted into #alioth on IRC a
while ago:

sed -i -e 's/^\([^#]*\)cia\.navi\.cx/\1cia.vc/' /svn/*/hooks/*cia*

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/caktje6ew-pyxzrjg6hoa6-bt7fpxjmoc2wc7iv0bgocqszv...@mail.gmail.com

Re: Feature suggestion: TCP-FIT congestion control

2012-09-08 Thread Paul Wise 
On Sun, Sep 9, 2012 at 8:06 AM,  Alex wrote:

> I see, that Debian Wheezy comes with new congestion control named 'yeah', 
> it's rather good innovation, but by my tests TCP-Fit congestion control 
> should be the best for now.
...
> It would be perfect if you'll innovate this into Wheezy.

Debian Wheezy is now frozen so no new features will be added to it:

http://lists.debian.org/debian-devel-announce/2012/06/msg9.html

If you want TCP-Fit in Debian jessie (the version after wheezy), you
will need to get it included into Linux upstream and then if it
requires enabling you can file a bug against the Debian linux package
to ask the Debian Linux packaging team to enable it.

http://kernelnewbies.org/UpstreamMerge
http://www.debian.org/Bugs/Reporting

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/CAKTje6HZoD9Gu5GyXwK=tj3lbexo4x3c4fuj-yq0hv_rcmi...@mail.gmail.com

Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package

2012-09-08 Thread Paul Wise 
On Sun, Sep 9, 2012 at 9:09 AM, Dmitry Smirnov wrote:

> Thanks Paul, primarily I was trying to address a problem when package build
> unnecessarily fails due to lack of "optional" dependency before an actual
> attempt to build.

I was more wanting to know which specific problem you were trying to
fix rather than a generality.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/caktje6ep8jv7-sb4pk8tjmzubwwha+icygspno3-jehqde4...@mail.gmail.com

Re: even root cannot read my symlinks!

2012-09-08 Thread Nick Leverton 
On Sun, Sep 09, 2012 at 01:54:20AM +0100, Ben Hutchings wrote:
> On Sun, 2012-09-09 at 06:06 +0800, jida...@jidanni.org wrote:
> > I see.
> > Who knows what they'll break next.
> 
> Do you use any particular obscure features that I could suggest?

Networking, keyboards, rotating media ...

Nick


-- 
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/20120909031700.ga26...@leverton.org