Cambio de fecha

[Seminario de Audiomotivación]

Queríamos avisarles que
el seminario previsto para el 26 de Abril
fue cambiado para el 3 de Mayo.

Todos aquellos interesados, pueden iongresar
a la web
http://www.todosobreventas.com/semiexcelsior.html
e inscribirse.

Desde ya muchas gracias
Mariana Mitchell
Gerente de Operaciones
www.todosobreventas.com

Re: Alternative: Source-Centric Approach [w/code]

[Freddie Unpenstein]

> > I'm wondering, what happens if you want to install MOST of the deps
> > from source? Wouldn't it be better to have apt-build (using the
> > "official apt algorithms") ask on a dep-by-dep basis whether you
> > want it compiled from source or installed from a binary?
> Which is basically what sourcerer acomplishes in a nice, transparent,
> round up fashion (upload pending some spare time).

What if I use dselect, aptitude, or any number of other similar packages as my 
package manager?  Can I select packages to be installed or upgraded?

I recognise that I may need to use your package to select packages that should 
be built from source as opposed to installed from binary packages, but can they 
be still be upgraded (via source) though my regular package manager?

My usual pattern is to update and select using dselect, download using a cron 
job with "apt-get -d dselect-upgrade", followed by installing the following day 
with "apt-get dselect-upgrade"...  What part of that process would need to 
change to support your package?


Fredderic

___
Join Excite! - http://www.excite.com
The most personalized portal on the Web!


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

Re: ITP: python-clamav -- Python bindings to ClamAV

[Stephen Gran]

This one time, at band camp, Cedric Delfosse said:
> * Package name: python-clamav
>   Version : 0.2.2
>   Upstream Author : Alexandre Norman <[EMAIL PROTECTED]>
> * URL : http://xael.org/norman/python/pyclamav/
> * License : GPL
>   Description : Python bindings to ClamAV
> 
>  This package add virus detection capabilities to Python software,
>  thanks to the ClamAV antivirus toolkit.
> 
> 
> I will create the python2.1-clamav, python2.2-clamav, python2.3-clamav,
> and python2.4-clamav packages too.
> 
> (hmm, maybe python-libclamav is a better name ?)


Be aware before you take this on that libclamav is still undergoing
fairly rapid development.  It will take a little work to keep your
package in sync with it.  It does, however, sound like a good idea.

Take care, and good luck with it,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


pgpauPhHB6Oka.pgp
Description: PGP signature

Policy for Scheme implementations supporting SRFI 22

[Jorgen Schaefer]

Hello!
The Scheme programming language is notorious for its lack of
standardization. The SRFI process[1] is trying to mitigate this
problem. Particularily, SRFI 22[2], "Running Scheme Scripts on
Unix", tries to standardize interpreter names for Scheme scripts.
This is relevant to Debian as this introduces a name conflict if
two implementations of Scheme both want to support SRFI 22, and
thus provide the same interpreter command.

This should be solved as usual by using the alternatives system. In a
talk between the package maintainers of Scheme implementations, a
policy document was formulated which expresses the ideas and
concerns of all parties involved. This policy draft can be found at

http://people.debian.org/~forcer/debian-scheme-policy/debian-scheme-policy.html/

The essence of the document is that

a) The interpreters defined in SRFI 22 should be managed by
   update-alternatives
b) Implementations should Provides: the appropriate interpreter
   names
c) Scripts should Depends: on the appropriate interpreter names

The problem with b) and c) is that there's no standard available
to portably install Scheme modules as Debian packages, which
somewhat lowers the usability of the virtual packages, as
libraries that are required for a script might not be available,
and no Depends: line will make it available. Still, this at least
allows to depend on SRFI 22 implementations.

One other concern was that this policy talks a lot, but says
little. It can be summarized easily, as seen in the enumeration
above. The proposition was to use something like this instead:

   Please use update-alternatives to provide /usr/bin/scheme-r5rs,
   /usr/bin/... if appropriate. Priorities should reflect the
   relative maturity and completeness of the implementations,
   typically ranging from 10 to 50. Packages should "Provides:
   scheme-r5rs" etc. if the named functionality provided is
   standards-complete, or nearly so.

This is of course much shorter, but lacks the examples and detail.

As for virtual packages, this policy would create:
- scheme-r4rs
- scheme-r5rs
- scheme-ieee-11878-1900
- scheme-srfi-0
- scheme-srfi-7
- scheme-srfi-55

I have not yet created the bug report against debian-policy, as
this discussion might conclude that the virtual packages should
not be created.


Any comments on the proposal, or the mentioned problems of the proposal?


Greetings,
-- Jorgen

[1] http://srfi.schemers.org/
[2] http://srfi.schemers.org/srfi-22/srfi-22.html

-- 
Debian GNU/Linux Developer
[EMAIL PROTECTED]
http://www.forcix.cx/


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

Re: Sarge release for amd64 - Please help to fix the remaining bugs

[Joey Hess]

Goswin von Brederlow wrote:
> We have daily builds and the normal upload in
> 
> http://debian-amd64.alioth.debian.org/pure64/pool/unstable/main/amd64/d/debian-installer/debian-installer-images_20041227_amd64.tar.gz
> 
> I guess you want that untared to
> /dists/sarge/main/installer-amd64/ on the new server?

Yep.

