jack still broken

[Thomas Bushnell BSG]

Jack has been broken for three months now.

The problem is that the libraries libjack0.80.0-0 and libjack0.100.0-0
declare exact version requirements against jackd: both of them
conflict with all but one version of jackd.

If they really are proper library packages, then they shouldn't
conflict with jackd at all.

This has been going on for three months.

Why?

Thomas


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

Re: jack still broken

[Steve Langasek]

On Thu, Sep 22, 2005 at 12:00:22AM -0700, Thomas Bushnell BSG wrote:

> Jack has been broken for three months now.

> The problem is that the libraries libjack0.80.0-0 and libjack0.100.0-0
> declare exact version requirements against jackd: both of them
> conflict with all but one version of jackd.

> If they really are proper library packages, then they shouldn't
> conflict with jackd at all.

How else do you handle the case of a library which implements a line
protocol (presumably Unix sockets, in this case), and that protocol has
changed incompatibly?

> This has been going on for three months.

Why has it taken three months for the reverse dependencies to be rebuilt?
That shouldn't really be acceptable, whether or not there's some reason for
(effective) conflicts between different versions of the lib.

-- 
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/


signature.asc
Description: Digital signature

Re: architecture-specific release criteria - requalification needed

[Steve Langasek]

On Wed, Sep 21, 2005 at 02:52:57PM +0200, Ingo Juergensmann wrote:
> Although it was discussed several times, I have still no idea how those
> users should be counted? 
> Who has to show those numbers? The users? The porters?

"someone".  That someone is probably a porter by definition, I'd say.

> Is it intended that a user should mail debian-release to say "Hi! I'm using
> port X!"? I doubt so. 

No, please assemble a list of users willing to vouch for their use of the
port and submit it to the release team when it's complete.

> So, a little more info is needed, how those numbers are counted. 
> Are users just meant to be ordinary users of does that included developers?

Developers are users too.

> > |  * Porters and Upstream support: There is support by the porters and
> > |upstream. This is especially true for the toolchain and the
> > |kernel.
> > Obviously, we cannot keep a port alive if there is nobody doing support for
> > it.  Of course, it is quite possible that Debian and upstream support is
> > done by the same persons.  And our experiences with support of gcc-4.0
> > on m68k have shown that it is possible to get such issues fixed, if the
> > porters are notified in time and are really interested in their port (and
> > if there are enough porters).

> Uh, well, I hope that slower archs will be given a large time frame to fix
> things than faster archs? It would be unfair to give just a week time to fix
> a problem, when the recompilation of the package would take 10 days,
> wouldn't it? ;)

Why would it be in Debian's interest to be lenient with slower architectures
here?  The whole point of these architecture requirements is to prevent an
individual architecture from dragging the release down, and "this
architecture is too slow to debug effectively" is *definitely* an instance
of dragging the release down.  You're making a very good argument in *favor*
of dropping such ports, I think.

> > |  * Archive coverage: The architecture needs to have successfully
> > |compiled the current version of the overwhelming part of the
> > |archive, excluding architecture-specific packages.
> > Our back-of-the-envelope number for this criterion is 98%.  As pointed
> > out multiple times during recent discussions, we don't have a good way
> > to measure an architecture's compliance with this yet, but we'll work on
> > figuring that out; of course we will exclude hardware-specific packages and
> > buggy optional/extra packages with severe portability issues, but
> > porters must take responsibility for working with maintainers to fix
> > portability issues.

> I still believe this definition is far too strict (without being precise).
> You can't say, you have to be 98% uptodate without saying what you
> understand by "being uptodate". As already outlined during the last
> discussion: when all m68k buildds are building package, that can easily be
> more than 110 packages marked as building and therefore missing as installed
> (given a total of 5500 packages). 

Once again, what I'm hearing here is a plea for latitude towards certain
ports because they're slow, instead of an acknowledgement that being slow
(and therefore, failing to keep up) is what causes extra work for the
release team.

> Currently m68k has ~650 packages listed that are not in state Installed (203
> Needs-Build, 142 Building, 180 Failed, 123 Dep-Wait (+ 5 Failed-Removed + 25
> Not-For-Us)). That's roughly 6% of all packages. 

Yes, and a week ago the m68k porter lists were informed that the current
state of m68k is unacceptable and that if significant progress wasn't made
soon, we would ask for m68k to be ignored for all testing propagation.

Your percentage is a bit off, btw; 650 is 7% of all source packages in
unstable, and if you *exclude* packages that are in P-a-s, the percentage
would be higher.  This is reflected on
.

> And when does that percent mark need to be reached? After freeze or at any
> time before a release?

The intent was that the threshold should be met on an ongoing basis.  Yes,
there will be times when a glut of uploads ensures that all ports are
struggling to meet it, and there may be times when one port or another dips
below the mark for particular reasons, but it really only becomes
significant when the release team *notices* it because it's impacting our
ability to process updates for testing, proceed with a multi-tier ABI
transition, etc.

