Re: Correct spelling/capitalisation of project names

[Rafael Laboissiere]

* Russ Allbery <[EMAIL PROTECTED]> [2008-01-07 23:54]:

> So if you notice any common misspelled words that Lintian doesn't catch,
> please let debian-lint-maint know and we'll add them to the table.

The name of the S-Lang library is sometimes wrongly spelled as "slang". It
would be good to have this fixed but if you add a rule slang -> S-Lang in
Lintian you will hit some false positives (like in packages ascii and
jargon) because "slang" is an English word.

-- 
Rafael


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

Bug#460341: ITP: eaccelerator-src -- sources for PHP's eAccelerator module

[Alexander Gerasiov]

Package: wnpp
Severity: wishlist
Owner: Alexander Gerasiov <[EMAIL PROTECTED]>

* Package name: eaccelerator-src
  Version : 0.9.5.2
* URL : http://eaccelerator.net/
* License : GPL
  Programming Lang: C
  Description : sources for PHP's eAccelerator module

 eAccelerator is a free open-source PHP accelerator, optimizer, and dynamic
 content cache. It increases the performance of PHP scripts by caching them
 in their compiled state, so that the overhead of compiling is almost completely
 eliminated. It also optimizes scripts to speed up their execution. eAccelerator
 typically reduces server load and increases the speed of your PHP code by 1-10
 times.
 .
 Unfortunatly it could not be distribured in binary form as it links againg
 GPL-incompatible PHP. eaccelerator-package will build eAccelerator debian
 package for you.
 .
 This package contain eAccelerator's source code.


-- System Information:
Debian Release: lenny/sid
  APT prefers testing-proposed-updates
  APT policy: (700, 'testing-proposed-updates'), (700, 'testing'), (670, 
'proposed-updates'), (670, 'stable'), (600, 'unstable'), (550, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-3-vserver-686 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/bash



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

Re: Role account whitelisting on alioth

[Steve Langasek]

Hi Stephen,

On Tue, Jan 08, 2008 at 12:15:12AM +, Stephen Gran wrote:
> It looks like we have whitelisting for certain role addresses working
> correctly on alioth's mailman.  Those interested in how you do these
> things (I had no idea mailman was so flexible) can take a look at the
> DebianWhitelist mailman handler on alioth.

> So, the good news is maintainers can stop having to worry about
> whitelisting mail from the BTS and dak and so on.  This should stop
> some of the annoyance for people who handle those various role accounts,
> and also make sure maintainers actually get to see the mail instead of
> having to manage the mailing list interface all the time.  So, if you
> have some manual whitelisting for debian role accounts in your lists,
> feel free to drop it now.  If you read mail for a role account and
> get killed with 'pending' messages, let us know.  

> M-F-T set to -devel, but you can send new addresses either to myself or
> to [EMAIL PROTECTED]

I just wanted to say a big "THANK YOU" for your work on this.  Prior to this
change, I was unable to find any way to locally configure the alioth lists I
admin to allow all (subscriber,BTS,ftp-master,svn commit) mail through
without manually maintaining a whitelist of subscribers.  Now all the good
mail is getting through, and I don't have to moderate posts (except
rejecting the occasional spam) or keep track of subscribers.  This was a
long-time annoyance of mine, and I'm very happy to see it finally fixed once
for all.  Kudos!

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


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

Re: Packages leaving obsolete init.d scripts behind

[Holger Levsen]

Hi Petter,

On Friday 11 January 2008 12:39, Petter Reinholdtsen wrote:
> Here are some examples from my sid chroot:

Did you file bugs?


regards,
Holger (writing this offline..)


pgpJ76J5F8Jr4.pgp
Description: PGP signature

Re: ldbl128 transition for liborbit2 could be omitted

[Steve Langasek]

On Sat, Jan 12, 2008 at 03:56:17AM +0100, Josselin Mouette wrote:
> Hi,

> looking at why ORBit hadn’t been updated to the latest upstream version,
> I noticed there is an open RC bug about the ldbl128 transition. Given
> the number of rdeps (373), this is a huge beast to update.