> CD images will be hosted on cdimage.debian.org along with the official
> sarge images. So far we only have netinst images build (as they are
> the most usefull and alioth doesn't have space) but the rest will
> follow. By whom or where they will be build remains to be seen.

I think there's a certian value in having all CD images built in one
place, for several reasons, but I'm still not sure if bla can accomidate
the amd64 builds.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: mplayer 1.0pre7

[Sam Morris]

A Mennucc wrote:
> mplayer 1.0pre7 is ready and packaged at
> http://tonelli.sns.it/pub/mplayer/sarge
If you are familiar with Christian Marillat's unofficial packages from 
, would you mind summarising the major 
differences between his package and yours? I'm just curious to see what 
formats, etc, had to be removed for Mplayer to be accepted into Debian.

The script that downloads binary codecs for unsupported media types is a 
nice touch. I see that it downloads the codecs from (mirrors of) 
Mplayer's own site; I guess therefore that having the script check 
cryptographic signatures of the downloaded files is out of the question. 
The script should probably be altered to check the downloaded files 
against the MD5SUMS file on the Mplayer mirrors, however.

Anyway, thanks for preparing the package and dowsing the flames; I hope 
it's accepted into the archive soon!

--
Sam Morris
http://robots.org.uk/
PGP key id 5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mplayer 1.0pre7

[Jeroen van Wolffelaar]

On Mon, Apr 25, 2005 at 04:34:41PM +0200, A Mennucc wrote:
> mplayer 1.0pre7 is ready and packaged at
> http://tonelli.sns.it/pub/mplayer/sarge
> 
> a.
> 
> ps: still no news from ftpmasters... hope they at least will try to read
>   http://people.debian.org/~mjr/mplayer.html

Right, so as an mplayer user and having an interest in its inclusion, I
took a look. Note that I'm a member of the FTP team, and occasionally do
NEW processing, but the large majority of it has been done by Joerg
Jaspert.

First thing I noticed was that it's about 700.000 lines of sourse code.
That's a lot. Of the potential issues, I'll give you my own, personal
opinion, which might or might not be shared by all ftp-masters.

- Copyright: I believe consensus is that this case is settled, thanks
to the great work by the numerous people involved

- Packaging stuff: Of course there are always nitpicks, but IMHO those
are not a consideration for whether or not to accept the package, not
in the last place because of the long time it's already in the queue.
Particular issues that itch the ftp-master that would approve the
package are IMHO best done with filing a bug after accepting, I didn't
see any serious issues in any case.

- Patents: The big issue with mplayer a.t.m. I'm myself not very
following the patent stuff, but as far as I understood, certain
patents hold by the MPEG organisation, esp. those w.r.t. encoding of
MPEG data streams, are actively being enforced, (again afaik) in the
United States in particular. See [1] for more information of what I
believe is relevant here. Unfortunately, links there mostly either
shine in unavailability (404 etc) or utter vagueness and
non-information (I couldn't find any bit of useful patenting
information at [2], for example). The FFII had more useful information
at [3].

All this seems to concentrate on MPEG-related *encoding* though, and
not to decoding. Moreover, Debian contains plenty of MPEG-related
decoding software, and the FTP-master policy at least w.r.t. audio
MPEG decoding has always been to not let supposed patents in this area
stand in the way of distributing this software, on the basis that it
seems to be an unenforceable patent, or at least, it isn't enforced
(and giving in to any patent would mean Debian could not distribute
anything). I see no reason why MPEG videa decoding would be different in
this respect, again, to the best of my knowledge.

So, adding these two tentative[4] conclusions together, it seems
likely that if mplayer were demonstrated with reasonable certainty to be
free of MPEG-encoding code, it would be acceptable for inclusion in
main as far as the FTP-masters are concerned (note: We're not (yet?)
saying it's *required* to strip MPEG encoding stuff, but in my personal
opinion, it seems likely that this is what it'll turn out to be. Don't
take my words on too much value though, maybe stripping this won't be
required after all, but in any case, if it isn't there, we don't need to
think/discuss about it -- reinclusion of the encoding stuff can then
later separately be discussed).

I must mention one big 'but' though: as mentioned above, patent stuff
isn't my expertise, and I could easily have missed a patent (or other)
issue.  MPlayer is definitely a hairy subject, unfortunately, and that's
the reason for the delay in processing it[5], it requires careful
research and reasonable deal of attention to boring patent stuff.

I hope this helps,
--Jeroen

[1] http://www.mpeg.org/MPEG/starting-points.html#ipr
[2] http://www.licensing.philips.com/information/mpeg/
[3] http://swpat.ffii.org/patents/effects/mpeg/index.en.html
[4] Barring mistakes in my reasoning
[5] The 'suboptimal' communication has other reasons that will no doubt
be talked about in the next FTP-master flame[6], so I'm not inclined
to comment on that
[6] I've not yet been informed about its ETA

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


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

Re: Sarge release for amd64 - Please help to fix the remaining bugs

[Steve Langasek]

On Mon, Apr 25, 2005 at 11:40:25AM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 25 Apr 2005, Andreas Jochens wrote:
> > Unfortunately, quite a few important packages still Build-Depend 
> > on libmysqlclient10-dev:
> > 
> > cyrus-sasl2
> > cyrus-sasl2-mit

> Frozen. I will gladly update them if the release team tells me to go ahead
> and do it.

Since dovecot, libnss-mysql, and libnss-mysql-bg have already been updated to
use libmysqlclient12, the main reason for *not* updating cyrus-sasl2, the
MTAs, and the ftp daemons (i.e.: segfaults from mixing and matching) no
longer applies.  I would accept an update of cyrus-sasl2 built against
libmysqlclient12, but I would prefer to see at least exim4 and postfix
updated first.

Ideally, we would have agreement to update all of the following packages to
libmysqlclient12 at the same time:

  courier
  cyrus-sasl2
  exim4
  linesrv
  pam-mysql
  postfix
  proftpd

Even if they weren't all done together, there's still a possibility of
segfaults because of libnss-mysql right now, so it's worth transitioning as
many of them as possible.  The only other thing to worry about is to make
sure that these packages all have licenses covered by the current MySQL
license exception.

Incidentally, I think cyrus-sasl2-mit's build-dep on libmysqlclient10-dev is
spurious and should be dropped.

Cheers,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Bug#305753: acknowledged by developer (closing 305753)

[Dan Jacobson]

m> You should be hearing from them with a substantive response shortly...
Why was it closed?


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

VT6410 support?

[Vagabond]

Hi,

I just got a new mobo, but the anoyning thing is that i'm running out
of IDE ports, only one native port on the mobo, the other 2 come with
VT6410. I found the via official driver but it seems it's quite out
dated, and won't compile against my 2.6 kernel. Is there any
alternative driver that can get the controller working? Just the basic
ide function will be OK, i'm not even think about the raid support. Or
a patch/hack to the official driver?

thanks in advance

vaga

Re: Status of PHP5?

[Piotr Roszatycki]

On Mon, 25 Apr 2005, Romain Francoise wrote:
> > I don't see any bonus in converting the YADA-based packages to the
> > other build system. I don't understand why it might be a reason for
> > rejection.
>
> Well, you co-authored yada, didn't you?  Of course it sounds ideal to
> you.  But don't you understand that other developers might not like it
> as much as you do?

I see that other developers don't like current php4 packages. There is no
php4 woody backport. I'm sure the reason is the package is horribly hard
to maintain. The much easier way is to make it from scratch. See
sources.dotdeb.org. So I did the same.

Please, don't tell the backports are unimportant. The backports.org is one
of the most important Debian sub-projects. Fortunately, some people do
really good job instead pure talking.

> I don't and in fact, I have nothing to do with PHP whatsoever.  I'm
> suggesting that you try to work with existing teams instead of doing
> your own thing in your corner and then whining when it gets rejected.
> Debian has more than 900 developers, a minimum amount of cooperation is
> necessary...  it may not work as well as you want but hijacking other
> people's packages is not a solution.

I'd like to ask one more time: where is mailing list, the repository,
project page? It doesn't seem like open project.

Cooperation? A little less conversations, more action, please. Do you know
"The cathedral and the bazaar"?

Hijacking? For 10 months there are no packages. I should start MIA
procedure. The ITP seems like to be orphaned.

-- 
.''`.Piotr Roszatycki, Netia SA
: :' :mailto:[EMAIL PROTECTED]
`. `' mailto:[EMAIL PROTECTED]
  `-


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

Re: Large ramdisks, kernel memory space issue

[Goswin von Brederlow]

salman h <[EMAIL PROTECTED]> writes:

> Hi All,
>
> I'm using a slightly modified Debian kernel along with
> PXELinux to boot a machine over the network. 
>
> My kernel's memory footprint is quite large (400 megs)
> because it pre-allocates memory for some processes (in
> the interest of speedier process execution).
>
> My ramdisk size is about 500 megs.
>
> Now, the ramdisk has to fit in the lower 1 Gig of
> memory which the kernel can access. So a ramdisk
> bigger than 500 megs cannot be loaded by the kernel,
> since the ramdisk would exceed the 1 Gig kernel memory
> space bound.
>
> My question: Is there an easy way make the Linux
> kernel be able to access the entire memory space? This
> way I can easily load larger ramdisks on my target
> machines which have 2 Gigs of physical memory.
>
> Thanks, 
>
> Salman

Just a thought but why not load the ramdisk yourself.

Write a small initrd that sets up large ramdisk and downloads an image
from the network.

MfG
Goswin


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

Re: Automatic testing of Debian packages

[Goswin von Brederlow]

Mads Lindstrøm <[EMAIL PROTECTED]> writes:

>...
> Do there exist, any other kind of automatic tests that I have not
> mentioned here?
>
> Anything else I have missed?
>
> Which errors are typical for Debian packages? This is important as
> certain kinds of error will properly newer be caught automatically.

Here are some ideas from my sourcerer-buildd package:

Before build:
- build source package and compare contents against original

After build:
- build source package and compare again
- installing package from scratch
- remove and reinstall package
- purge package
- install stable/testing version and update package
- install stable/testing version, remove it and install package
- install/update/remove/purge package and then abort action
- unpack package before all its Depends
- configure package first in a Depends cycle

Some extra tests:
- build against stable/testing versions if Build-Depends allow
- build binary package twice (if this fails the clean test should fail
already)
- build binary package with itself installed
(cyclic Build-Depends like gcc, ghc, ...)
- build some reverse Build-Depends with this package installed

MfG
Goswin


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

Re: Sarge release for amd64 - Please help to fix the remaining bugs

[Goswin von Brederlow]

[EMAIL PROTECTED] (Andrew M.A. Cater) writes:

> On Mon, Apr 25, 2005 at 11:32:25AM +0200, Andreas Jochens wrote:
>> Debian sarge release for the amd64 architecture
>> ---
>> 
>> At the amd porters irc meeting on 2005-04-23 07:00 UTC, the amd64 porting
>> team decided to release a version of sarge for amd64 which is based on the 
>> unpatched Debian sarge source packages. 
>>
> This is good news for at least some of the users I support :)
>
> I run a full mirror of Debian here: can you please advise precisely what 
> else I need to mirror?

In a while you add a mirror of
http://debian-amd64.alioth.debian.org/debian. That will roughly be
what is currently
http://debian-amd64.alioth.debian.org/debian-pure64/.

> Has the amd64 / pure64 split been sorted out yet: which amd distribution
> is this?  If this is "straight amd64", should I also be making plans to
> mirror pure64 / amd64-gcc4.0 or whatever it's to be called?

The new server will be running Debians DAK suite and hopefully debians
original arch:all packages (what was named debian-amd64) instead of
rebuild packages (what was named debian-pure64). We still have to
convince the DAK to do it though.

An incremental (as in only files not already on a normal debian
mirror) view of the amd64 archive might or might not be provided in
the future. Haven't talked to ganneff about that yet.


The gcc-3.4/4.0 branch will be split of complety as a seperate alioth
project and will be rebuild completly with the now released gcc-4.0
for another round of bug finding. That branch is highly experimental
and not for general use. I highly doubt there is any use in mirroring
it.

> Sorry to be so entirely thick and stupid but it is not
> altogether clear.  With apologies for extraneous noise :)
>
> Andy

MfG
Goswin


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

Re: Status of PHP5?

[Joerg Jaspert]

On 10270 March 1977, Piotr Roszatycki wrote:

> * easy way to manage the patches
> * easy way to generate the packages for different Debian suites - 
> experimental/sid/sarge/woody - from one source (ifdef..else..endif)
> * simple includes with macros so I don't need to write the same code 40 times 
> for each module (for build/installation/control scripts)

Its a tool where everything is written in one file, and then something
generates the debian/ out of it. I cant see how that should be good, sorry.
The feature to generate stuff for different suites isnt that important -
we package for unstable (and sometimes for experimental), *nearly* never
for stable or testing directly. So this is a 0 pointer.

Simple includes - ever heard of Makefile targets? Yes, 2 different
targets like build/binary-all can depend on the same target to do stuff.
And for the shellscripts to be run on users system: write one with
common tasks in it in functions, include that whenever you need it and
call the functions...

So, it may make *your* life easier, as one author of it, dont think that
everyone else may like it.

> Yes, I know the better tool. It is RPM but we are Debian world and I don't 
> see 
> any better than YADA for Debian, yet.

Switch to an rpm based one?
Better tools for such big, popular packages are any tools that are
widely used and as such known to many people.
Like debhelper or cdbs.

> I don't understand why it might be a reason for rejecting the packages. At 
> least somebody could convert it to the other system AFTER releasing 
> YADA-based packages.