If an architecture fails the release candidate criteria for whatever
reason, and is demoted to a non-release arch, I believe the sensible course
of action is to give the porters a fixed two-month period to remedy the
lapses before being re-evaluated by the release team.  That leaves the
porters free to focus on fixing whatever the issues are instead of scurrying
to get re-qualified ASAP, and it also ensures the release team's time isn't
wasted re-approving a port which qualifies at the instant but immediately
be

Re: Bug#329462: general: standard value $LANG="[EMAIL PROTECTED]" -> very tiny GTK1 font

[Alexander Wirt]

Annett Fritz schrieb am Donnerstag, den 22. September 2005:

> Package: general
> Severity: grave
> Tags: l10n
> Justification: renders package unusable
> 
> The standard value $LANG="[EMAIL PROTECTED]" breaks fontsize for some gtk1
> programs like gxedit or tipptrainer. With $LANG="de_DE" they show a
> readable font. 
> A normal user doesn't know that when he chooses the locale
> "dpkg-reconfigure locales" during installation.
The solution would be to install the transcoded fonts by default. That fixes
that problem. 

Best wishes
Alex


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

Re: architecture-specific release criteria - requalification needed

[Debian-armeb Porting Team]

On 9/21/05, Andreas Barth <[EMAIL PROTECTED]> wrote:
> These criteria do _not_ control addition of an architecture to unstable,
> but rather apply to architectures which the ftp-masters have accepted
> into unstable and are targetting testing and the next stable release.
> In other words, an architecture that fails these criteria can still be
> part of unstable.

Andreas,

Can you outline the requirements for a new architecture (e.g.
debian-armeb[1]) to be added to unstable ?  Or at least be added to the
existing buildd infrastructure?

Below are representative responses to the requalification criteria for
the debian-armeb port, and the debian-armeb porting team is very
interested in understandig how to move forward to be added to the buildd
infrastructure and eventually be able to contribute to Debian unstable.

> |  * Availability:
> | The architecture needs to be available for everybody, i.e.

The Linksys NSLU2 is available for USD$80 at various online retail
outlets.  Other consumer-level armeb machines suitable for running
Debian can be readily purchased for less than USD$200.  Other high-end
armeb machines can range into the tens of thousands of dollars ...

> |  * Developer availability: The architecture must have a
> |developer-available (i.e. debian.org) machine that contains the
> |usual development chroots (at least stable, testing, unstable).

We can easily afford (from user contributions of money) to donate two or
three machines for Debian developers to use.

> |  * Users: The architecture needs to prove that developers and users
> |are actually using it. Five Developers needs to certify in that
> |they're actively developing on this architecture, and it needs to
> |be demonstrated that at least 50 users are using the platform.

We have no DDs on the team at the moment, but we do have a number of
DDs interested, and expect to be able to meet the requalification
requirement of 5 DDs actively developing after some period of time
(either by recruiting existing DDs, and/or by the DD applications of the
core armeb porting team progressing to approval).  We are tracking
installations now[2] and are half-way to the goal of 50 in less than two
months of operation.  We also intend using the popularity-contest to
assist in tracking progress towards meeting this requirement.

However, how does one get "armeb" recognised as a valid option for the
graphs on http://popcon.debian.org?  Will simply sending in valid survey
results with armeb as the architecture cause the graphs on that page to
list armeb separately?

> |  * Installer: The architecture must have a working, tested installer.

We have a fairly easy method of bootstrapping Debian on an NSLU2 right
now[3], and have people working on porting the standard debian-installer
(we need one that works across the network out of the box, since the
NSLU2 does not have a console without modifying the hardware[4]).

> |  * Porters and Upstream support: There is support by the porters and
> |upstream. This is especially true for the toolchain and the
> |kernel.

There is a very active team supporting Linux on the NSLU2, and other
armeb devices[5].  We are running the 2.6.12 kernel at the moment.

> |  * Archive coverage: The architecture needs to have successfully
> |compiled the current version of the overwhelming part of the
> |archive, excluding architecture-specific packages.

We currently have 2500+ stable packages released[6] (including all of
important, required and standard), and we have started building the same
set (important, required and standard) for unstable as well.

This is where the chicken-and-egg situation comes into play.

We *really* need to be hooked into the buildd system to be able to
automatically build the rest of the stable, testing and unstable
releases.  This is our top-most priority, and we hope to get help on
this point from the Debian infrastructure teams.  We have buildd clients
ready and running, but we need a server to feed them build requests.

> |  * Archive cleanliness: All binary packages need to be built from
> |unmodified sources (i.e. from the source found in the
> |ftp archive), and all binary packages need to be built by Debian
> |developers.

None of the current team building the armeb packages are DDs, but we
have at least two DDs who may be willing to sponsor the port.  The
question is whether we can get some armeb boxes into the buildd
infrastructure now, and therefore have packages built automatically, or
whether we have to rebuild all our packages after one of our team
becomes a DD (or a DD takes on the task of building the packages for
us).