> However, looking at the headers, I can see that in fact, it can probably
> be avoided. The basic long double type, which is used by all structures,
> is the following:
>   typedef gdouble   CORBA_long_double;

> This is a clear violation of the CORBA specification, but the result for
> us is that this transition should not be necessary.

> Is it OK to close this bug, or am I missing something?

Yes, this is ok.  The problem is a small bug in the regexp used to find
offenders:

 long *double

this of course matches "longdouble", where the intended regexp was really:

 long \+double

I've confirmed that the latter pattern has no matches in
/usr/include/orbit-2.0, so closing the bug with this mail.

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


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

Re: Bug#459403: libuuid1: missing depends on non-essential package passwd

[Colin Watson]

On Mon, Jan 07, 2008 at 12:39:30PM +0100, Bill Allombert wrote:
> Since libuuid1 is essential, every system will end up with a libuuid
> user/group, so why not just add it to base-passwd instead of creating it
> dynamically ?

In general I want to avoid almost all further creation of global static
IDs. The last exception I made was when the installer needed a group
with a static ID to exist so that it could hardcode its GID in
/etc/fstab. Global static IDs are difficult to maintain, complicate
partial upgrades, require user interaction (this should be overhauled,
admittedly, but nevertheless), and have a very limited available space.

I don't think "but we don't want to make adduser Priority: required" is
a good enough reason to add global static IDs; and passwd doesn't need
to be made Essential just because an Essential package depends on it
(Essential isn't closed under dependency).

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: Bug#459403: libuuid1: missing depends on non-essential package passwd

[Steve Langasek]

On Sat, Jan 12, 2008 at 11:33:23AM +, Colin Watson wrote:
> On Mon, Jan 07, 2008 at 12:39:30PM +0100, Bill Allombert wrote:
> > Since libuuid1 is essential, every system will end up with a libuuid
> > user/group, so why not just add it to base-passwd instead of creating it
> > dynamically ?

> In general I want to avoid almost all further creation of global static
> IDs. The last exception I made was when the installer needed a group
> with a static ID to exist so that it could hardcode its GID in
> /etc/fstab. Global static IDs are difficult to maintain, complicate
> partial upgrades, require user interaction (this should be overhauled,
> admittedly, but nevertheless), and have a very limited available space.

> I don't think "but we don't want to make adduser Priority: required" is
> a good enough reason to add global static IDs; and passwd doesn't need
> to be made Essential just because an Essential package depends on it
> (Essential isn't closed under dependency).

The use case here was that passwd would be a dependency of a pre-dependency
of an essential package, which does promote it into the effective essential
set.

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


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

Re: Correct spelling/capitalisation of project names

[Russ Allbery]

Rafael Laboissiere <[EMAIL PROTECTED]> writes:
> * Russ Allbery <[EMAIL PROTECTED]> [2008-01-07 23:54]:

>> So if you notice any common misspelled words that Lintian doesn't catch,
>> please let debian-lint-maint know and we'll add them to the table.

> The name of the S-Lang library is sometimes wrongly spelled as "slang". It
> would be good to have this fixed but if you add a rule slang -> S-Lang in
> Lintian you will hit some false positives (like in packages ascii and
> jargon) because "slang" is an English word.

Yeah, unfortunately I don't think lintian will be able to catch that one.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Packages leaving obsolete init.d scripts behind

[Petter Reinholdtsen]

[Holger Levsen]
> Did you file bugs?

I believe I reported (or checked that there was a report) for each of
the ones I found, but am not sure, as my current focus is on the boot
system, and I do not want to be sidetracked from that work.

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: Bits from the Qt/KDE team

[Ana Guerrero]

On Thu, Jan 10, 2008 at 11:38:10PM +0100, Armin Berres wrote:
> On Thu, 10 Jan 08 14:18, Charles de Miramon wrote:
> > Ana Guerrero wrote:
> > > There are still some issues that need to be resolved, such as migration of
> > > configuration files, since we have patched KDE 4 to store its settings in
> > > ~/.kde4 instead of ~/.kde .
> > 
> > Why don't you patch Lenny's KDE3 so it uses ~/.kde3 and have KDE4 uses the
> > regular ~/.kde ? I would rather patch the end of life KDE3 than KDE4.
> 
> The plan is to use ~/.kde for KDE 3 and for KDE 4. We patched KDE 4
> right now, because we are not sure that KDE 4 applications won't eat
> your nice and pretty KDE 3 config.
> In the long run we want to remove the patch from KDE 4, but we need to
> try if this really works first.
>

And uploading between KDE 4 betas/RC versions the configuration settings has 
been 
lose sometimes :/

Ana


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

Re: Correct spelling/capitalisation of project names

[Rafael Laboissiere]

* Russ Allbery <[EMAIL PROTECTED]> [2008-01-12 09:11]:

> Rafael Laboissiere <[EMAIL PROTECTED]> writes:
> > The name of the S-Lang library is sometimes wrongly spelled as "slang". It
> > would be good to have this fixed but if you add a rule slang -> S-Lang in
> > Lintian you will hit some false positives (like in packages ascii and
> > jargon) because "slang" is an English word.
> 
> Yeah, unfortunately I don't think lintian will be able to catch that one.

Can't you add exceptions for some packages in the Lintian check?  The only
packages in sid that use "slang" as an English word are ascii, jargon, and
jargon-text.  Other packages that use "slang" or "SLang" mean actually the
"S-Lang" library.

-- 
Rafael


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

Re: Correct spelling/capitalisation of project names

[Michael Tautschnig]

> * Russ Allbery <[EMAIL PROTECTED]> [2008-01-12 09:11]:
> 
> > Rafael Laboissiere <[EMAIL PROTECTED]> writes:
> > > The name of the S-Lang library is sometimes wrongly spelled as "slang". It
> > > would be good to have this fixed but if you add a rule slang -> S-Lang in
> > > Lintian you will hit some false positives (like in packages ascii and
> > > jargon) because "slang" is an English word.
> > 
> > Yeah, unfortunately I don't think lintian will be able to catch that one.
> 
> Can't you add exceptions for some packages in the Lintian check?  The only
> packages in sid that use "slang" as an English word are ascii, jargon, and
> jargon-text.  Other packages that use "slang" or "SLang" mean actually the
> "S-Lang" library.
>

I gues SLang could safely be added, but adding some packages as exceptions would
mean changes to lintian every time a new packages (correctly) uses slang, which
would even mean that this should be done before some new package foo gets added
to the archive, otherwise people can't even upload lintian-clean packages...

If an slang check is introduced in lintian I'd rather opt for people overriding
this in their packages (following your reasoning that this concerns only very
few packages).

Best,
Michael



pgpzy5VtnHP5C.pgp
Description: PGP signature

Wrong Architecture for openhackware

[Roland Stigge]

reopen 339870
thanks

Hi,

Debian Bug Tracking System wrote:
>* Error out if the toolchain used to build is not powerpc-linux-gnu.
>  (Closes: #322300, #339870)

Again, I don't agree here (backed by p2): The package is wrong if it
asserts that it's "Architecture: all". It contains powerpc specific
stuff and can only be built on (i.e. for) that architecture. Therefore,
it should be "Architecture: powerpc".

Workarounds like an error on wrong toolchain architecture are wrong
(there is an error anyway if you try to build on !powerpc).

Thanks for considering.

Roland


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

Re: Correct spelling/capitalisation of project names

[Rafael Laboissiere]

* Michael Tautschnig <[EMAIL PROTECTED]> [2008-01-12 18:57]:

> I gues SLang could safely be added, but adding some packages as exceptions 
> would
> mean changes to lintian every time a new packages (correctly) uses slang, 
> which
> would even mean that this should be done before some new package foo gets 
> added
> to the archive, otherwise people can't even upload lintian-clean packages...
> 
> If an slang check is introduced in lintian I'd rather opt for people 
> overriding
> this in their packages (following your reasoning that this concerns only very
> few packages).

Okay, let us add to Lintian corrections just for SLang, S-lang, and s-lang.
I already filed bug reports against the six packages in sid using the wrong
spelling [1].

[1] http://bugs.debian.org/460443
http://bugs.debian.org/460444
http://bugs.debian.org/460445
http://bugs.debian.org/460446
http://bugs.debian.org/460447
http://bugs.debian.org/460448

-- 
Rafael


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

Re: Wrong Architecture for openhackware

[brian m. carlson]

On Sat, Jan 12, 2008 at 06:47:53PM +0100, Roland Stigge wrote:

Debian Bug Tracking System wrote:

   * Error out if the toolchain used to build is not powerpc-linux-gnu.
 (Closes: #322300, #339870)


Again, I don't agree here (backed by p2): The package is wrong if it
asserts that it's "Architecture: all". It contains powerpc specific
stuff and can only be built on (i.e. for) that architecture. Therefore,
it should be "Architecture: powerpc".

Workarounds like an error on wrong toolchain architecture are wrong
(there is an error anyway if you try to build on !powerpc).


openhackware is needed by qemu on all architectures for powerpc 
emulation.  It's not acceptable to make it Architecture: powerpc because 
that defeats the purpose.  I should be able to use qemu-ppc on any 
architecture, and for that I need openhackware.


p2's explanation fails because it assumes that openhackware belongs on 
the target system, which is not the case.  It needs to be installed on 
the host system; that is, the one that qemu-ppc is running on.  
I can't install the powerpc package unless I can boot the target system, 
which I can't do without the package.  The only system I could then 
install openhackware on would likely be one with Open Firmware already 
on it, which makes the package useless.


--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

electronics-menu REJECTED (discussion)

[Peter Clifton]

Hi,

Introduction and motivation:

I'm seeking some discussion regarding adding extra menus for specific
"niche" sub-categories of programs, such as Electronic design
applications, Hamradio etc..

There exists a hamradiomenus package which adds a "Ham Radio" menu, and
as a developer and user of Electronic CAD packages, would like to see a
similar "Electronics" menu. None of the main XDG menu categories
actually fit this sort of application, and the spec conflictingly says
not to list categories which aren't applicable, and that a package
should list one of the main categories.

In gEDA, the .desktop files list "Electronics" and "Engineering" (both
of which are sub-categories), and without an additional XML file
describing a new menu, these applications will appear under "Others"
under gnome, or lost+found under KDE.


My proposed package:

Description: Menu for Electronics applications
 This package crates an "Electronics" submenu with icon for GNOME, KDE
 and other XDG menu-spec compliant desktop environments.

dpkg-query -L electronics-menu (snipped non file output)

  /usr/share/icons/hicolor/48x48/categories/applications-electronics.png
  /usr/share/icons/hicolor/22x22/categories/applications-electronics.png
  /usr/share/icons/hicolor/24x24/categories/applications-electronics.png
  /usr/share/icons/hicolor/scalable/categories/applications-electronics.svg
  /usr/share/icons/hicolor/16x16/categories/applications-electronics.png
  /usr/share/doc/electronics-menu/copyright
  /usr/share/doc/electronics-menu/changelog.Debian.gz
  /usr/share/desktop-directories/Electronics.directory
  /etc/xdg/menus/applications-merged/electronics.menu


This is similar to the "hamradiomenus" package, although I'm shipping a
more complete theme set of sized icons, rather than a single pixmap.


The rejection:

Hi Maintainer,

rejected, for now, as I disagree with an own package just for two simple
files (plus some graphics).

Any reason why that doesnt go into menu? That would be the more logical
place for it, IMO.

-- 
bye Joerg


My reply:

There was precedent, in the "hamradiomenus" package upon which the idea
for this package was based. Since the "Electronics" category in .desktop
files is only officially a subcategory in the XDG menu specification,
the intention was that this package would be installed at the user's
preference. (Probably suggested by packages which provide .desktop files
falling into the "Electronics" category).

The "menu" package doesn't seem to be the right place for this, as
"menu" appears to deal specifically with the Debian menu system, not the
XDG menus.

The nearest correct packages appear to be "gnome-menus" and
"kdelibs-data" which provide the default Gnome and KDE menu files:

/etc/xdg/menus/applications.menu
/etc/xdg/menus/kde-applications.menu

It doesn't seem beneficial to duplicate the registration of the menu in
two packages, certainly as the installed icons would clash. Using either
of these would also stop it working with any other XDG desktops. (ROX?..
I don't know if that is Debian packaged or not).

This leads me to suspect that we do need it to be in some separate
package, even if it could be combined with others of a similar ilk.
Since the same "upstream" (me) sources for this menu and icons may be
used in different distributions, I'd make the case that a separate
package is appropriate here, since others may wish to use the same
shared data without dragging it out of a Debian specific package.


Joerg's reply:

"""
This sounds like some kind of xdg-extra-menus package providing menus
like the electronics and hamradio one. Not a single package for every
5kb menu package.
"""


I then sought advice from Joerg on IRC (a summary):

Ganneff: they are small, so disk space is not an issue. so maybe have a
way to let a user enable extra menus, in case he wants them.

pcjc2: I suspect in the cases of ham radio and electronics, the clashing
possibilities are low.. but if the user wanted to install an
"Engineering" menu then you'd get packages listed in both Electronics
and Engineering menus

Ganneff: if you provide a small app for that than the user could ven
chose on their own, not an admin for them.

Ganneff: you can have a app that symlinks menus into the users ~. iirc
there is a place within that ~ for own menu additions?

pcjc2: ~/.config/menus I think

Ganneff: and if not - it would be a script for the admin to
enable/disable the menus for the whole machine

Ganneff: so you install them all in /somewhere, admin runs script, that
symlinks the wanted menus to /wherever

Ganneff: that gives them only the menus they want and us not a trillion
of 5k packages. (which ftpteam *really* dislikes).

pcjc2: I'm basically an upstream on gEDA, PCB and gerbv, all of which
need an Electronics menu

pcjc2: We need collaboration with hamradiomenus and any others which
would be covered under this

(EDIT.. we are talking about two so far, not 1 trillion)

pcjc2: Are you going to delete hamradiomenus fro

Bug#460493: ITP: libfprint -- fingerprint library of fprint project

[Emfox Zhou]

Package: wnpp
Owner: Emfox Zhou <[EMAIL PROTECTED]>
Severity: wishlist

* Package name: libfprint
  Version : 0.0.5
  Upstream Author : 
* URL or Web page : http://reactivated.net/fprint/wiki/Libfprint
* License : LGPL 2.1
  Description : fingerprint library of fprint project

The fprint project aims to plug a gap in the Linux desktop: support for consumer
fingerprint reader devices.

Previously, Linux support for such devices has been scattered amongst different
projects (many incomplete) and inconsistent in that application developers would
have to implement support for each type of fingerprint reader separately. For
more information on where we came from, see the project history page.

We're trying to change that by providing a central system to support all the
fingerprint readers we can get our hands on. The software is open source and in
the long term we're shooting for adoption by distributions, integration into
common desktop environments, etc.



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

Bug#460495: ITP: pam-fprint -- PAM module allowing authentication via fprint

[Emfox Zhou]

Package: wnpp
Owner: Emfox Zhou <[EMAIL PROTECTED]>
Severity: wishlist

* Package name: pam-fprint
  Version : 0.2
  Upstream Author : 
* URL or Web page : http://reactivated.net/fprint/wiki/Pam_fprint
* License : 
  Description : PAM module allowing authentication via fprint

The fprint project aims to support for consumer fingerprint reader devices.

Previously, Linux support for such devices has been scattered amongst different
projects (many incomplete) and inconsistent in that application developers
would have to implement support for each type of fingerprint reader separately.
We're trying to change that by providing a central system to support all the
fingerprint readers we can get our hands on.

pam_fprint is a PAM module which uses libfprint's fingerprint verification
functionality to implement a fingerprint-based login system.



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