Experience shows that it is easy to get a change down BEFORE you accept
a package. After you accepted some/most/many/... maintainers dont
care much. "Hell, its in, shut up".

-- 
bye Joerg
>From a NM after doing the license stuff:
I am glad that I am not a lawyer!  What a miserable way to earn a living.


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

Re: Sarge release for amd64 - Please help to fix the remaining bugs

[Goswin von Brederlow]

Joey Hess <[EMAIL PROTECTED]> writes:

> Andreas Jochens wrote:
>> Debian sarge release for the amd64 architecture
>> ---
>> 
>> At the amd porters irc meeting on 2005-04-23 07:00 UTC, the amd64 porting
>> team decided to release a version of sarge for amd64 which is based on the 
>> unpatched Debian sarge source packages. 
>> 
>> The amd64 porting team will provide security support for the sarge release
>> by autobuilding the security updates as soon as the fixed sources become
>> available.
>> 
>> Proposed updates and updated versions for Debian sarge point releases 
>> will also be made available for amd64 by the amd64 porting team.
>> 
>> The package archive for the Debian amd64 sarge port will be hosted by
>> a Debian server which is located in Darmstadt, Germany. 
>> The complete debian-amd64 project will move from the current alioth host 
>> to that server.
>
> Well it's nice to see this happening. About the installer, I assume
> you'll be including builds of the debian-installer package on your new
> server, including the "byhand" images it generates. If those images test
> out ok and you give me a url for that, I can add it to
> http://www.debian.org/devel/debian-installer/ where we have the rc3
> release, which will probably soon be renamed to the sarge r0 release.

We have daily builds and the normal upload in

http://debian-amd64.alioth.debian.org/pure64/pool/unstable/main/amd64/d/debian-installer/debian-installer-images_20041227_amd64.tar.gz

I guess you want that untared to
/dists/sarge/main/installer-amd64/ on the new server?

> If you also build netinst, businesscard, full CD, and/or DVD images
> against sarge, using the udebs and installer images in sarge (not daily
> builds), we can also links for them to that page. And probably to the
> other CD pages on the website, although that may need help from the CD
> and/or web teams. It's also possible that the CD team could do these
> builds for you (we've also moved to a new build server and it could
> possibly add an amd64 mirror), though I haven't discussed this with the
> rest of the team yet.

CD images will be hosted on cdimage.debian.org along with the official
sarge images. So far we only have netinst images build (as they are
the most usefull and alioth doesn't have space) but the rest will
follow. By whom or where they will be build remains to be seen.

MfG
Goswin


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

Re: ITP: python-clamav -- Python bindings to ClamAV

[Jérôme Marant]

Josselin Mouette <[EMAIL PROTECTED]> writes:

>> Wasn't there a python-central project aiming at handling byte-compiling
>> of python modules for any python version installed on a system?
>> (like emacsen-common)
>
> That wouldn't work for most of the python packages, for which a C module
> has to be built against each python major version.

Right.

-- 
Jérôme Marant

Re: FTBFS for illegal archs

[Goswin von Brederlow]

Nico Golde <[EMAIL PROTECTED]> writes:

> Hi,
> does anyone knows a solution to let packages FTBFS on
> buildd's which architecure are not supported by the
> software?
> regards nico
>
> -- 
> Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF
> http://www.ngolde.de | http://www.muttng.org | http://grml.org 
> VIM has two modes - the one in which it beeps 
> and the one in which it doesn't -- encrypted mail preferred

Some things should be noted:

1. the Archtecture line of the source is relevant
  - sources with only arch dependend packages only list relevant archs
Sbuild checks for this and skips bad packages.

  - sources with also arch independend packages are arch any
This gives a false positve with sbuild and the package builds
often up until dpkg-gencontrol fails to find a matching arch.

  It would be nice to get the Architecture field to list e.g. "all
  i386 x86_64" in those cases instead of "any".

2. Build-Depends may not be on (purely) virtual packages
   A "Build-Depends: i386 | x86_64" does not work. Instead the
   following can be used:

   Build-Depends: type-handling
   Build-Conflicts: alpha arm hppa darwin-i386 freebsd-i386 hurd-i386 
kfreebsd-i386 knetbsd-i386 netbsd-i386 openbsd-i386 ia64 m68k mips mipsel 
darwin-powerpc powerpc s390 s390x sh3 sh3eb sh4 sh4eb sparc sparc64

   The right Build-Conflicts can (should) be generate with e.g.
   type-handling -n i386,x86_64 linux

3. debian/rules can check the arch
   Some package should build on archs but don't, e.g. kernel-patch-arch
   packages that are arch:all still only build on their own arch none
   the less. Others should fail but instead do serious harm to buildds
   if tried on the wrong arch, e.g. kernel-patch packages going into
   an endless loop.

4. packages-arch-specific can remove packages from being autobuild on
   certain archs at all
   This, unlike 2 or 3 above, actualy prevents the buildd and buildd
   admins from wasting any time on your package. It does not help
   developers that try to build your package though.

MfG
Goswin


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

Re: Status of PHP5?

[Romain Francoise]

Piotr Roszatycki <[EMAIL PROTECTED]> writes:

> I don't see any bonus in converting the YADA-based packages to the
> other build system. I don't understand why it might be a reason for
> rejection.

Well, you co-authored yada, didn't you?  Of course it sounds ideal to
you.  But don't you understand that other developers might not like it
as much as you do?

> For 6 month I see nothing. Where are the packages? The people need
> them. I'm not just talking. I'm working on _my_ packages and I'm doing
> it as well as I can do it. Do you have better packages? So please
> upload it into incoming. Or just allow me to make a good job on
> them. Don't obstruct the Debian project.

I don't and in fact, I have nothing to do with PHP whatsoever.  I'm
suggesting that you try to work with existing teams instead of doing
your own thing in your corner and then whining when it gets rejected.
Debian has more than 900 developers, a minimum amount of cooperation is
necessary...  it may not work as well as you want but hijacking other
people's packages is not a solution.

Cheers,

-- 
  ,''`.
 : :' :Romain Francoise <[EMAIL PROTECTED]>
 `. `' http://people.debian.org/~rfrancoise/
   `-


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

Re: ITP: python-clamav -- Python bindings to ClamAV

[Josselin Mouette]

Le lundi 25 avril 2005 à 22:48 +0200, Jérôme Marant a écrit :
> > Please don't, unless this is really necessary. We already have enough
> > duplicate python packages in the archive. Except for very widely used
> > modules, there should only be a python-foo package, built against the
> > default version in sid.
> 
> Wasn't there a python-central project aiming at handling byte-compiling
> of python modules for any python version installed on a system?
> (like emacsen-common)

That wouldn't work for most of the python packages, for which a C module
has to be built against each python major version.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

Re: ITP: python-clamav -- Python bindings to ClamAV

[Jérôme Marant]

Josselin Mouette <[EMAIL PROTECTED]> writes:
 
>> I will create the python2.1-clamav, python2.2-clamav, python2.3-clamav,
>> and python2.4-clamav packages too.
>
> Please don't, unless this is really necessary. We already have enough
> duplicate python packages in the archive. Except for very widely used
> modules, there should only be a python-foo package, built against the
> default version in sid.

Wasn't there a python-central project aiming at handling byte-compiling
of python modules for any python version installed on a system?
(like emacsen-common)

Cheers,

-- 
Jérôme Marant

Re: Alternative: Source-Centric Approach [w/code]

[Goswin von Brederlow]

"Freddie Unpenstein" <[EMAIL PROTECTED]> writes:

>> > Your priority are your users, and if Debian has decided to focus
>> > only on some key architectures it would be the best for them to
>> > help them switching to Gentoo instead of hacking Debian to become
>> > some cheap Gentoo clone for most architectures.
>
>> I don't view this as being a cheap Gentoo clone.  In fact, I view
>> srcinst as being the Gentoo idea, done right.  Gentoo has a lot of
>> problems, especially relating to difficult upgrades.  Because of 
>> our superior packaging system, we are in a great position to hit
>> the ground running and, with a little help from something like
>> srcinst, come up with something that works -- and works better than
>> Gentoo -- in a short amount of time.
>
> I'm wondering, what happens if you want to install MOST of the deps from 
> source?  Wouldn't it be better to have apt-build (using the "official apt 
> algorithms") ask on a dep-by-dep basis whether you want it compiled from 
> source or installed from a binary?
>
> Even better, would be to allow apt's preferences file to state whether a 
> specific package should be installed from binary or source, and have the 
> stock "apt-get install" do what's appropriate.  With a few options to set the 
> default mode (binary or source), and to overide the mode for specific 
> packages.  And of course, last but not least, apt should keep the package 
> comming from the same source unless specifically changed.
>
>
> Now, if only apt-get understood that a pacakge may be available from more 
> than one mirror at a time...
>
> Fredderic

Which is basically what sourcerer acomplishes in a nice, transparent,
round up fashion (upload pending some spare time).

sourcerer-archive maintains a local archive of selected sources and
packages from various sources (debian mirrors or incoming
queue). E.g. mirror all installed packages and sources.

sourcerer-watcher watches for apt activity and can update the
selection of sourcerer-archive automatically. On "apt-get install
foobar" foobar gets added to the package list, on purge it gets
removed.

sourcerer-buildd finaly builds selected packages from the archive and
uploads it to the archive again. Local gcc options can be enforced,
e.g. to optimize for i686, and the version is modified bumping the 4th
part of the debian revision (debian only uses 3) to generate a version
higher than this one and lower than any debian upload.


With this and apts pining it is trivial to install and update a system
with only locally build debs or with the prebuild debs as fallback for
the first install or as fallback for anything yet unbuild or build
failures.

This also has one big advantage over apt-get install from source: You
do not have to wait for the compile to finish. The nightly cron job
will start the build and the new debs will be ready for install in the
morning.

MfG
Goswin


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

Re: ITP: python-clamav -- Python bindings to ClamAV

[Cedric Delfosse]

Le lundi 25 avril 2005 à 22:00 +0200, Josselin Mouette a écrit :
> > [...]
> > I will create the python2.1-clamav, python2.2-clamav, python2.3-clamav,
> > and python2.4-clamav packages too.
> 
> Please don't, unless this is really necessary. We already have enough
> duplicate python packages in the archive. Except for very widely used
> modules, there should only be a python-foo package, built against the
> default version in sid.

Hmmm I agree with you.
But I will package all of them if some users ask me for them.

Regards,

-- 
Cédric Delfosse, http://cdelfosse.free.fr
Jabber ID: [EMAIL PROTECTED]
Get a free backup server: http://lrs.linbox.org !
Linbox: http://linbox.com


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

Re: Sarge release for amd64 - Please help to fix the remaining bugs

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Debian sarge release for the amd64 architecture

Yes! Very good move. Congrats. Keep it up.

Greetings
Bernd


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

Re: Status of PHP5?

[Martin Geisler]

Romain Francoise <[EMAIL PROTECTED]> writes:

> 5. Your packages use a radically different build system (yada) that not
>all developers are comfortable with (understatement);
>
> 6. Your packages include patches that may not be suitable for general
>use in Debian (like Hardened PHP);

I'm don't know enough to discuss the pros or cons of the choices made
by Piotr Roszatycki when preparing his PHP5 packages, but shouldn't
one also take into account the amount of time (about 10 months) we
have been waiting for PHP5 packages?

I mean --- people are waiting for official Debian packages, so perhaps
these packages could be used until the official PHP group within
Debian gets some packages done.

-- 
Martin Geisler  My GnuPG Key: 0x7E45DD38

PHP EXIF Library  |  PHP Weather |  PhpShell
http://pel.sf.net/|  http://phpweather.net/  |  http://gimpster.com/
Read/write EXIF data  |  Show current weather|  A shell in a browser


pgpQsoTtYFtIZ.pgp
Description: PGP signature

Re: Status of PHP5?

[Piotr Roszatycki]

On Monday 25 of April 2005 19:57, Joerg Jaspert wrote:
> I cant see much coordination with existing php maintainer(s). As far as I
> know they/he informed you about the project on alioth.

Where is mailing list, the home page for the project, the CVS or SVN 
repository? I was sent to /dev/null.

> And then there is this yada packaging you used.
> Nothing against it, whoever wants it can use it[1] - but for such a popular
> package that probably will receive a lot of help from different people
> this is IMO the worst thing ever to choose.
> Something that is known to many,like debhelper, cdbs, whatever is for
> sure the better thing to use.
>
> [1] No flamewar against it intended.

Do you know the system which gives me:

* easy way to manage the patches
* easy way to generate the packages for different Debian suites - 
experimental/sid/sarge/woody - from one source (ifdef..else..endif)
* simple includes with macros so I don't need to write the same code 40 times 
for each module (for build/installation/control scripts)

The people just use the php5 package and modifies it on they own. They are 
sysadmins, not Debian developers. I've some emails about that.

Yes, I know the better tool. It is RPM but we are Debian world and I don't see 
any better than YADA for Debian, yet.

I don't understand why it might be a reason for rejecting the packages. At 
least somebody could convert it to the other system AFTER releasing 
YADA-based packages.

-- 
 .''`.Piotr Roszatycki, Netia SA
: :' :mailto:[EMAIL PROTECTED]
`. `' mailto:[EMAIL PROTECTED]
  `-


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

Re: ITP: python-clamav -- Python bindings to ClamAV

[Josselin Mouette]

Le lundi 25 avril 2005 à 21:55 +0200, Cedric Delfosse a écrit :
> * Package name: python-clamav
>   Version : 0.2.2
>   Upstream Author : Alexandre Norman <[EMAIL PROTECTED]>
> * URL : http://xael.org/norman/python/pyclamav/
> * License : GPL
>   Description : Python bindings to ClamAV
> 
>  This package add virus detection capabilities to Python software,
>  thanks to the ClamAV antivirus toolkit.
> 
> 
> I will create the python2.1-clamav, python2.2-clamav, python2.3-clamav,
> and python2.4-clamav packages too.

Please don't, unless this is really necessary. We already have enough
duplicate python packages in the archive. Except for very widely used
modules, there should only be a python-foo package, built against the
default version in sid.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

Re: Sarge release for amd64 - Please help to fix the remaining bugs

[Andreas Jochens]

Andrew M.A. Cater wrote:
> On Mon, Apr 25, 2005 at 11:32:25AM +0200, Andreas Jochens wrote:
>> Debian sarge release for the amd64 architecture
>> ---
>> 
>> At the amd porters irc meeting on 2005-04-23 07:00 UTC, the amd64 porting
>> team decided to release a version of sarge for amd64 which is based on the 
>> unpatched Debian sarge source packages. 
>>
> This is good news for at least some of the users I support :)
>
> I run a full mirror of Debian here: can you please advise precisely what 
> else I need to mirror?

