Re: ftp.debian.org lacking behind and p.d.o too

[Raphael Hertzog]

On Tue, 03 Jul 2007, Daniel Leidert wrote:
> Am Dienstag, den 03.07.2007, 09:44 -0400 schrieb Anthony Towns:
> > On Mon, Jul 02, 2007 at 01:44:04PM -0400, Anthony Towns wrote:
> > > On Mon, Jul 02, 2007 at 02:48:34PM +0200, Daniel Leidert wrote:
> > > > Can someone tell me, why ftp.debian.org is lacking behind? 
> > > Apparently it's out of disk :(
> > 
> > This is now fixed. Thanks for the report.
> 
> Thanks for fixing this (saw the results already yesterday :)).

FWIW, debian-devel was not really the proper place to report this problem
(no blame though :)).
The bug had already been signaled to the RT by Joey Hess:
https://rt.debian.org/Ticket/Display.html?id=130

I poked elmo and other DSA on IRC about this problem since the PTS was
suffering from it too and it got fixed about one day later. Anthony
probably did the same (he doesn't have the ability to fix this problem
AFAIK).

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Bug#417118: ntpdate: Start sequence problem for some network setups

[Simon Kelley]

Touko Korpela wrote:

Peter Eisentraut wrote:


The network is started by /etc/rc0.d/S35networking, which starts ntpdate
when eth0 becomes "up". At that time, the local nameserver is not yet
available, it is started by /etc/rc[2345].d/S15bind9. ntpdate cannot
resolve the names of the NTP servers and fails.


That is really a more general problem: Most network services need name 
service, so whatever script is run when a network interface comes up 
will fail.


Is there any ideas to fix this? I'm having same problem with ntp+dnsmasq




Not a general solution, but an observation. It's fine to start dnsmasq 
before the network interface(s) are up, as long as the --bind-interfaces 
option is not used.


Cheers,

Simon.



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

Re: Considerations for 'xmms' removal from Debian

[Jordi Gutierrez Hermoso]

On 03/07/07, Klaus Ethgen <[EMAIL PROTECTED]> wrote:


Am Di den  3. Jul 2007 um 23:10 schrieb Josselin Mouette:
> When you talk about the "good old" XMMS, is it the one that cuts the
> sound each time you switch a workspace, or the one that randomly locks
> up when reading files over NFS?



I heard this crap only when using alsa.


which is a problem, since OSS is deprecated in favour of ALSA.

- Jordi G. H.


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

Re: uupdate: version check ?

[Bruno Costacurta]

On Monday 02 July 2007 18:24, Thijs Kinkhorst wrote:
> On Monday 2 July 2007 17:58, Frans Pop wrote:
> > On Monday 02 July 2007 17:45, Bruno Costacurta wrote:
> > > uupdate -u ../secpanel-0.5.2.tar
> > > New Release will be 0.5.2-1.
> > > uupdate: new version 0.5.2-1 <= current version 0.41+0.4.2-3; aborting!
> >
> > Looks like someone made a typo in a previous upload. 0.41 should probably
> > have been 0.4.1 (just guessing though). As it is now the "41" is greater
> > than the "5" and thus the new version is not good.
> > Looks like you'll need to add an epoch to resolve this (1:0.5.2-1).
>
> Looking at the changelog, it seems that upstream changed from numbering
> their versions from "0.41" to "0.4.2". The previous maintainer solved that
> by using the version number "0.41+0.4.2". That yields a strange version
> number. It's not needed, you can use indeed an epoch for that. Epochs (e.g.
> "1:" at the start of the version number) are intended to solve the
> situation where upstream changes the numbering scheme.
>
> I propose to indeed use 1:0.5.2-1 as the new version number, since
> 0.41+0.5.2-1 is even more ugly.
>
>
> Thijs

Works fine with epoch '1:' as you indicated.
Many thanks for attention.

Bye,
Bruno


-- 
PGP key ID: 0x2e604d51
Key : http://www.costacurta.org/keys/bruno_costacurta_pgp_key.html
Key fingerprint = 713F 7956 9441 7DEF 58ED  1951 7E07 569B 2E60 4D51
--


pgpeM7eURhWb7.pgp
Description: PGP signature

Re: Considerations for 'xmms' removal from Debian

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am Di den  3. Jul 2007 um 23:10 schrieb Josselin Mouette:
> When you talk about the "good old" XMMS, is it the one that cuts the
> sound each time you switch a workspace, or the one that randomly locks
> up when reading files over NFS?

I heard this crap only when using alsa. And even worse also if I move
the mouse. But this is not a problem of xmms than of alsa as it happens
in all applications. With OSS I never had problems like this. (In fact I
never ever had problems ever, it just works.

Regards
   Klaus Ethgen
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBRoroL5+OKpjRpO3lAQL6Wwf/czPbKSiQtWpV0olQafvyCBsFoW4dPMCL
R3Fg33IZhVHi3mgwFWocDalYrotHAlS0iclm9so5pyPUQhIhb6RLYhmoXRIO/5Ke
NTf9xyicnQ8KDrEy/sgumTOlH+u82Hpt/mYD39BggjW0dcCGTBWP8u0HmkhyXqqq
yeNrvP3k5cuC2r/KAAooHWAjH45vDL+IsB8kiDs2Z0OrXXeqQLI8plt3nIaDowrU
MyZ0DkuIGvNAAI8y2T0s87X1RSnOs9YM+SsIa66WHmCA53C+us02iypDyrSKVGPw
6qb/pmn58bV7llTv2ad36sEqZqZ5ehkLp50vxx8AwBupOjTn4uumkw==
=E/G3
-END PGP SIGNATURE-


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

Re: Missing license info in source files - fixed in upstream svn

[Ben Finney]

"Paul Cager" <[EMAIL PROTECTED]> writes:

> On Tue, July 3, 2007 8:38 am, Andreas Barth wrote:
> > Explain it in debian/copyright, that's the proper place (the
> > source files don't actually need license statement, even though of
> > course it helps transparence and is therefore encouraged).
>
> I didn't realise that. I had assumed that each source file *had* to
> have a license declaration in it.

