Re: GCC 4.1 now the default GCC version for etch

[Joost Yervante Damad]

Hi,

quite some of the "dereferencing type-punned pointer" problems are really 
problems in the wxwindows 2.6 library.

Greetings, Joost Damad

-- 
The planet Andete is famous for it's killer edible poets.


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

Bug#372268: ITP: valkyrie -- A graphical front-end to valgrind

[Tobias Klauser]

Package: wnpp
Severity: wishlist
Owner: Tobias Klauser <[EMAIL PROTECTED]>

* Package name: valkyrie
  Version : 1.1.0
  Upstream Author : OpenWorks LLP <[EMAIL PROTECTED]>
* URL : http://www.open-works.co.uk/projects/valkyrie.html
* License : GPL
  Programming Lang: C++
  Description : A graphical front-end to valgrind

Valkyrie is an open-source graphical user interface for the Valgrind 3.X
line. Valkyrie uses the Qt widget library, and is based on Valgrind`s
XML output capabilities.
.
Currently, Valkyrie supports Memcheck only, although work is in progress
to handle Cachegrind and Massif.

-- 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.16-xenon
Locale: LANG=en_GB, LC_CTYPE=de_CH (charmap=ISO-8859-1) (ignored: LC_ALL set to 
en_GB)


signature.asc
Description: Digital signature

CDBS and dh_install

[Jean Parpaillon]

Hi,
I want to migrate my package (wormux) to CDBS.
In the .install files, path are not prefixed by "debian/tmp" so
the building fail.
It seems that I can correct this in 2 ways:
- either I prefix the paths with debian/tmp
- or I can set a special variable (DEB_DESTDIR, am I right ?) to debian/tmp

Why do the default behaviour of dh_install is not to get files in
'debian/tmp' ? And am I right with my solutions ?

Jean

-- 
 
/ Les petits lits font les grandes   \
\ maîtresses. -+- Pierre Perret -+- /
 
\   ^__^
 \  (xx)\___
(__)\   )\/\
 U  ||w |
|| ||


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

Re: CDBS and dh_install

[Stephen Gran]

This one time, at band camp, Jean Parpaillon said:
> Hi,
> I want to migrate my package (wormux) to CDBS.
> In the .install files, path are not prefixed by "debian/tmp" so
> the building fail.
> It seems that I can correct this in 2 ways:
> - either I prefix the paths with debian/tmp
> - or I can set a special variable (DEB_DESTDIR, am I right ?) to debian/tmp
> 
> Why do the default behaviour of dh_install is not to get files in
> 'debian/tmp' ? And am I right with my solutions ?

I think cdbs looks at your debian/compat level for where to install the
files.  For recent compat levels, it wants to install to
debian/$package.  I am not sure of the solution, but it may just be
simplest to migrate to the new directory location.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: debdelta

[A Mennucc]

Nikita V. Youshchenko wrote:

The command 'debdelta-upgrade' is meant to be run between 'apt-get
 update' and 'apt-get upgrade'; it downloads .debdelta files and
 recreate the new .deb files from them; always using the *installed* old
 version of the .deb, and not the old .deb file itself.


Is it safe - e.g. in case of localy-modified config files?



yes

a.


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

Re: mystery of dh_installdirs

[Loïc Minier]

Hi,

On Fri, Jun 09, 2006, Atsuhito Kohda wrote:
> Hi all, I got an FTBFS bug yesterday;
> > There was an error while trying to autobuild your package:
> > > install -m 755 debian/lynx 
> > > /build/buildd/lynx-cur-2.8.6dev18/debian/lynx-cur-wrapper/usr/bin/lynx-cur
> > > install: cannot create regular file 
> > > `/build/buildd/lynx-cur-2.8.6dev18/debian/lynx-cur-wrapper/usr/bin/lynx-cur':
> > >  No such file or directory

 From the buildd log, this seems wrong:
# Add here commands to install the package into debian/.
/usr/bin/make install-full x=".cur" 
prefix=/build/buildd/lynx-cur-2.8.6dev18/debian/lynx-cur/usr \
libdir=/build/buildd/lynx-cur-2.8.6dev18/debian/lynx-cur/etc/lynx-cur \

docdir=/build/buildd/lynx-cur-2.8.6dev18/debian/lynx-cur/usr/share/doc/lynx-cur 
\

helpdir=/build/buildd/lynx-cur-2.8.6dev18/debian/lynx-cur/usr/share/doc/lynx-cur/lynx_help
 \

mandir=/build/buildd/lynx-cur-2.8.6dev18/debian/lynx-cur/usr/share/man/man1

 The "prefix" and other vars you pass to configure shouldn't be
 overriden in make install.  You should switch to using "DESTDIR"
 instead.  Even if your package does not use automake, it seems to
 properly implement DESTDIR support.  make install DESTDIR=debian/tmp

 This is also scary:
mv -f /build/buildd/lynx-cur-2.8.6dev18/debian/lynx-cur/usr/bin/lynx.cur 
/build/buildd/lynx-cur-2.8.6dev18/debian/lynx-cur/usr/bin/lynx.old
mv: cannot stat 
`/build/buildd/lynx-cur-2.8.6dev18/debian/lynx-cur/usr/bin/lynx.cur': No such 
file or directory
m

 I couldn't reproduce the build failure the buildd experienced neither
 on my sid, nor in a pbuilder but I think you should fix the above
 problems first to see clearer in the problem.

 Perhaps it's a permission problem due to the usage of different umasks
 on the buildd setups and on our setups?  I saw numerous "mkdir" and
 "cp" calls, which should IMO be install -d and install calls.

 Oh and you might want to use dh_install and debian/*.install instead of
 calling install manually.

  Bye,
-- 
Loïc Minier <[EMAIL PROTECTED]>


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

Re: CDBS and dh_install

[Andreas Metzler]

Jean Parpaillon  altern.org> writes:
> I want to migrate my package (wormux) to CDBS.
> In the .install files, path are not prefixed by "debian/tmp" so
> the building fail.
> It seems that I can correct this in 2 ways:
> - either I prefix the paths with debian/tmp
> - or I can set a special variable (DEB_DESTDIR, am I right ?) to debian/tmp
[...]

Hej,
I am using
DEB_DH_INSTALL_SOURCEDIR = debian/tmp
for that purpose.
cu andreas


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

Re: CDBS and dh_install

[Jean Parpaillon]

Le 09.06.2006 13:37, Andreas Metzler a écrit :
> Jean Parpaillon  altern.org> writes:
>   
>> I want to migrate my package (wormux) to CDBS.
>> In the .install files, path are not prefixed by "debian/tmp" so
>> the building fail.
>> It seems that I can correct this in 2 ways:
>> - either I prefix the paths with debian/tmp
>> - or I can set a special variable (DEB_DESTDIR, am I right ?) to debian/tmp
>> 
> [...]
>
> Hej,
> I am using
> DEB_DH_INSTALL_SOURCEDIR = debian/tmp
> for that purpose.
> cu andreas
>
>
>   
Thanks, it works fine.
But the real question is : why it is not the default behaviour ? Is it a
bug in CDBS or a feature ;-)

Jean

-- 
 
/ J'ai emprunté ma chaumière Aux puces \
| et aux moustiques Et j'ai dormi -+-|
\ Issa -+-   /
 
\   ^__^
 \  (..)\___
(__)\   )\/\
||w |
|| ||


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

Re: GBit performance problem with nfs client

[Bastian Blank]

On Thu, Jun 08, 2006 at 12:53:48PM +0200, Gordon Grubert wrote:
> Problematic Debian-Client (structurally identical to Suse-Client):
> - Linux DEBIAN-CLIENT 2.6.15.1
> - Yukon Gigabit Ethernet with default drivers (Debian Sarge AMD64)

Sarge don't have a kernel 2.6.15. But this is a known and unfixed bug in
Linux. The fix is sheduled for .18.

Bastian

-- 
We have found all life forms in the galaxy are capable of superior
development.
-- Kirk, "The Gamesters of Triskelion", stardate 3211.7


signature.asc
Description: Digital signature

Re: GCC 4.1 now the default GCC version for etch

[Simon Kelley]

Martin Michlmayr wrote:


Simon Kelley
  dnsmasq 2.31-1



Looks pretty trivial, it will fixed in the next upstream/upload.

Cheers,

Simon.


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

Re: CDBS and dh_install

[martin f krafft]

also sprach Jean Parpaillon <[EMAIL PROTECTED]> [2006.06.09.1118 +0200]:
> I want to migrate my package (wormux) to CDBS.

Why?

This is my opinion and others will disagree:
Please don't. CDBS is a major pain to use for those who didn't
(co-)author it. It's just too much about obfuscation.

> In the .install files, path are not prefixed by
> "debian/tmp" so the building fail.

They should not be.

also sprach Andreas Metzler <[EMAIL PROTECTED]> [2006.06.09.1337 +0200]:
> I am using
> DEB_DH_INSTALL_SOURCEDIR = debian/tmp
> for that purpose.

This is old. Why not switch to debhelper compatibility level 5,
which includes switching to a new format for *.install files?

also sprach Jean Parpaillon <[EMAIL PROTECTED]> [2006.06.09.1344 +0200]:
> But the real question is : why it is not the default behaviour
> ? Is it a bug in CDBS or a feature ;-)

man dh_install
man debhelper

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"never attribute to malice what can be
 adequately explained by incompetence." 
   -- mark twain


signature.asc
Description: Digital signature (GPG/PGP)

Re: CDBS and dh_install

[Adeodato Simó]

* Jean Parpaillon [Fri, 09 Jun 2006 11:18:07 +0200]:

> Why do the default behaviour of dh_install is not to get files in
> 'debian/tmp' ?

That was the default behavior for the old dh_movefiles, which got
deprecated in debhelper 4 in favour of dh_install (see the changelog for
4.0.0 for details).

AIUI, one of the design decisions in dh_install was that its file lists
would be relative to the top level dir, which makes sense if you take
into account that all debhelper commands run from the top level dir.

The --sourcedir option was introduced in 4.0.4 to ease the migration
from the list of files for dh_movefiles to that of dh_install.

> And am I right with my solutions ?

Yes.


* Jean Parpaillon [Fri, 09 Jun 2006 13:44:59 +0200]:

> But the real question is : why it is not the default behaviour ? Is it a
> bug in CDBS or a feature ;-)

See above. CDBS defaults to debhelper's defaults, which is sane. If you care
about numbers, you'll see that CDBS's default would just fit the majority of
packages that use dh_install.

  @gluck:/org/lintian.debian.org/laboratory/source
  % grep -e --sourcedir=debian/tmp -l **/rules | wc -l
  509

  @gluck:/org/lintian.debian.org/laboratory/source
  % grep dh_install -l **/rules | xargs grep -e --sourcedir=debian/tmp -L | wc 
-l
  8374

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
 Listening to: Rosa León - El día que me quieras

Re: Renaming a package

[Ian Jackson]

Daniel Kobras writes ("Re: Renaming a package"):
>  but the alternative patch to dpkg is quite simple (see
> below). Alas, it changes current behaviour.

I don't think it this patch is correct as is, but something similar
might not be unreasonable if it had to be turned on with a command
line option.

Ian.


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

Re: Who can make binding legal agreements

[Ian Jackson]

John Goerzen writes ("Re: Who can make binding legal agreements"):
>  * If a member project engages in activities that would jeopardize
>SPI's classification as a non-profit entity

Things of that kind would be using SPI property or funds for
unsuitable activities.  Note that if Debian do it separately, without
our support or funding, then SPI has no problem.  SPI's resources are
only for charitable purposes, but that doesn't infect the whole of
each of our associated projects.

(NB, associated projects, not member projects.  They're not members in
any normal sense.)

>  * If a member project engages in illegal activities or presents
>significant legal exposure to the organization

Obviously if Debian used SPI property (eg, the servers) for copyright
infringement we'd have to step in and stop that.  But copyright
infringement is possible only if you don't have the permission of the
copyright holder.  Here Sun have told Debian repeatedly that they
approve, so obviously it's not infringement; if Sun should change
their mind then obviously Debian would stop distributing the software
(and thus stop using SPI's property to do so) immediately.

> First of all, corporate winds can change.  But really my point is not
> that SPI should have rejected this license.  My point is that SPI should
> have been consulted about the indemnification so that we could get the
> advice of our attorney, and perhaps based on his feedback, either raise
> concerns about it (or not).

SPI has not indemnified anyone.  We are not a party to the licence.

Ian.


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

Re: Who can make binding legal agreements

[Ian Jackson]

John Goerzen writes ("Re: Who can make binding legal agreements"):
> The other plausible interpretation is that SPI *is* on the hook, as the
> legal entity that owns servers that are distributing software.

If you use your shell account at your ISP to distribute software, and
the ISP concludes you have a licence (so lets you carry on) but that
turns out to be wrong, then the ISP is generally not liable if they're
broadly speaking reasonable.  In this particular case we've had
multiple messages from the copyright holder telling us it's OK so them
sueing us would be even more absurd.

> I'm not so sure that a court would buy the "Debian is not a legal
> entity, and SPI hasn't delegated authority, therefore neither is liable"
> argument.  But again, a question for our attorney.

The following legal entities would be liable:
 * The individual ftpmasters and/or Maintainers (who appear to have
 indemnified Sun).  It's not clear to me exactly which people a
 court would say had performed the infringing acts, but the
 Maintainers and ftpmasters are I think probably on the hook.
 * SPI if we knowingly allowed Debian to infringe copyright
(which we are not doing because Sun has told us it's ok,
 which means even if Sun were confused or lying or something,
 we can reasonably not have known that it was infringement).

So I'm not saying that no-one would be liable.  SPI is neither a party
to the licence (it doesn't need to be because it's not doing the
distribution) nor liable for contributory infringement (because there
is no actual infringement and even if there is we don't know about
it).

Ian.


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

Re: severities of blocking bugs

[Ian Jackson]

Manoj Srivastava writes ("Re: severities of blocking bugs"):
> Well, consider this.  If there is a feature someone wants from
>  a package, say kernel-pack^H^H^H^Hfoo.
>[most of scenario snipped -iwj]
> Can one now change the wishlist bug to grave as well?  I think
>  not, since the feature request for foo remains a feature request.

This is another example of a situation where people are trying to use
the machinery intended to _support_ our work as a stick to _force_
someone to do some work that they're not interested in.

If some program lacks a feature or bugfix you want for your package,
then _implement it_ instead of whining !

Most maintainers are much more cooperative when you tag the bug as
+patch and say something like:

  Here is a patch which implements this feature, which my new package
  universe-destruction-preventer depends on; I'd be very grateful if
  you could look it over and let me know what you think.

  You'll notice that I haven't taken the approach suggested by Fred.
  This is because the neutron flow can be reversed at the critical
  point, resulting in an unfortunate explosion in certain error cases.
  Instead I have made frobnicate_hairball independent of the neutron
  flow polarity.

  If you don't have the effort to make a release right now I'd be
  happy to make an appropriate NMU.

As opposed to writing to demand that the maintainer spend their free
time to help you fix your problem !

Remember also that the purpose of bug reports is to help us improve
the package.  The purpose of bug reports in Free software is _not_ to
solve the submitter's problem !  (Although that's sometimes a helpful
side-effect.)

Ian.


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

Re: GCC 4.1 now the default GCC version for etch

[Mike Hommey]

On Thu, Jun 08, 2006 at 07:46:06AM +0200, Mike Hommey <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 07, 2006 at 10:28:29AM +0200, Martin Michlmayr <[EMAIL 
> PROTECTED]> wrote:
> > * Matthias Klose <[EMAIL PROTECTED]> [2006-06-07 02:20]:
> > > We did pick two compiler warnings and scanned the build logs of one
> > > archive rebuild on alpha (64bit), where wrong code may be generated.
> > > These warnings can be found in 1600 packages [4]; they are:
> > > [4] http://people.debian.org/~tbm/logs/pointer/
> > 
> > Here is a list of maintainers and their packages which exhibit such
> > warnings:
> > 
> > Mike Hommey
> >   xulrunner 1.8.0.1-11
> 
> What I quite don't get is why xulrunner gets warnings while firefox and
> thunderbird don't...

Moreover, I don't understand how you managed to build xulrunner with gcc
4.1. I just tried and got loads of
error: no suitable 'operator delete' for 'whateverClass'
on delete operators defined as operator delete(void *, size_t).

Which will obviously fail on firefox and thunderbird as well...

Mike


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

Re: GBit performance problem with nfs client

[Gordon Grubert]

Problematic Debian-Client (structurally identical to Suse-Client):
- Linux DEBIAN-CLIENT 2.6.15.1
- Yukon Gigabit Ethernet with default drivers (Debian Sarge AMD64)


Sarge don't have a kernel 2.6.15. But this is a known and unfixed bug in
Linux. The fix is sheduled for .18.

My fault. The used kernel was compiled by myself and the NIC driver
is the default one from the kernel sources of kernel.org.
But the performance problem occures in both cases: original
Debian kernel 2.6.8-11 and the used kernel 2.6.15.1.

Gordon


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

Re: CDBS and dh_install

[Andreas Metzler]

martin f krafft  debian.org> writes:
[...] 
> also sprach Andreas Metzler  downhill.at.eu.org>
[2006.06.09.1337 +0200]:
>> I am using
>> DEB_DH_INSTALL_SOURCEDIR = debian/tmp
>> for that purpose.
 
> This is old. Why not switch to debhelper compatibility level 5,
> which includes switching to a new format for *.install files?
[...]

For my own packages I usually do not use debhelper features unavailable in
stable as I like to be able to make backports easily.
cu andreas


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

Re: CDBS and dh_install

[Adeodato Simó]

* martin f krafft [Fri, 09 Jun 2006 15:19:03 +0200]:

> This is old. Why not switch to debhelper compatibility level 5,
> which includes switching to a new format for *.install files?

What new format?

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Listening to: Presuntos Implicados - Samurai


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

Re: severities of blocking bugs

[Thomas Bushnell BSG]

Ian Jackson <[EMAIL PROTECTED]> writes:

> Most maintainers are much more cooperative when you tag the bug as
> +patch and say something like:

How do you think I should have applied this advice in the case of bug
#360851?

> As opposed to writing to demand that the maintainer spend their free
> time to help you fix your problem !

How does adjusting the severity of a bug report amount to a demand
that the maintainer spend their free time to solve a problem?

Thomas


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

Re: CDBS and dh_install

[martin f krafft]

also sprach Andreas Metzler <[EMAIL PROTECTED]> [2006.06.09.1724 +0200]:
> For my own packages I usually do not use debhelper features
> unavailable in stable as I like to be able to make backports
> easily.

Then use compatibility level 4. Debhelper 5 *is* on backports.org
though.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"the perfect gun is an idealist without any ideal."
  -- mc 900 ft jesus


signature.asc
Description: Digital signature (GPG/PGP)

Re: CDBS and dh_install

[martin f krafft]

also sprach Adeodato Simó <[EMAIL PROTECTED]> [2006.06.09.1747 +0200]:
> > This is old. Why not switch to debhelper compatibility level 5,
> > which includes switching to a new format for *.install files?
> 
> What new format?

Sorry, there's no old and new. There's one and two column, the first
of which needs --sourcedir. They are both equally acceptable.

Cheers,

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
quantum mechanics: the dreams stuff is made of.


signature.asc
Description: Digital signature (GPG/PGP)

Re: severities of blocking bugs

[Stephen Gran]

This one time, at band camp, Thomas Bushnell BSG said:
> Ian Jackson <[EMAIL PROTECTED]> writes:
> 
> > Most maintainers are much more cooperative when you tag the bug as
> > +patch and say something like:
> 
> How do you think I should have applied this advice in the case of bug
> #360851?

In the same way Martin and others handled 357057?  That's because
he wanted a compiler version transition, and he worked hard for it,
finding out all the problems and filing bugs with patches.  Does this
help answer your question?

> > As opposed to writing to demand that the maintainer spend their free
> > time to help you fix your problem !
> 
> How does adjusting the severity of a bug report amount to a demand
> that the maintainer spend their free time to solve a problem?

When you make a wishlist bug RC, you are by definition forcing someone
else to spend time on it, either to fix it or play BTS ping pong with
you, since their package doesn't need to be kept out of the next stable
release over a wishlist bug.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: severities of blocking bugs

[Thomas Bushnell BSG]

Stephen Gran <[EMAIL PROTECTED]> writes:

> This one time, at band camp, Thomas Bushnell BSG said:
>> Ian Jackson <[EMAIL PROTECTED]> writes:
>> 
>> > Most maintainers are much more cooperative when you tag the bug as
>> > +patch and say something like:
>> 
>> How do you think I should have applied this advice in the case of bug
>> #360851?
>
> In the same way Martin and others handled 357057?  That's because
> he wanted a compiler version transition, and he worked hard for it,
> finding out all the problems and filing bugs with patches.  Does this
> help answer your question?

No, because when I asked for the status of the work, I received *NOT A
SINGLE REPLY FROM THE MAINTAINER*.  How on earth am I supposed to help
with the transition, when a simple question "what's the state of the
transition?" is *ENTIRELY IGNORED*?

Moreover, I wasn't even asking for the work to be stepped up or
anything else.  All I wanted was *SOME* idea of the plan.  Even the
statement, "We have no plan unfortunately" would have been helpful
(and then I could say "What can I do to help out?").

> When you make a wishlist bug RC, you are by definition forcing someone
> else to spend time on it, either to fix it or play BTS ping pong with
> you, since their package doesn't need to be kept out of the next stable
> release over a wishlist bug.

The maintainer agrees that it's an important bug, not a wishlist bug.
So let's not pretend that it's wishlist; it's not.

In fact, fixing this bug has already been said by the release team is
a release goal for etch.  So, at least in that sense, it *is* release
critical.

Nor did I play ping pong; when the severity was set back to important
(not wishlist), my reaction was to ask debian-devel.  And while Steve
and Manoj gave helpful replies that understood the particular case and
the general principles--replies which will help me to do my work more
efficiently and helpfully in the future--Ian and you have given
useless replies, that show no awareness of the particular case or the
general principles.

Indeed, both you and Ian seem to be operating from the standpoint that
bug reports are "demands" and imply some kind of malfeasance on the
part of a maintainer.  It is this approach which is harmful to Debian.

Thomas


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

Re: GBit performance problem with nfs client

[Florian Weimer]

* Bastian Blank:

> On Thu, Jun 08, 2006 at 12:53:48PM +0200, Gordon Grubert wrote:
>> Problematic Debian-Client (structurally identical to Suse-Client):
>> - Linux DEBIAN-CLIENT 2.6.15.1
>> - Yukon Gigabit Ethernet with default drivers (Debian Sarge AMD64)
>
> Sarge don't have a kernel 2.6.15. But this is a known and unfixed bug in
> Linux. The fix is sheduled for .18.

Are you sure?  I thought that as well, but that fix is only supposed
to help write performance.  (AFAICT, Gordon benchmarked read
performance.)


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

Re: CDBS and dh_install

[Christoph Berg]

Re: martin f krafft 2006-06-09 <[EMAIL PROTECTED]>
> also sprach Jean Parpaillon <[EMAIL PROTECTED]> [2006.06.09.1118 +0200]:
> > I want to migrate my package (wormux) to CDBS.
> 
> Why?

I was just about to ask the same. Which packaging scheme do you use
now?

> This is my opinion and others will disagree:
> Please don't. CDBS is a major pain to use for those who didn't
> (co-)author it. It's just too much about obfuscation.

This is also my impression. CDBS might be nice to automate the task
"make a .deb out of this Gnome source", but imho it completely fails
when you want to deviate from the "standard" in any way.

CDBS hides what it's going on while building the package. It is very
hard to see what it does, and if you are a newcomer, it is next to
impossible to actually learn anything from using it. (And the syntax
is very ugly.)

Sorry for the rant, please read this as a "kids, please don't try this
at home" message. I've seen way too many requests on -mentors or
#-mentors where people tried to use CDBS and failed just because it is
evil black magic. (In one case a guy even said something like "I have
bug foo in my package, I've even tried to repackage it using CDBS but
it didn't help" - madness lies along this path.)

Again, I'm fine if you use CDBS for your package, but please never
recommend it to any new maintainer.

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


signature.asc
Description: Digital signature

Re: CDBS and dh_install

[Adeodato Simó]

* Christoph Berg [Fri, 09 Jun 2006 19:30:27 +0200]:

> Again, I'm fine if you use CDBS for your package, but please never
> recommend it to any new maintainer.

Full ack, seconded.

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
   Listening to: Alejandro Sanz - Que no te daría yo


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

Re: CDBS and dh_install

[Manoj Srivastava]

On 9 Jun 2006, Christoph Berg said:

> Re: martin f krafft 2006-06-09
> <[EMAIL PROTECTED]>
>> also sprach Jean Parpaillon <[EMAIL PROTECTED]> [2006.06.09.1118
>> +0200]:
>>> I want to migrate my package (wormux) to CDBS.
>>
>> Why?
>
> I was just about to ask the same. Which packaging scheme do you use
> now?
>
>> This is my opinion and others will disagree:
>> Please don't. CDBS is a major pain to use for those who didn't
>> (co-)author it. It's just too much about obfuscation.
>
> This is also my impression. CDBS might be nice to automate the task
> "make a .deb out of this Gnome source", but imho it completely fails
> when you want to deviate from the "standard" in any way.

I am surprised to hear you say so, since CDBS is one of the
 most configurable build systems out there. You can add commands to
 any phase of the build, by just adding targets/dependencies/variables. 

Off hand, I would say that the cdbs approach is as flexible as
 any one might find.

> CDBS hides what it's going on while building the package. It is very 
> hard to see what it does, and if you are a newcomer, it is next to
> impossible to actually learn anything from using it. (And the syntax
> is very ugly.)

Very subjective. I mean, heavens, cdbs is just a make file,
 and we all have some need to know how make works, as opposed to
 learning python/Perl/ruby or whatever other languages a helper
 package may be written in.


I haven't really found the CDBS makefiles very hard to follow,
 but that again is subjective.

> Sorry for the rant, please read this as a "kids, please don't try
> this at home" message. I've seen way too many requests on -mentors
> or -mentors where people tried to use CDBS and failed just because
> it is evil black magic. (In one case a guy even said something like
> "I have bug foo in my package, I've even tried to repackage it using
> CDBS but it didn't help" - madness lies along this path.)

I have expressed similar reservations about helper packages in
 general (including debhelper).

> Again, I'm fine if you use CDBS for your package, but please never
> recommend it to any new maintainer.

Why would this not apply to any other helper packages as well?

manoj
-- 
"Infidels in all ages have battled for the rights of man, and have at
all times been the fearless advocates of liberty and justice."--
Robert Green Ingersoll
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Summary of Debconf i18n/l10n activities

[Denis Barbier]

On Fri, Jun 09, 2006 at 08:18:31AM +0200, Christian Perrier wrote:
> raw answers...
> 
> > Who does decide which files are being imported?
> 
> I would say the team who administers the server (what we defined as
> "Administrators" in the infrastructure targets). This is of course
> coordinated with the upstream itself, to determine what notification
> method they prefer.

I am still puzzled.  Imagine for instance that French translators of
OpenOffice are willing to use this infrastructure, whereas Dutch
are not interested.  Will this situation be allowed?

> An alternative method could be an "opt-in" system where upstreams are
> doing a volunteer action to "register" their project (here we come
> with ideas similar to the TP)

This is not enough.  For instance Debian maintainers may ask for debconf
translations (or manpages that they have written), but do not want to
include upstream PO files.

> > How are translations pushed upstream?
> 
> Here comes the needed modularity of the system.
> 
> We will probably need to design several modules to push translation to
> upstream maintainers (as you already explained in one of your mails,
> "upstream" can be a Debian maintainer when it comes at Debian packages
> related translations):
> 
> -direct commit to upstream RCS (so various plugins for various RCS)
> -sending bug reports to upstream BTS (so various plugins for various
>  BTS systems)
> -e-mail (similar to the TP)
> -others?
> 
> The push module will of course need to be able to send the
> translations in whatever format is needed by upstream (PO, XLIFF,
> Mozilla stuff, whatever...)

I do not understand how Debian developers will communicate with the
infrastructure.  Could we pick a random package and define the
different processes?

Denis


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

Re: CDBS and dh_install

[Daniel Jacobowitz]

On Fri, Jun 09, 2006 at 02:02:48PM -0500, Manoj Srivastava wrote:
> I am surprised to hear you say so, since CDBS is one of the
>  most configurable build systems out there. You can add commands to
>  any phase of the build, by just adding targets/dependencies/variables. 

If you can figure out where they go.  The last time I had to adjust my
(CDBS-using) build process I wasted an hour grepping around in
/usr/share/cdbs.

I think what CDBS could really use would be an improved manual.  The
examples don't cover a lot of things you can do with it.

-- 
Daniel Jacobowitz
CodeSourcery


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

Re: Summary of Debconf i18n/l10n activities

[Christian Perrier]

> I am still puzzled.  Imagine for instance that French translators of
> OpenOffice are willing to use this infrastructure, whereas Dutch
> are not interested.  Will this situation be allowed?

Well, it is quite likely to happen, yes, so my first reaction is to
say that, yes, the system should allow it.

So, to amend what I first answered, the choice of using the
infrastructure will actually be a combination of the wishes by the
upstream and, optionnally, the wishes of the teams (though some
upstream may want to enforce using the systemfor instance, for
most Debian translations, we will probably make it non optional for
teams to work with the Debian i18n infrastructure (bazaars are OK, but
some cathedral parts in them allow them to still stand up after a
couple of time).

> > An alternative method could be an "opt-in" system where upstreams are
> > doing a volunteer action to "register" their project (here we come
> > with ideas similar to the TP)
> 
> This is not enough.  For instance Debian maintainers may ask for debconf
> translations (or manpages that they have written), but do not want to
> include upstream PO files.


Yay, sure, my definition was a little bit a shortcut. Of course, when
a given package/software has several trnslatable areas, the system
should offer a method to register only some of them.

> > The push module will of course need to be able to send the
> > translations in whatever format is needed by upstream (PO, XLIFF,
> > Mozilla stuff, whatever...)
> 
> I do not understand how Debian developers will communicate with the
> infrastructure.  Could we pick a random package and define the
> different processes?


Yep. Could be a good idea.




signature.asc
Description: Digital signature

Re: CDBS and dh_install

[Steve Langasek]

On Fri, Jun 09, 2006 at 02:02:48PM -0500, Manoj Srivastava wrote:

> >> This is my opinion and others will disagree:
> >> Please don't. CDBS is a major pain to use for those who didn't
> >> (co-)author it. It's just too much about obfuscation.

> > This is also my impression. CDBS might be nice to automate the task
> > "make a .deb out of this Gnome source", but imho it completely fails
> > when you want to deviate from the "standard" in any way.

> I am surprised to hear you say so, since CDBS is one of the
>  most configurable build systems out there. You can add commands to
>  any phase of the build, by just adding targets/dependencies/variables. 

> Off hand, I would say that the cdbs approach is as flexible as
>  any one might find.

Flexible, yes.  Accessible?

> > CDBS hides what it's going on while building the package. It is very 
> > hard to see what it does, and if you are a newcomer, it is next to
> > impossible to actually learn anything from using it. (And the syntax
> > is very ugly.)

> Very subjective. I mean, heavens, cdbs is just a make file,
>  and we all have some need to know how make works, as opposed to
>  learning python/Perl/ruby or whatever other languages a helper
>  package may be written in.

> I haven't really found the CDBS makefiles very hard to follow,
>  but that again is subjective.

Let's compare debhelper to cdbs.

When using debhelper, you (typically) have a single debian/rules makefile
which lists out all the commands that are invoked for building your package;
each of those commands primarily uses the contents of other files in debian/
as input.  If you have questions about what any one of those lines does,
there is a manpage that you can refer to.  Thus, a debhelper-based
debian/rules is composed of discrete units, each of which can be understood
separately through the *documentation*, and the maintainer held to account
if the behavior doesn't match the documentation, without any requirement
that the user understand the implementation language of perl.

In contrast, almost all of cdbs is stashed away in /usr/share/cdbs/; almost
none of what it does is inspectible by looking at the debian/rules and using
those lines as hooks into the documentation.  There is
/usr/share/doc/cdbs/cdbs-doc.html, which documents many of the common
variables one may wish to use, but there is no concise description of what
the cdbs rules *themselves* do.  It's nice to know that you can supplement
the standard rules with additional double-colon rules, but you're basically
expected to trust that the default rules Do The Right Thing -- if you find
that a cdbs rule does the wrong thing, your only recourses are to either try
to fix up the output after the fact (assuming the Wrong Thing isn't a fatal
failure), or to not include that problematic cdbs class and reimplement the
rules by hand.  Oh, and to top it off, almost all cdbs packages include
/usr/share/cdbs/1/rules/debhelper.mk anyway, so they're still *using*
debhelper behind the scenes. :)  Just not in a form that leaves the package
maintainer any control over the process beyond that granted them by the
cdbs maintainers...

And btw, last I looked at the cdbs makefiles, they were among the most
arcane uses of make syntax that I'd ever seen.  Arguing that cdbs is good
because make is a least common denominator language in Debian is like
arguing that we should do GRs in iambic pentameter because English is the
lingua franca. :)

> > Again, I'm fine if you use CDBS for your package, but please never
> > recommend it to any new maintainer.

> Why would this not apply to any other helper packages as well?

Is it no longer a requirement of NM that applicants demonstrate themselves
capable of putting together a source package without the use of rules
helpers?

There are also pretty significant differences in the design goals of
debhelper and cdbs, differences which I believe have a major impact on the
ability of maintainers to understand their own packages and on the
respective helper-induced build failure rates of the two.  I think these are
very pertinent reasons not to recommend cdbs to novice maintainers.

-- 
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: CDBS and dh_install

[martin f krafft]

also sprach Steve Langasek <[EMAIL PROTECTED]> [2006.06.10.0010 +0200]:
> Let's compare debhelper to cdbs.

... this makes me think:

  cdbs is top-down because it defines the package build as much as
  possible in line with how the cdbs developers think it should be
  done. It expects the developer to tweak the countless,
  undocumented parameters until it's right.

  debhelper is bottom-up because it gives you small tools that each
  do their own thing. You then get to put them together to
  accomplish what you want to accomplish.

Those who know me also know that I am a big fan of anything
bottom(s)-up.

And guess which approach is more reminiscent of the Unix philosophy?

> Is it no longer a requirement of NM that applicants demonstrate
> themselves capable of putting together a source package without
> the use of rules helpers?

was it ever?

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"in the country of the blind,
 the one-eyed man is not king.
 he is taken to be a hallucinating lunatic."
 -marshall mcluhan


signature.asc
Description: Digital signature (GPG/PGP)

Re: CDBS and dh_install

[Russ Allbery]

Steve Langasek <[EMAIL PROTECTED]> writes:

> Is it no longer a requirement of NM that applicants demonstrate
> themselves capable of putting together a source package without the use
> of rules helpers?

Well, I've never actually done this, and I got through NM.  (I've always
used debhelper, although I've sponsored and/or comaintained packages using
CDBS before and have poked a little at yada.)  I'm certain that I *could*
do this if I wanted to, as it's all fairly clearly documented, but I've
never gone through the exercise.

I agree with all the complaints Steve has, but the one that bugs me the
most is the lack of documentation.  If something goes wrong with CDBS,
there really doesn't seem to be a recourse other than figuring out what's
going on by reading the source.  We had a problem with Shishi with
dependencies not showing up in the dependency list of the built packages
that was worked around by reordering the packages in debian/control, and I
never could figure out just what was going on from the CDBS makefiles.  (I
believe this bug has subsequently been fixed.)

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Bug#372530: ITP: libhighline-ruby -- High-level interactive IO Ruby library

[Esteban Manchado Velázquez]

Package: wnpp
Severity: wishlist
Owner: "Esteban Manchado Velázquez" <[EMAIL PROTECTED]>

* Package name: libhighline-ruby
  Version : 1.2.0
  Upstream Author : James Edward Gray II <[EMAIL PROTECTED]>
* URL : http://highline.rubyforge.org/
* License : Ruby's and GPL
  Programming Lang: Ruby
  Description : High-level interactive IO Ruby library

High-level IO library that provides validation, type conversion, and more for
command-line interfaces. HighLine also includes a complete menu system that
can crank out anything from simple list selection to complete shells with just
minutes of work.

-- 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.16-2-686
Locale: [EMAIL PROTECTED], LC_CTYPE=ISO_8859_1 (charmap=ISO-8859-15) (ignored: 
LC_ALL set to [EMAIL PROTECTED])

Re: CDBS and dh_install

[Eduard Bloch]

#include 
* Manoj Srivastava [Fri, Jun 09 2006, 02:02:48PM]:
> On 9 Jun 2006, Christoph Berg said:

> > This is also my impression. CDBS might be nice to automate the task
> > "make a .deb out of this Gnome source", but imho it completely fails
> > when you want to deviate from the "standard" in any way.
> 
> I am surprised to hear you say so, since CDBS is one of the
>  most configurable build systems out there. You can add commands to
>  any phase of the build, by just adding targets/dependencies/variables. 

Oh, really? The last time I tried to add a custom command to the install
rule (well, >> 1 year ago) it was a real PITA. Docs have not told me how
it works, docs have not told me in an understandable language how to add
extensions, and after trying to find a proper way to insert a command by
myself, I gave up and threw it away.

So I have to agree with Martin here.

> > CDBS hides what it's going on while building the package. It is very 
> > hard to see what it does, and if you are a newcomer, it is next to
> > impossible to actually learn anything from using it. (And the syntax
> > is very ugly.)
> 
> Very subjective. I mean, heavens, cdbs is just a make file,
>  and we all have some need to know how make works, as opposed to
>  learning python/Perl/ruby or whatever other languages a helper
>  package may be written in.

Choice of language is not an excuse. You can write a lot of ugly things
with Makefiles.

> > Again, I'm fine if you use CDBS for your package, but please never
> > recommend it to any new maintainer.
> 
> Why would this not apply to any other helper packages as well?

Because there is documentation telling what is going behind the scenes?
Like understandable manpages for every debhelper command.

Eduard.


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

Re: severities of blocking bugs

[Steve Langasek]

On Fri, Jun 09, 2006 at 09:41:34AM -0700, Thomas Bushnell BSG wrote:
> > When you make a wishlist bug RC, you are by definition forcing someone
> > else to spend time on it, either to fix it or play BTS ping pong with
> > you, since their package doesn't need to be kept out of the next stable
> > release over a wishlist bug.

> The maintainer agrees that it's an important bug, not a wishlist bug.
> So let's not pretend that it's wishlist; it's not.

> In fact, fixing this bug has already been said by the release team is
> a release goal for etch.  So, at least in that sense, it *is* release
> critical.

No, release-critical bugs are, by definition, those that we will not
release etch without resolving.  Release goals are things that the
release team believes *should* be resolved for etch, to the point of
encouraging a relaxed NMU policy for packages related to these goals,
but they are not automatically bugs that would be allowed to delay the
release or result in a package's removal from the release.  Sorry if the
previous mail on this point was unclear.

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


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

Re: CDBS and dh_install

[Christian Perrier]

> There are also pretty significant differences in the design goals of
> debhelper and cdbs, differences which I believe have a major impact on the
> ability of maintainers to understand their own packages and on the
> respective helper-induced build failure rates of the two.  I think these are
> very pertinent reasons not to recommend cdbs to novice maintainers.


I tend to agree.

I think it's important for new maintainers to understand how their
packages are built. For this, the very classical approach of
debian/rules with debhelper commands is a good compromise between
readability and accessibility.

On the other hand, the constant changes and new neat features
introduced in Debian (new debhelper commands, new ways to handle
stuff, etc) is a big challenge for maintainers to cope with (in short,
I bet that mostly noone except the debhelper maintainer is really
aware of all debhelper nice features).

Using cdbs is indeed a very convenient way to be sure that packages
use a kind of common build method, which allows major build design
changes without big communication to developers. Of course, this
assumes that cdbs is kept up-to-date with recent evolutions of the
Debian packages build process and new neat features in debhelper.

I actually use cdbs for several of my packages, the most important
being shadow (others are font packages which are usually very
simple). In that specific case, I find it particularly convenient
because it allows the debian/rules to only list actions that are very
specific (actually, things that are done "by hand" for various
reasons, good or bad).

The funny goal of having one-liner debian/rules files, with cdbs, is
indeed a very good way to track down all hacks, dirty or not, we are
currently using in debian/rules fileswhich is, for the long term,
a good improvement.

But, be safe, Steve, I won't push for cdbs in samba (even though,
ahem, it's debian/rules file has room for improvement probably)..



signature.asc
Description: Digital signature

Re: CDBS and dh_install

[Christian Perrier]

>   cdbs is top-down because it defines the package build as much as
>   possible in line with how the cdbs developers think it should be
>   done. It expects the developer to tweak the countless,
>   undocumented parameters until it's right.
> 
>   debhelper is bottom-up because it gives you small tools that each
>   do their own thing. You then get to put them together to
>   accomplish what you want to accomplish.


Yeah. Interesting analogy.

So, actually, we have tools for both ways of thinking. Which is Good,
isn't it? After all, Unix is also the philosophy of achieving the
goals you have with the tools you find appropriate with regards of
your way to think

But I suspect that implicitely telling Manoj that he thinks top-down
because he actually likes cdbs will get you into trouble,
dude. Top-down is not exactly a very liberal attitude (reference to a
thread in debconf-discuss for those not aware).(just small pun
intended)





signature.asc
Description: Digital signature

Re: CDBS and dh_install

[Christian Perrier]

Quoting Russ Allbery ([EMAIL PROTECTED]):
> Steve Langasek <[EMAIL PROTECTED]> writes:
> 
> > Is it no longer a requirement of NM that applicants demonstrate
> > themselves capable of putting together a source package without the use
> > of rules helpers?
> 
> Well, I've never actually done this, and I got through NM.  (I've always
> used debhelper, although I've sponsored and/or comaintained packages using
> CDBS before and have poked a little at yada.)  I'm certain that I *could*
> do this if I wanted to, as it's all fairly clearly documented, but I've
> never gone through the exercise.


I'm certain that I *couldn't* do this and I also went through NM
(actually I really wonder whether I could go through NM *now* indeed).




signature.asc
Description: Digital signature

Re: CDBS and dh_install

[Christian Perrier]

> Because there is documentation telling what is going behind the scenes?
> Like understandable manpages for every debhelper command.


Sure. I think that we basically here all agree that, whether we
actually like cdbs or not, its documentation has a lot of room for
improvement...




signature.asc
Description: Digital signature