The basic source of information for amd64 archive and mirror questions is

http://debian-amd64.alioth.debian.org/archive-structure.txt

However, please note that this structure is not yet fully in place.

An announcement will be made when the move to the new host has been 
completed and the structure has been set up.

> Has the amd64 / pure64 split been sorted out yet: which amd distribution
> is this?  If this is "straight amd64", should I also be making plans to
> mirror pure64 / amd64-gcc4.0 or whatever it's to be called?

There will only be one official amd64 archive. That archive will follow 
the unpatched Debian stable, testing and unstable distributions.

The current amd64/gcc-4.0 archive will be continued in a separated 
project to sort out any remaining issues for Debian's planned move to 
gcc-4.0 for etch. Now that gcc-4.0 has been officially released, 
the gcc-4.0 archive will be recompiled from scratch and reuploaded 
to a different location. Details will be announced as soon as this 
has been completed.

Regards
Andreas Jochens


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

ITP: python-clamav -- Python bindings to ClamAV

[Cedric Delfosse]

* Package name: python-clamav
  Version : 0.2.2
  Upstream Author : Alexandre Norman <[EMAIL PROTECTED]>
* URL : http://xael.org/norman/python/pyclamav/
* License : GPL
  Description : Python bindings to ClamAV

 This package add virus detection capabilities to Python software,
 thanks to the ClamAV antivirus toolkit.


I will create the python2.1-clamav, python2.2-clamav, python2.3-clamav,
and python2.4-clamav packages too.

(hmm, maybe python-libclamav is a better name ?)

-- 
Cédric Delfosse, http://cdelfosse.free.fr
Jabber ID: [EMAIL PROTECTED]
Get a free backup server: http://lrs.linbox.org !
Linbox: http://linbox.com


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

Bug#306328: ITP: scavr -- Squid ClamAV Redirector

[Cedric Delfosse]

Package: wnpp
Severity: wishlist
Owner: Cedric Delfosse <[EMAIL PROTECTED]>

* Package name: scavr
  Version : 1.6.3
  Upstream Author : Michael Lang <[EMAIL PROTECTED]>
* URL : http://www.jackal-net.at/tiki-read_article.php?articleId=1
* License : GPL
  Description : Squid ClamAV Redirector

 Squid ClamAV Redirector is a Squid helper script to get virus scanning for
 defined extensions (for example .exe, .com, .bat ...), thanks to the Clam
 AntiVirus toolkit.
 .
 SCAVR handles the request as given from Squid, downloads the URL and scans it
 for known virus. If a file is infected, it rewrites the URL from Squid to a
 blocked URL or to an info page with scanning results.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-1-686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: Status of PHP5?

[Piotr Roszatycki]

On Monday 25 of April 2005 20:18, Romain Francoise wrote:
> Piotr Roszatycki <[EMAIL PROTECTED]> writes:

> You forgot:
>
> 5. Your packages use a radically different build system (yada) that not
>all developers are comfortable with (understatement);

No one was interested in converting it to the other system. I see no problem 
as far as I'd like to see ANY official php5 package. The YADA is very easy 
and powerful tool and I allowed me to make a packages quickly. I can use the 
same source for sid, sarge and woody release. The includes and macros gives 
me possibility to reuse the code. The patches are handled very comfortable. I 
don't see any bonus in converting the YADA-based packages to the other build 
system. I don't understand why it might be a reason for rejection.

> 6. Your packages include patches that may not be suitable for general
>use in Debian (like Hardened PHP);

Did you analyse the patch? It doesn't break binary compatibility with 
non-patched binaries. It shouldn't break anything. At least it could be easly 
removed without breaking anyting ease. I need the BTS so the people could 
send the reports. I've got many on my mailbox. They asked, why there is no 
official php5.

> 7. As far as I can tell, you didn't discuss any of your proposed changes
>beforehand and presented your packages as final without justification.
>If you had presented a rationale for each change, and worked with the
>PHP maintainers to create your php5 packages, you might have had more
>success.

For 6 month I see nothing. Where are the packages? The people need them. I'm 
not just talking. I'm working on _my_ packages and I'm doing it as well as I 
can do it. Do you have better packages? So please upload it into incoming. Or 
just allow me to make a good job on them. Don't obstruct the Debian project.