A grant of license is ambiguous (and therefore a greater risk for
someone exercising that license) if it's not explicitly clear to a
third party which work the license applies to.

Since the easiest way to be explicit about a grant of license on a
text file is to place a license grant prominently inside the text
file, that's what is recommended for program source code.

> So if the source files do not have license declarations, we are
> still OK if there is a "COPYING" (or similar) file in the tarball?

No, there needs to be an explicit grant of license explaining what
terms apply, and exactly which files comprise the work being licensed.

-- 
 \ "Pinky, are you pondering what I'm pondering?" "I think so, |
  `\ Brain, but how will we get a pair of Abe Vigoda's pants?"  -- |
_o__)_Pinky and The Brain_ |
Ben Finney


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

Re: Bug#229357: Can we require build-arch/indep targets for lenny?

[Wouter Verhelst]

On Mon, Jul 02, 2007 at 03:28:05PM +0200, Simon Richter wrote:
>> Running debian-rules can always have side effects and can actively
>> rely on them so a "--has-target" can not be implemented cleanly in
>> make.
>
> I am proposing hooking into the logic that ultimately decides that
> there is no such target in the Makefile and goes on to print "Don't
> know how to make 'foo'. Stop.".

$(shell ls temp-target-* && rm temp-target-*):

Yes, that's broken, but there are your side effects, and you'll have to
run this code if you want to make your --has-target work.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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

Re: Bug#229357: Can we require build-arch/indep targets for lenny?

[Wouter Verhelst]

On Fri, Jun 29, 2007 at 11:11:04PM +0200, Bill Allombert wrote:
> One of the issue is that tools like sbuild and pbuilder which want to
> take advantage of the Build-Depends-Indep split needs to know whether
> dpkg-buildpackage will call debian/rules build or build-arch.

It needs to know no such thing. It just needs to know that if it runs
"dpkg-buildpackage -b", only .debs will be generated, and if it runs
"dpkg-buildpackage -B", all debs apart from the _all.debs will be
generated. How exactly this happens is of no concern to sbuild.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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

Re: Bug#417118: ntpdate: Start sequence problem for some network setups

[Marco d'Itri]

On Jul 04, Touko Korpela <[EMAIL PROTECTED]> wrote:

> Is there any ideas to fix this? I'm having same problem with ntp+dnsmasq
Hope that some day we will switch to upstart.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#417118: ntpdate: Start sequence problem for some network setups

[Touko Korpela]

Peter Eisentraut wrote:

>> The network is started by /etc/rc0.d/S35networking, which starts ntpdate
>> when eth0 becomes "up". At that time, the local nameserver is not yet
>> available, it is started by /etc/rc[2345].d/S15bind9. ntpdate cannot
>> resolve the names of the NTP servers and fails.

>That is really a more general problem: Most network services need name 
>service, so whatever script is run when a network interface comes up 
>will fail.

Is there any ideas to fix this? I'm having same problem with ntp+dnsmasq


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

Bug#431626: ITP: python-boto -- Python interface to Amazon's Web Services

[Eric Evans]

Package: wnpp
Severity: wishlist
Owner: Eric Evans <[EMAIL PROTECTED]>


* Package name: python-boto
  Version : 0.9a
  Upstream Author : Mitch Garnaat <[EMAIL PROTECTED]>
* URL : http://code.google.com/p/boto/
* License : MIT
  Programming Lang: Python
  Description : Python interface to Amazon's Web Services

Boto is a Python module used to access Amazon's Web Services. Support 
is provided for S3 (Simple Storage Service), SQS (Simple Queue 
Service), and EC2 (Elastic Compute Cloud).

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

Kernel: Linux 2.6.18-4-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/bash

-- 
Eric Evans
[EMAIL PROTECTED]


signature.asc
Description: Digital signature

Re: kile

[Steve Langasek]

On Tue, Jul 03, 2007 at 03:06:36PM -0600, Art Edwards wrote:
> In testing, kile has been removed.

That doesn't appear to be the case.

> It appears that texlive is undergoing a reorganization. As a result,
> kile's dependencies are at odds with the new organization.

I don't see this in any version of kile in etch/lenny/sid.

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


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

Re: Considerations for 'xmms' removal from Debian

[Josselin Mouette]

Le mardi 03 juillet 2007 à 20:57 +0200, Eduard Bloch a écrit :
> Unless I am able to find such
> visible problems within minutes, this program is no replacement for the
> good old XMMS.

When you talk about the "good old" XMMS, is it the one that cuts the
sound each time you switch a workspace, or the one that randomly locks
up when reading files over NFS?

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

kile

[Art Edwards]

In testing, kile has been removed. It appears that texlive is undergoing 
a reorganization. As a result, kile's dependencies are at odds with the 
new organization. When will kile be returned to the distribution?


--
Arthur H. Edwards
Senior Research Physicist
Air Force Research Laboratory
AFRL/VSSE
Bldg. 914
3550 Aberdeen Ave. SE
KAFB, NM 87117-5776

(505) 853-6042 (O)
(505) 463-6722 (C)
(505) 846-2290 (F)


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

Re: Bug#229357: Can we require build-arch/indep targets for lenny?

[Andreas Barth]

* Russ Allbery ([EMAIL PROTECTED]) [070703 20:04]:
> Ian Jackson <[EMAIL PROTECTED]> writes:
> > Steve Langasek writes ("Re: Bug#229357: Can we require build-arch/indep 
> > targets for lenny?"):
> >> Attached is a patch to dpkg which implements a check for a 'build-arch'
> >> target using 'make -f debian/rules -qn build-arch'.
> 
> > Why are we so resistant to the new debian/control field ?  That
> > doesn't require any of this messing about with make.
> 
> Agreed.  If I had my way, we'd add a Homepage debian/control field as
> well; instead we have an ugly workaround hack due to similar resistance.

I think we can still fix this mess.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: Bug#431482: Considerations for 'xmms' removal from Debian

[Adeodato Simó]

* Steve Langasek [Tue, 03 Jul 2007 13:02:50 -0700]:

> On Tue, Jul 03, 2007 at 09:31:13PM +0200, Adeodato Simó wrote:
> > * Steve Langasek [Tue, 03 Jul 2007 12:25:11 -0700]:

> > > But at a minimum, yes, the audacious-plugins package should be depending 
> > > on
> > > libaudacious by way of shlibdeps.

> > There is no NEEDED entry in the plugins against libaudaciousX.

> That's a bug in the plugins, isn't it?  Don't they refer to symbols from
> libaudacious?

Well, point. But the package level strict dependency is still needed
because you don't want audacious against lib4 and -plugins against lib5
installed at the same time. Given that, I can understand why plugins
would not DT_NEED the main library. (Is that a serious bug? I don't
think so, after all they're not directly under /usr/lib.)

> > (Which, true, solves the situation.)

This referred to the "independent migration to testing" situation.
Breakage may still occur due to partial upgrades.

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Truth is the most valuable thing we have, so let's economize it.
-- Mark Twain


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

Re: Considerations for 'xmms' removal from Debian

[Joseph Neal]

> Hi
> 
> Could you get audacious + audacious-plugins-extra from unstable and tell 
> us which formats are supported by xmms but not by audacious ?
> 

Is there is a wiki page for this?

Just at a glance, here is what I see. I've pasted the package descriptions for 
what I suspect are the most obscure ones.  You can probably track down the 
developers of these on the Hydrogen Audio forums.  Rarewares is the 
repository associated with that community. 

repositories I'm looking at:

deb http://ftp.us.debian.org/debian/ sid main contrib non-free

deb http://www.debian-multimedia.org/ sid main
deb http://www.debian-multimedia.org/ experimental main

deb http://www.rarewares.org/debian/packages/unstable/ ./
deb http://www.rarewares.org/debian/packages/experimental/ ./


Input plugins:
xmms-bonk
xmms-dtsc
xmms-dvb
Package: xmms-dvb
Version: 0.4.0-1
Architecture: i386
Maintainer: mike gan <[EMAIL PROTECTED]>
Installed-Size: 72
Depends: libc6 (>= 2.3.2.ds1-4), libglib1.2 (>= 1.2.0), libgtk1.2 (>= 
1.2.10-4), libx11-6 | xlibs (>> 4.1.0), libxext6 | xlibs (>> 4.1.0), libxi6 | 
xlibs (>> 4.1.0), xmms, xmms (>= 1.2.10-1), liblame0 (>= 3.89-1)
Filename: ./xmms-dvb_0.4.0-1_i386.deb
Size: 25100
MD5sum: ddeb8abc2f6c2fa59532590616a64b5d
Section: sound
Priority: optional
Description: direct dvb playback for xmms
 enables XMMS to directly play MPEG-1 Layer II audio streams received
 by a DVB-S PCI-Adapter compatible with the driver available from
 http://www.linuxtv.org/
xmms-la (lossless audio)
xmms-mac (monkey's audio)
xmms-musepack-sv8 (frequent sv8 SVN snapshots are available on rarewares. The 
musepack in debian is old enough to be a different beast.)
xmms-vqfplugin
xmms-adplug
xmms-sexyspc
xmms-festalon (I have no idea if game_music_emu is a  satisfactory replacement 
or not)
xmms-optimfrog
xmms-speex
xmms-a52dec

Output plugins:
xmms-encode-lame
xmms-encode-vorbis
xmms-oss-surround
Package: xmms-oss-surround
Version: 0.1-1
Architecture: i386
Maintainer: mike gan <[EMAIL PROTECTED]>
Installed-Size: 52
Depends: libc6 (>= 2.3.2.ds1-4), xmms (>= 1.2.10-1)
Filename: ./xmms-oss-surround_0.1-1_i386.deb
Size: 14798
MD5sum: d189d19cc8baa535b7507381f2224aed
Section: sound
Priority: optional
Description: oss surround sound output plugin for xmms - a52dec
 an OSS output plugin supporting surround sound.
 distributed with xmms-a52dec
xmms-rplay

I suspect the biggest one is shorten.  It's still used a lot in the legal 
bootleg / etree community. I'm not aware of anything other than xmms that 
supports it without using ffmpeg.  If xmms goes away deadhead linux users, 
which I suspect is a fair sized population, will riot.  A lot of people have 
thousands or hours of hours of audio in .shn files. 

In some cases there are plugins which provide similar functionality but are 
not the same.  There's just libmad and no libmpeg123.People have had ten 
years now to convince themselves they can hear the difference and xmms 
remains the media player of choie for adiophilles.  Between arts in KDE and 
the gnome HIG, there hasn't been a lot in recent years to convince audio 
geeks they should use anything else. 


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

Re: Bug#431482: Considerations for 'xmms' removal from Debian

[Steve Langasek]

On Tue, Jul 03, 2007 at 09:31:13PM +0200, Adeodato Simó wrote:
> * Steve Langasek [Tue, 03 Jul 2007 12:25:11 -0700]:

> > But at a minimum, yes, the audacious-plugins package should be depending on
> > libaudacious by way of shlibdeps.

> There is no NEEDED entry in the plugins against libaudaciousX.

That's a bug in the plugins, isn't it?  Don't they refer to symbols from
libaudacious?

> Do you mean hardcoding the dependency instead? (Which, true, solves the
> situation.)

Nope.

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


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

Re: Bug#229357: Can we require build-arch/indep targets for lenny?

[Adam Borowski]

On Tue, Jul 03, 2007 at 10:01:47AM -0700, Steve Langasek wrote:
> On Tue, Jul 03, 2007 at 09:54:03AM +0200, Adam Borowski wrote:
> > So, an idea: what about checking "make -f /dev/null blah 2>/dev/null" first,
> > for some portability?
> 
> What 'blah' are you planning to use that's guaranteed to not have broken
> side-effects in some cases on Debian packages?

Any 'blah' which is not found in /dev/null, I think.
I'm not aware of any local files which can break 'make -f'.

-- 
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: Bug#431482: Considerations for 'xmms' removal from Debian

[Adam Cécile (Le_Vert)]

Do you mean having the right audacious-plugins dependency on audacious
wouldn't be enough ?

Adeodato Simó a écrit :
> * Steve Langasek [Tue, 03 Jul 2007 12:25:11 -0700]:
> 
>> But at a minimum, yes, the audacious-plugins package should be depending on
>> libaudacious by way of shlibdeps.
> 
> There is no NEEDED entry in the plugins against libaudaciousX. Do you
> mean hardcoding the dependency instead? (Which, true, solves the
> situation.)
> 
> Cheers,
> 


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

Re: Bug#431482: Considerations for 'xmms' removal from Debian

[Adeodato Simó]

* Steve Langasek [Tue, 03 Jul 2007 12:25:11 -0700]:

> But at a minimum, yes, the audacious-plugins package should be depending on
> libaudacious by way of shlibdeps.

There is no NEEDED entry in the plugins against libaudaciousX. Do you
mean hardcoding the dependency instead? (Which, true, solves the
situation.)

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Acaba de...
Acaba de una vez...
Acaba de una vez conmigo
-- Astrud, Masaje


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

Re: Bug#431482: Considerations for 'xmms' removal from Debian

[Steve Langasek]

On Tue, Jul 03, 2007 at 08:46:45AM +0200, "Adam Cécile (Le_Vert)" wrote:

> I really hate circular depency and I'm not sure it's the better way. In 
> fact, audacious is broken in testing for ages and forcing a build of mcs 
> on mipsel would fix all that crap...

I wonder why audacious and audacious-plugins should be separate packages at
all instead of building them into a single binary package, given that this
circular dependency relationship exists (even if not on paper currently).

But at a minimum, yes, the audacious-plugins package should be depending on
libaudacious by way of shlibdeps.  That won't prevent all broken
combinations of coinstallable packages, but it would have prevented the
current broken combination within 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.
[EMAIL PROTECTED]   http://www.debian.org/


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

Re: Considerations for 'xmms' removal from Debian

[Eduard Bloch]

#include 
* Josselin Mouette [Tue, Jul 03 2007, 09:37:55AM]:
> Le mardi 03 juillet 2007 à 08:18 +0200, Eduard Bloch a écrit :
> > Audacious, like many other players, has this stupid concept of reading
> > every file from the filelist to get the metadata. Not really realistic
> > when acting on slow filesystems. But this is something that made XMMS so
> > much superiour over others, it was fast and lightweight.
> 
> By default, audacious only does it for files that are displayed,

I see this in strace output with default configuration. Switching the
setting between on-display and on-load makes it even worse, then it
opens every file THREE times. Sorry, wtf?

Further, it has broken SIGTERM handling. Unless I am able to find such
visible problems within minutes, this program is no replacement for the
good old XMMS.

> depending on the size of the playlist window. This feature can also be
> entirely deactivated.

I don't want to have it entirely deactivated, I want it to work then and
only then when I need this information.

Eduard.


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

Re: Bug#229357: Can we require build-arch/indep targets for lenny?

[Sam Hocevar]

On Tue, Jul 03, 2007, Steve Langasek wrote:

> > So, an idea: what about checking "make -f /dev/null blah 2>/dev/null" first,
> > for some portability?
> 
> What 'blah' are you planning to use that's guaranteed to not have broken
> side-effects in some cases on Debian packages?

   How about: "blah$((uptime;ps aux) | sha1sum | cut -f1 -d-)"

Cheers,
-- 
Sam.


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

Re: ftp.debian.org lacking behind and p.d.o too

[Daniel Leidert]

Am Dienstag, den 03.07.2007, 09:44 -0400 schrieb Anthony Towns:
> On Mon, Jul 02, 2007 at 01:44:04PM -0400, Anthony Towns wrote:
> > On Mon, Jul 02, 2007 at 02:48:34PM +0200, Daniel Leidert wrote:
> > > Can someone tell me, why ftp.debian.org is lacking behind? 
> > Apparently it's out of disk :(
> 
> This is now fixed. Thanks for the report.

Thanks for fixing this (saw the results already yesterday :)).

Regards, Daniel


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

Re: RFC: declaritive diversions

[Russ Allbery]

Steve Langasek <[EMAIL PROTECTED]> writes:

> I don't have much to contribute to a discussion (other than to say that
> the idea seems reasonable), but I would like to register my interest in
> being a pair of eyeballs for whatever spec you come up with for this.
> Currently, maintainers that use diversions tend to go through a lot of
> false starts in trying to get the ordering right, particularly when a
> diversion is dropped from a package, so it would be great to see dpkg
> make this easier.

First steps first, I know, but I'd *love* to see this done for
alternatives as well.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: RFC: declaritive diversions

[Steve Langasek]

On Tue, Jul 03, 2007 at 06:40:37PM +1000, Robert Collins wrote:
> Ian and I have chatted a few times about diversions in packages. It
> seems like it would be easier to look for packages that should divert
> (and don't), or do (and perhaps shouldn't :)) if the diversions were
> declared in the package rather than being done by turing complete
> code :).

> This is a long-promised email to kick start discussion about this.

> I don't have a proposed syntax at this point, but I was thinking a
> control file in the source such as debian/PACKAGENAME.diversions would
> be a good starting point - if thats able to record everything thats
> needed, even if the binaries stay as they are (doing diversions in the
> maintainer scripts) for now for compatibility this would improve things.

I don't have much to contribute to a discussion (other than to say that the
idea seems reasonable), but I would like to register my interest in being a
pair of eyeballs for whatever spec you come up with for this.  Currently,
maintainers that use diversions tend to go through a lot of false starts in
trying to get the ordering right, particularly when a diversion is dropped
from a package, so it would be great to see dpkg make this easier.

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


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

Re: Bug#229357: Can we require build-arch/indep targets for lenny?

[Russ Allbery]

Steve Langasek <[EMAIL PROTECTED]> writes:

> Heh, I was very much in favor of Homepage as a debian/control field; my
> objections to this use of Build-Options is not to the addition of this
> field (which also has other benefits), but to this particular use of it
> to declare information that must also be represented elsewhere in the
> package.

Yeah, I just saw your other message, and that does make sense, but I don't
trust make's ability to tell you what targets are available in the
presence of all the complex makefile tricks that Debian packages do.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Bug#229357: Can we require build-arch/indep targets for lenny?

[Steve Langasek]

On Tue, Jul 03, 2007 at 10:54:07AM -0700, Russ Allbery wrote:
> Ian Jackson <[EMAIL PROTECTED]> writes:
> > Steve Langasek writes ("Re: Bug#229357: Can we require build-arch/indep 
> > targets for lenny?"):
> >> Attached is a patch to dpkg which implements a check for a 'build-arch'
> >> target using 'make -f debian/rules -qn build-arch'.

> > Why are we so resistant to the new debian/control field ?  That
> > doesn't require any of this messing about with make.

> Agreed.  If I had my way, we'd add a Homepage debian/control field as
> well; instead we have an ugly workaround hack due to similar resistance.

Heh, I was very much in favor of Homepage as a debian/control field; my
objections to this use of Build-Options is not to the addition of this field
(which also has other benefits), but to this particular use of it to declare
information that must also be represented elsewhere in the package.

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


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

Re: Bug#229357: Can we require build-arch/indep targets for lenny?

[Steve Langasek]

On Tue, Jul 03, 2007 at 06:07:54PM +0100, Ian Jackson wrote:
> Steve Langasek writes ("Re: Bug#229357: Can we require build-arch/indep 
> targets for lenny?"):
> > Attached is a patch to dpkg which implements a check for a 'build-arch'
> > target using 'make -f debian/rules -qn build-arch'.

> Why are we so resistant to the new debian/control field ?  That
> doesn't require any of this messing about with make.

But it does require the maintainer to keep three bits of information in
sync: the new declarative Build-Options field, the build-arch target, and
the Build-Depends field.  That's added complexity which means an added
opportunity for bugs, so if the complexity can be avoided I think it's
worthwhile.

If the dpkg maintainers feel that this autodetection isn't adequate, I do
support implementing build-arch by way of Build-Options.  The benefits would
be realized more slowly, but they would be realized, and without the
insanity of making 75% of our packages FTBFS in unstable first.

> Note that the current setup does not actually require debian/rules to
> be a makefile.  I don't think we should introduce software which has a
> requirement if we can avoid it.

This doesn't require debian/rules to be a makefile either (though Policy
does), it just requires that debian/rules be a makefile *if* the package
implements build-arch and uses the corresponding semantics for
Build-Depends.

Anyway, for the perverse, the following is a valid makefile and a valid
shell script. ;)

  #!/bin/sh

  fakeout="
  build-arch: "

case "$1" in
build-arch)
echo whee fun.
;;
esac



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


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

Re: Bug#229357: Can we require build-arch/indep targets for lenny?

[Russ Allbery]

Ian Jackson <[EMAIL PROTECTED]> writes:
> Steve Langasek writes ("Re: Bug#229357: Can we require build-arch/indep 
> targets for lenny?"):
>> Attached is a patch to dpkg which implements a check for a 'build-arch'
>> target using 'make -f debian/rules -qn build-arch'.

> Why are we so resistant to the new debian/control field ?  That
> doesn't require any of this messing about with make.

Agreed.  If I had my way, we'd add a Homepage debian/control field as
well; instead we have an ugly workaround hack due to similar resistance.

I think the addition of a new control field is a nicely elegant solution
to the problem and is something we can use later on.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Source package containing HTML-only form of texinfo doc

[Jordi Gutierrez Hermoso]

On 01/07/07, Vincent Fourmond <[EMAIL PROTECTED]> wrote:

upstream source ships with HTML-only form of the octave's texinfo
documentation, which is licensed under GPL. This documentation is
actually not installed in any binary package (for many reasons).


Am I misunderstanding what you're saying? octave2.9-htmldoc contains
this exact documentation that upstream is distributing.

- Jordi G. H.


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

Re: RFC: declaritive diversions

[Ian Jackson]

Steinar H. Gunderson writes ("Re: RFC: declaritive diversions"):
> if ! dpkg --assert-declarative-diversions 2>/dev/null; then
>   dpkg --divert etc.
> fi

I would prefer to do this in dpkg-divert.  Eg
   dpkg-divert --also-declaratively-declared ...

> Given that we already seem to have such assertions in place, it doesn't sound
> too bad to me. debhelper could even generate such snippets from .diversions
> files automatically for as long as needed.

dpkg --assert... may or may not quite right during the transition,
because it talks about the installed version of dpkg rather than the
actually-running one.  We need to do a proper design for the
transition I think.

Ian.


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

Re: Bug#229357: Can we require build-arch/indep targets for lenny?

[Ian Jackson]

Steve Langasek writes ("Re: Bug#229357: Can we require build-arch/indep targets 
for lenny?"):
> Attached is a patch to dpkg which implements a check for a 'build-arch'
> target using 'make -f debian/rules -qn build-arch'.

Why are we so resistant to the new debian/control field ?  That
doesn't require any of this messing about with make.

Note that the current setup does not actually require debian/rules to
be a makefile.  I don't think we should introduce software which has a
requirement if we can avoid it.

Ian.


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

Re: Bug#229357: Can we require build-arch/indep targets for lenny?

[Ian Jackson]

Simon Richter writes ("Re: Bug#229357: Can we require build-arch/indep targets 
for lenny?"):
> The entire issue circles around not being able to reliably detect 
> whether the target is present using a simple script. But who said it has 
> to be a script?

We want the package to _declare_ whether it supports this new target.

The proposed -Options field will actually be very useful for any
other enhancements we make to the source package format.

> Proposed alternative solution:
> 
> 1. hack GNU make to support a "--has-target" option that returns an 
> appropriate return code (hey, it's free software, after all!). Proposed 
> return codes are 0 (yes), 1 (no) and 2 (error).

OMG WTF BBQ

(ie, this is a terrible suggestion)

Ian.


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

Re: Source package containing HTML-only form of texinfo doc

[Ian Jackson]

Vincent Fourmond writes ("Source package containing HTML-only form of texinfo 
doc"):
>   I am currently reviewing the qtoctave package (#430731) before
> sponsoring it. The package is now in a pretty good shape, excepted with
> a problem for which I would like to have some advice: the qtoctave
> upstream source ships with HTML-only form of the octave's texinfo
> documentation, which is licensed under GPL. This documentation is
> actually not installed in any binary package (for many reasons).

Upstream are being foolish.

>   My first reaction was that shipping this was violating the GPL and
> that the documentation should be removed. However, do you think it is
> reasonable to just add a statement to debian/copyright indicating the
> authors/copyright of this document and where to find its source code
> should be enough ? This way, no repackaging would be needed.

Unfortunately that's not good enough.  Distributing the original
tarball obviously involves distributing this html manual, but
according to the GPL we are required to distribute the corresponding
source code.

We don't have a practical way to do that, so you'll have to repack the
tarball to remove the errant parts.

Note that this applies to _anyone_ who distributes the upstream
qtoctave tarball without an exactly corresponding texinfo source for
the octave documentation, _including qtoctave upstream_.  Perhaps a
mail to the FSF's GPL violation desk is in order ?  They can probably
have a quiet word with qtoctave upstream.

Ian.


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

Re: Bug#229357: Can we require build-arch/indep targets for lenny?

[Steve Langasek]

On Tue, Jul 03, 2007 at 09:54:03AM +0200, Adam Borowski wrote:
> On Mon, Jul 02, 2007 at 09:26:23PM -0700, Steve Langasek wrote:
> > I believe the attached patch has the following characteristics:
> > - Behavior on systems where 'make' is not GNU make is undefined.
> >   Specifically, on such a system dpkg is likely to either conclude that
> >   /all/ packages support 'build-arch', or that /none/ of them support
> >   'build-arch', depending on whether and how 'make -qn' fails.

> Too bad, both Solaris and BSD make fail the bad way, returning 1 on a bad
> target -- and neither has -v or --version.  I haven't checked the rest, but
> it's likely they behave the same way.

> So, an idea: what about checking "make -f /dev/null blah 2>/dev/null" first,
> for some portability?

What 'blah' are you planning to use that's guaranteed to not have broken
side-effects in some cases on Debian packages?

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


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

Re: Missing license info in source files - fixed in upstream svn

[Frank Lichtenheld]

On Tue, Jul 03, 2007 at 04:06:11PM +0100, Paul Cager wrote:
> On Tue, July 3, 2007 8:38 am, Andreas Barth wrote:
> > Explain it in debian/copyright, that's the proper place (the source
> > files don't actually need license statement, even though of course it
> > helps transparence and is therefore encouraged).
> 
> I didn't realise that. I had assumed that each source file *had* to have a
> license declaration in it.
> 
> So if the source files do not have license declarations, we are still OK
> if there is a "COPYING" (or similar) file in the tarball? What about if
> there is no such file but there is an explicit license declaration on
> upstream's web site?

As long as you have a statement from upstream which copyright and which
license applies and this license is available in debian/copyright, you
should be fine.

You should get upstream to fix it anyway (but that seems to have happened
in your case). E.g. people sometimes don't really care
about copyright and licenses when they copy together code (there should
be enough evidence of that in Debian's BTS) but most of the time they are
also too lazy to remove the copyright and license statements contained.
Which gives people a chance to latter find out where the code came from.
If the files have neither statement, good luck with that.

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: Missing license info in source files - fixed in upstream svn

[Neil Williams]

On Tue, 3 Jul 2007 16:06:11 +0100 (BST)
"Paul Cager" <[EMAIL PROTECTED]> wrote:

> On Tue, July 3, 2007 8:38 am, Andreas Barth wrote:
> > Explain it in debian/copyright, that's the proper place (the source
> > files don't actually need license statement, even though of course it
> > helps transparence and is therefore encouraged).
> 
> I didn't realise that. I had assumed that each source file *had* to have a
> license declaration in it.

Sometimes this is not possible - generated files often would not
contain a license (glade-2).
 
> So if the source files do not have license declarations, we are still OK
> if there is a "COPYING" (or similar) file in the tarball?

As long as nothing in the source files contradicts the license.

> What about if
> there is no such file but there is an explicit license declaration on
> upstream's web site?

Most licenses require that the license is distributed alongside the
licensed work so, AFAICT, that would not be deemed to be properly
licensed.

-- 


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



pgpbQReARZkgx.pgp
Description: PGP signature

Re: RFC: declaritive diversions

[Steinar H. Gunderson]

On Tue, Jul 03, 2007 at 04:19:15PM +0100, Ian Jackson wrote:
> Ideally the setup should allow the same packages to declare diversions
> both ways.  This would make the transition a lot easier.

if ! dpkg --assert-declarative-diversions 2>/dev/null; then
dpkg --divert etc.
fi

Given that we already seem to have such assertions in place, it doesn't sound
too bad to me. debhelper could even generate such snippets from .diversions
files automatically for as long as needed.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Re: FTBFS if built twice in a row

[Mark Brown]

On Mon, Jul 02, 2007 at 09:50:52AM -0700, Russ Allbery wrote:
> Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> >> This check would fail many packages that can still be built twice in a
> >> row (any package that runs autotools during the build process without
> >> doing a complicated dance to preserve the upstream-shipped files, for
> >> example), and it's not clear to me that there's a consensus that those
> >> packages are really broken.

> > But exceedingly anoying when doing a patch and debdiff.

> Not if you use pdebuild or similarly build in a chroot, which IMO everyone
> should be doing.

I find that it's still useful to be able to do repeated edit, compile
and run cycles during development, if only for performance.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Re: RFC: declaritive diversions

[Ian Jackson]

Robert Collins writes ("RFC: declaritive diversions"):
> I don't have a proposed syntax at this point, but I was thinking a
> control file in the source such as debian/PACKAGENAME.diversions would
> be a good starting point - if thats able to record everything thats
> needed, even if the binaries stay as they are (doing diversions in the
> maintainer scripts) for now for compatibility this would improve things.

Ideally the setup should allow the same packages to declare diversions
both ways.  This would make the transition a lot easier.

Ian.


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

Re: Missing license info in source files - fixed in upstream svn

[Paul Cager]

On Tue, July 3, 2007 8:38 am, Andreas Barth wrote:
> Explain it in debian/copyright, that's the proper place (the source
> files don't actually need license statement, even though of course it
> helps transparence and is therefore encouraged).

I didn't realise that. I had assumed that each source file *had* to have a
license declaration in it.

So if the source files do not have license declarations, we are still OK
if there is a "COPYING" (or similar) file in the tarball? What about if
there is no such file but there is an explicit license declaration on
upstream's web site?


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

Re: ftp.debian.org lacking behind and p.d.o too

[Anthony Towns]

On Mon, Jul 02, 2007 at 01:44:04PM -0400, Anthony Towns wrote:
> On Mon, Jul 02, 2007 at 02:48:34PM +0200, Daniel Leidert wrote:
> > Can someone tell me, why ftp.debian.org is lacking behind? 
> Apparently it's out of disk :(

This is now fixed. Thanks for the report.

Cheers,
aj



signature.asc
Description: Digital signature

Re: synchronizing README.Debian with wiki.debian.org

[Osamu Aoki]

On Mon, Jul 02, 2007 at 04:45:41PM +0100, Jon Dowland wrote:
> On Sun, Jul 01, 2007 at 03:16:11PM +0200, Enrico Zini wrote:
> > I think more packages, and the wiki itself, could benefit
> > if this procedure could become a bit more standardised.
> 
> Can someone upload an example of a wikipage, exported as
> docbook and post-processed? I'm interested to see e.g.  what
> happens to links etc.
> 
> I think it would be worth taking a look at
> , too: it
> actually back-ends to docbook, and might be more suitable
> for maintaining large, inter-linked documents, such as the
> developer's reference.

There was a debian package at Jeremy Malcolm's web site.
 deb http://people.debian.org/~terminus binary/
 deb-src http://people.debian.org/~terminus source/

But it is gone?

> I've had a quick look at this stuff but haven't had time to
> run moinmoin output through docbook processor nor setup
> this other wiki to play yet... I might try again tonight.

Current moinmoin's docbook generation code has bugs around table if cells
are connected to span multiple ranges.  That is the most annoyng one I
see of this XML code.  Other than that it is fine.

See bug list: http://moinmoin.wikiwikiweb.de/DocBook/Bugs


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

Re: Bug#431482: Considerations for 'xmms' removal from Debian

[Adam Cécile (Le_Vert)]

Adeodato Simó a écrit :

* "Adam Cécile (Le_Vert)" [Tue, 03 Jul 2007 08:46:45 +0200]:

  

Hi Steve,



(My name is not Steve.)

  

Wasn't talking to new or mistake.

I really hate circular depency and I'm not sure it's the better way.



Well, do as Joss said and tighten the audacious-plugins dependency in
audacious, *and* introduce tight dependencies against audacious in all
the rest of plugin packages. No circular dependencies.

  

In fact, audacious is broken in testing for ages and forcing a build
of mcs on mipsel would fix all that crap...



Well, sorry but no. It is not broken in testing because of mcs not being
built, it is broken in testing because it's not packaged correctly.
  

Maybe, I didn't know how to deal with this circular dependency.
Here is what I understand, let me know if there's something wrong:
audacious 1.3.X should depends on audacious-plugins (>= 1.3) and 
audacious-plugins (<< 1.4).
That make senses now upstream and me are sure X.Y ABI will always be 
incompatible with X.Z ABI.


If it's fine I'll prepare a new upload for it, however I still can't do 
anything until mcs is built on mipsel ;)



Cheers,

  



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

Re: RFC: declaritive diversions

[Francesco P. Lovergine]

On Tue, Jul 03, 2007 at 06:40:37PM +1000, Robert Collins wrote:
> Ian and I have chatted a few times about diversions in packages. It
> seems like it would be easier to look for packages that should divert
> (and don't), or do (and perhaps shouldn't :)) if the diversions were
> declared in the package rather than being done by turing complete
> code :).
> 
> This is a long-promised email to kick start discussion about this.
> 
> I don't have a proposed syntax at this point, but I was thinking a
> control file in the source such as debian/PACKAGENAME.diversions would
> be a good starting point - if thats able to record everything thats
> needed, even if the binaries stay as they are (doing diversions in the
> maintainer scripts) for now for compatibility this would improve things.
> 

I would like also some sort of tracking for diversions, because I found
broken diversions quite often on my development sid boxes. I have not an idea 
about
that, but some sort of dpkg logging would be nice for instance...

-- 
Francesco P. Lovergine


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

Re: Bug#431482: Considerations for 'xmms' removal from Debian

[Adeodato Simó]

* "Adam Cécile (Le_Vert)" [Tue, 03 Jul 2007 08:46:45 +0200]:

> Hi Steve,

(My name is not Steve.)

> I really hate circular depency and I'm not sure it's the better way.

Well, do as Joss said and tighten the audacious-plugins dependency in
audacious, *and* introduce tight dependencies against audacious in all
the rest of plugin packages. No circular dependencies.

> In fact, audacious is broken in testing for ages and forcing a build
> of mcs on mipsel would fix all that crap...

Well, sorry but no. It is not broken in testing because of mcs not being
built, it is broken in testing because it's not packaged correctly.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny..."
-- Isaac Asimov


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

Re: Considerations for 'xmms' removal from Debian

[Adeodato Simó]

* Josselin Mouette [Tue, 03 Jul 2007 09:34:19 +0200]:

> And the sane way to fix it is to make the plugins link to the library.
> This way audacious-plugins will depend on libaudacious5 and testing
> won't be broken again.

Yah, and what happens when the application (linked against
libaudacious4) dlopens the plugins (linked against libaudacious5).

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
It is impossible to make anything foolproof because fools are so ingenious.


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

Re: synchronizing README.Debian with wiki.debian.org

[Holger Levsen]

Hi,

On Monday 02 July 2007 17:45, Jon Dowland wrote:
> Can someone upload an example of a wikipage, exported as
> docbook and post-processed? I'm interested to see e.g.  what
> happens to links etc.

try 
http://wiki.skolelinux.no/Dokumentasjon/ITIL/Samleside?action=format&mimetype=xml/docbook
 
or any other page on wiki.skolelinux.no


regards,
Holger


pgp0Qi8lvMDr2.pgp
Description: PGP signature

Bug#431536: ITP: z80dasm -- Disassembler for the Zilog Z80 microprocessor

[Tomaz Solc]

Package: wnpp
Severity: wishlist
Owner: Tomaz Solc <[EMAIL PROTECTED]>


* Package name: z80dasm
  Version : 1.0.0
  Upstream Author : Tomaz Solc <[EMAIL PROTECTED]>
* URL : http://www.tablix.org/~avian/blog/articles/z80dasm
* License : GPL
  Programming Lang: C
  Description : Disassembler for the Zilog Z80 microprocessor

The Z80 microprocessor is used in some 1980s home microcomputers, such as the
Sinclair ZX80, ZX81, Spectrum, Galaksija and in several newer devices, such
as graphical calculators from Texas Instruments and the original GameBoy.

This disassembler is useful for reverse engineering programs and operating
systems written for such devices. It produces assembly source code from binary
ROM images and tries to guess locations of labels and symbols.  Its output can
be directly converted back to binary with a Z80 assembler, such as z80asm.

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

Kernel: Linux 2.6.18-4-k7 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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: Considerations for 'xmms' removal from Debian

[Adam Cécile (Le_Vert)]

Joseph Neal a écrit :

Most of this packages are xmms plugins. Maintainers will need to port
them to xmms2 or bmpx, or they should be removed.

Other packages just depend on xmms as a mere multimedia player, and
therefore we recommend the maintainers to adjust their dependencies to
bmpx, xmms2 or audacious.

2.2 Popcon

xmms is now 1069 in the overall popcon rank, with 11029 installations,
not counting the plugin users.



There are a number of plugins available from the rarewares repository[1] and 
perhaps other third party repositories which provide the only convient way 
I'm aware of to access a number of media formats (bonk, wavepack, lossless 
audio, shorten, various DVD audio formats).  While I do not expect debian to 
support these packages, I do ask that the wider ecosystem be taken into 
consideration.


Thanks

[1] http://www.rarewares.org/index.php

  

Hi

Could you get audacious + audacious-plugins-extra from unstable and tell 
us which formats are supported by xmms but not by audacious ?



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

Re: Considerations for 'xmms' removal from Debian

[Joseph Neal]

> Most of this packages are xmms plugins. Maintainers will need to port
> them to xmms2 or bmpx, or they should be removed.
>
> Other packages just depend on xmms as a mere multimedia player, and
> therefore we recommend the maintainers to adjust their dependencies to
> bmpx, xmms2 or audacious.
>
> 2.2 Popcon
>
> xmms is now 1069 in the overall popcon rank, with 11029 installations,
> not counting the plugin users.

There are a number of plugins available from the rarewares repository[1] and 
perhaps other third party repositories which provide the only convient way 
I'm aware of to access a number of media formats (bonk, wavepack, lossless 
audio, shorten, various DVD audio formats).  While I do not expect debian to 
support these packages, I do ask that the wider ecosystem be taken into 
consideration.

Thanks

[1] http://www.rarewares.org/index.php


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

RFC: declaritive diversions

[Robert Collins]

Ian and I have chatted a few times about diversions in packages. It
seems like it would be easier to look for packages that should divert
(and don't), or do (and perhaps shouldn't :)) if the diversions were
declared in the package rather than being done by turing complete
code :).

This is a long-promised email to kick start discussion about this.

I don't have a proposed syntax at this point, but I was thinking a
control file in the source such as debian/PACKAGENAME.diversions would
be a good starting point - if thats able to record everything thats
needed, even if the binaries stay as they are (doing diversions in the
maintainer scripts) for now for compatibility this would improve things.

-Rob
-- 
GPG key available at: .


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

Re: Missing license info in source files - fixed in upstream svn

[Andreas Barth]

* Paul Cager ([EMAIL PROTECTED]) [070702 23:04]:
> I'm packaging a couple of Java libraries where the source files do not
> have any license declarations. This is being fixed in upstream's svn
> repository.
> 
> I still want to package upstream's latest *release* rather than the head
> of svn, so is it OK just to explain the situation in
> README.Debian-source (leaving the source files without license
> declarations)?

Explain it in debian/copyright, that's the proper place (the source
files don't actually need license statement, even though of course it
helps transparence and is therefore encouraged).


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: Bug#229357: Can we require build-arch/indep targets for lenny?

[Adam Borowski]

On Mon, Jul 02, 2007 at 09:26:23PM -0700, Steve Langasek wrote:
> I believe the attached patch has the following characteristics:
> - Behavior on systems where 'make' is not GNU make is undefined.
>   Specifically, on such a system dpkg is likely to either conclude that
>   /all/ packages support 'build-arch', or that /none/ of them support
>   'build-arch', depending on whether and how 'make -qn' fails.

Too bad, both Solaris and BSD make fail the bad way, returning 1 on a bad
target -- and neither has -v or --version.  I haven't checked the rest, but
it's likely they behave the same way.

So, an idea: what about checking "make -f /dev/null blah 2>/dev/null" first,
for some portability?

-- 
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: Considerations for 'xmms' removal from Debian

[Josselin Mouette]

Le mardi 03 juillet 2007 à 08:18 +0200, Eduard Bloch a écrit :
> Audacious, like many other players, has this stupid concept of reading
> every file from the filelist to get the metadata. Not really realistic
> when acting on slow filesystems. But this is something that made XMMS so
> much superiour over others, it was fast and lightweight.

By default, audacious only does it for files that are displayed,
depending on the size of the playlist window. This feature can also be
entirely deactivated.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: Considerations for 'xmms' removal from Debian

[Josselin Mouette]

Le mardi 03 juillet 2007 à 00:40 +0200, Adeodato Simó a écrit :
> > windlord:~> audacious
> > Failed to load plugin (/usr/lib/audacious/Input/libaac.so): 
> > /usr/lib/audacious/Input/libaac.so: undefined symbol: 
> > vfs_buffered_file_new_from_uri
> 
> Files in audacious-plugins are dlopened by audacious, so they don't
> depend on any libaudaciousX package. 

And the sane way to fix it is to make the plugins link to the library.
This way audacious-plugins will depend on libaudacious5 and testing
won't be broken again.

You should also enforce dependencies between audacious and
audacious-plugins in a stronger way. There is no need for a circular
dependency, you can just make audacious depend on audacious-plugins (>=
X.Y), audacious-plugins (<< X.Y+1).

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.