We are keeping patches[7] for the armeb port separate, and are ready to
contribute them now, or at any future time that is more appropriate. 
Another chicken-and-egg - are package maintainers expected to accept
patches for architectures that are not yet official?

> |  * Autobuilder support:
> |The architecture is able 

Re: architecture-specific release criteria - requalification needed

[Christoph Berg]

Re: Petter Reinholdtsen in <[EMAIL PROTECTED]>
> Personally, I find the list of requirements sensible, and very
> understandable after the clarifying rounds on the lists.  This colors
> my view of the discussion.

AOL.

(Though I would like to see something like "at least N+1 buildd
_admins_" added.)

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: glibc and PaX issue

[Russell Coker]

On Monday 05 September 2005 05:21, Laszlo Boszormenyi <[EMAIL PROTECTED]> wrote:
> > Installation of ,,fixed packages''[2] soloved this issue. But in my
> > opinion better solution is fixing it in Debian :P.
>
>  Debian will support SELinux, I do not know if GRSecurity will have a
> chance. :-|

SE Linux also controls read&&execute access to memory and can do so in 
conjunction with PAX or Exec-Shield.  So on a SE Linux system you will see 
exactly the same issues.

Debian's libc6 needs to be fixed.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Bug#329462: general: standard value $LANG="[EMAIL PROTECTED]" -> very tiny GTK1 font

[Steve Langasek]

reassign 329462 libgtk1.2
severity 329462 important
thanks

On Thu, Sep 22, 2005 at 02:57:15AM +0200, Annett Fritz wrote:
> Package: general
> Severity: grave
> Tags: l10n
> Justification: renders package unusable

> The standard value $LANG="[EMAIL PROTECTED]" breaks fontsize for some gtk1
> programs like gxedit or tipptrainer. With $LANG="de_DE" they show a
> readable font. 
> A normal user doesn't know that when he chooses the locale
> "dpkg-reconfigure locales" during installation.

Can you explain what you mean when you say it "breaks" fontsize?  That
doesn't sound to me like a bug that makes the package unusable.

In any case, I fear that this bug will probably go unfixed since libgtk1.2
is no longer being developed.

-- 
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/


signature.asc
Description: Digital signature

Processed: Re: Bug#329462: general: standard value $LANG="[EMAIL PROTECTED]" -> very tiny GTK1 font

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 329462 libgtk1.2
Bug#329462: general: standard value $LANG="[EMAIL PROTECTED]" -> very tiny GTK1 
font
Bug reassigned from package `general' to `libgtk1.2'.

> severity 329462 important
Bug#329462: general: standard value $LANG="[EMAIL PROTECTED]" -> very tiny GTK1 
font
Severity set to `important'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: Bug#329425: RFA: psutils -- A collection of PostScript document handling utilities

[Glyn Edwards]

> The point in bug #159888 about psmerge being a horribly brittle kludge
> and ought to be superseded by a ghostscript wrapper is well made, but
> that does not mean that the same point applies to, say, psselect or
> psnup.
The psmerge from seismic unix is very useful. I don't think it was ever
packaged however.

http://www.cwp.mines.edu/cwpcodes/
http://lists.debian.org/debian-devel/1999/11/msg00662.html

Glyn


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

php5 + apache2 + FastCgiExternalServer, anyone?

[Marek Habersack]

Hey folks,

  Has anyone gotten the setup mentioned in the subject to work as
advertised? The config I'm using is:


  
   Options ExecCGI
   SetHandler fastcgi-script
  
  
  FastCGIExternalServer /fcgi-bin/php5-cgi -host 127.0.0.1:
  
  AddType application/x-httpd-fastphp5 .php
  Action application/x-httpd-fastphp5 /fcgi-bin/php5-cgi


And yet apache2 doesn't want to connect to the -host host, instead it
launches the binary mentioned in Action and uses it to handle the requests.
Maybe I'm reading the docs incorrectly
(http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiExternalServer)
but apache fails to serve the PHP requests if /fcgi-bin/ is not found in the
docroot and if the php5-cgi binary doesn't exist in it. Am I doing something
wrong or is it, perhaps, a bug in the mod_fastcgi module (or documentation
thereof)? I would appreciate any help/hints/doc pointers regarding the issue,

tia,

marek


signature.asc
Description: Digital signature

Re: architecture-specific release criteria - requalification needed

[Ingo Juergensmann]

On Thu, Sep 22, 2005 at 01:52:06AM -0700, Steve Langasek wrote:
> On Wed, Sep 21, 2005 at 02:52:57PM +0200, Ingo Juergensmann wrote:
> > Although it was discussed several times, I have still no idea how those
> > users should be counted? 
> > Who has to show those numbers? The users? The porters?
> "someone".  That someone is probably a porter by definition, I'd say.

"Someone" is not necessarily a porter. That's why I asked. So, it should be
said that a porter has to do the reports.

> > So, a little more info is needed, how those numbers are counted. 
> > Are users just meant to be ordinary users of does that included developers?
> Developers are users too.

Great if you see it that way, but it could've been different, though. :)

> > Uh, well, I hope that slower archs will be given a large time frame to fix
> > things than faster archs? It would be unfair to give just a week time to fix
> > a problem, when the recompilation of the package would take 10 days,
> > wouldn't it? ;)
> Why would it be in Debian's interest to be lenient with slower architectures
> here?  The whole point of these architecture requirements is to prevent an
> individual architecture from dragging the release down, and "this
> architecture is too slow to debug effectively" is *definitely* an instance
> of dragging the release down.  You're making a very good argument in *favor*
> of dropping such ports, I think.

Oh well, then again you could argue that every port that is slower than the
fastest port should be dropped, i.e. drop all archs. Is that what you want?

> > I still believe this definition is far too strict (without being precise).
> > You can't say, you have to be 98% uptodate without saying what you
> > understand by "being uptodate". As already outlined during the last
> > discussion: when all m68k buildds are building package, that can easily be
> > more than 110 packages marked as building and therefore missing as installed
> > (given a total of 5500 packages). 
> Once again, what I'm hearing here is a plea for latitude towards certain
> ports because they're slow, instead of an acknowledgement that being slow
> (and therefore, failing to keep up) is what causes extra work for the
> release team.

No. Looking at s390, which ought to be no slow arch, there are currently 90
packages in Needs-Build, 116 in Building, 6 Failed, 39 Dep-Wait, 1
Failed-Removed and 28 Not-For-Us. So, a total of 251 (+29) packages marked
as not Installed. That's >2% as well. 
That's why I asked how this number will be obtained. 

> > Currently m68k has ~650 packages listed that are not in state Installed (203
> > Needs-Build, 142 Building, 180 Failed, 123 Dep-Wait (+ 5 Failed-Removed + 25
> > Not-For-Us)). That's roughly 6% of all packages. 
> Yes, and a week ago the m68k porter lists were informed that the current
> state of m68k is unacceptable and that if significant progress wasn't made
> soon, we would ask for m68k to be ignored for all testing propagation.

Yes, and although there are at least two buildds that are not running
currently (because the local admin was very busy in the past) and even one
of them has a broken boot disk, the port is keeping up fairly well now. 

> If an architecture fails the release candidate criteria for whatever
> reason, and is demoted to a non-release arch, I believe the sensible course
> of action is to give the porters a fixed two-month period to remedy the
> lapses before being re-evaluated by the release team.  That leaves the
> porters free to focus on fixing whatever the issues are instead of scurrying
> to get re-qualified ASAP, and it also ensures the release team's time isn't
> wasted re-approving a port which qualifies at the instant but immediately
> becomes a liability again after being approved.

When a port isn't keeping up, it's already free to decide for the release
team to release that port or not. Instead, new, arbitrary numbers and rules
are raised. 
And I still think this is a proposal? Shouldn't it be voted about before it
becomes reality?

> graphics/gem_1:0.90.0-17: Dep-Wait by buildd_m68k-kiivi [optional:out-of-date]
>   Dependencies: libjack0.80.0-0 (>= 0.99.0)
>   Previous state was Building until 2005 Aug 10 08:44:01
> This is a sampling of screwy dep-waits I was able to find by glancing
> through the buildd.debian.org webpages, and excludes those that I've already
> specifically asked the m68k porters to remove in the recent past because
> they were holding up transitions.

So, what is better: to set a dep-wait and maybe do something wrong or
setting no dep-wait at all and let the package in Building state for weeks? 

> And sure, other buildd maintainers occasionally set a bogus dep-waits, but
> it seems to be m68k where I most frequently have to ask for their removal...

Which is usually corrected asap, right?
 
> > Ok, let's have a look at http://release.debian.org/etch_arch_qualify.html:
> > - 5 devs (porters): think so, yes: cts, adconrad, smarenka, smurf, rnhodek,
> > wout

Re: architecture-specific release criteria - requalification needed

[Petter Reinholdtsen]

[Debian-armeb Porting Team]
> However, how does one get "armeb" recognised as a valid option for
> the graphs on http://popcon.debian.org?  Will simply sending in
> valid survey results with armeb as the architecture cause the graphs
> on that page to list armeb separately?

Yes.  The url to the port page might be incorrect, but that is a minor
detail.  Report a bug against the popularity-contest package with the
port page URL to have this fixed.

So, please enable popularity-contest on the machines in question, so
we can get a count on them. :)

> We are keeping patches[7] for the armeb port separate, and are ready
> to contribute them now, or at any future time that is more
> appropriate.  Another chicken-and-egg - are package maintainers
> expected to accept patches for architectures that are not yet
> official?

It depend on the patch.  Personally, I welcome patches making the
software more portable and less buggy, and I consider compile problems
or unable to run on any platform a bug.  On the other hand, if the
patch is cludgy, it will need to be rewritten.

> Chicken-and-egg again.  We need automatic support for keeping the
> autobuilders busy.  The machines we currently use run 24x7, but the
> feeding of items to build and the determination of build
> dependencies is currently done manually (which is very tedious).  We
> really need to be hooked into the buildd infrastructure.

You know it is possible to set up your own buildd infrastructure?  It
has been done in the past, and will probably happen in the future too.
You do not need to wait for the buildd.debian.org people to have time
to help you to set up your own buildd. :)


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

Re: glibc and PaX issue

[Bastian Blank]

On Thu, Sep 22, 2005 at 07:41:12PM +1000, Russell Coker wrote:
> Debian's libc6 needs to be fixed.

There is no bug. It just enforces the EPERM message from the kernel.

Bastian

-- 
Intuition, however illogical, is recognized as a command prerogative.
-- Kirk, "Obsession", stardate 3620.7


signature.asc
Description: Digital signature

Bug#329631: ITP: binutils-msp430 -- Binutils files for the Texas Instruments MSP430 family of microprocessors

[Tom Parker]

Package: wnpp
Severity: wishlist
Owner: Tom Parker <[EMAIL PROTECTED]>

* Package name: binutils-msp430
  Version : 2.16
  Upstream Author : FSF (well, I'm fairly sure they're the main
  copyright holders)
* URL : http://www.gnu.org/software/binutils/
* License : GPL
  Description : Binary utilities that support TI's MSP430

 The programs in this package are used to manipulate binary and object
 files that may have been created for TI's MSP430 architecture.  This package
 is primarily for MSP430 developers and cross-compilers and is not needed
 by normal users or developers.

(Text for description is mostly copy+paste from binutils-avr)
I'm not currently a Debian developer, but have considered becoming one
when a package that I particularly wanted turns up. I've made
preliminary versions of this package available at http://tevp.net/debian/ and
intend to search for a sponsor.

-- System Information:
Debian Release: testing/unstable
  APT prefers stable
  APT policy: (990, 'stable'), (103, 'testing'), (102, 'unstable'), (99, 
'experimental'), (98, 'hoary'), (97, 'breezy')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686-smp
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

[OT] Names

[Daniel Jacobowitz]

On Thu, Sep 22, 2005 at 06:45:35PM +0930, Debian-armeb Porting Team wrote:
> -- Signed, the debian-armeb porting team.

We've always had a policy of asking people to use real names on this
list.  Usually we invoke this for people using pseudonyms, but I think
it's appropriate for role addresses, too.

Whenever you write a message, you speak for yourself, in addition to
any group of people you represent.  So I would appreciate it if you at
least signed messages with a name.

Thanks.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


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

Re: access to debian mirror pools

[Osamu Aoki]

On Tue, Sep 20, 2005 at 09:34:22AM -0500, Carlo Segre wrote:
...
> I have investigated this by grabbing individual files with wget and I have 
> discovered that the same IP address is selected each time I run wget on a 
> specific computer.  
...
> Any insights?  Is this a bug, if so for what package?

You should check your DNS set up of each computer which you ran wget or
any of the similar programs.   DNS server (or its local cache value on
your PC) provides IP address to programs such as wget and apt.

Osamu


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

Re: architecture-specific release criteria - requalification needed

[Kurt Roeckx]

On Thu, Sep 22, 2005 at 06:45:35PM +0930, Debian-armeb Porting Team wrote:
> 
> We *really* need to be hooked into the buildd system to be able to
> automatically build the rest of the stable, testing and unstable
> releases.  This is our top-most priority, and we hope to get help on
> this point from the Debian infrastructure teams.  We have buildd clients
> ready and running, but we need a server to feed them build requests.

There is nothing that prevents you from setting up wanna-build
and dak yourself.  Other ports (amd64, m32r?) and projects
(experimental, volatile, secure-testing?) already do this.  

However, I agree that it would be easier to start a new port if
we had some central place where new ports could start out without
the need to already be in the main archive.


Kurt


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

Bug#329676: ITP: CashUtil -- GnuCash command line interface and shell

[Neil Williams]

Package: wnpp
Severity: wishlist
Owner: Neil Williams <[EMAIL PROTECTED]>


* Package name: CashUtil
  Version : 0.1.0
  Upstream Author : Neil Williams <[EMAIL PROTECTED]>
* URL : http://www.linux.codehelp.co.uk/cashutil/
* License : GPL
  Description : GnuCash command line interface and shell

 A command line interface for GnuCash providing access to most GnuCash
 features. CashUtil supports SQL-type queries using QOF and writes
 results to QSF XML to support external report scripts / tools. It
 also includes the prototype QOF interactive shell and limited undo
 capability.
 .
 This package provides the files needed to run CashUtil.

The XML format used by cashutil exports is documented here:
http://code.neil.williamsleesmill.me.uk/qsf.html
and
http://code.neil.williamsleesmill.me.uk/doxygen/group__QSF.html

CashUtil requires libqof1 (QOF >= 0.6.0) and will share some
libraries with GnuCash.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.4.25-1-686
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)


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

A quick favor to ask...

[ADSL HQ]

Hi,

I've just set up a new site about ADSL stuff, and when I was 
researching the subject, I found your site. I think your site has 
got some fantastic content, and it would be a great resource for 
my visitors. Would it be alright if I traded links with you?

I was so excited about the possible links, that I went ahead and 
added a link to your site to my Resource Directory.

Is that OK with you? The site address is 
http://www.adsl-hq.com and the link is on http://www.adsl-hq.com/adslconsoleport

If this is alright, can I ask a favor? Will you give me a link back on 
your site? I'd really appreciate it!

As you can imagine, the list that I have created of all of the sites 
I've visited is really long, and some errors sometimes creep in. If you have 
received this message and it is not relevant to you, then please accept
my sincere apologies. I will remove you from my list immediately.

If you want to chat about this further, then please drop me an email, and
we'll see where we go from there.

Warm regards and best wishes,

from Andy.

[EMAIL PROTECTED]

P.S. When you do link back, there's some suggested code to use at
http://www.adsl-hq.com/links/addlink.html

//

ITP: ksplash-engine-moodin -- fading splash screen engine for KDE

[Fathi Boudra]

Package: wnpp
Severity: wishlist
Owner: Fathi Boudra <[EMAIL PROTECTED]>


* Package name: ksplash-engine-moodin
  Version : 0.4.2
  Upstream Author : Christian Leh <[EMAIL PROTECTED]>
* URL : http://moodwrod.com/files/
* License : GPL
  Description : fading splash screen engine for KDE

Heavily customizable ksplash engine for various types of themes.

This KDE splash screen engine is based upon Linspire's
engine by Sean Meiners <[EMAIL PROTECTED]>


At the moment, the source file provided by the upstream contains svn 
directory. So i've got the source-contains-svn-control-dir .svn warning from 
lintian. My package can be found on mentors.debian.net.

cheers,

Fathi

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-k7
Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1)


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

Re: Build-Depend'ing on libasound2-dev just for Linux

[Goswin von Brederlow]

Guillem Jover <[EMAIL PROTECTED]> writes:

> Hi,
>
> On Fri, Sep 16, 2005 at 09:09:25AM +0200, Josselin Mouette wrote:
>> Le vendredi 16 septembre 2005 à 00:33 +0200, Aurelien Jarno a écrit :
>> > It is maybe a crazy idea, but it is the only one that work. What you 
>> > suggest simply doesn't work, as not+linux is a provided package, and the 
>> > autobuilders are not able to see it. In short a package with such a 
>> > build-dependency will FTBFS on non linux architectures, if built by an 
>> > autobuilder.
>> 
>> In this case, it is enough to do something like:
>> Build-Depends: type-handling, libasound2-dev | not+linux-gnu
>
> No, that's too late, the Build-Depends are analyzed before installing
> them. You'd need some kind of ugly Build-PreDepends or similar.

That isn't the problem at all.

There are 2 problems here:

1. 'Build-Depends: A | B' means the buildd installs A. B is never
considered when looking for something to install.

2. not+linux-gnu is a virtual package and Build-Depends then can cause
apt errors. The official buildd software works around the problem but
apt-get build-dep (as a user might run) won't.

This isn't fatal but anoying.

> So type-handling is broken, do not use it. We (the GNU/kFreeBSD team)
> have adopted it and will push for its removal once dpkg gets the
> needed functionality.

It isn't the fault of type-handling. This is just the way
Build-Depends are ment to work.

To make it behave the way you wanted you need to generate a control.new
file on the fly in clean with type-handling output and fail if that
file differs from control.

It is also nice to have a traget "debian/control" that generates
control.new and copies it over control. But this must not be done
automaticaly as at that point it would be too late.

> regards,
> guillem

MfG
Goswin

PS: yes, this sort of sucks.


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

Re: architecture-specific release criteria - requalification needed

[Goswin von Brederlow]

Andreas Barth <[EMAIL PROTECTED]> writes:

> Hi all,
>
> It has been discussed for a while already.  While we have release
> criteria for packages, up until now we don't have any for the
> architectures.  However, decisions made about an architecture affect
> both our users (and developers) and the release cycle much more than
> decisions about an individual package.
>
> For that reason, we discussed in multiple meetings, together with porters,
> ftp-masters and other people more than once how the criteria should
> look.  Also, there was more than one discussion on debian-devel. [1, 2]

Before you talk about the color of the car could we maybe first say
what kind of car we are building?

What I mean is that there are several issues overlapping here and you
are attacking the last and least urgent issue first.

Here is how I see the current urgencies:

1. split the mirror system into required and optional archs.

Specify what criteria an arch has to meat to be required on all
mirrors. This seems to be nearly exclusivly an "how many downloads
does the arch generate" criteria.

The split must be implemented for the archive and the mirror
infrastructure has to adapt to this. The reason amd64 wasn't added to
sid over a year ago was that mirrors are running out of bandwith,
mirror pusles take too long and are too expensive for some. With the
growth of Debian in the last year this must be even more of a problem
now than ever.


2. Define criteria for scc archs

Define what levels of archs there will be, e.g.:

- new ports with just unstable (could be hosted as alioth projects)
- ports that don't have stable (no releases)
- slow/incomplete ports that don't block testing but are release
  candidates if they can catch up during freeze
- full ports

Implement this in the archive software.

Will ports that don't block testing have their own britney runs or
just be continiously out of sync unless the port can keep up?


3. Define criteria for releases

This should realy be done after 2 is implemented and some experience
has been made. There is hardly a point in deciding what gets released
and then having to delay etch for 2 years till the archive implements
the infrastructure to make that even possible.

Also who makes the release and what makes it official?

For sarge amd64 basicaly was in the "doesn't block testing" section
from above and did the unofficial release with a small delay to the
official sarge and only minimal deviation from sarge source where
absoluetly neccessary. I think there should be some criteria for the
porting team to pull of a release like that and declare it
official. The work for this should fall to the porting team and they
should organize security for that port as well (like amd64 did).


So I suggest 2 release criteria:

a) this is needed for the RM team to include the arch
b) this is needed if the port team wants to make a release (and call
   it official)


As for what exactly each criteria should be keep fighting.

MfG
Goswin


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

Bug#329695: ITP: slgdbm -- access to GDBM databases from S-Lang

[Rafael Laboissiere]

Package: wnpp
Severity: wishlist
Owner: Rafael Laboissiere <[EMAIL PROTECTED]>


* Package name: slgdbm
  Version : 1.6
  Upstream Author : Paul Boekholt <[EMAIL PROTECTED]>
* URL : http://www.cheesit.com/downloads/slang/slgdbm.html
* License : GPL
  Description : access to GDBM databases from S-Lang

This package contains a S-Lang module which provides access to GDBM
databases, with an assoc-like syntax for the user interface.  This module
can be used in slsh (the S-Lang shell), in the JED editor, and in the
news reader slrn.
  
There is a temporary apt-getable repository for the package:

http://people.debian.org/~rafael/slgdbm/

I am considering transfering the maintainership of this package to the
Debian Jed Group (http://pkg-jed.alioth.debian.org).

Alastair: what do you think?

-- 
Rafael


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.8-1-686
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: architecture-specific release criteria - requalification needed

[Henrique de Moraes Holschuh]

On Thu, 22 Sep 2005, Goswin von Brederlow wrote:
> Before you talk about the color of the car could we maybe first say
> what kind of car we are building?
> 
> What I mean is that there are several issues overlapping here and you
> are attacking the last and least urgent issue first.

Well, it is the release team speaking, they deal only with the last issue.
And there is absolutely no reason for them to wait on any of the other
issues at all, if they already know what they want.  SCC might not even be
under the release team's umbrella, for all we know of the future.

IMHO it is much better to get the release criteria out NOW, and thus let
people adapt and react to it with enough time to actually manage to fix
problems, so that an arch that would not be released ends up being released.

> 3. Define criteria for releases
> 
> This should realy be done after 2 is implemented and some experience
> has been made. There is hardly a point in deciding what gets released

Not really.  It just depends on how well the release team knows about what
is going to cause them trouble without the need for SCC insight.

> a) this is needed for the RM team to include the arch
> b) this is needed if the port team wants to make a release (and call
>it official)

IMHO (b) is quite tied to SCC, and it is better discursed along with SCC.

-- 
  "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]

Re: [OT] Names

[Lennert Buytenhek]

On Thu, Sep 22, 2005 at 10:15:32AM -0400, Daniel Jacobowitz wrote:

> > -- Signed, the debian-armeb porting team.
> 
> We've always had a policy of asking people to use real names on this
> list.  Usually we invoke this for people using pseudonyms, but I think
> it's appropriate for role addresses, too.
> 
> Whenever you write a message, you speak for yourself, in addition to
> any group of people you represent.  So I would appreciate it if you at
> least signed messages with a name.

Makes sense, we'll sign messages with our real names from now on.

All members of the Debonaras core team contributed to the email you
quoted, but since I was elected as leader of the project, you can
consider it as having been signed by me.


cheers,
Lennert


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

Re: Need C programmer to verify gcc-4.0 FTBFS patch --done

[Christian Hammers]

On 2005-09-22 Christian Hammers wrote:
> The latest upstream version of libnet-rawip-perl won't compile with gcc-4.0
> and produces lot of the below quoted errors. I produced a patch but would
> like a real C programmer to verify what I tried.

No help needed anymore :)

bye,

-christian-


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

Need C programmer to verify gcc-4.0 FTBFS patch

[Christian Hammers]

Hello

(please Cc me)

The latest upstream version of libnet-rawip-perl won't compile with gcc-4.0
and produces lot of the below quoted errors. I produced a patch but would like
a real C programmer to verify what I tried.

I tried to understand the changelog of gcc-4.0 and think I learned that the
left hand side has to be a "plain simple variable without any frills" and as
a typecast never changes the actual value the removing it should be fine, or?

thanks,

-christian-

"pktr" and "user" are "struct"s and "ihl" an "u_int".

RawIP.xs: In function 'XS_Net__RawIP_dispatch':
RawIP.xs:1287: error: invalid lvalue in assignment
RawIP.xs: In function 'XS_Net__RawIP_loop':
RawIP.xs:1309: error: invalid lvalue in assignment

SID_i386 [EMAIL PROTECTED]:~/debian/perl/t$ diff 
../libnet-rawip-perl-0.20/RawIP.xs
RawIP.xs  762c762
< (u_char*)pktr = (u_char*)pktr + (ihl*4 - 20);  
---
> pktr = (u_char*)pktr + (ihl*4 - 20);  
788c788
<(u_char*)pktr = (u_char*)pktr + (doff*4 - 20);
---
>pktr = (u_char*)pktr + (doff*4 - 20);
821c821
< (u_char*)pktr = (u_char*)pktr + (ihl*4 - 20);  
---
> pktr = (u_char*)pktr + (ihl*4 - 20);  
861c861
< (u_char*)pktr = (u_char*)pktr + (ihl*4 - 20);  
---
> pktr = (u_char*)pktr + (ihl*4 - 20);  
895c895
< (u_char*)pktr = (u_char*)pktr + (ihl*4 - 20);  
---
> pktr = (u_char*)pktr + (ihl*4 - 20);  
1287c1287
< (u_char *)user = SvIV(user); 
---
> user = SvIV(user); 
1309c1309
< (u_char *)user = SvIV(user); 
---
> user = SvIV(user); 


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

Work-needing packages report for Sep 23, 2005

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 188 (new: 2)
Total number of packages offered up for adoption: 79 (new: 5)
Total number of packages requested help for: 16 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   gtk-engines-thinice (#329655), orphaned today
 Description: ThinIce theme for GTK+ 1.2

   zorroutils (#328650), orphaned 6 days ago
 Description: Zorro bus utilities for Amigas running 2.1 and later
 kernels

186 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   liblog-dispatch-perl (#329645), offered today
 Description: Dispatches messages to multiple Log::Dispatch::*
 objects
 Reverse Depends: request-tracker3.4

   libmusicbrainz-2.1 (#328958), offered 4 days ago
 Reverse Depends: libmusicbrainz4-dev xmms-scrobbler libtunepimp2c2
 libtunepimp2-dev zinf juk k3b libmusicbrainz-ruby1.8
 beep-media-player-scrobbler libtunepimp-bin sound-juicer

   psutils (#329425), offered yesterday
 Description: A collection of PostScript document handling utilities
 Reverse Depends: logidee-tools kdeprint alml impose+

   xsnow (#329485), offered yesterday (non-free)
 Description: Brings Christmas to your desktop

   zinf (#328956), offered 4 days ago
 Description: Extensible, cross-platform audio player
 Reverse Depends: zinf-extras zinf-plugin-esound zinf-plugin-arts
 zinf-plugin-alsa

74 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   aboot (#315592), requested 91 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot-cross ltsp-server dfsbuild aboot

   athcool (#278442), requested 331 days ago
 Description: Enable powersaving mode for Athlon/Duron processors

   debtags (#321654), requested 47 days ago
 Description: Enables support for package tags
 Reverse Depends: libdebtags1-pic debtags-edit

   dselect (#282283), requested 306 days ago
 Description: a user tool to manage Debian packages

   grub (#248397), requested 500 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: webmin-grub grubconf replicator dfsbuild
 grub-splashimages

   gtkpod (#319711), requested 60 days ago
 Description: manage songs and playlists on an Apple iPod

   lsdvd (#316922), requested 80 days ago
 Description: read the contents of a DVD

   mwavem (#313369), requested 101 days ago (non-free)
 Description: Mwave/ACP modem support software

   parted (#262885), requested 416 days ago
 Description: Searching co-maintainer for the parted package.
 Reverse Depends: libparted1.6-dbg libparted1.6-i18n prep-installer
 qtparted partitioner partconf parted parted-udeb elilo-installer
 gparted autopartkit partman-base partman-efi partconf-mkfstab
 libparted1.6-dev aboot-installer lvmcfg-utils mindi
 partconf-find-partitions

   pbbuttonsd (#270558), requested 380 days ago
 Description: PBButtons daemon to handle special hotkeys of Apple
 computers
 Reverse Depends: pbbuttonsd-dev gtkpbbuttons gtkpbbuttons-gnome
 powerprefs

   php-pspell (#326173), requested 20 days ago

   qmailadmin (#267756), requested 394 days ago
 Description: web interface for managing qmail with virtual domains
 [contrib]

   sourcenav (#263051), requested 416 days ago
 Description: Source code analysis, editor, browser and build tool:
 Looking for co-maintainer

   sql-ledger (#320442), requested 55 days ago
 Description: A web based double-entry accounting program

   squashfs (#267078), requested 398 days ago
 Description: Tool to create and append to squashfs filesystems

   stlport4.6 (#263052), requested 416 days ago
 Description: STLport C++ class library
 Reverse Depends: libstlport4.6-dev

See http://www.debian.org/devel/wnpp/help_requested for more information.


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