-- 
 .''`.Piotr Roszatycki, Netia SA
: :' :mailto:[EMAIL PROTECTED]
`. `' mailto:[EMAIL PROTECTED]
  `-


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

Re: Sarge release for amd64 - Please help to fix the remaining bugs

[Andreas Jochens]

Hello Kurt,

thank you for the clarifications.

On 05-Apr-25 19:49, Kurt Roeckx wrote:
> On Mon, Apr 25, 2005 at 11:32:25AM +0200, Andreas Jochens wrote:
> > gnustep-base -  +  does not build with gcc-3.3 (needs gcc >= 3.4)
> It looks like it builds fine with gcc-3.3.  But if my memory is
> any good, it (used to?) miscompile it?

Yes, gcc-3.3 used to miscompile gnustep-base on amd64. The build
of many gnustep-related packages stopped with something like 
"autogsdoc ... error" if I remember correctly. 

I have to re-check if this is still the case.

> > libgtk-java  - java.lang.NullPointerException
> There are alot of java package that fail to build and I still
> have to track those down.  Those are ussually not the fault of
> the package itself.  They're also arch all, so you can get them
> from the archive anyway.

kaffe used to work fine for quite some time on amd64, but the latest
versions either stop with "java.lang.NullPointerException" or get into
an endless loop when I try to build a java package. Unfortunately,
libgtk-java is not arch:all. We need to get kaffe fixed somehow :)

> > portslave- "pppd.h: No such file or directory"
> ??

This was a problem with an older version of ppp that seems to be fixed. 
portslave builds fine now.

> > tela - configure: error: "Blas not found!"
> ??

I still have to check this one further.

Regards
Andreas Jochens


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

Re: Sarge release for amd64 - Please help to fix the remaining bugs

[Andrew M.A. Cater]

On Mon, Apr 25, 2005 at 11:32:25AM +0200, Andreas Jochens wrote:
> Debian sarge release for the amd64 architecture
> ---
> 
> At the amd porters irc meeting on 2005-04-23 07:00 UTC, the amd64 porting
> team decided to release a version of sarge for amd64 which is based on the 
> unpatched Debian sarge source packages. 
>
This is good news for at least some of the users I support :)

I run a full mirror of Debian here: can you please advise precisely what 
else I need to mirror?

Has the amd64 / pure64 split been sorted out yet: which amd distribution
is this?  If this is "straight amd64", should I also be making plans to
mirror pure64 / amd64-gcc4.0 or whatever it's to be called?

Sorry to be so entirely thick and stupid but it is not
altogether clear.  With apologies for extraneous noise :)

Andy


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

Re: mplayer 1.0pre7

[David Nusinow]

On Mon, Apr 25, 2005 at 08:51:04PM +0200, Joerg Jaspert wrote:
> On 10270 March 1977, Petter Reinholdtsen wrote:
> 
> > The list used to be >200 packages long.  It is now ~20 packages long.
> 
> It was somewhere around 600.

Showoff :-)

(Thank you and the other ftpmasters for blasting through the queue so fast)

 - David Nusinow


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

Re: mplayer 1.0pre7

[Joerg Jaspert]

On 10270 March 1977, Petter Reinholdtsen wrote:

> The list used to be >200 packages long.  It is now ~20 packages long.

It was somewhere around 600.

-- 
bye Joerg
"Paris Hilton" is a woman? Not a hotel? This thread gets more surreal
with every post...
<[EMAIL PROTECTED]>


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

Re: Status of PHP5?

[Romain Francoise]

Piotr Roszatycki <[EMAIL PROTECTED]> writes:

> The facts are:

[...]

You forgot:

5. Your packages use a radically different build system (yada) that not
   all developers are comfortable with (understatement);

6. Your packages include patches that may not be suitable for general
   use in Debian (like Hardened PHP);

7. As far as I can tell, you didn't discuss any of your proposed changes
   beforehand and presented your packages as final without justification.
   If you had presented a rationale for each change, and worked with the
   PHP maintainers to create your php5 packages, you might have had more
   success.

Cheers,

-- 
  ,''`.
 : :' :Romain Francoise <[EMAIL PROTECTED]>
 `. `' http://people.debian.org/~rfrancoise/
   `-


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

Re: Sarge release for amd64 - Please help to fix the remaining bugs

[Kurt Roeckx]

On Mon, Apr 25, 2005 at 07:36:36PM +0200, Adrian von Bidder wrote:
> 
> Does that mean amd64 installer come without a mailer by default? Or will the 
> amd64 installer install a different mailer?

The problem is that the old version of libmysqlclient-lgpl was
build before we switched to an nptl only libc, and build fine at
that point.  It's still in the archive like that.  It also builds
fine if you just disable the configure check.

Packages like postfix and exim4 can be build and installed
without problems, the problem is more that the archive can't be
rebuild from sources.


Kurt


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

Re: mplayer 1.0pre7

[Jeroen van Wolffelaar]

On Mon, Apr 25, 2005 at 07:53:50PM +0200, Adeodato Sim? wrote:
> * Russ Allbery [Mon, 25 Apr 2005 10:47:13 -0700]:
> 
> > it's more clear what's going on; some packages are sitting, but most
> > things are being approved very quickly.  mplayer (and hot-babe) are among
> > the ones that are sitting.
> 
>   And as I learnt yesterday, some of the ones "sitting" are still there
>   because the maintainer hasn't reacted in weeks to mail from ftpmaster
>   pointing out obvious problems with the package.
> 
>   Perhaps it'd be nice in the long term add a column with a short note
>   enumerating the problems, or to CC the ITP bug the mail sent to the
>   maintainer. This way, if a maintainer goes MIA, other interested
>   people can know that the ball is in the maintainer's roof, not in
>   ftpmasters', and offer to help.

Just for the record, while this is true for some packages, this is not
the case for mplayer -- the ball is at ftp-masters.

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


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

Re: Status of PHP5?

[Joerg Jaspert]

On 10270 March 1977, Piotr Roszatycki wrote:

> 1. The ftpmaster was a member of pkg-php project, he boycotts my work and 
> don't offer something else.

Im not a member of the php project and I would have rejected it too, I
dont think it has anything todo with jvw beeing intrested in php stuff...

I cant see much coordination with existing php maintainer(s). As far as I
know they/he informed you about the project on alioth.

And then there is this yada packaging you used.
Nothing against it, whoever wants it can use it[1] - but for such a popular
package that probably will receive a lot of help from different people
this is IMO the worst thing ever to choose.
Something that is known to many,like debhelper, cdbs, whatever is for
sure the better thing to use.

[1] No flamewar against it intended.

