Work-needing packages report for Jul 15, 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: 215 (new: 2)
Total number of packages offered up for adoption: 112 (new: 11)
Total number of packages requested help for: 13 (new: 0)

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



The following packages have been orphaned:

   diablo (#318303), orphaned today (non-free)
 Description: News transport system without reader support.
 Reverse Depends: diablo diablo-readerd ninpaths diablo-common

   ibwebadmin (#318201), orphaned yesterday
 Description: Web-based administration for the Firebird and Interbase
 database

213 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:

   dmalloc (#317427), offered 6 days ago
 Description: debug memory allocation library
 Reverse Depends: dmalloc libdmalloc4-dev

   etask-el (#317808), offered 3 days ago
 Description: Define and manage projects within Emacs with Gantt

   f-prot-installer (#318002), offered 2 days ago
 Description: F-Prot(tm) Antivirus installer package

   libanydata-perl (#317403), offered 6 days ago
 Description: simple tied hash interface for files and data
 structures
 Reverse Depends: libdbd-anydata-perl

   libcgi-xml-perl (#317406), offered 6 days ago
 Description: perl module for converting CGI variables from/to XML

   libcgi-xmlapplication-perl (#317405), offered 6 days ago
 Description: perl module for creating XML-DOM and OO based CGI
 scripts

   libcgi-xmlform-perl (#317407), offered 6 days ago
 Description: perl module for reading/generating formatted XML

   libdbd-anydata-perl (#317408), offered 6 days ago
 Description: perl DBI driver for files and data structures
 Reverse Depends: libdbd-ram-perl

   libdbix-xml-rdb-perl (#317412), offered 6 days ago
 Description: perl module for creating XML from a DBI datasource

   libdbix-xmlmessage-perl (#317413), offered 6 days ago
 Description: perl module for exchanging XML messages between DBI
 data sources

   libextutils-f77-perl (#317400), offered 6 days ago
 Description: Simple interface to F77 libs

101 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 21 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot-cross dfsbuild aboot

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

   debtags (#262927), requested 346 days ago
 Description: Evolution of package metadata
 Reverse Depends: debtags-edit

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

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

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

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

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

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

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

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

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

   stlport4.6 (#263052), requested 346 days ago
 Description: STLport C++ class library
 Reverse Depends: libstlport4.6-dev openoffice.org-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 [EMAI

Re: shared library -dev package naming proposal

[martin f krafft]

also sprach Junichi Uekawa <[EMAIL PROTECTED]> [2005.07.14.1416 +0300]:
> libfoobar-2.1-0 will have 
> libfoobar-2.1-0-dev.

Please distinguish between API and ABI!

-- 
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
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
 
"the liar at any rate recognises that recreation, not instruction, is
 the aim of conversation, and is a far more civilised being than the
 blockhead who loudly expresses his disbelief in a story which is told
 simply for the amusement of the company."
-- oscar wilde


signature.asc
Description: Digital signature

Re: pbuilder status update

[Henning Glawe]

On Fri, Jul 15, 2005 at 11:54:15AM +1000, Brian May wrote:
> Ideally there needs to be either
> 
> * a login environment where changes are saved AND/OR

there is one: use
pbuilder login --save-after-login

(have been confronted with the same problem yesterday...)


-- 
c u
henning


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

aspell dictionary packages fail to build

[Matt Kraai]

Howdy,

The aspell dictionary packages build-depend on aspell-bin (>> 0.60).
aspell-bin is now a virtual package provided by aspell, but virtual
packages cannot be versioned, so these build-dependency cannot be
satisfied.

There are fifteen such packages:

 aspell-br
 aspell-cy
 aspell-de
 aspell-de-alt
 aspell-el
 aspell-es
 aspell-fr
 aspell-ga
 aspell-is
 aspell-it
 aspell-pt
 aspell-sk
 aspell-sl
 aspell-sv
 aspell-ukr

Should I file bugs against each of these packages?  Should I contact
the maintainers directly via email?  Should I email d-d-a?

-- 
Matt


signature.asc
Description: Digital signature

Re: no time for all debian tasks was: interacting with the press

[Brian May]

> "Greg" == Greg Folkert <[EMAIL PROTECTED]> writes:

Greg> Common Courtesy states that one should also mention personal
Greg> communications, even if completely ignored by the person(s)
Greg> in question.

Doesn't this also run the risk of making the person look bad?

I guess it depends on how you say it.

"I tried but was unable to resolve this issue via private email."

might be better then:

"I tried contacting XYZ in private but he failed to {respond to my
emails,acknowledge the problem,worship me as his god[1], etc}"

...as the first version doesn't blame XYZ in anyway.

Surely you don't need to provide details what happened?

(note: none of this is specific to anybody mentioned in this thread)

Notes:
[1] Who me? Watch to much Stargate? Never!
-- 
Brian May <[EMAIL PROTECTED]>


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

Re: pbuilder status update

[Brian May]

> "Junichi" == Junichi Uekawa <[EMAIL PROTECTED]> writes:

Junichi> Hi, I'll just write a mail here to notify people using
Junichi> pbuilder, that sid is a wild place.

I recently had major dramas trying to create a sid chroot from a sarge
system. So perhaps these issues have been fixed for sid users already,
but no doubt they will be a problem for sarge users.

I encountered two issues:

1. gcc-4.0 being the default.

2. gpg signature verification failed to work because gnupg was not
   installed. This meant the update operation failed as well as
   downloading dependencies.

I tried going from etch to sarge, because at the changes had not moved
across to etch yet. I could get etch OK, but I encountered the same
problems (IIRC) after upgrading to sarge.

This made me realize that the current set of hooks in pbuilder is
insufficient to fix the problem, at least by my understanding, in
sarge.

There is:

A* - build: happens too late, apt-get has already aborted with an
 error that the packages cannot be verified.

B* - build: same as above.
C* - build: same as above.

D* - build: this is good for the build operation but isn't called for
 update.

E* - update: called too late.

F* - login: not relevant.

Ideally there needs to be either

* a login environment where changes are saved AND/OR

* a hook that gets executed for an update operation, *before* apt-get
  is called.

Even this issue is solved, the extra hook could also be useful for
adding extra keys to validate against. This might be important if you
want to download packages from a local archive.

My work around was to hack the values of "required" and "base" in
debootstrap script /usr/lib/debootstrap/scripts/sid.buildd:

required="base-files base-passwd bash bsdutils coreutils debianutils diff 
dpkg dselect e2fslibs e2fsprogs findutils gcc-4.0-base grep gzip hostname 
initscripts libacl1 libattr1 libblkid1 libc6 libcap1 libcomerr2 libdb1-compat 
libdb3 libgcc1 libncurses5 libpam-modules libpam-runtime libpam0g libss2 
libstdc++6 libuuid1 login mawk mount ncurses-base ncurses-bin passwd perl-base 
sed slang1a-utf8 sysv-rc sysvinit tar util-linux zlib1g"

base="libstdc++5 gcc-3.3-base apt binutils cpio cpp cpp-4.0 dpkg-dev g++ 
g++-4.0 gcc gcc-4.0 libc6-dev libdb4.2 libgdbm3 libstdc++6-4.0-dev 
linux-kernel-headers make patch perl perl-modules gnupg libbz2-1.0 libldap2 
libreadline5 libusb-0.1-4 makedev libgnutls11 libsasl2 debconf libtasn1-2 
libopencdk8 liblzo1 libgpg-error0 libgcrypt11 debconf-english $additional"

At the time aptitude wasn't recompiled, so no doubt this will need
changing again.
-- 
Brian May <[EMAIL PROTECTED]>


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

Re: congratulations to the X team!!

[Miles Bader]

FWIW, I previously had xorg from Ubuntu installed, and upgrading from
that to Debian's xorg _didn't_ go smoothly:  the file "/etc/X11/Xsession"
was created by two packages, x11-common [debian], and xorg-common
[ubuntu], and in upgrading tried to install x11-common before removing
xorg-common.

I ended up downgrading to xfree86 from testing, and then upgraded back up
to xorg from unstable (and all that went smoothly).

[I know none of that is supported, but just FYI... :-]

-Miles
-- 
((lambda (x) (list x x)) (lambda (x) (list x x)))


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

Re: skills of developers

[Laszlo Boszormenyi]

Hi Bartosz,

On Fri, 2005-07-15 at 01:52 +0200, Bartosz Fenski aka fEnIo wrote:
> What are the required skills of the
> developers/developers-to-be?
 Skip, as we both passed the NM process.

> should everyone be able to maintain every package on the world?
 No, packaging is not just put the right files to the correct place
thing. You/we often should make changes to the source to make it
compile, further develop upstream (like the kernel-source or what
Siggy and a bit me was doing with MailMan, etc). Changes sometimes
also required to make the depends optional and/or chooseable.
(Bug-)Reporters may submit patches, that you should read and approve
or reject, etc. Last but not least you should know how to configure
a package, how to make transitions from one version to an other if
it needs configuration/data upgrade.
Packaging is not just packaging, see that some packages have a team
to do it right, because one person just can't do it.

> To be honest I intended to join Debian project mainly to work on
> documentation/translation efforts.
 Yes, I have asked you back then that you are going to be a Debian
_Developer_ when the only thing you want to do is documentation and
translation.

>  I was HIGHLY SURPRISED that my
> application manager (greetings to him) asked me how to create Debian
> package. For Christ's sake who the f*** I am to know about it if I'm going
> only to translate some stupid documents huh?
 Debian _Developer_. You can translate documents, submit then against
the package as patch for example. You can even join to the translation
teams.
Have you seen http://www.debian.org/intl/l10n/ for example? I think
yes, as you are involved according to
http://www.debian.org/intl/l10n/po-debconf/pl
There are mailing lists even:
http://lists.debian.org/i18n.html
Also, general documentation needs translators as well:
http://www.debian.org/doc/user-manuals
There are some Polish done, but others may accept help as well.

> I'll be never good programmer and I'm aware of it. Knowing C and knowing
> C can be two different things.
 Yup, and knowing C and Ada can be an other kind of different things.

> In sum. Maybe it's time to create additional positions in Debian project?
 There are already differences, maybe not like you 'proposed', but for
example _no-one_ should be a DD to make translations. So I think the
very first thing a translator should do is to join his/her tranlation
team and/or maillist and offer help. DD as the name suggests is a
'Developer'.

> I suppose we're going to have flamewar here as usual, so please... oh
> nevermind :P
 It was my first and only shot. I do not know how I got your mail even,
as I am not on debian-devel@ anymore. Thus I don't think I will get
the replies even, will read archives.

Regards,
Laszlo/GCS


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

Re: skills of developers

[Michael K. Edwards]

On 7/14/05, Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> wrote:
> In sum. Maybe it's time to create additional positions in Debian project?
> Maybe something like Packager (with knowledge about Bash and Debian
> Policy), Translator (with knowledge about some particular language and
> English), Helper (with knowledge about Debian in general), and finally
> DEVELOPER which develops software and is able to fix it if it's broken.
> Developers could be splitted to Python/Perl/C/C++/Java/Mono/and so on...

AIUI, DD-hood principally conveys voting rights, upload and login
privileges to certain machines, and r/w access to debian-private and w
access to d-d-a.  None of this has much to do with real-world
"software developer" competence and it would be rather odd to try to
retrofit such an expectation onto the "Developer" status at this
point.  It's not as if bogus position titles weren't ubiquitous in the
software industry anyway -- I have knuckled under to accepting titles
like "Staff Engineer" despite the fact that I am no engineer and do
not pretend to be even in job interviews, let alone any other setting.

But FWIW I would be disinclined to see Developer status split along
programming language lines in any way that isn't purely advisory.  In
a crisis I'd rather have a wizard developer who has never seen Python
(Scheme, OCaml, whatever) before step in, figure out an RC bug, and
deal with it without having to jump some stupid "hello world" hoops
first.  After you've worked in a dozen disparate languages, the
thirteenth is just more grist for the mill.  And for that matter, with
a little help from Google, fixing a screwed-up translation file in
some human language you don't know isn't all that hard either.  It
won't be idiomatic, but they'll get the idea.

Cheers,
- Michael

skills of developers

[Bartosz Fenski aka fEnIo]

Hello.

I would like to move one subject. What are the required skills of the
developers/developers-to-be?

Debian Policy, Developers' Reference, New Maintainers' Guide and most 
documentation describe only _how to make a good package_. 

Good package in that case means it will comply with Debian Policy.
That's great, but that doesn't ensure us that maintainer know anything
besides mentioned documents. That's not big deal to create Debian package.

That's example:
http://lists.debian.org/debian-mentors/2005/07/msg00254.html
Nothing against poster of this document... that's only example which is the
most up-to-date one.

Please read whole thread to get know about rationale.

Don't lie ourselves. Everyone who know where to put binary and architecture
independent data and  a little of bashism can became Debian developer.
In general there's nothing wrong with that, but... yes there's BIG BUT here, 
should everyone be able to maintain every package on the world?

Or should we split duties and call persons repectively to their knowlegde?

To be honest I intended to join Debian project mainly to work on
documentation/translation efforts. I was HIGHLY SURPRISED that my
application manager (greetings to him) asked me how to create Debian
package. For Christ's sake who the f*** I am to know about it if I'm going
only to translate some stupid documents huh?

Yep, I learned that and I passed "the exam". Sure I know
C/Python/Perl/ but I hate that. Yes not everone in the Unix/Linux 
world loves to hack.

I'll be never good programmer and I'm aware of it. Knowing C and knowing
C can be two different things. 

In sum. Maybe it's time to create additional positions in Debian project?
Maybe something like Packager (with knowledge about Bash and Debian
Policy), Translator (with knowledge about some particular language and
English), Helper (with knowledge about Debian in general), and finally
DEVELOPER which develops software and is able to fix it if it's broken.
Developers could be splitted to Python/Perl/C/C++/Java/Mono/and so on...

I suppose we're going to have flamewar here as usual, so please... oh
nevermind :P

regards
fEnIo

-- 
  ,''`.  Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo
 : :' :   32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland
 `. `'   phone:+48602383548 | proud Debian maintainer and user
   `-  http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001


signature.asc
Description: Digital signature

Re: congratulations to the X team!!

[Daniel Stone]

On Thu, Jul 14, 2005 at 11:43:50AM -0300, Gustavo Franco wrote:
> On 7/14/05, Daniel Stone <[EMAIL PROTECTED]> wrote:
> > The server hasn't been modularised yet, it's just that I split up all
> > the packaging.  I've been working closely with Josh Triplett on the
> > libraries, and keeping David fully in the loop with everything I'm doing
> > in Breezy, and I'm pretty sure that we're going to arrive at a common
> > base for packaging when Debian gets over to the modular tree.
> 
> Hi Daniel,
> 
> Thank you for clarifying the topic. 

No worries.

> About the split up, is there a consensus in what to install exactly ? See, 
> the user will install all the packages related to video drivers and dexconf 
> will do its job and it's up to the user remove what is not needed ? I'm asking
> about Debian, because i guess that in Ubuntu you'll autodetect as much as
> possible in the install and just keep there what's necessary maybe using a
> different approach if the user change his video card, plug a new input device
> or whatever.
> 
> Closing, what are the side effects (if any) that this split up and
> modularization will
> put on the loop for stuff like lessdisks and ltsp ?

For the time being -- both in Debian and in Ubuntu -- everything will
continue to be installed.  It's more about not having to update
everything at the same time, really.


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

Bug#318336: ITP: asterisk-sounds-moh -- Asterisk PBX Music On Hold (MOH)

[Mark Purcell]

Package: wnpp
Severity: wishlist
Owner: Mark Purcell <[EMAIL PROTECTED]>

* Package name: asterisk-sounds-moh
  Version : 20050715
  Upstream Author : Enjoy Elena Kuschnerova and Lev Guelbard
* URL : http://www.signate.com/moh.php
* License : Public Domain
  Description : Asterisk PBX Music On Hold (MOH)

Enjoy Elena Kuschnerova, pianist, and Lev Guelbard, violinist, playing
public domain classical music on hold with your Asterisk PBX.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-2-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]

Re: Bug#318272: ITP: asterisk-sounds -- Additionals sound files for the Asterisk PBX

[Mark Purcell]

On Thursday 14 July 2005 15:12, Simon Richter wrote:
> Please name it asterisk-sounds-extra, as there is already a virtual
> package called "asterisk-sounds". Also, I suppose these are not spoken
> by Allison, in which cade this should be mentioned in the description.


Simon,

Yes I discovered this as I completed the package and tried to installed.

No I believe these are spoken by Allison, with the exception of the monkey 
sounds. :-) I'll include a comment in the description.

Thanks,
Mark


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

Re: no time for all debian tasks was: interacting with the press

[Greg Folkert]

On Thu, 2005-07-14 at 21:25 +0100, Andrew Suffield wrote:
> On Thu, Jul 14, 2005 at 12:03:00PM -0400, Greg Folkert wrote:
> > On Thu, 2005-07-14 at 17:57 +0200, Olaf van der Spek wrote:
> > > On 7/14/05, Christian Fromme <[EMAIL PROTECTED]> wrote:
> > > > Anand Kumria wrote:
> > > > 
> > > > > Thanks for your comments -- however I don't think anyone should be 
> > > > > able
> > > > > afraid to point out when a debian developer is obviously not able to
> > > > > satisfy all the Debian-related demands on their time; let alone their
> > > > > committments.
> > > > 
> > > > First of all, in my opinion your mail never should have gone to -devel,
> > > > but only to Martin Schulze and maybe to Branden Robinson.
> > > 
> > > Why can't this be discussed in public? There are probably more people
> > > concerned about this then only him.
> > 
> > Initially it is far better to air ones dirty laundry in the privacy of
> > your own house than out in the Public. Due mainly to the fact of
> > yellowish stains, brown streaks and in-human smells, or in other words
> > Bringing to your attention before you embarrass him before a multitude
> > of people.
> 
> How exactly do you know that he didn't? Do you read Joey's mail for him?
> 
> [That goes for all you other people saying the same thing]

Common Courtesy states that one should also mention personal
communications, even if completely ignored by the person(s) in question.

Even though Anand Kumria mention recent personal conflict with Martin,
this still does nothing in the way of informing us of Netiquette being
properly maintained. It is also not an excuse to cut this part out of
being done period, nor of mentioning it being either way.

Personally, I would have mentioned the dates and times of the
e-mails/phone calls/snail-mails in the preface of the d-d-a list mail.

But, then again, I am not (by far) an average person. I guess I should
*FORCE* myself to have less than respectable expectations for these type
of attacks^Wcriticisms.

And, BTW, How do I know, officially, I don't know if he did or didn't
try to contact Martin. And Yes, I read your e-mail, as well Andrew.

And I too, have been guilty of doing the same thing and have also been
admonished. Why stop now, trying to make d-d or d-d-a more civil, it
would be hard to make less civil, on average.

(of course you know I don't read yours or Martin's e-mail, as this is
"tongue in cheek" mode and is a forever written in stone as a sysadmin
commandment, "thou shalt not read thine users e-mail")
-- 
greg, [EMAIL PROTECTED]

For technology that is 
Strong, Better, Faster: Linux


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

Re: congratulations to the X team!!

[Greg Folkert]

On Thu, 2005-07-14 at 00:42 -0700, Sean Perry wrote:
> I just updated to X.org. With apt. Automatically. Woohoo!! I mean full 
> on xserver-xorg too. I did not touch ANYTHING.
> 
> X team you rock. This is why I started using Debian 7 years ago. This is 
> what keeps me here.
> 
> One and only one snag. purging the xfree86-common package failed because 
> it was trying to run update-rc.d remove while the config still existed.
> 
> Beers to those I meet in person. (Or something else more to your liking, 
> and at a similar cost (-:

Yes! I am in the same boat and as ecstatic about said X.org X server.

But, I don't see the rendering problems others see. Of course I have an
Oxygen card. Old, costly, but still damn fast 5 years later. Faster in
some operations than the new ATI and nVidia cards. But generally overall
slower than them, but not much.
-- 
greg, [EMAIL PROTECTED]

For technology that is 
Strong, Better, Faster: Linux


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

Re: no time for all debian tasks was: interacting with the press

[Andrew Suffield]

On Thu, Jul 14, 2005 at 12:03:00PM -0400, Greg Folkert wrote:
> On Thu, 2005-07-14 at 17:57 +0200, Olaf van der Spek wrote:
> > On 7/14/05, Christian Fromme <[EMAIL PROTECTED]> wrote:
> > > Anand Kumria wrote:
> > > 
> > > > Thanks for your comments -- however I don't think anyone should be able
> > > > afraid to point out when a debian developer is obviously not able to
> > > > satisfy all the Debian-related demands on their time; let alone their
> > > > committments.
> > > 
> > > First of all, in my opinion your mail never should have gone to -devel,
> > > but only to Martin Schulze and maybe to Branden Robinson.
> > 
> > Why can't this be discussed in public? There are probably more people
> > concerned about this then only him.
> 
> Initially it is far better to air ones dirty laundry in the privacy of
> your own house than out in the Public. Due mainly to the fact of
> yellowish stains, brown streaks and in-human smells, or in other words
> Bringing to your attention before you embarrass him before a multitude
> of people.

How exactly do you know that he didn't? Do you read Joey's mail for him?

[That goes for all you other people saying the same thing]

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: cpufrequtils init script in rcS.d

[Andrew Suffield]

On Thu, Jul 14, 2005 at 11:21:52AM +0200, Tollef Fog Heen wrote:
> * Mattia Dongili 
> 
> | - setting the CPUFreq policy must be done as early as possible in the
> |   boot process (IMHO)
> 
> Why?  This looks just like an opinion without any rationale.

It's dumb anyway. If you wanted it set early, you'd have done it on
the kernel command line.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Bug#318204: ITP: php-simpletest -- Unit testing and web testing framework for PHP

[Matthew Palmer]

On Wed, Jul 13, 2005 at 08:48:44PM -0400, Charles Fry wrote:
> * License : The Open Group Test Suite License

I'm not optimistic about this licence being DFSG-free.

- Matt


signature.asc
Description: Digital signature

Re: interacting with the press

[Matthew Palmer]

On Wed, Jul 13, 2005 at 11:11:49AM +0200, Florian Weimer wrote:
> * Anand Kumria:
> 
> > [1]:  > http://smh.com.au/news/breaking/debian-debates-support-for-ports/2005/07/12/1120934228145.html>
> 
> Apparently, this is subscription only. 8-(
> 
> Has this article been republished by another newspaper with less tight
> access controls?

Lynx is love.

- Matt


signature.asc
Description: Digital signature

Re: shared library -dev package naming proposal

[Goswin von Brederlow]

Junichi Uekawa <[EMAIL PROTECTED]> writes:

> BTW, having Build-Depends: libfoo-dev in 
> a library's build-deps, will allow the developer
> to overlook a soname change in depending shared library.
> Which is a bad idea in the QA standpoint.

Yes and no.

The programer can overlook the soname change for the source. The API
hasn't changed and nothing needs to adjust for the new soname.

The packaging system won't let the binary forget the soname change
though as that is part of the package name of the libary. Binaries
will keep using the old lib till they are recompiled.

You see, nothing breaks.

MfG
Goswin


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

Re: shared library -dev package naming proposal

[Goswin von Brederlow]

Junichi Uekawa <[EMAIL PROTECTED]> writes:

> Having a solid naming scheme will allow me to
>
> ldd /usr/lib/libwhatever.so to track down its
> shared library dependency, and appending "-dev" 
> to individual package to create the list of 
> requisite -dev packages.

With the current scheme it is:

ldd /usr/lib/libwhatever.so to track down its shared library
dependency, strip the soversion and appending "-dev" to individual
package to create the list of requisite -dev packages.

And, by the way, that list is just plain wrong.

Say you have:

libfoobar1 depends (only on) libfoo1, libfoo1 depends libbar1.

YOU would get:

libfoo1: Depends: libbar1-dev
libfoobar1-dev Depends: libfoo1-dev, libbar1-dev.


Now libbar2 is uploaded and libfoo1 recompiled with libbar2:

libfoobar1 depends libfoo1, libfoo1 depends libbar2.
libfoo1: Depends: libbar2-dev

libfoobar1-dev is now uninstallable for no good reason at all.

MfG
Goswin


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

Re: shared library -dev package naming proposal

[Goswin von Brederlow]

Will Newton <[EMAIL PROTECTED]> writes:

> On Thursday 14 July 2005 17:14, Junichi Uekawa wrote:
>
>> The current recommendation I'm trying to give is:
>>
>> Package: libXXX-dev
>> Conflicts: libXXX-dev
>> Provides: libXXX-dev
>>
>>
>> Thus, it won't contradict with your requirement to
>> be able to just build-depend on libXXX-dev.
>
> I may be wrong, but I thought it was incorrect to build-dep only on a pure 
> virtual package? e.g.:
>
> Build-Depend: xlibmesa-gl-dev | libgl-dev

Indeed. apt-get build-dep will regulary fall over Build-Depends on
virtual packages.

MfG
Goswin


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

36 hours of freedom.

[Susanna]

Get the medication you need delivered to your door in 24 hours.
http://ffyw.vag6hwv6snd3hed.upwhircadmh.net



Creativity comes from trust. Trust your instincts.  
Age is…wisdom, if one has lived one's life properly.
God gives us our relatives--thank God he lets us choose our friends. 




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

Re: congratulations to the X team!!

[Roger Leigh]

"Francesco P. Lovergine" <[EMAIL PROTECTED]> writes:

> On Thu, Jul 14, 2005 at 10:17:24AM +0200, Benjamin Mesing wrote:
>> my congratulation to the team too. However I was not as fortunate as the
>> Sean.
>> 
>
> Me too, at least on this machine I had to explicitly install
> xserver-xorg to complete the move. BTW, I see the rendering of some ttf
> fonts looks not so good. For instance I used happily this resource:
>
> XTerm*Font: -monotype-andale mono-medium-r-normal--15-0-0-0-c-0-iso8859-15
>
> and the visual quality of that font is now less good.

I also get screen corruption with the Radeon driver:

http://people.debian.org/~rleigh/Screenshot.png

Galeon is also similarly afflicted.  It's either a GTK+ bug, or a
Radeon bug (ati driver).


Regards,
Roger

-- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.


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

Microsoft Autoroute 2005 DvD UK - $19.95

[Luke]

Microsoft Digital Image Suite Pro v10.0 - $19.95
Microsoft Autoroute 2005 DvD UK - $19.95
Microsoft Office System Professional 2003 - $54.95
Microsoft Digital Image Suite Pro v10.0 - $19.95

and much more. at http://replacesoft.com/?a=3331 with fr e e e  bonus.




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

Re: shared library -dev package naming proposal

[Eduard Bloch]

#include 
* Will Newton [Thu, Jul 14 2005, 05:36:05PM]:

> > Thus, it won't contradict with your requirement to
> > be able to just build-depend on libXXX-dev.
> 
> I may be wrong, but I thought it was incorrect to build-dep only on a pure 
> virtual package? e.g.:
> 
> Build-Depend: xlibmesa-gl-dev | libgl-dev

I just though the same. In addition, that proposal removes the
possibility to depend on a certain -dev package and all newer versions
(by setting a versioned dependency on libfoo-dev).

Regards,
Eduard.
-- 
 ich kotz gleich. warum reichen 512mb nicht für konqueror, konsole,
kopete, kontact, ksirc, openoffice und 10 weitere programme aus?
 kbloat, kmemeater, kleak ...


signature.asc
Description: Digital signature

Norton Internet Security Professional 2005 - $19.95

[Shay]

Adobe Creative Suite CS CE Premium Edition - $99
Autocad 2006 - $69.95
Roxio Easy Media Creator 7.0 - $19.95
Nero Burning Rom 6.6.0.5 - $19.95

and much more. at http://replacesoft.com/?a=3331 with fr e e e  bonus.




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

Re: shared library -dev package naming proposal

[Stephen Frost]

* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> The current recommendation I'm trying to give is:
> 
> Package: libXXX-dev
> Conflicts: libXXX-dev
> Provides: libXXX-dev
> 
> 
> Thus, it won't contradict with your requirement to
> be able to just build-depend on libXXX-dev.

Uhh, then it doesn't fix your 'QA' concern anyway...

> Having a solid naming scheme will allow me to
> 
> ldd /usr/lib/libwhatever.so to track down its
> shared library dependency, and appending "-dev" 
> to individual package to create the list of 
> requisite -dev packages.

If this is actually necessary for libtool-using packages, then write
something which goes through all of the .la files and does this, since
that's what libtool wants to do.

Stephen


signature.asc
Description: Digital signature

Re: shared library -dev package naming proposal

[Stephen Frost]

* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> BTW, having Build-Depends: libfoo-dev in 
> a library's build-deps, will allow the developer
> to overlook a soname change in depending shared library.
> Which is a bad idea in the QA standpoint.

Uh, no it isn't.  SONAME changes are fine, the package has to be
rebuilt, but that's not an issue if the API hasn't changed.  If the API
has changed then it's more than an SONAME change and people will need to
adjust code which depends on it.  That's not solved by putting the
SONAME into the -dev package, you'd need an API revision number in the
-dev package to deal with that (which a number of things do, and which
is good).

Stephen


signature.asc
Description: Digital signature

Re: shared library -dev package naming proposal

[Stephen Frost]

* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > > There may be other showstoppers.
> > 
> > What does doing this solve?  What does it even help with?
> 
> Hmmm... we are talking about naming
> Debian development shareed library package names based on 
> Debian runtime shared library package names.

Errr, you still havn't said what problem you're trying to solve 
with this yet.

Stephen


signature.asc
Description: Digital signature

Re: shared library -dev package naming proposal

[Junichi Uekawa]

Hi,

> You can (and it is often done) extend an api to include more
> functionality without breaking the existing api. Any program using one
> of the new functions must use a versioned depend on the libfoo-dev
> package introducing the function.
> 
> The API can (and will) even stay compatibly across ABI changes like
> the c++ transition or changes in one of the sub libarries.
> 
> So having an unversioned provide is quite unsatisfactory and having
> versioned depends on the libfoo-dev quite common. Lets do a very rough
> count:
> 
> [EMAIL PROTECTED]:~% grep-dctrl -F Build-Depends "dev (" 
> /mnt/mirror/debian/dists/sid/main/source/Sources -sPackage | wc
>16633326   31941
> 

You have a point, that probably makes libfoo-dev being 
a unversioned provides to be a problem.


> > There may be other showstoppers.
> >
> > I would really like this 10-year old non-regulation to 
> > go to a concensus (it is indeed rather embarassing we don't 
> > agree on a good solution after 10 years...)
> 
> It has worked for the last 10 years so why change it now? Till now you
> seem to only show your nameing scheme isn't worse but not why it is
> better.
> 
> Or can you show any problems in the current names?

Currently, it's unordered.

Say a shared library package has the following:

libfoo-0.1-0

The development package looks like one of the following 
or another random incarnation:


1. libfoo-dev
2. libfoo-0.1-dev
3. libfoo-0.1-0-dev


1 and 2 cannot easily be deduced from the shared library package name,
and I am proposing using 3 as a means of deducing the 
-dev package name.

However, the goal of "having an information to shared library package name 
with development package name" can be achieved by having the 
package name in the "Provides:" field, so that might be a less disruptive
approach.




BTW, having Build-Depends: libfoo-dev in 
a library's build-deps, will allow the developer
to overlook a soname change in depending shared library.
Which is a bad idea in the QA standpoint.



regards,
junichi


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

Re: shared library -dev package naming proposal

[Will Newton]

On Thursday 14 July 2005 17:14, Junichi Uekawa wrote:

> The current recommendation I'm trying to give is:
>
> Package: libXXX-dev
> Conflicts: libXXX-dev
> Provides: libXXX-dev
>
>
> Thus, it won't contradict with your requirement to
> be able to just build-depend on libXXX-dev.

I may be wrong, but I thought it was incorrect to build-dep only on a pure 
virtual package? e.g.:

Build-Depend: xlibmesa-gl-dev | libgl-dev


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

Re: shared library -dev package naming proposal

[Junichi Uekawa]

Hi,

> > 2. The information of -dev packages depending on other -dev packages
> > cannot be automatically determined currently; 
> > it should be possible to obtain a minimal list by analyzing the 
> > NEEDED field of the objdump output.
> 
> Errr, -dev packages generally don't (and shouldn't) depend on other -dev
> packages.  If you're trying to push the idea that -dev packages should
> depend on the -dev packages of libraries they depend on- don't.  That's
> *wrong*, it's the completely wrong approach and should *not* be taken.

Give me justifications rather than just saying *wrong*,
because you are giving me an argument that is contrary to 
current practice in Debian.

-dev packages do depend on other -dev packages,
and if they don't work, they are usually filed a serious bug 
for non-functionality.


regards,
junichi


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

Re: shared library -dev package naming proposal

[Junichi Uekawa]

Hi,

> > I'd like to propose, for new -dev packages, to 
> > name -dev packages after their runtime library counterparts.
> 
> I personally found it very handy that the dev packages automatically
> selects the most recent API compatible version. Why do you want this
> switch by the way? You did not name reasons as far as I could see.


The current recommendation I'm trying to give is:

Package: libXXX-dev
Conflicts: libXXX-dev
Provides: libXXX-dev


Thus, it won't contradict with your requirement to
be able to just build-depend on libXXX-dev.


Having a solid naming scheme will allow me to

ldd /usr/lib/libwhatever.so to track down its
shared library dependency, and appending "-dev" 
to individual package to create the list of 
requisite -dev packages.



regards,
junichi


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

Re: shared library -dev package naming proposal

[Junichi Uekawa]

Hi,


> > There may be other showstoppers.
> 
> What does doing this solve?  What does it even help with?

Hmmm... we are talking about naming
Debian development shareed library package names based on 
Debian runtime shared library package names.

> 
> > I would really like this 10-year old non-regulation to 
> > go to a concensus (it is indeed rather embarassing we don't 
> > agree on a good solution after 10 years...)
> 
> non-regulation?  What non-regulation?  What regulation?  Indeed, I'm not
> sure there *isn't* majority agreement- it's just that you're in the
> minority...  That doesn't a concensus make, but, well, you'd have to
> change your mind and you don't seem too keen on doing that..
> 
> The only good solution is to not let people who don't know how to handle
> API and ABI changes and understand SONAMEs and how loaders and symbols
> work to write libraries.

This is not a relevant point, since I'm talking about the 
Debian packaging, not how upstream should code.



regards,
junichi


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

Re: shared library -dev package naming proposal

[Steve Langasek]

[once more, doesn't belong on -release...]

On Thu, Jul 14, 2005 at 12:11:21PM -0400, Stephen Frost wrote:
> * Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > > * Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > > > I'd like to propose, for new -dev packages, to 
> > > > name -dev packages after their runtime library counterparts.

> > > Uh, no?  The -dev packages have no need to match to a specific runtime
> > > library and this just creates unnecessary work.

> > Well, I will list the rationale; it might have been a bit 
> > of an abrupt mail for those who did not attend today's talk.

> > 1. usually -dev packages have a symlink to the shared library 
> > contained in the runtime shared library package.

> Uhh, this isn't a reason for them to have the major SO version in the
> name of the -dev package.

> > 2. The information of -dev packages depending on other -dev packages
> > cannot be automatically determined currently; 
> > it should be possible to obtain a minimal list by analyzing the 
> > NEEDED field of the objdump output.

> Errr, -dev packages generally don't (and shouldn't) depend on other -dev
> packages.  If you're trying to push the idea that -dev packages should
> depend on the -dev packages of libraries they depend on- don't.  That's
> *wrong*, it's the completely wrong approach and should *not* be taken.

It's more or less mandatory for libtool-based packages, due to a historical
misfeature of libtool; it's the only way to ensure static libs from any
particular -dev package are in a usable state; and it's essential when use
of the -dev package depends on the availability of headers from other -dev
packages.

That's not a very strong rationale for the proposed policy, but the -dev
dependencies themselves are (unfortunately) warranted.

-- 
Steve Langasek
postmodern programmer

Re: shared library -dev package naming proposal

[Goswin von Brederlow]

Junichi Uekawa <[EMAIL PROTECTED]> writes:

> Hi,
>
>> > I'd like to propose, for new -dev packages, to 
>> > name -dev packages after their runtime library counterparts.
>> > 
>> > If the library package is named lib$NAME, 
>> > call the -dev package lib$NAME-dev.
>> [...]
>> 
>> Hej,
>> The obvious downside of this is that the name of dev-package will change
>> although the API did not necessarily change. This would increase 
>> workload for stuff like the current C++ transition and makes backporting
>> more difficult.
>
> Thanks for pointing these points out.
> My impression is that your point can be addressed as follows:
>
> 1. libwhateverXXX-dev can (and in most cases must) provide
>(and conflict) with libwhatever-dev, 
>so the first point is moot.
>
> 2. However, versioned depends will suffer, but having a versioned 
>depends will make moot the problem with backporting and C++ transition.

You can (and it is often done) extend an api to include more
functionality without breaking the existing api. Any program using one
of the new functions must use a versioned depend on the libfoo-dev
package introducing the function.

The API can (and will) even stay compatibly across ABI changes like
the c++ transition or changes in one of the sub libarries.

So having an unversioned provide is quite unsatisfactory and having
versioned depends on the libfoo-dev quite common. Lets do a very rough
count:

[EMAIL PROTECTED]:~% grep-dctrl -F Build-Depends "dev (" 
/mnt/mirror/debian/dists/sid/main/source/Sources -sPackage | wc
   16633326   31941

> There may be other showstoppers.
>
> I would really like this 10-year old non-regulation to 
> go to a concensus (it is indeed rather embarassing we don't 
> agree on a good solution after 10 years...)

It has worked for the last 10 years so why change it now? Till now you
seem to only show your nameing scheme isn't worse but not why it is
better.

Or can you show any problems in the current names?

MfG
Goswin


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

Re: no time for all debian tasks was: interacting with the press

[Florian Weimer]

* Olaf van der Spek:

>> First of all, in my opinion your mail never should have gone to -devel,
>> but only to Martin Schulze and maybe to Branden Robinson.
>
> Why can't this be discussed in public? There are probably more people
> concerned about this then only him.

It's considered bad style to criticize a person's performance when
they are not available to defend themselves. Debian Developers are
humans, too.  The usual standards of courtesy apply.  (Surely you
don't expect them to read debian-devel cover-to-cover, which would
only add more load.)

Right now, Debian has some external communication problems, but I can
assure you that discouraging Martin in any way is not part of the
solution.


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

Re: shared library -dev package naming proposal

[Stephen Frost]

* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > * Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > > I'd like to propose, for new -dev packages, to 
> > > name -dev packages after their runtime library counterparts.
> > 
> > Uh, no?  The -dev packages have no need to match to a specific runtime
> > library and this just creates unnecessary work.
> 
> Well, I will list the rationale; it might have been a bit 
> of an abrupt mail for those who did not attend today's talk.
> 
> 1. usually -dev packages have a symlink to the shared library 
> contained in the runtime shared library package.

Uhh, this isn't a reason for them to have the major SO version in the
name of the -dev package.

> 2. The information of -dev packages depending on other -dev packages
> cannot be automatically determined currently; 
> it should be possible to obtain a minimal list by analyzing the 
> NEEDED field of the objdump output.

Errr, -dev packages generally don't (and shouldn't) depend on other -dev
packages.  If you're trying to push the idea that -dev packages should
depend on the -dev packages of libraries they depend on- don't.  That's
*wrong*, it's the completely wrong approach and should *not* be taken.

> 3. d-shlibs provides an infrastracture for generating devlibs:Depends
> for debian/control, but it has a long sed rule for replacing -dev 
> package names; it shoulnd't really neeed them.

This doesn't sound quite right either.  Looks at 'd-shlibs', it sounds
like it's doing the *wrong* thing anyway.

> 4. I'm only requesting NEW packages to come under this naming 
> scheme, we'll try to cover the old packages with some kind of sed 
> script or replacement rule.

Again, not a reason to follow the proposal at all.

Stephen


signature.asc
Description: Digital signature

Re: shared library -dev package naming proposal

[Stephen Frost]

* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> There may be other showstoppers.

What does doing this solve?  What does it even help with?

> I would really like this 10-year old non-regulation to 
> go to a concensus (it is indeed rather embarassing we don't 
> agree on a good solution after 10 years...)

non-regulation?  What non-regulation?  What regulation?  Indeed, I'm not
sure there *isn't* majority agreement- it's just that you're in the
minority...  That doesn't a concensus make, but, well, you'd have to
change your mind and you don't seem too keen on doing that..

The only good solution is to not let people who don't know how to handle
API and ABI changes and understand SONAMEs and how loaders and symbols
work to write libraries.

Stephen


signature.asc
Description: Digital signature

Re: no time for all debian tasks was: interacting with the press

[Greg Folkert]

On Thu, 2005-07-14 at 17:57 +0200, Olaf van der Spek wrote:
> On 7/14/05, Christian Fromme <[EMAIL PROTECTED]> wrote:
> > Hello,
> > 
> > Anand Kumria wrote:
> > 
> > > Thanks for your comments -- however I don't think anyone should be able
> > > afraid to point out when a debian developer is obviously not able to
> > > satisfy all the Debian-related demands on their time; let alone their
> > > committments.
> > 
> > First of all, in my opinion your mail never should have gone to -devel,
> > but only to Martin Schulze and maybe to Branden Robinson.
> 
> Why can't this be discussed in public? There are probably more people
> concerned about this then only him.

Initially it is far better to air ones dirty laundry in the privacy of
your own house than out in the Public. Due mainly to the fact of
yellowish stains, brown streaks and in-human smells, or in other words
Bringing to your attention before you embarrass him before a multitude
of people.

If then nothing comes of it, then start the airing publically. There in
lies the rub.
-- 
greg, [EMAIL PROTECTED]

For technology that is 
Strong, Better, Faster: Linux


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

Re: shared library -dev package naming proposal

[Junichi Uekawa]

Hi,

> * Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > I'd like to propose, for new -dev packages, to 
> > name -dev packages after their runtime library counterparts.
> 
> Uh, no?  The -dev packages have no need to match to a specific runtime
> library and this just creates unnecessary work.

Well, I will list the rationale; it might have been a bit 
of an abrupt mail for those who did not attend today's talk.


1. usually -dev packages have a symlink to the shared library 
contained in the runtime shared library package.

2. The information of -dev packages depending on other -dev packages
cannot be automatically determined currently; 
it should be possible to obtain a minimal list by analyzing the 
NEEDED field of the objdump output.

3. d-shlibs provides an infrastracture for generating devlibs:Depends
for debian/control, but it has a long sed rule for replacing -dev 
package names; it shoulnd't really neeed them.

4. I'm only requesting NEW packages to come under this naming 
scheme, we'll try to cover the old packages with some kind of sed 
script or replacement rule.


regards,
junichi


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

Re: no time for all debian tasks was: interacting with the press

[Olaf van der Spek]

On 7/14/05, Christian Fromme <[EMAIL PROTECTED]> wrote:
> Hello,
> 
> Anand Kumria wrote:
> 
> > Thanks for your comments -- however I don't think anyone should be able
> > afraid to point out when a debian developer is obviously not able to
> > satisfy all the Debian-related demands on their time; let alone their
> > committments.
> 
> First of all, in my opinion your mail never should have gone to -devel,
> but only to Martin Schulze and maybe to Branden Robinson.

Why can't this be discussed in public? There are probably more people
concerned about this then only him.

Re: shared library -dev package naming proposal

[Junichi Uekawa]

Hi,

> > I'd like to propose, for new -dev packages, to 
> > name -dev packages after their runtime library counterparts.
> > 
> > If the library package is named lib$NAME, 
> > call the -dev package lib$NAME-dev.
> [...]
> 
> Hej,
> The obvious downside of this is that the name of dev-package will change
> although the API did not necessarily change. This would increase 
> workload for stuff like the current C++ transition and makes backporting
> more difficult.

Thanks for pointing these points out.
My impression is that your point can be addressed as follows:

1. libwhateverXXX-dev can (and in most cases must) provide
   (and conflict) with libwhatever-dev, 
   so the first point is moot.

2. However, versioned depends will suffer, but having a versioned 
   depends will make moot the problem with backporting and C++ transition.


There may be other showstoppers.


I would really like this 10-year old non-regulation to 
go to a concensus (it is indeed rather embarassing we don't 
agree on a good solution after 10 years...)



regards,
junichi


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

Re: shared library -dev package naming proposal

[Philipp Kern]

On Thu, 2005-07-14 at 20:16 +0900, Junichi Uekawa wrote:
> I'd like to propose, for new -dev packages, to 
> name -dev packages after their runtime library counterparts.

I personally found it very handy that the dev packages automatically
selects the most recent API compatible version. Why do you want this
switch by the way? You did not name reasons as far as I could see.

Kind regards,
Philipp Kern



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

Re: shared library -dev package naming proposal

[Stephen Frost]

* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> I'd like to propose, for new -dev packages, to 
> name -dev packages after their runtime library counterparts.

Uh, no?  The -dev packages have no need to match to a specific runtime
library and this just creates unnecessary work.

> This allows mechanically determining shared library 
> package and corresponding -dev package.

Eh?  How about you go a bit deeper into why that's necessary and how
that's not possible today?  What problem are you trying to solve with
this?

> This was raised in the Shared library BOF @ Debconf5
> which was held this morning.

Clearly something's missing here 'cause you havn't provided any rational
for why this would be a good thing and honestly it certainly looks like
a bad thing(tm) to do to me.

Stephen


signature.asc
Description: Digital signature

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Jon Dowland]

On Thu, Jul 14, 2005 at 02:55:48PM +0200, Stig Sandbeck Mathisen wrote:
> Jon Dowland <[EMAIL PROTECTED]> writes:
> 
> > I suggest having __two__ lists: a wishlist and a worklist (with the
> > latter being the existing TODOlist)
> 
> A decent idea, since items can be moved back and forth as needed.

I've suggested as such at  and put
a stub page at .

-- 
Jon Dowland
http://jon.dowland.name/
PGP fingerprint: 7032F238


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

Bug#318300: ITP: baobab -- graphical tool to analyse directory trees

[Federico Di Gregorio]

Package: wnpp
Severity: wishlist
Owner: Federico Di Gregorio <[EMAIL PROTECTED]>

* Package name: baobab
  Version : 1.0.0
  Upstream Author : Fabio Marzocca <[EMAIL PROTECTED]>
* URL : http://www.marzocca.net/linux/baobab.html
* License : GPL
  Description : graphical tool to analyse directory trees

Baobab is able to scan either specific directories or the whole
filesystem, in order to give the user a graphical tree representation
including each directory size or percentage in the branch.


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

Re: interacting with the press

[Thijs Kinkhorst]

On Thu, July 14, 2005 17:20, Thijs Kinkhorst wrote:
> On Wed, July 13, 2005 04:04, Nigel Jones wrote:
>> but IMHO he does a good job.
>
> I do not -

of couse I meant "I do not agree"... :-)


Thijs


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

Unidentified subject!

[Anand Kumria]

Hi Steve,

Thanks for your email.  I'd like to say touche but I basically believe
you are wrong.  Unfortunately I found from past-personal experience that
email to busy people is generally ignored unless brought to their
attention.

Additionally personal personality conflicts between myself and press
contact would practically guarantee that.  At any rate, I had hoped that
my email was being constructive (or that it could spaark a constructive
discussion) but that doesn't appear to have been the case.

I had hoped that others would have noted:

- the most recent PR does not have any indication of embargoed
  status.  Is it for immediate release?  Should it be held
  briefly?

  Most organisation use embargoed press releases so that when
  important events happen (e.g. a Debian release) everything can
  be prepared in advance and happen simultaneously.

- no 'about Debian' section

 Even smaller projects like Gnome has a section detailing, who
 they are, a brief outline of their goals, etc.  We place great
 value on things like the Social Contract and the DFSG and we
 should have a similiar section which mentions them -
 particularly for journalists who are not familiar with Debian
 this may be a great 'teaser' in an article about us.

 A good example one is
 http://gnome.org/press/releases/guadec2006-location.html>

 - nothing about debconf

 The Gnome release, above, highlights where the next GUADEC will
 be; how many Press Release have their been highlighting the
 current debcamp/debconf?  

There are other additional issues, all of which are technical -- since
press release are essentially 'cookie-cutter' things.  The last issue is
related to timelyness and my belief that quite a number of developers
have taken on too many roles within the project -- to the detriment of
the project.

Once again, thanks for your email, I personally didn't like the tone but
I do take your point. I just happen to diagree with it.

Regards,
Anand

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"


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

Re: interacting with the press

[Thijs Kinkhorst]

On Wed, July 13, 2005 04:04, Nigel Jones wrote:
>> Or, should you find the demands on your time too pressing, why not use
>> this opportunity to step-aside as the Debian press contact.
> Love the pun, but IMHO he does a good job.

I do not - while I don't want to judge Joey's skills, for me it's a given
that both the following statements hold: Joey is the only person in the
press team, and the press team does not function well. I don't think he's
incompetent, probably it's out of a lack of time, but the press function
can be performed way better than it is now.

Why? Some concerns:
- The Debian press contact does not even list phone numbers, just an
anonymous email address (See www.debian.org -> contact us). I find that to
be very unprofessional and something that should be changed in order to be
a serious point of contact for the press.

- A lot of the bad press about security was based about dubious
information from blogs and other gossip. An early press release from
Debian with the facts could have gotten out a whole lot more balanced
view. The first statement from Debian about security was released when
everything was solved, i.e. way too late.

- There have not been many interesting press releases in the past year.
What about a news item about a big German city adopting Debian? Tell the
world about secure APT. Branden Robinson as the new DPL is also not
news-worthy appearently.

I've already offered to take part in changing this situation.


regards,
Thijs


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

Re: #311724

[Marc Haber]

On Thu, 14 Jul 2005 13:13:49 +0200, BJoerg Jaspert <[EMAIL PROTECTED]>
wrote:
>And now please go and read my reject mail again - I propose a way for
>people who really need help to set the correct Build-Depends.

The way you propose in your original bug report must be made possible
by a CDBS change. Is there any possibility for me to have the feature
in the form you suggested, Now?

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: shared library -dev package naming proposal

[Andreas Metzler]

[I am stopping the cross-posting to -release, as -release is no
discussion list]
On 2005-07-14 Junichi Uekawa <[EMAIL PROTECTED]> wrote:
> I'd like to propose, for new -dev packages, to 
> name -dev packages after their runtime library counterparts.
> 
> If the library package is named lib$NAME, 
> call the -dev package lib$NAME-dev.
[...]

Hej,
The obvious downside of this is that the name of dev-package will change
although the API did not necessarily change. This would increase 
workload for stuff like the current C++ transition and makes backporting
more difficult.
  cu andreas


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

Re: no time for all debian tasks was: interacting with the press

[Christian Fromme]

Hello,

Anand Kumria wrote:


Thanks for your comments -- however I don't think anyone should be able
afraid to point out when a debian developer is obviously not able to
satisfy all the Debian-related demands on their time; let alone their
committments.


First of all, in my opinion your mail never should have gone to -devel, 
but only to Martin Schulze and maybe to Branden Robinson.



From http://www.debian.org/intro/organization> you can various

people listed more than once; in Martin Schulze case 6 times.


Well, he *does* work hard for Debian, so you should better thank him a 
lot for that instead of making (in my opinion) senseless accusations. I 
read the article you referenced and I do not agree with you at all.


Christian


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

shared library -dev package naming proposal

[Junichi Uekawa]

Hi,

I'd like to propose, for new -dev packages, to 
name -dev packages after their runtime library counterparts.


If the library package is named lib$NAME, 
call the -dev package lib$NAME-dev.


For example,


libxxx0 will have
libxxx0-dev.

libfoobar-2.1-0 will have 
libfoobar-2.1-0-dev.


This allows mechanically determining shared library 
package and corresponding -dev package.
This was raised in the Shared library BOF @ Debconf5
which was held this morning.

For transition purposes, I would like this only to be 
enforced on new packages, since renaming every single 
-dev package would be prohibitively intrusive,
but would like to enforce this rule for new packages.


Comments?



regards,
junichi


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

pbuilder status update

[Junichi Uekawa]

Hi,

I'll just write a mail here to notify people using pbuilder, that 
sid is a wild place.

My testsuite tells me that currently Debian sid/etch is not 
debootstrap'able. This is due to several problems, 
including g++ ABI transition breaking aptitude.

However, the good news is that you should be able to create 
sarge chroot, and then upgrade to sid.

A command-sequence like the following should work:

pbuilder create --distribution sarge
pbuilder update --distribution sid --override-config

It's a bumpy ride in sid right now, but this is your workaround.



For reference:

[FAIL] create-sid
[FAIL] build-sid-dsh
[FAIL] pdebuild-sid-dsh
[FAIL] pdebuild-internal-sid-dsh
[OK]   create-sarge
[OK]   build-sarge-dsh
[OK]   pdebuild-sarge-dsh
[OK]   pdebuild-internal-sarge-dsh
[OK]   update-sarge-etch.log
[OK]   update-sarge-etch-sid.log
[OK]   update-sarge-etch-sid-experimental.log
[FAIL] create-etch
[FAIL] build-etch-dsh
[FAIL] pdebuild-etch-dsh
[FAIL] pdebuild-internal-etch-dsh
[FAIL] update-etch-sid.log
[FAIL] update-etch-sid-experimental.log


regards,
junichi


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

Re: congratulations to the X team!!

[David Nusinow]

On Thu, Jul 14, 2005 at 12:42:54AM -0700, Sean Perry wrote:
> I just updated to X.org. With apt. Automatically. Woohoo!! I mean full 
> on xserver-xorg too. I did not touch ANYTHING.
> 
> X team you rock. This is why I started using Debian 7 years ago. This is 
> what keeps me here.
> 
> One and only one snag. purging the xfree86-common package failed because 
> it was trying to run update-rc.d remove while the config still existed.
> 
> Beers to those I meet in person. (Or something else more to your liking, 
> and at a similar cost (-:

Thank you very much :-) Hopefully we can get them moving in to etch and
then push ahead towards getting the upcoming X.Org release in to the
archive as close to its release date as possible.

 - David Nusinow


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

Re: congratulations to the X team!!

[David Nusinow]

On Thu, Jul 14, 2005 at 02:41:18PM +0300, Jaakko Niemi wrote:
> On Thu, 14 Jul 2005, Sean Perry wrote:
> > I just updated to X.org. With apt. Automatically. Woohoo!! I mean full 
> > on xserver-xorg too. I did not touch ANYTHING.
> 
>  My only gripe is that the upload did not have pciids for
>  radeon X700 etc.
> 
>  http://lists.debian.org/debian-x/2005/06/msg00179.html
> 
>  Now I'm pondering between sending a patch and trusting 
>  people to check their TODO lists :=)

Patches are most assuredly welcome :-)

 - David Nusinow


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

Re: congratulations to the X team!!

[David Nusinow]

On Thu, Jul 14, 2005 at 12:08:00PM +0200, Francesco P. Lovergine wrote:
> On Thu, Jul 14, 2005 at 10:17:24AM +0200, Benjamin Mesing wrote:
> > my congratulation to the team too. However I was not as fortunate as the
> > Sean.
> > 
> 
> Me too, at least on this machine I had to explicitly install
> xserver-xorg to complete the move. BTW, I see the rendering of some ttf
> fonts looks not so good. For instance I used happily this resource:
> 
> XTerm*Font: -monotype-andale mono-medium-r-normal--15-0-0-0-c-0-iso8859-15
> 
> and the visual quality of that font is now less good.

Yes, several people have reported this issue, and I plan to look in to it
as soon as the packages are updated to build properly on all arches where
they've failed.

 - David Nusinow


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

Re: congratulations to the X team!!

[David Nusinow]

On Thu, Jul 14, 2005 at 11:02:09AM -0300, Gustavo Franco wrote:
> I see that yesterday a modularized xserver (xorg) entered ubuntu
> breezy (the current development branch) archives.

It's exciting stuff, but my primary goal is to get the current X.Org
release in to etch.

> I've some questions: Is XSF coordinating its work with them or what ?
> Is modularized xorg a goal for us ? I think that it's easy to do since
> some if not all xorg ubuntu maintainers are DDs too.

Yes, Daniel and I have been working closely together, and while I haven't
looked at the modular stuff yet, it's very much something I want to see
done in Debian if possible. I may produce one more set of monolithic
packages (6.9 series) to tide us over during the modular transition, but if
I do it's likely that these will be unofficial unless for some unexpected
reason we're not able to complete the transition to the modular tree for
etch.

> Closing, congratulations for both teams anyway.

Thank you very much.

 - David Nusinow


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

no time for all debian tasks was: interacting with the press

[Anand Kumria]

Hi Torsten,

Thanks for your comments -- however I don't think anyone should be able
afraid to point out when a debian developer is obviously not able to
satisfy all the Debian-related demands on their time; let alone their
committments.

>From http://www.debian.org/intro/organization> you can various
people listed more than once; in Martin Schulze case 6 times.  I've
already said I do not believe that Martin is being an effective press
contact -- good intentions are great, but I'd like tto htink we also
deserve good execution.

Thanks,
Anand

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"


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

Re: no time for all debian tasks was: interacting with the press

[Torsten Landschoff]

Hi Anand, 

On Fri, Jul 15, 2005 at 12:32:54AM +1000, Anand Kumria wrote:
> Thanks for your comments -- however I don't think anyone should be able
> afraid to point out when a debian developer is obviously not able to
> satisfy all the Debian-related demands on their time; let alone their
> committments.

First this is a thing to suggest in private. And second I don't see how
a comment by Joey which you think was not PC has anything to do with his 
Debian time.

> From http://www.debian.org/intro/organization> you can various
> people listed more than once; in Martin Schulze case 6 times.  I've
> already said I do not believe that Martin is being an effective press
> contact -- good intentions are great, but I'd like tto htink we also
> deserve good execution.
 
The reason for Joey being listed that often that he really lives Debian.
Most people do Debian as a hobby but for Joey my impression is that he
spends more time on Debian than other people on their job. 

Wether that's a good thing for him is another question and stays his
decision anyway. 

Greetings

Torsten


signature.asc
Description: Digital signature

Re: congratulations to the X team!!

[Gustavo Franco]

On 7/14/05, Daniel Stone <[EMAIL PROTECTED]> wrote:
> 
> The server hasn't been modularised yet, it's just that I split up all
> the packaging.  I've been working closely with Josh Triplett on the
> libraries, and keeping David fully in the loop with everything I'm doing
> in Breezy, and I'm pretty sure that we're going to arrive at a common
> base for packaging when Debian gets over to the modular tree.

Hi Daniel,

Thank you for clarifying the topic. 

About the split up, is there a consensus in what to install exactly ? See, 
the user will install all the packages related to video drivers and dexconf 
will do its job and it's up to the user remove what is not needed ? I'm asking
about Debian, because i guess that in Ubuntu you'll autodetect as much as
possible in the install and just keep there what's necessary maybe using a
different approach if the user change his video card, plug a new input device
or whatever.

Closing, what are the side effects (if any) that this split up and
modularization will
put on the loop for stuff like lessdisks and ltsp ?

--
Gustavo Franco -- <[EMAIL PROTECTED]>

Re: congratulations to the X team!!

[Daniel Stone]

On Thu, Jul 14, 2005 at 11:02:09AM -0300, Gustavo Franco wrote:
> I see that yesterday a modularized xserver (xorg) entered ubuntu
> breezy (the current development branch) archives.
> 
> I've some questions: Is XSF coordinating its work with them or what ?
> Is modularized xorg a goal for us ? I think that it's easy to do since
> some if not all xorg ubuntu maintainers are DDs too.
> 
> Closing, congratulations for both teams anyway.

The server hasn't been modularised yet, it's just that I split up all
the packaging.  I've been working closely with Josh Triplett on the
libraries, and keeping David fully in the loop with everything I'm doing
in Breezy, and I'm pretty sure that we're going to arrive at a common
base for packaging when Debian gets over to the modular tree.


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

Re: Bug#318272: ITP: asterisk-sounds -- Additionals sound files for the Asterisk PBX

[Simon Richter]

Hi,

Mark Purcell schrieb:

> * Package name: asterisk-sounds

Please name it asterisk-sounds-extra, as there is already a virtual
package called "asterisk-sounds". Also, I suppose these are not spoken
by Allison, in which cade this should be mentioned in the description.

   Simon


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

Re: congratulations to the X team!!

[Gustavo Franco]

I see that yesterday a modularized xserver (xorg) entered ubuntu
breezy (the current development branch) archives.

I've some questions: Is XSF coordinating its work with them or what ?
Is modularized xorg a goal for us ? I think that it's easy to do since
some if not all xorg ubuntu maintainers are DDs too.

Closing, congratulations for both teams anyway.

Thanks,
Gustavo Franco -- <[EMAIL PROTECTED]>

Bug#318272: ITP: asterisk-sounds -- Additionals sound files for the Asterisk PBX

[Mark Purcell]

Package: wnpp
Severity: wishlist
Owner: Mark Purcell <[EMAIL PROTECTED]>

* Package name: asterisk-sounds
  Version : 1.0.9
  Upstream Author : [EMAIL PROTECTED]
* URL : 
http://www.asterisk.org/html/downloads/asterisk-sounds-1.0.9.tar.gz
* License : BSD
  Description : Additionals sound files for the Asterisk PBX

Extra sound files for use with the Asterisk PBX, including city names,
other words and phases.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-2-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]

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Stig Sandbeck Mathisen]

Jon Dowland <[EMAIL PROTECTED]> writes:

> I suggest having __two__ lists: a wishlist and a worklist (with the
> latter being the existing TODOlist)

A decent idea, since items can be moved back and forth as needed.

-- 
Stig Sandbeck Mathisen


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Jon Dowland]

On Mon, Jul 11, 2005 at 11:50:14AM -0400, David Nusinow wrote:
 
> What I'd like to see is no more new items added to that list without
> someone signing up and taking responsibility for them. What I really want
> to see more than anything with that list is for each and every item to have
> at least one person signed up, taking responsibility for it. That way, it
> becomes a real TODO list, rather than just a stupid wishlist.

I think the TODO list is an incredibly useful tool and I agree that it
shouldn't be clogged up by wishlist items (i.e. items someone thinks
are worthy enough to add, but nobody is up for working on them yet).
However I do think wishlist items serve a purpose too: They demonstrate
a desire from users for a feature that could be picked up on and
converted into a TODO list item by an interested party.

I suggest having __two__ lists: a wishlist and a worklist (with the
latter being the existing TODOlist)

-- 
Jon Dowland
http://jon.dowland.name/
PGP fingerprint: 7032F238


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

Re: Mass bug filing for packages that FTBFS because of changes to texi2html

[Andreas Barth]

* Matt Kraai ([EMAIL PROTECTED]) [050714 02:21]:
> texi2html's behavior changed recently: if it is invoked with
> -split=chapter, old versions place the HTML files in the same
> directory as the documentation source, whereas new versions place the
> generated files in a subdirectory.
> 
> After I'd filed a few bugs about this, Santiago Vila suggested that I
> should contact d-d-a instead and allow developers a chance to fix
> their packages before filing bugs.
> 
> I checked the packages that build-depend on texi2html and found that
> 19 of them fail because of this problem (not including the ones I've
> already filed bugs against).  Should I file bugs individually, post to
> d-d-a, or do something else?

Post to d-d-a and _include the list of packages_.


Cheers,
Andi


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

Re: congratulations to the X team!!

[Jaakko Niemi]

On Thu, 14 Jul 2005, Sean Perry wrote:
> I just updated to X.org. With apt. Automatically. Woohoo!! I mean full 
> on xserver-xorg too. I did not touch ANYTHING.

 My only gripe is that the upload did not have pciids for
 radeon X700 etc.

 http://lists.debian.org/debian-x/2005/06/msg00179.html

 Now I'm pondering between sending a patch and trusting 
 people to check their TODO lists :=)

--j


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

Re: #311724

[BJoerg Jaspert]

On 10350 March 1977, Martin-Eric Racine wrote:

>>> Doing an NMU on CDBS to fix #311724 might be a more constructive approach
>>> than asking everyone who uses CDBS with debian/control.in to go and fix
>>> their package's static debian/control for absolutely no gain, given how it
>>> will be overwrriten at the next build run.
>> NO. Just remove the auto-update var in your debian/rules, fix the
>> control file and build the package.
>> DO NOT, EVER, change the Build-Depends in an automated way. NEVER.
> That's your opinion.  It damn well better be backed by a Policy item.

Just turn on common-sense and maybe other stuff and think about what
this auto-update-control-crap means.
Think about - the buildds getting other build-depends than you had for
your build.
Or the security team.
Or a later NMU.

Anyone who wants that really should not upload a package.

And now please go and read my reject mail again - I propose a way for
people who really need help to set the correct Build-Depends.

-- 
bye Joerg


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

Re: #311724

[Martin-Eric Racine]

On Thu, 14 Jul 2005, Joerg Jaspert wrote:


On 10350 March 1977, Martin-Eric Racine wrote:


You may want to follow bug #311724, which is about exactly this issue.

Understood, but out of my hands; it appears to be a CDBS issue.


Yep, including this feature is a cdbs mistake. Using it is a maintainer mistake.


I would like to know the Policy section which forbids either.


The last version of the default static debian/control I shipped was
correct; however, it doesn't change anything:  my sponsor has to build
this package, at which point CDBS will overwrite this again.



Doing an NMU on CDBS to fix #311724 might be a more constructive approach
than asking everyone who uses CDBS with debian/control.in to go and fix
their package's static debian/control for absolutely no gain, given how it
will be overwrriten at the next build run.


NO. Just remove the auto-update var in your debian/rules, fix the
control file and build the package.
DO NOT, EVER, change the Build-Depends in an automated way. NEVER.


That's your opinion.  It damn well better be backed by a Policy item.

--
Martin-Eric Racine
http://q-funk.iki.fi


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

Re: GCC 4.0 as the default GCC / C++ ABI change

[Matthias Klose]

Robert Jordens writes:
> Hello!
> 
> [Tue, 05 Jul 2005] Matthias Klose wrote:
>  
> > - - 5-day NMU for all C++ library packages, which can be converted, but
> >   are left alone.
> > 
> > i.e. if libfoo1++ depends on libbar1++, libfoo1++ can be NMU'ed 5 days
> > after libbar1++ is uploaded.
> 
> Since NMUs are allowed now: Are they allowed as 0-day NMUs?
> Are they "0-day NMUs after 5 days" or "5-day NMUs after 5 days"?

My intention was to have 0-day NMU's after 5 days.

  Matthias


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

Re: congratulations to the X team!!

[Florian Weimer]

* Francesco P. Lovergine:

> Me too, at least on this machine I had to explicitly install
> xserver-xorg to complete the move. BTW, I see the rendering of some ttf
> fonts looks not so good. For instance I used happily this resource:
>
> XTerm*Font: -monotype-andale mono-medium-r-normal--15-0-0-0-c-0-iso8859-15
>
> and the visual quality of that font is now less good.

Same for -bitstream-bitstream vera sans mono-bold-r-*-*-12-*-*-*-*-*-*-*.
The hinting defaults for TrueType fonts probably changed.

Apart from that, the transition went fine.  (For a couple of days,
I've been struggling with ion3 and it's effect on mouse focus, but
this is unrelated.)


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

Re: Mass bug filing for packages that FTBFS because of changes to texi2html

[Santiago Vila]

On Wed, 13 Jul 2005, Matt Kraai wrote:

> texi2html's behavior changed recently: if it is invoked with
> -split=chapter, old versions place the HTML files in the same
> directory as the documentation source, whereas new versions place the
> generated files in a subdirectory.
> 
> After I'd filed a few bugs about this, Santiago Vila suggested that I
> should contact d-d-a instead and allow developers a chance to fix
> their packages before filing bugs.
> 
> I checked the packages that build-depend on texi2html and found that
> 19 of them fail because of this problem (not including the ones I've
> already filed bugs against).  Should I file bugs individually, post to
> d-d-a, or do something else?

I vote for a post to d-d-a, wait a week, then file bugs.

However, I would like to see a texi2html option to get the old
behaviour first... In some cases, converting a debian/rules to the
new behaviour becomes an ugly hack, as there is already an executable
having the name texi2html would use for the directory.


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

Re: congratulations to the X team!!

[Francesco P. Lovergine]

On Thu, Jul 14, 2005 at 10:17:24AM +0200, Benjamin Mesing wrote:
> my congratulation to the team too. However I was not as fortunate as the
> Sean.
> 

Me too, at least on this machine I had to explicitly install
xserver-xorg to complete the move. BTW, I see the rendering of some ttf
fonts looks not so good. For instance I used happily this resource:

XTerm*Font: -monotype-andale mono-medium-r-normal--15-0-0-0-c-0-iso8859-15

and the visual quality of that font is now less good.

-- 
Francesco P. Lovergine


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

Re: cpufrequtils init script in rcS.d

[Tollef Fog Heen]

* Mattia Dongili 

| - setting the CPUFreq policy must be done as early as possible in the
|   boot process (IMHO)

Why?  This looks just like an opinion without any rationale.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

Re: congratulations to the X team!!

[Steinar H. Gunderson]

On Thu, Jul 14, 2005 at 10:17:24AM +0200, Benjamin Mesing wrote:
> What about the xlibmesa-glu packages? Can we expect them to enter the
> archive again? Else I have to remove some of my shiny GL applications
> (crystalspace, freewrl, libdevil,...)

Build-dep on "libglu1-xorg-dev | libglu-dev", and it should work.

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


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

Re: congratulations to the X team!!

[Benjamin Mesing]

Hello,


my congratulation to the team too. However I was not as fortunate as the
Sean.

What about the xlibmesa-glu packages? Can we expect them to enter the
archive again? Else I have to remove some of my shiny GL applications
(crystalspace, freewrl, libdevil,...)

Greetings Ben

-- 
Please do not sent any email to the [EMAIL PROTECTED] - all email not
originating from the mailing list will be deleted automatically. Use the
reply to address instead.


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

congratulations to the X team!!

[Sean Perry]

I just updated to X.org. With apt. Automatically. Woohoo!! I mean full 
on xserver-xorg too. I did not touch ANYTHING.


X team you rock. This is why I started using Debian 7 years ago. This is 
what keeps me here.


One and only one snag. purging the xfree86-common package failed because 
it was trying to run update-rc.d remove while the config still existed.


Beers to those I meet in person. (Or something else more to your liking, 
and at a similar cost (-:



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

Re: #311724

[Joerg Jaspert]

On 10350 March 1977, Martin-Eric Racine wrote:

>> You may want to follow bug #311724, which is about exactly this issue.
> Understood, but out of my hands; it appears to be a CDBS issue.

Yep, including this feature is a cdbs mistake. Using it is a maintainer mistake.

> The last version of the default static debian/control I shipped was 
> correct; however, it doesn't change anything:  my sponsor has to build 
> this package, at which point CDBS will overwrite this again.

> Doing an NMU on CDBS to fix #311724 might be a more constructive approach 
> than asking everyone who uses CDBS with debian/control.in to go and fix 
> their package's static debian/control for absolutely no gain, given how it 
> will be overwrriten at the next build run.

NO. Just remove the auto-update var in your debian/rules, fix the
control file and build the package.
DO NOT, EVER, change the Build-Depends in an automated way. NEVER.

-- 
bye Joerg


pgpWHZf2XOs7i.pgp
Description: PGP signature

#311724 (was: Re: gaim-irchelper_0.11-1_i386.changes REJECTED)

[Martin-Eric Racine]

On Wed, 13 Jul 2005, Joerg Jaspert wrote:


While checking your package in NEW I found that it has the cdbs "Play with
my debian/control in a bad way" option turned on, and thus modifies
Build-Dependencies on the fly.


[...]


You may want to follow bug #311724, which is about exactly this issue.


Understood, but out of my hands; it appears to be a CDBS issue.



Note2: This is *MY* opinion/position on this matter. If you disagree you are of
  course always free to answer to this mail and state your position, or
  to reupload an unfixed version and hope that another one processing NEW
  accepts this.


The last version of the default static debian/control I shipped was 
correct; however, it doesn't change anything:  my sponsor has to build 
this package, at which point CDBS will overwrite this again.


Doing an NMU on CDBS to fix #311724 might be a more constructive approach 
than asking everyone who uses CDBS with debian/control.in to go and fix 
their package's static debian/control for absolutely no gain, given how it 
will be overwrriten at the next build run.


--
Martin-Eric Racine
http://q-funk.iki.fi


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