-- 
bye Joerg
[http://www.youam.net/stuff/info...-hosting.de/server-info.php]
"[...] und der Arbeitsspeicher recht schnell und hoch ist."
(Wie hoch? 2cm, 4cm? Am besten an die Decke nageln, was?


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

Re: mplayer 1.0pre7

[Adeodato Simó]

* Russ Allbery [Mon, 25 Apr 2005 10:47:13 -0700]:

> it's more clear what's going on; some packages are sitting, but most
> things are being approved very quickly.  mplayer (and hot-babe) are among
> the ones that are sitting.

  And as I learnt yesterday, some of the ones "sitting" are still there
  because the maintainer hasn't reacted in weeks to mail from ftpmaster
  pointing out obvious problems with the package.

  Perhaps it'd be nice in the long term add a column with a short note
  enumerating the problems, or to CC the ITP bug the mail sent to the
  maintainer. This way, if a maintainer goes MIA, other interested
  people can know that the ball is in the maintainer's roof, not in
  ftpmasters', and offer to help.

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
Military justice is to justice what military music is to music.
-- Groucho Marx


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

Re: Sarge release for amd64 - Please help to fix the remaining bugs

[Kurt Roeckx]

On Mon, Apr 25, 2005 at 11:32:25AM +0200, Andreas Jochens wrote:
> 
> There are still a few packages in sarge which fail to build from source 
> on amd64. Those packages will not be part of the amd64 release of sarge.

I've made a list list on saterday too which included all patched
versions in the archive that I know about, and which possible
could also need a patch.  It's available on:

http://debian-amd64.alioth.debian.org/patched-versions.txt

Note that I also have a list of package that failed to build in
sid and sarge at /pure64/failed.txt and
/pure64/failed-testing.txt

> Package  BTS Bug   Problem description
>  ---   ---
> amynth   #274703+  missing '#include ' in main.cc
That's amsynth

> armagetron   - dh_installchangelogs: command returned error code 
> 11
#298198

> cal3d-  +  libcal3d-doc/html/functions_rela.html missing
#305411

> ftape-tools  - "ltconfig: you must specify a host type..."
That's marked as not-for-us because it only works with older
kernels?

> gnustep-base -  +  does not build with gcc-3.3 (needs gcc >= 3.4)
It looks like it builds fine with gcc-3.3.  But if my memory is
any good, it (used to?) miscompile it?

> libgtk-java  - java.lang.NullPointerException
There are alot of java package that fail to build and I still
have to track those down.  Those are ussually not the fault of
the package itself.  They're also arch all, so you can get them
from the archive anyway.

> libpolyxmass - "*** [localealias.o] Error 1"
#303856, not sure what you mean with that error.

> mondo- missing amd64 in architecture list
This requires mindi, which we don't have either.

> mozart   - "undefined reference to `free'"
Not 64 bit clean: #119583

> ogre - "no matching function for call to ..."
It's in dep-wait for cegui-mk2-dev (#303072)
The version for sarge has: #291606

> plex86   - amd64 missing from architecture list
I doubt plex86 is going to work at all.

> pocketpc-gcc - "/tmp/ccEpnAHc.s:1046: Error: bignum invalid"
#301645

> portslave- "pppd.h: No such file or directory"
??

> prc-tools- "machine `x86_64' not recognized"
It uses gcc 2.95, which just doesn't support us.

> redboot  - "Unknown target amd64"
#152911

> tela - configure: error: "Blas not found!"
??

> xview#294844+  amd64 missing from architecture list

It's been said more than once that xview (and everything
depending on it) does not work on ia64 and amd64.  You even said
so yourself in the bugreport.


Kurt


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

Re: mplayer 1.0pre7

[Russ Allbery]

Jeff Carr <[EMAIL PROTECTED]> writes:

> FTP Assistants --
>   member Randall Donald (NEW processing)
>   member Daniel Silverstone (NEW processing)
>   member Joerg Jaspert (NEW processing)

> Am I correct in assuming "NEW processing" means this is what you guys
> volunteered to handle? Did new packages stop getting processed because
> someone uploaded that "hot-babe" package?

Er, no.  In fact, the turnaround on NEW processing for uncontroversial
uploads has been *fantastic*.  I'm seeing turnaround on the order of a
day, and not infrequently on the order of an hour or two.

If you look at:



it's more clear what's going on; some packages are sitting, but most
things are being approved very quickly.  mplayer (and hot-babe) are among
the ones that are sitting.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: Sarge release for amd64 - Please help to fix the remaining bugs

[Andreas Jochens]

Steve Langasek wrote:
>> portslave- "pppd.h: No such file or directory"
>
> Hmm, you may want to re-check this against current versions of ppp and
> portslave.

I just re-checked this again and now portslave builds fine in testing,
thanks.

Regards
Andreas Jochens


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

Re: mplayer 1.0pre7

[Petter Reinholdtsen]

[Jeff Carr]
> Did new packages stop getting processed because someone uploaded
> that "hot-babe" package?

You might find
http://qa.debian.org/~anibal/debian-NEW-summary.html> slightly
illuminating.  From that list, I read that the NEW queue processing in
general is progressing nicely, and that there are some packages not
being processed at all.

The list used to be >200 packages long.  It is now ~20 packages long.

http://ftp-master.debian.org/new.html> is the same list with a
bit less detail, and higher update frequency.  The first list is
updated once a day, the second list is updated once per hour, I
believe.


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

Re: Sarge release for amd64 - Please help to fix the remaining bugs

[Adrian von Bidder]

On Monday 25 April 2005 14.51, Andreas Jochens wrote:
> Steve Langasek wrote:

> >> libmysqlclient-lgpl -   Linuxthreads test has to be switched off for
> >> amd64
[...]
> Unfortunately, quite a few important packages still Build-Depend
> on libmysqlclient10-dev:

> exim4

Does that mean amd64 installer come without a mailer by default? Or will the 
amd64 installer install a different mailer?

> postfix

Especially since at least one of these two would be very nice to have...


greetings
-- vbi

-- 
featured link: http://fortytwo.ch/gpg/subkeys


pgpaIFwotqoXi.pgp
Description: PGP signature

Re: mplayer 1.0pre7

[Jeff Carr]

A Mennucc wrote:
hi
mplayer 1.0pre7 is ready and packaged at
http://tonelli.sns.it/pub/mplayer/sarge
a.
ps: still no news from ftpmasters... hope they at least will try to read
  http://people.debian.org/~mjr/mplayer.html
FTP Assistants --
 member Randall Donald (NEW processing)
 member Daniel Silverstone (NEW processing)
 member Joerg Jaspert (NEW processing)
Am I correct in assuming "NEW processing" means this is what you guys 
volunteered to handle? Did new packages stop getting processed because 
someone uploaded that "hot-babe" package?

Thanks for doing the work of cleaning up mplayer. I hope it gets 
included soon.

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

Re: Status of 'sarge' for the amd64 architecture

[Andreas Barth]

* Josselin Mouette ([EMAIL PROTECTED]) [050425 18:20]:
> Le lundi 25 avril 2005 à 16:54 +0200, Jeroen van Wolffelaar a écrit :
> > > See, that just makes no sense whatsover. You can claim either:
> > > 
> > > 1) Adding AMD64 would increase the mirror load unacceptably
> > > OR
> > > 2) Removing ARM would not have a significant effect on the mirror load
> > > 
> > > but not both at the same time. (Yes, I realize that two different people
> > > made these claims, but which one am I supposed to believe?)

> > Sure one can: removing arm would be removing arm from testing, not from
> > unstable. Currently around 800 (of the > 8000) source packages in
> > testing have a different version compared to unstable, even less so
> > different arm packages (think big arch:all packages, or arch:i386
> > specific packages). This means that removing arm from testing would
> > only save about 1GB of space.
 
> This is true today. Will it still be true in a few months for the
> differences between stable and unstable?

The size of the mirror pushes is not really changed by keeping some
random packages (aka stable) or not.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: Status of 'sarge' for the amd64 architecture

[Josselin Mouette]

Le lundi 25 avril 2005 à 16:54 +0200, Jeroen van Wolffelaar a écrit :
> > See, that just makes no sense whatsover. You can claim either:
> > 
> > 1) Adding AMD64 would increase the mirror load unacceptably
> > OR
> > 2) Removing ARM would not have a significant effect on the mirror load
> > 
> > but not both at the same time. (Yes, I realize that two different people
> > made these claims, but which one am I supposed to believe?)
> 
> Sure one can: removing arm would be removing arm from testing, not from
> unstable. Currently around 800 (of the > 8000) source packages in
> testing have a different version compared to unstable, even less so
> different arm packages (think big arch:all packages, or arch:i386
> specific packages). This means that removing arm from testing would
> only save about 1GB of space.

This is true today. Will it still be true in a few months for the
differences between stable and unstable?
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

Re: Status of PHP5?

[Piotr Roszatycki]

On Monday 25 of April 2005 16:05, Martin Geisler wrote:
> Also, what went wrong with the packages that were uploaded[1] in
> February?
>
> [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=262977#msg37

About a half year ago I've asked the maintainer who filled ITP, what was the 
progress of developing his packages. He told me he want to see php5 packages 
after sarge release. It is some kind of joke. We have experimental area, at 
least.

This situation is very unclear as far as there is no active project on alioth 
for php5 packages other that my pear-package.alioth.debian.org. There is no 
any sign of active development. The people want the PHP5 packages just now 
but somebody still blocks my job.

The last mail from ftpmaster:


This upload supposedly happened without informing the team of people that
currently maintain PHP, in close cooperation with the apache folks by the way.
An alioth project for PHP was already made (pkg-php), and you were invited to
join.

Anyway, this is just a covert package hijack, if you have a problem with a
maintainer, please contact QA and/or MIA. Rejected.


The facts are:

1. The ftpmaster was a member of pkg-php project, he boycotts my work and 
don't offer something else.
2. I didn't know about pkg-php project. BTW, the pkg-php project is really 
dead now or has very hidden activity. The http://php.debian.net/ and 
http://alioth.debian.org/projects/pkg-php are empty pages. There is no public 
available mailing list or repository.
3. There are no official PHP5 packages in Debian after 6 months and it makes 
much of problems with other packages. See `apt-cache rdepends php5'. Some of 
maintainers denied the request for adding php5 to dependencies. Some of them 
added.
4. I haven't enough time for empty talking. I'm just developer and I want to 
see high quality packages in the distribution. If you've got better ones that 
I could offer, please release them. If not, please explain, why some private 
ambitions makes the life more harder for some maintainers and users.

Seems like there are power-maintainers and SCC-maintainers...

-- 
 .''`.Piotr Roszatycki, Netia SA
: :' :mailto:[EMAIL PROTECTED]
`. `' mailto:[EMAIL PROTECTED]
  `-


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

Re: Status of PHP5?

[Markus Fischer]

Martin Geisler wrote:
I've been asking Danish hosting providers about offering PHP5, and one
of them (csg.dk) specifically said that they were waiting for PHP5 to
appear in apt.
Exactly the issue why I came here. My current hoster doesn't provide 
PHP5 because no package do exist. They would charge two to three 
man-days if I want it without apt package ... :/

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

Bug#306290: ITP: ttf-mph-2b-damase -- font with ranges from the latest version of unicode

[Paul Wise]

Package: wnpp
Severity: wishlist
Owner: Paul Wise <[EMAIL PROTECTED]>

* Package name: ttf-mph-2b-damase
  Version : 001.000
  Upstream Author : Mark Williamson <[EMAIL PROTECTED]>
* URL : http://fixedsys.org/~node_ue/fonts/
* License : Public Domain
  Description : font with ranges from the latest version of unicode

MPH 2B Damase is a SuperUnicode font, including some ranges in Plane 1
and some ranges added only in the latest release of the Unicode
standard, 4.1 (such as Tifinagh, Kharosthi, hPhags-pa, Old Persian
Cuneiform etc).

Better short/long descriptions very welcome.

-- 
bye,
pabs


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

Re: Status of 'sarge' for the amd64 architecture

[Andreas Barth]

* Steve Greenland ([EMAIL PROTECTED]) [050425 16:45]:
> On 23-Apr-05, 17:24 (CDT), Andreas Barth <[EMAIL PROTECTED]> wrote: 
> > Beyond the fact that it is too late to add another architecture for
> > sarge, removing arm from sarge does not make the mirror pulses much
> > smaller - and AFAIK the size of the mirror pulses is the main problem.


> See, that just makes no sense whatsover. You can claim either:
> 
> 1) Adding AMD64 would increase the mirror load unacceptably
> 
> OR
> 
> 2) Removing ARM would not have a significant effect on the mirror load
> 
> 
> but not both at the same time. (Yes, I realize that two different people
> made these claims, but which one am I supposed to believe?)

Why not? removing arm from testing does not change at all the number of
binary arm packages being pushed each day, as the packages between
testing and unstable are shared (and only few packages go in via t-p-u).
So, the only win is that packages are faster removed - but as unstable
and testing are quite in sync, even this is not so much difference.
Adding a new arch however adds a lot of new binary packages to be pushed
each day (and, for the sanity of the mirrors, we should probably take
20-30 days [just as guess, I didn't start calculate the number] for the
initial pushing in of any new arch to restrict the maximum new binary
packages on each day).



Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: Status of 'sarge' for the amd64 architecture

[Jeroen van Wolffelaar]

On Mon, Apr 25, 2005 at 09:24:28AM -0500, Steve Greenland wrote:
> On 23-Apr-05, 17:24 (CDT), Andreas Barth <[EMAIL PROTECTED]> wrote: 
> > Beyond the fact that it is too late to add another architecture for
> > sarge, removing arm from sarge does not make the mirror pulses much
> > smaller - and AFAIK the size of the mirror pulses is the main problem.
> 
> See, that just makes no sense whatsover. You can claim either:
> 
> 1) Adding AMD64 would increase the mirror load unacceptably
> 
> OR
> 
> 2) Removing ARM would not have a significant effect on the mirror load
> 
> 
> but not both at the same time. (Yes, I realize that two different people
> made these claims, but which one am I supposed to believe?)

Sure one can: removing arm would be removing arm from testing, not from
unstable. Currently around 800 (of the > 8000) source packages in
testing have a different version compared to unstable, even less so
different arm packages (think big arch:all packages, or arch:i386
specific packages). This means that removing arm from testing would
only save about 1GB of space. That's only half of what today's mirror
pulse will be, for example. Adding amd64 would however require all the
amd64 .deb's to be added, I don't know *how* many it is, but probably
about 10 times as much, certainly more than the space saving by removing
arm.
 
--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


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

Re: Status of 'sarge' for the amd64 architecture

[Steve Greenland]

On 23-Apr-05, 17:24 (CDT), Andreas Barth <[EMAIL PROTECTED]> wrote: 
> Beyond the fact that it is too late to add another architecture for
> sarge, removing arm from sarge does not make the mirror pulses much
> smaller - and AFAIK the size of the mirror pulses is the main problem.

See, that just makes no sense whatsover. You can claim either:

1) Adding AMD64 would increase the mirror load unacceptably

OR

2) Removing ARM would not have a significant effect on the mirror load


but not both at the same time. (Yes, I realize that two different people
made these claims, but which one am I supposed to believe?)

Steve

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


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

Re: Sarge release for amd64 - Please help to fix the remaining bugs

[Henrique de Moraes Holschuh]

On Mon, 25 Apr 2005, Andreas Jochens wrote:
> Unfortunately, quite a few important packages still Build-Depend 
> on libmysqlclient10-dev:
> 
> cyrus-sasl2
> cyrus-sasl2-mit

Frozen. I will gladly update them if the release team tells me to go ahead
and do it.

-- 
  "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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

mplayer 1.0pre7

[A Mennucc]

hi

mplayer 1.0pre7 is ready and packaged at
http://tonelli.sns.it/pub/mplayer/sarge

a.

ps: still no news from ftpmasters... hope they at least will try to read
  http://people.debian.org/~mjr/mplayer.html

-- 
Andrea Mennucc
 "E' un mondo difficile. Che vita intensa!" (Tonino Carotone)


signature.asc
Description: Digital signature

Re: Sarge release for amd64 - Please help to fix the remaining bugs

[Steve Greenland]

On 25-Apr-05, 04:32 (CDT), Andreas Jochens <[EMAIL PROTECTED]> wrote: 
> Package  BTS Bug   Problem description
>  ---   ---
> amynth   #274703+  missing '#include ' in main.cc

Or possibly '#include ', depending on the rest of the code.

> hfsutils #280310+  missing '#include '
> icom #277805+  missing '#include '
> nntp #280278+  missing '#include '
> oleo #287854+  missing '#include '
> radiusd-livingst #273629+  missing '#include '
> rplay#280274+  missing '#include '
> sam  #280259+  missing '#include ' in libframe/misc.c
> socks4-server#280262+  missing '#include '
> tct  #254165+  missing 'defined(x86_64)' and '#include '
> xppaut   #306173+  missing '#include '

Outstanding. It's only been what, 16 years since C89 made 'extern int
errno' officially buggy? (It had been non-portable and buggy in practice
long before that.) These should be upgraded to RC on all platforms: just
because it builds doesn't make it correct or working.

Steve

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


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

Re: Status of PHP5?

[Martin Geisler]

Markus Fischer <[EMAIL PROTECTED]> writes:

> Hello,
>
> I wanted to inform myself on the current status of PHP5.

I'm interested in seeing these packages in Debian too.

Before finding the packages by Piotr Roszatycki I used packages from
dotdeb.org, but I would feel more comfortable using packages coming
From the official Debian mirrors.

And so would others, I believe.  That is why I don't understand why
PHP5 packages have not yet been included in unstable?  (Getting them
into Sarge would be great, but perhaps it's too late?)

I've been asking Danish hosting providers about offering PHP5, and one
of them (csg.dk) specifically said that they were waiting for PHP5 to
appear in apt.

Could someone explain why the packages aren't there yet?

Also, what went wrong with the packages that were uploaded[1] in
February?

[1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=262977#msg37 

-- 
Martin Geisler  My GnuPG Key: 0x7E45DD38

PHP EXIF Library  |  PHP Weather |  PhpShell
http://pel.sf.net/|  http://phpweather.net/  |  http://gimpster.com/
Read/write EXIF data  |  Show current weather|  A shell in a browser


pgppZ1nshwGGu.pgp
Description: PGP signature

Re: Sarge release for amd64 - Please help to fix the remaining bugs

[Kevin B. McCarty]

Andreas Jochens wrote:
mn-fit   #301509   segmentation fault on 64bit architectures
FYI, this looks like it's due to some 64-bit brokenness in Cernlib (on 
which mn-fit depends).  The same problem appears on alpha and ia64.  I 
don't expect this to be solved for a long while, if ever; certainly not 
before the release of Sarge.

regards,
--
Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Sarge release for amd64 - Please help to fix the remaining bugs

[Joey Hess]

Andreas Jochens wrote:
> Debian sarge release for the amd64 architecture
> ---
> 
> At the amd porters irc meeting on 2005-04-23 07:00 UTC, the amd64 porting
> team decided to release a version of sarge for amd64 which is based on the 
> unpatched Debian sarge source packages. 
> 
> The amd64 porting team will provide security support for the sarge release
> by autobuilding the security updates as soon as the fixed sources become
> available.
> 
> Proposed updates and updated versions for Debian sarge point releases 
> will also be made available for amd64 by the amd64 porting team.
> 
> The package archive for the Debian amd64 sarge port will be hosted by
> a Debian server which is located in Darmstadt, Germany. 
> The complete debian-amd64 project will move from the current alioth host 
> to that server.

Well it's nice to see this happening. About the installer, I assume
you'll be including builds of the debian-installer package on your new
server, including the "byhand" images it generates. If those images test
out ok and you give me a url for that, I can add it to
http://www.debian.org/devel/debian-installer/ where we have the rc3
release, which will probably soon be renamed to the sarge r0 release.

If you also build netinst, businesscard, full CD, and/or DVD images
against sarge, using the udebs and installer images in sarge (not daily
builds), we can also links for them to that page. And probably to the
other CD pages on the website, although that may need help from the CD
and/or web teams. It's also possible that the CD team could do these
builds for you (we've also moved to a new build server and it could
possibly add an amd64 mirror), though I haven't discussed this with the
rest of the team yet.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Sarge release for amd64 - Please help to fix the remaining bugs

[Andreas Jochens]

Hello Steve,

thank you for your quick reply to my amd64 bug list.

Steve Langasek wrote:
>> libmysqlclient-lgpl -   Linuxthreads test has to be switched off for amd64
>
> I'm not going to give this a high priority, personally; all my reasons for
> adding this package in the first place have since been addressed by the
> upstream licensing fixes, so anything still using it is of fairly limited
> use (especially with the protocol incompatibilities with MySQL 4.1).

I agree with this. Applications should Build-Depend on the newer 
libmysqlclient14-dev or at least libmysqlclient12-dev instead of 
libmysqlclient10-dev from libmysqlclient-lgpl. This was one reason why
I did not yet file a patch for libmysqlclient-lgpl with a similar change
as the one that has been applied to the mysql-dfsg and mysql-dfsg-4.1 
packages.

However, I made a mistake with respect to the importance of the 
libmysqlclient-lgpl package. It was possible to build it on amd64 
about a year ago when the toolchain was different. That version is
still in the current amd64 archive on alioth. But now, with the new
toolchain, it does not build on amd64 anymore.

Unfortunately, quite a few important packages still Build-Depend 
on libmysqlclient10-dev:

cyrus-sasl2
cyrus-sasl2-mit
exim4
gpsdrive
ircii-pana
linesrv
motion
mp3kult
mydns
mysql-navigator
pam-mysql
pike7.2
pike7.4
pike7.6
pimppa
postfix
prokyon3
pure-ftpd
www-sql
xlc

It would certainly be a good idea to update the Build-Depends 
for those packages. Ideally, the libmysqlclient-lgpl package
could be dropped entirely. But I guess it will not be possible 
to fix all those Build-Depends for sarge. 

I will file a patch for libmysqlclient-lgpl in a separate mail.


>> portslave- "pppd.h: No such file or directory"
>
> Hmm, you may want to re-check this against current versions of ppp and
> portslave.

This was a bug in sid which has been fixed recently. The fixed version
of portslave has entered sarge, but sarge has an older version of ppp,
which does not work with that fix.

Because of this, portslave has a FTBFS problem in sarge now until the 
latest ppp makes it into sarge.


Again, thanks for looking at my list of amd64 related FTBFS bugs.

Regards
Andreas Jochens


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

Bug#306268: ITP: connect -- Establish socket connection using SOCKS4 or 5 and HTTP tunnel.

[Philippe COVAL]

Package: wnpp
Severity: wishlist
Owner: Philippe COVAL <[EMAIL PROTECTED]>


* Package name: connect
  Version : 1.93
  Upstream Author : Shun-ichi GOTO <[EMAIL PROTECTED]>
* URL : http://www.taiyo.co.jp/~gotoh/ssh/connect.html
* License : GPL 2
  Description : Establish socket connection using SOCKS4 or 5 and HTTP 
tunnel.

This command line program enables ssh connection over proxies.
I was suprised it wasn't allready packaged (maybe there are alternatives to it).

There is not upstream tarball, just a simple C file.
I built the package and checked them with lintian and linda.

Get the packages at : http://rzr.online.fr/docs/contrib/tmp/

ps: My key is about to be signed by a dd in a couple of days.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.11.7-k7-amiloa
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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

Re: Debian Project Leader report for 2005-04-24

[Josselin Mouette]

Le lundi 25 avril 2005 à 01:03 -0500, Branden Robinson / Debian Project
Leader a écrit :
> Woody Security Update Challenges and Progress
> -
> The ARM problems we've had have also affected the timeliness with which
> we've been able to get security updates out.  A security fix to
> ``xfree86``, for example, has been stalled for weeks because no ARM
> build daemon has been operational to compile it.  (See `Debian bug
> #298939`_ for details.)

Why, in this case, isn't the package released for the other
architectures? There's nothing wrong with sending an update later for
architectures that were missing in the first run.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: Sarge release for amd64 - Please help to fix the remaining bugs

[Steve Langasek]

Hi Andreas,

On Mon, Apr 25, 2005 at 11:32:25AM +0200, Andreas Jochens wrote:
> Packages from sarge with build problems on amd64
> 

> There are still a few packages in sarge which fail to build from source 
> on amd64. Those packages will not be part of the amd64 release of sarge.

> The packages mentioned in the table below and all their dependencies 
> will not be part of the amd64 sarge release unless the listed problems 
> get fixed really soon and the fixed package versions make it into sarge.

> The following architecture specific packages from Debian sarge/main 
> currently (as of 2005-04-24) fail to build from source for amd64:

It's probably worth noting that some of these failures also affect other
architectures and are RC bugs; thus, they won't ship with *any* architecture
in sarge unless they're fixed. :-)

> Package  BTS Bug   Problem description
>  ---   ---
> libmysqlclient-lgpl -  Linuxthreads test has to be switched off for amd64

I'm not going to give this a high priority, personally; all my reasons for
adding this package in the first place have since been addressed by the
upstream licensing fixes, so anything still using it is of fairly limited
use (especially with the protocol incompatibilities with MySQL 4.1).

> portslave- "pppd.h: No such file or directory"

Hmm, you may want to re-check this against current versions of ppp and
portslave.

> ruby-gnome2  #304951   "*** extconf.rb failed ***"

RC bug, definitely fixed one way or another as soon as glibc is unstuck.

> xview#294844+  amd64 missing from architecture list

A package with historical 64-bit issues, and not much of a use case in
modern envs, AFAICT; seems unlikely to be fixed.

Cheers,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Status of PHP5?

[Markus Fischer]

Hello,
I wanted to inform myself on the current status of PHP5.
As it currently is, there is no PHP5 package in sid nor testing. I've 
found the bug report 262977 [1] and an email in march [2] where Piotr 
Roszatycki was asking about PHP thread safety and before that there was 
a small conversation in Nov [3]. I also would like to see getting PHP5 
into sarge (though it may be to late, I don't know). If not sarge, at 
least packaged soon.

It's not obvious to me what is currently holding back further work on 
php5, maybe some of the php4 packagers can give an overview?

thanks for your time,
- Markus
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=262977
[2] http://lists.debian.org/debian-devel/2005/03/msg00055.html
[3] http://lists.debian.org/debian-devel/2004/11/msg00342.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Sarge release for amd64 - Please help to fix the remaining bugs

[Andreas Jochens]

Debian sarge release for the amd64 architecture
---

At the amd porters irc meeting on 2005-04-23 07:00 UTC, the amd64 porting
team decided to release a version of sarge for amd64 which is based on the 
unpatched Debian sarge source packages. 

The amd64 porting team will provide security support for the sarge release
by autobuilding the security updates as soon as the fixed sources become
available.

Proposed updates and updated versions for Debian sarge point releases 
will also be made available for amd64 by the amd64 porting team.

The package archive for the Debian amd64 sarge port will be hosted by
a Debian server which is located in Darmstadt, Germany. 
The complete debian-amd64 project will move from the current alioth host 
to that server.


Packages from sarge with build problems on amd64


There are still a few packages in sarge which fail to build from source 
on amd64. Those packages will not be part of the amd64 release of sarge.

The packages mentioned in the table below and all their dependencies 
will not be part of the amd64 sarge release unless the listed problems 
get fixed really soon and the fixed package versions make it into sarge.

The following architecture specific packages from Debian sarge/main 
currently (as of 2005-04-24) fail to build from source for amd64:

Package  BTS Bug   Problem description
 ---   ---
amynth   #274703+  missing '#include ' in main.cc
armagetron   - dh_installchangelogs: command returned error code 11
cal3d-  +  libcal3d-doc/html/functions_rela.html missing
cbmlink  #207003+  uses i386 specific code
cdrdao   #249634+  x86_64-linux-{cc,gcc}.rul links missing
elk  -  +  needs workaround for ICE with gcc-3.3
freewnn  #142253   segfaults during build (same as on ia64)
ftape-tools  - "ltconfig: you must specify a host type..."
ghdl #276399   ghdl internal compiler error: Segmentation fault
gnustep-base -  +  does not build with gcc-3.3 (needs gcc >= 3.4)
guile-core   #255894+  amd64 missing in UNSUPPORTED_QTHREAD_ARCHS
heaplayers   - "*** [allocators] Error 1"
hfsutils #280310+  missing '#include '
icom #277805+  missing '#include '
ircd-ircu#254165+  configure check for res_mkquery fails
k3d  #278966   compilation of expression.cpp does not finish
kmatplot #286533+  missing -fPIC
krb4 #175491+  configure does not define HAVE_H_ERRNO
kuake- "Can't find X libraries"
kxstitch - "Can't find X libraries"
libglademm2.0#279985+  "$LD" vs. $LD in configure
libgtk-java  - java.lang.NullPointerException
libhdf4  #251275+  missing amd64 support in hdf/src/hdfi.h
libmysqlclient-lgpl -  Linuxthreads test has to be switched off for amd64
libooc-vo#164726   "*** [EMAIL PROTECTED]@] Error 1"
libpolyxmass - "*** [localealias.o] Error 1"
licq - undefined reference to pthread_kill_other_threads_np
linux86  #260647+  elksemu's file format not recognized
lsb-release  #249396+  mising 'amd64' in architecture list
lvm2 #298762+  "device/dev-io.c:342:3: #error miss O_NOATIME"
lxdoom   #279190+  missing '#include '
masqmail #254720+  configure check for res_search in -lresolv fails
mn-fit   #301509   segmentation fault on 64bit architectures
mondo- missing amd64 in architecture list
mozart   - "undefined reference to `free'"
mtr  #254089   configure check for res_mkquery broken
muddleftpd   #253618   missing -fPIC
nntp #280278+  missing '#include '
ogre - "no matching function for call to ..."
oleo #287854+  missing '#include '
oo2c #251577+  missing 64bit-arch handling in debian/rules
perlipq  #278944   links against non-fPIC libipq.a
pike7.4  - "*** [build/autodoc.xml] Segmentation fault"
plex86   - amd64 missing from architecture list
pocketpc-gcc - "/tmp/ccEpnAHc.s:1046: Error: bignum invalid"
portslave- "pppd.h: No such file or directory"
prc-tools- "machine `x86_64' not recognized"
redboot  - "Unknown target amd64"
radiusd-livingst #273629+  missing '#include '
rplay#280274+  missing '#include '
rpvm #277834   missing -fPIC in pvm library
rsplib   #305894   No sctplib installation found (/usr/lib/libsctp.a)
ruby-gnome2  #304951   "*** extconf.rb failed ***"
sam  #280259+  missing '#include ' in libframe/misc.c
snacc#277690   "*** [tbl.c] Segmentation fault"
socks4-server#280262+  missing '#include '
syslinux