Re: Bug#330239: ITP: hibernate -- a powerful, ultra-high performance object/relational persistence and query service for Java

[Kalle Kivimaa]

martin f krafft <[EMAIL PROTECTED]> writes:
> libhibernate-java?

libhibernate-java is correct as per the Debian Java Packaging Policy.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


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

Re: ITP: g-wrap -- Scripting interface generator for C

[Thomas Bushnell BSG]

Andreas Rottmann <[EMAIL PROTECTED]> writes:

> [CC'ed Thomas Bushnell, since he has filed an ITA on gwrapguile]
>
> [EMAIL PROTECTED] writes:
>
>> Please, check the following bugs, rename or close them, however you prefer.
>>
>>
>>   1) #242467: ITA: gwrapguile -- Tool for exporting C libraries into...
>>
>>   2) #263127: O: gwrapguile -- g-wrap: Tool for exporting C...
>>
> I prefer to have them open until GnuCash is built against G-Wrap 1.9.3
> and the gwrapguile source package can be removed. 

I have, rather, taken over maintenance of the 1.3.4 gwrapguile package.

I am not interested in maintaining a gnucash linked or built with
guile-2 versions of things that are not supported by upstream.  (I am
correct, right, that the g-wrap to which you refer is a guile 2
thingie?)

gnucash is a guile-1 program.  Many people think that every package
should migrate to guile-2.  They are right.  The upstream gnucash
developers are working on this as fast as they can.

Thomas


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

Re: libpng10(/2) gone, [gdk-]imlib1 and GNOME 1 going -- check your packages

[Josselin Mouette]

Le mardi 27 septembre 2005 à 00:05 -0400, Nathanael Nerode a écrit :
> libpng2 and libpng10 are gone.
> 
> This has caused quite a lot of uninstallable packages which either need
> new uploads or removal (listed below).  In addition, imlib1 and gdk-imlib1
> exist solely for libpng10 support (imlib11 is essentially the same upstream
> for libpng12) and will presumably be removed.

> Is a mass bug filing warranted?  :-P

I've already filed bug reports asking to rebuild all these packages
against libpng12. The real issue is the imlib1 maintainer is orphaning
his packages and no one stepped up to maintain them.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: libpng10(/2) gone, [gdk-]imlib1 and GNOME 1 going -- check your packages

[Hamish Moffatt]

On Tue, Sep 27, 2005 at 12:05:32AM -0400, Nathanael Nerode wrote:
> Furthermore, the plan is to remove GNOME 1 entirely, as noted at:
> http://lists.debian.org/debian-gtk-gnome/2005/06/msg00025.html
> 
> If your package depends on one of these and you wish to keep it in Debian,
> please convert it to libpng12 and/or imblib11 and/or libimlib2 and/or
> GNOME 2, so that it not depend on any of the above.  :-P
> 
> If your package is a GNOME 1 package, please consider filing a bug with
> ftp.debian.org requesting the removal of your package from unstable.

What if it's a non-GNOME-core package that uses GNOME 1?
gnucash and gpredict, for example.

gpredict is still maintained upstream but the author has not migrated to
GNOME 2 yet. Of course if it were trivial or there was a good tutorial I
might be able to assist; however I don't know the GNOME/GTK API yet.

> Is a mass bug filing warranted?  :-P

Is this package removal warranted, or simply aesthetically pleasing?

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: libpng10(/2) gone, [gdk-]imlib1 and GNOME 1 going -- check your packages

[Thomas Bushnell BSG]

Hamish Moffatt <[EMAIL PROTECTED]> writes:

> On Tue, Sep 27, 2005 at 12:05:32AM -0400, Nathanael Nerode wrote:
>> Furthermore, the plan is to remove GNOME 1 entirely, as noted at:
>> http://lists.debian.org/debian-gtk-gnome/2005/06/msg00025.html
>> 
>> If your package depends on one of these and you wish to keep it in Debian,
>> please convert it to libpng12 and/or imblib11 and/or libimlib2 and/or
>> GNOME 2, so that it not depend on any of the above.  :-P
>> 
>> If your package is a GNOME 1 package, please consider filing a bug with
>> ftp.debian.org requesting the removal of your package from unstable.
>
> What if it's a non-GNOME-core package that uses GNOME 1?
> gnucash and gpredict, for example.
>
> gpredict is still maintained upstream but the author has not migrated to
> GNOME 2 yet. Of course if it were trivial or there was a good tutorial I
> might be able to assist; however I don't know the GNOME/GTK API yet.
>
>> Is a mass bug filing warranted?  :-P
>
> Is this package removal warranted, or simply aesthetically pleasing?

There is no need to remove gnome-1 packages at this point, since
gnucash (which I maintain) still need them.

If there are bugs, or maintainers actually needed, I'm happy to put my
name on.  But so far, that hasn't required any actual work.

Do not delete packages just because you think nobody *should* use
them; delete them because nobody *does* use them.  Right now, the
gnome-1 packages are still used.

Thomas


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

GNOME 1 discussion continues in d-g-g

[Loïc Minier]

On Tue, Sep 27, 2005, Nathanael Nerode wrote:
> Furthermore, the plan is to remove GNOME 1 entirely

 (debian-devel readers: this discussion is more on topic on
 debian-gtk-gnome, and is continuing there.)

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


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

Re: libpng10(/2) gone, [gdk-]imlib1 and GNOME 1 going -- check your packages

[Andreas Tille]

On Tue, 27 Sep 2005, Thomas Bushnell BSG wrote:


Do not delete packages just because you think nobody *should* use
them; delete them because nobody *does* use them.  Right now, the
gnome-1 packages are still used.


... same for imlib1 which is used as well.

Kind regards

Andreas.

--
http://fam-tille.de


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

Re: GNOME 1 discussion continues in d-g-g

[Thomas Bushnell BSG]

Loïc Minier <[EMAIL PROTECTED]> writes:

> On Tue, Sep 27, 2005, Nathanael Nerode wrote:
>> Furthermore, the plan is to remove GNOME 1 entirely
>
>  (debian-devel readers: this discussion is more on topic on
>  debian-gtk-gnome, and is continuing there.)

The gnome-1 libraries are in use by other Debian packages.

Anyone who does not want to maintain a package should orphan the damn
thing.  It seems that it is only the gnome maintainers who do not
understand this simple principle.  Do not declare what other people
can or should maintain, simply orphan it.  There is no shame in doing
so.  We know how to deal with orphaned packages.  Do not declare that
nobody could or should maintain it.  If you don't want to, then
don't.  Orphan the damn thing if you don't want to maintain it.

Thomas

Re: wiki.debian.net?

[Holger Levsen]

Hi,

On Monday 26 September 2005 23:39, Peter Samuelson wrote:
> Don't know why, but the content is supposed to be moving to
> wiki.debian.org real soon now.

For moving the contents help is still needed (perl skills prefered), please 
see http://wiki.debian.org/MigrationStatus 


regards,
Holger


pgpEmKqsw8pOt.pgp
Description: PGP signature

Re: GNOME 1 discussion continues in d-g-g

[Loïc Minier]

Hi,

On Tue, Sep 27, 2005, Thomas Bushnell BSG wrote:
> Anyone who does not want to maintain a package should orphan the damn
> thing.  It seems that it is only the gnome maintainers who do not
> understand this simple principle.  Do not declare what other people
> can or should maintain, simply orphan it.  There is no shame in doing
> so.  We know how to deal with orphaned packages.  Do not declare that
> nobody could or should maintain it.  If you don't want to, then
> don't.  Orphan the damn thing if you don't want to maintain it.

 You're either quoting the wrong person, or the wrong message.  I
 simply said the discussion continues on [EMAIL PROTECTED]

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


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

Re: editing library's soname (was Re: Fixed in upload of curl 7.14.1-1 to experimental)

[Domenico Andreoli]

On Sat, Sep 24, 2005 at 11:39:28AM -0400, Daniel Jacobowitz wrote:
> On Sat, Sep 24, 2005 at 04:52:31PM +0200, Domenico Andreoli wrote:
> > yes, i'm aware of this. it is due to the libcurl-gnutls.so.3 soname
> > still being libcurl.so.3. everything else is in place for a good upload.
> > 
> > as of today, i've not found a solution different from patching the
> > makefiles. i'd like a tool to modify this kind of things in the elf,
> > probably elfsh is what i'm looking for. something to run after the
> > build process. any idea?
> 
> In general you can't do this unless you're replacing it with a shorter
> soname.  I highly recommend fixing the build system instead.

the build system is automake+libtool. fixing it means telling to libtool
which soname is to be used. ah.. libtool... i hate clever software..

the only way i know to achieve this is to modify the lib_LTLIBRARIES
variable and releated. am i missing anything?

cheers
domenico

-[ Domenico Andreoli, aka cavok
 --[ http://people.debian.org/~cavok/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50


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

Bug#330298: ITP: php-benchmark -- PEAR framework to benchmark PHP scripts or function calls

[Piotr Roszatycki]

Package: wnpp
Severity: wishlist
Owner: Piotr Roszatycki <[EMAIL PROTECTED]>

* Package name: php-benchmark
  Version : 1.2.3
* URL : http://pear.php.net/package/Benchmark/
* License : PHP License
  Description : PEAR framework to benchmark PHP scripts or function calls

This small library provides the PHP class to benchmark PHP scripts or
function calls and it is used by more complex tools like i.e. PHPUnit2.


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

Bug#330301: ITP: php-phpunit2 -- PEAR Regression testing framework for unit tests

[Piotr Roszatycki]

Package: wnpp
Severity: wishlist
Owner: Piotr Roszatycki <[EMAIL PROTECTED]>

* Package name: php-phpunit2
  Version : 2.2.1
* URL : http://pear.php.net/package/PHPUnit2/
* License : PHP License
  Description : PEAR Regression testing framework for unit tests

PHPUnit is a regression testing framework used by the developer who
implements unit tests in PHP.

The PHPUnit is utilised by Phing and calling the test case can be one of
the Phing's targets.


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

Re: GNOME 1 discussion continues in d-g-g

[Thomas Bushnell BSG]

Loïc Minier <[EMAIL PROTECTED]> writes:

> On Tue, Sep 27, 2005, Thomas Bushnell BSG wrote:
>> Anyone who does not want to maintain a package should orphan the damn
>> thing.  It seems that it is only the gnome maintainers who do not
>> understand this simple principle.  Do not declare what other people
>> can or should maintain, simply orphan it.  There is no shame in doing
>> so.  We know how to deal with orphaned packages.  Do not declare that
>> nobody could or should maintain it.  If you don't want to, then
>> don't.  Orphan the damn thing if you don't want to maintain it.
>
>  You're either quoting the wrong person, or the wrong message.  I
>  simply said the discussion continues on [EMAIL PROTECTED]

And I'm saying that this is not sufficient, it needs to be here, on
debian-devel, since it concerns more than just packages maintained by
the debian-gtk-gnome team.

Re: GNOME 1 discussion continues in d-g-g

[Lars Wirzenius]

ti, 2005-09-27 kello 05:14 -0700, Thomas Bushnell BSG kirjoitti:
> And I'm saying that this is not sufficient, it needs to be here, on
> debian-devel, since it concerns more than just packages maintained by
> the debian-gtk-gnome team.

>From http://lists.debian.org/debian-gtk-gnome/:

Packages using GTK+ and/or GNOME

Discussion and coordination among maintainers of Debian's GTK+,
GNOME and dependent or related packages.

It seems to me that the debian-gtk-gnome list is *exactly* the right one
for discussion about removal of GNOME 1. Burdening the general list with
discussions that are on-topic for the more specific list and irrelevant
to most readers seems to me to be suboptimal.

(Ideally, of course, if any decisions are made on the debian-gtk-gnome
list, they will be announced on debian-devel-announce so that everyone
is aware of them.)


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

Bug#330302: ITP: sysconftool -- development tool to install and update configuration files

[Willi Mann]

Package: wnpp
Severity: wishlist
Owner: Willi Mann <[EMAIL PROTECTED]>

* Package name: sysconftool
  Version : 0.15
  Upstream Author : Sam Varshavchik <[EMAIL PROTECTED]>
* URL : http://www.courier-mta.org/sysconftool/
* License : GPL
  Description : development tool to install and update configuration files

sysconftool is a development utility that helps to install application
configuration files. sysconftool allows an existing application to be
upgraded without losing the older version's configuration settings, but
that's the advantage over plain dpkg upgrading, will add new
configuration settings (and remove unneeded). 


The reasons why I want to package it:
- I want to work with Stefan Hornburg (Racke) on a smoother upgrading
  strategy for courier* packages. (The idea was born in bug 233873)
- It's needed if someone wants to build courier from CVS


-- System Information:
Debian Release: testing/unstable
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: mass bug filing on packages that are blocking use of cdebconf

[Luigi Gangitano]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Il giorno 26/set/05, alle ore 19:57, Joey Hess ha scritto:

Luigi Gangitano <[EMAIL PROTECTED]>
   libapache-mod-acct


Fixed yesterday in 0.5-19.

Regards,

- --
Luigi Gangitano -- <[EMAIL PROTECTED]> -- <[EMAIL PROTECTED]>
GPG: 1024D/924C0C26: 12F8 9C03 89D3 DB4A 9972  C24A F19B A618 924C 0C26


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFDOT0D8ZumGJJMDCYRAgEiAJ43qv5GAz1Mnm4ZwNoi9OEUeAcr6gCcCD8f
vNbZEEtvZrMZ09UCaKnkGTc=
=bo+J
-END PGP SIGNATURE-


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

renaming mysql++

[Andres Salomon]

Hi,

I intend to rename the binary packages for mysql++ with the upload of 2.0.5.
They've been called libsqlplus* for a while now, which isn't overly
intuitive (I've had multiple people not realize mysql++ was packaged for
debian, due to the name).  My choices are either libmysqlpp* (to match
the library name) or libmysql++*.  Does anyone have any preferences, or 
any reasons why I shouldn't use ++ in the package name?  Given that g++
does it, and policy explicitly allows '+', I can't think of any reasons
not to name it libmysql++*.


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

Re: slgdbm_1.6-2_i386.changes is NEW

[Rafael Laboissiere]

[Moving this discussion to debian-devel.  The context is the recent upload
of the slgdbm package, which is the fisrt package in Debian to provide an
SLang2 module.  Please, keep Cc: to [EMAIL PROTECTED]

* G. Milde <[EMAIL PROTECTED]> [2005-09-27 08:19]:

> On 26.09.05, Paul Boekholt wrote:
> 
> > I should have brought this up sooner, but isn't slfoo too shortish
> > for a debian package name?  The perl policy says:
> ...
> >  naming convention for module Foo::Bar is libfoo-bar-perl.
> > 
> > The Python naming scheme seems to be python-foo.
> 
> I vote vor slang-foo. (Not only because I like python more than perl, but
> because this way slang modules will appear close to slang in an alphabetical
> listing (e.g. in aptitude or `ls /usr/share/doc/`).

There is no policy in Debian regarding packages which provide SLang2
modules.  Maybe we should write a draft and put it in one of the slang2
packages?  Alastair, what do you think?

-- 
Rafael


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

como ganar dinero en internet

[comerciomerida]

hi,
I recently opened my web site www.comerciomerida.com and I want to earn some money from the net. I would like to be part of your project.
My name is Juan Pablo Merida and my phone is 502-52073145, i÷m from Guatemala city Central America

Re: Patch²: Maintaining a patch for a debian package

[Jesús M. Navarro]

Hi, Sylvain:

El Viernes, 16 Septiembre 2005 16:12, Sylvain Beucler escribió:
> Hello,
>
> I have a couple Debian packages that I need to patch with custom local
> changes. The patches are small and I hence can follow the security
> updates from the security team.
>
> However, I wonder if there's already a way to automatically manage
> such kind of packages.

[...] 

Now, just for the record, I'll expand on what I think should have to be "the 
proper way", so someone else could explain best practices or suggest what can 
be done.

We all know there are "source" and "binary" distributions, and more or less we 
are aware of the benefits and problems about both of them.  Now comes what I 
think it is quite a usual scenario:

I want a binary distribution since it makes easier to me (the end user) to 
maintain my box and, at the same time, I can be more confident about the 
stability of the resultset, since those same binaries are installed on about 
a tonn of different computers.

Now, it tend to happen that on any given computer I want/need just a few 
packages to be built from sources, because some patches I should apply, some 
changes I need to introduce, compiling options... whatever.

I, of course, can grab the tarballs from the upside developer and compile them 
locally, but then I cannot benefit from the advantages of having all software 
under the package manager control.

I can, then, download the source packages from my distribution, expand, patch, 
modify... and then install my new local package (the situation of the parent 
poster) but...

1) I may leave all metadata as it came from the source package, but then, the 
package manager will "upgrade" it next time a new version is available, thus 
loosing my modifications.
2) I may change metadata for my package (either its name, its upstream 
version, its build version, or whatever), but then, when a new version is 
available from repositories (ie: a new security upgrade) I won't be aware of 
this, since for the package manager they will be either in different "package 
branches" or current installed version will be higher than that from the 
repos, or I'll be on situation 1) if my local package happens to have lesser 
precedence than the one from the public repo.

So, I think I want a mixed source/binary packager manager.

An example:

Current OS version on my computer is Sarge.  Let's imagine I patched and 
recompiled Postfix (this is an interesting package since it builds half a 
dozen different packages from a single source package).

Currently Sarge holds Postfix 2.1.5-9.

Now, let's imagine a new security fix for Postfix is produced (it should be, I 
think, Postfix 2.1.5-9sarge1)

I would want something like this:
# apt-get update
# apt-get dist-upgrade
(...)
Packages foo, bar (...) Postfix are going to be upgraded.
(...)
Postfix was locally build from sources.  Do you want to
(H)old your current version?
(U)pgrade from Sarge repositories?
Try to (M)erge changes and rebuild? (h|u|M)?

Then, I choose "M" and apt downloads new sources, tries to merge upstream and 
local changes (offering the option to manually manage the merge if needed), 
builds and installs.

By the day Etch becomes stable, my patch has been added to Etch's Postfix 
version, so there's no further need for me to maintain my own package. Then 
it should be able for me to "mark" it and abandon (maybe, by choosing the "U" 
option when upgrading).

Now, what's the way to achieve what I propose, if possible, or what should 
have to be done in order to get to this in the future?
-- 
SALUD,
Jesús

Re: Easy third-party package installer for debian-based distributions

[Jesús M. Navarro]

Hi, Sami:

El Domingo, 18 Septiembre 2005 23:22, Sami Dalouche escribió:
> OK, may be an overkill.
> But what happens with your solution if skype depends on libskype, which is
> not available from debian's repository ?The user has to download several
> .debs in order to install a single software ?

There's a current functional solution: it is not giving Joe Average a Deb 
package, but a new deb line for her /etc/apt/sources.list file.  After that, 
installing Skype is just a matter of the user typing apt-get install skype 
(or double-clicking using her apt GUI of choice).

Only other requirement is for (in this case) Skype developers to know how to 
deploy a deb repository.
-- 
SALUD,
Jesús

Re: mass bug filing on packages that are blocking use of cdebconf

[Gerfried Fuchs]

* Joey Hess <[EMAIL PROTECTED]> [2005-09-26 19:57]:
> Joey Hess wrote:
>> Just a reminder that these maintainers still have packages that depend
>> on debconf by itself without an alternate dependency on | debconf-2.0.
>> As I mentioned in my original post, I plan to file bugs on all of these
>> soon, which, omitting all the lg-issue* packages, comes to about 550
>> bugs.
> (Original post here:
> http://lists.debian.org/debian-devel/2005/08/msg00136.html)
> 
> This is your third and final reminder. I count 542 packages remaining,
> down only 9 from last month. I assume most of the people below do not
> read debian-devel, so I've taken the librerty of BCCing you all. :-P

 I wonder why you didn't sent it to debian-devel-announce then? This is
where this really belongs, not? This is what the list is for, not?

 So long,
Alfie [doing his updates]
P.S.: Yes, you are right. I ceaced to read debian-devel for quite a
  while due to the sheer mass of noise ratio. So Cc: me on replies
  that you think might be interesting to me, too. Honor the
  Mail-Followup-To: header.
-- 
 ZZcd ..
 oops
-- #jutesack


signature.asc
Description: Digital signature

Bug#330342: ITP: aptsh -- apt interactive shell

[Marcin Wrochniak]

Package: wnpp
Severity: wishlist


* Package name: aptsh
  Version : 0.0.4
  Upstream Author : Marcin Wrochniak <[EMAIL PROTECTED]>
* URL : http://aptsh.berlios.de
* License : GPL
  Description : apt interactive shell

 Aptsh helps in managing packages by providing nice pseudo-shell,
 with commands completion and simplified access to Apt's commands.
 Additional features, like command-queue and orphaned packages
 searcher are also included.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.10-5-386
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)


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

Re: Patch² : Maintaining a patch for a debian package

[Sylvain Beucler]

On Mon, Sep 26, 2005 at 12:15:11AM +1000, Paul TBBle Hampson wrote:
> On Sat, Sep 24, 2005 at 11:19:30PM +0200, Sylvain Beucler wrote:
> > On Sat, Sep 24, 2005 at 12:39:14AM +1000, Paul TBBle Hampson wrote:
> >> On Fri, Sep 23, 2005 at 03:10:34PM +0200, Sylvain Beucler wrote:
> > > >>> I got an issue though, but I think it is related to glibc itself:
> > > >>> after installing the built source packages, aptitude/apt-get
> > > >>> absolutely want to upgrade them with the binary versions:
> > >  The following packages will be upgraded:
> > >    libc6 libc6-dbg libc6-dev libc6-prof
> 
> > > >>> Is this normal?
> 
> > >>> It is if you've not updated the changelog to be a new version, as
> > >>> apt-get will prioritise remote versions of a package over currently
> > >>> installed versions, if the metadata differs (as it will when you
> > >>> rebuild a package locally)
> 
> > Curiously this doesn't seem to happen for all packages. libc6 and
> > dtach, for example, will be replaced; mutt and dpatch won't (for stable).
> 
> That is weird. Check apt-cache policy for those packages, and see what
> it says. My understanding is that it should happen for any package,
> as locally install packages have priority 100, and nothing else gets a
> lower priority by default.

Let's see :)


dmc:~# aptitude upgrade
[...]
The following packages will be upgraded:
  dtach


dmc:~# apt-cache policy libc6 # +0.1 trick
libc6:
  Installed: 2.3.2.ds1-22.1
  Candidate: 2.3.2.ds1-22.1
  Version Table:
 *** 2.3.2.ds1-22.1 0
100 /var/lib/dpkg/status
 2.3.2.ds1-22 0
500 http://ftp.fr.debian.org sarge/main Packages

dmc:~# apt-cache policy dtach # apt wants to replace it
dtach:
  Installed: 0.7-1
  Candidate: 0.7-1
  Version Table:
 0.7-1 0
500 http://ftp.fr.debian.org sarge/main Packages
 *** 0.7-1 0
100 /var/lib/dpkg/status

dmc:~# apt-cache policy mutt # apt says nothing for those
mutt:
  Installed: 1.5.9-2
  Candidate: 1.5.9-2
  Version Table:
 *** 1.5.9-2 0
500 http://ftp.fr.debian.org sarge/main Packages
100 /var/lib/dpkg/status
dmc:~# apt-cache policy dpatch
dpatch:
  Installed: 2.0.10
  Candidate: 2.0.10
  Version Table:
 *** 2.0.10 0
500 http://ftp.fr.debian.org sarge/main Packages
100 /var/lib/dpkg/status

Apparently apt considers mutt and dpatch to be equivalent to the
remote versions, which is after what I want.

Any clue? :/


> > >> Is there a way to automatically update a locally modified package, or
> > >> can't we avoid a manual processing?
> 
> >> You could use dch -i to increment the version, or dch -n to increment
> >> the NMU version.
> 
> >> You could hack dch to have a --local-build switch, which increments the
> >> Debian version by 0.0.0.1 and will therefore be greater than the source
> >> you built, and less than a bin-NMU of the package. And then send the
> >> patch as a wishlist bug to devscripts. I think it'd be generally useful,
> >> to be honest.
> 
> > Some other tricky stuff happens when multiple binary packages are
> > built from a single source one - the versions in the binary packages
> > dependencies may need to be resynchronized (eg libc6-i686 Depends on
> > the same version of libc6).
> 
> Where this happens, I hope they're using the various macros provided for
> that sort of thing (${Source-Version} etc) so updating the changelog
> file is all that's neccessary. Nothing I'm rebuilding has shown any
> issues for .0.0.1 increments in the version. (Mind you, I'm not
> rebuilding anything libc. I like my system to keep running. ^_^)

Hmmm:
Package: libc6-i686
Pre-Depends: libc6 (= ${Source-Version})

Well I guess I missed something. Maybe apt-src tried to install the
built packages one by one... I have to retry and build (sigh :))

(Note that I want my system running as well, it's just that
sysconf(SC_NGROUPS_MAX) returns 32 instead of 65536 and I need that
fixed :))

> > Changing the local version seems to trigger several issues. Maybe
> > there's a way to make local packages more prioritary than remote ones?
> 
> You could prolly put an apt-preferences entry so that packages from
> /var/lib/dpkg/status
> get a higher priority than 100, but that strikes me as a disaster
> waiting to happen, although I can't actually explain why.
> 
> Frankly, I just maintain a directory in my home directory called
> LocalDeb and build everything in that by hand. (Now using pbuilder-uml
> so I can trim the number of -dev packages floating around my system.)

Yeah, I guess if dpkg/status has a default low priority, there must be
reasons :)

Thanks,

-- 
Sylvain


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

What does this mean?

[Michael S. Peek]

Hello all,

I'm struggling to wrap my feeble intelect around the debian installation
scripts, so I thought I would take a gander at the scripts in
/var/lib/dpkg/info/ and see how other people handle things.  I've come accross
several statements that I don't understand, and that aren't documented
anywhere that I can find.

dpkg --assert-support-predepends
dpkg --assert-working-epoch

The only thing I can find about these options are from dpkg --help:

For internal use: dpkg --assert-support-predepends | --predep-package |
  --assert-working-epoch | --assert-long-filenames | --assert-multi-conrep

What do these mean?

Thanks for your help,

Michael Peek


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

Re: What does this mean?

[Simon Richter]

Hi,

Michael S. Peek wrote:


dpkg --assert-support-predepends
dpkg --assert-working-epoch


These are simple do-nothing options, but older dpkg will fail if it 
doesn't know them, so if a feature isn't present, dpkg will not start.


   Simon


signature.asc
Description: OpenPGP digital signature

Bug#330355: ITP: libmms -- MMS stream protocol library

[Loïc Minier]

Package: wnpp
Severity: wishlist
Owner: Loic Minier <[EMAIL PROTECTED]>

Hi,

* Package name: libmms
  Version : 0.1
  Current developers:
Maciej Katafiasz (Mathrick) <[EMAIL PROTECTED]>
SÃren Hansen (shawarma) <[EMAIL PROTECTED]>
  Original implementation:
Major MMS 
  Other authors   : the Xine project 
* URL : 
* License : LGPL
  Description : MMS stream protocol library

 libmms is a library implementing the mms streaming protocol


 This package was pulled from Ubuntu's archive, eg. at:

 It was debianized by SÞren Hansen <[EMAIL PROTECTED]>.


 The upstream description of the library:
 "LibMMS aims to be common mms:// and mmsh:// (Microsoft streaming
 protocols) parsing library, licensed on LGPL, and thus usable by many
 projects that don't use GPL."


 To my knowledge, there's no problem preventing inclusion of this
 library in main.  GStreamer plugins has a MMS plugin which will
 build-depend on this library to play mms:// and mmsh:// streams from
 eg. totem.

   Bye,

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

Bug#330357: ITP: aspell-hi -- Aspell wordlist for Hindi

[Soumyadip Modak]

Package: wnpp
Severity: wishlist


* Package name: aspell-hi
  Version : 0.01
  Upstream Author : Swapnil Hajare  <[EMAIL PROTECTED]>
* URL : ftp://ftp.gnu.org/gnu/aspell/dict/
* License : GPL
  Description : Aspell wordlist for Hindi

Hindi language wordlist for GNU Aspell

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.10-5-k7
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8)


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

Bug#330358: ITP: aspell-mr -- Aspell Marathi wordlist

[Soumyadip Modak]

Package: wnpp
Severity: wishlist


* Package name: aspell-mr
  Version : 0.10
  Upstream Author : Swapnil Hajare <[EMAIL PROTECTED]>
* URL : ftp://ftp.gnu.org/gnu/aspell/dict/
* License : GPL
  Description : Aspell Marathi wordlist

Marathi language wordlist for GNU Aspell

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.10-5-k7
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8)


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

Bug#330359: ITP: aspell-or -- Aspell Oriya wordlist

[Soumyadip Modak]

Package: wnpp
Severity: wishlist


* Package name: aspell-or
  Version : 0.03
  Upstream Author : Gora Mohanty <[EMAIL PROTECTED]>
* URL : ftp://ftp.gnu.org/gnu/aspell/dict/
* License : GPL
  Description : Aspell Oriya wordlist

Oriya language wordlist for GNU Aspell

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.10-5-k7
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8)


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

Bug#330360: ITP: aspell-pa -- Aspell Wordlist for Punjabi

[Soumyadip Modak]

Package: wnpp
Severity: wishlist


* Package name: aspell-pa
  Version : 0.01
  Upstream Author : Amanpreet Singh Alam <[EMAIL PROTECTED]>
* URL : ftp://ftp.gnu.org/gnu/aspell/dict/
* License : GPL
  Description : Aspell Wordlist for Punjabi

Punjabi language wordlist for GNU Aspell

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.10-5-k7
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8)


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

Bug#330361: ITP: aspell-ta -- Aspell wordlist for Tamil

[Soumyadip Modak]

Package: wnpp
Severity: wishlist


* Package name: aspell-ta
  Version : 0.01
  Upstream Author : http://developer.thamizha.com/spellchecker
* URL : ftp://ftp.gnu.org/gnu/aspell/dict/
* License : GPL
  Description : Aspell wordlist for Tamil

Tamil language wordlist for GNU Aspell

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.10-5-k7
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8)


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

Bug#330367: ITP: w3chess -- web and mail based chess board

[David Moreno Garza]

Package: wnpp
Severity: wishlist
Owner: David Moreno Garza <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: w3chess
  Version : 0.8.2
  Upstream Author : Sirtobi
* URL : http://w3chess.sf.net/
* License : GPL
  Description : web and mail based chess board

Web- and email-based chess system. You make your move in
your Web browser, and get the latest move of your opponent 
via email.

- -- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-386
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDOZYxmBxf18ZxJX0RAsbgAKC/Qv9eXxOTSwbFJhB/al1UpjTq6QCgiaTm
t+EHvKdDAlucMPT9MbPH/64=
=wZEh
-END PGP SIGNATURE-


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

Re: slgdbm_1.6-2_i386.changes is NEW

[Alastair McKinstry]

Rafael Laboissiere wrote:


[Moving this discussion to debian-devel.  The context is the recent upload
of the slgdbm package, which is the fisrt package in Debian to provide an
SLang2 module.  Please, keep Cc: to [EMAIL PROTECTED]

* G. Milde <[EMAIL PROTECTED]> [2005-09-27 08:19]:

 


On 26.09.05, Paul Boekholt wrote:

   


I should have brought this up sooner, but isn't slfoo too shortish
for a debian package name?  The perl policy says:
 


...
   


naming convention for module Foo::Bar is libfoo-bar-perl.

The Python naming scheme seems to be python-foo.
 


I vote vor slang-foo. (Not only because I like python more than perl, but
because this way slang modules will appear close to slang in an alphabetical
listing (e.g. in aptitude or `ls /usr/share/doc/`).
   



There is no policy in Debian regarding packages which provide SLang2
modules.  Maybe we should write a draft and put it in one of the slang2
packages?  Alastair, what do you think?

 


My preference is for slang-foo, as it is more visible that it is
a slang-related, rather than a generic DSO; slang-gdbm is more 
interesting to a slang developer than to a gdbm one, and this shows that.


It appears php and common lisp, follow the $lang-foo naming scheme,
with ruby going the perl direction.

I can write up a short policy specifying it and include it in the next copy
of slang2. Please CC: me on any relevant comments.

Regards
Alastair



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

Re: slgdbm_1.6-2_i386.changes is NEW

[Rafael Laboissiere]

* Alastair McKinstry <[EMAIL PROTECTED]> [2005-09-27 21:16]:

> My preference is for slang-foo, as it is more visible that it is
> a slang-related, rather than a generic DSO; slang-gdbm is more 
> interesting to a slang developer than to a gdbm one, and this shows that.

Thanks for the advice.  I will change the name of the package in the next
upload.  I hope the ftp-master folks won't get mad on me...

> I can write up a short policy specifying it and include it in the next
> copy of slang2. Please CC: me on any relevant comments.

I would keep the first version really short.  The only two things that
are important for now is the package naming, the installation directory
for the modules, and maybe the dependency relationships.  The upstream
Makefile for slgdbm installs the module in
/usr/share/slsh/local-packages, but I moved it to /usr/share/slsh.  Do
you think this is correct?  As regards dependency relationships, slgdbm
has:

Suggests: slsh (>= 2.0) | jed (>= 0.99.17) | slrn (>= 0.9.8.1pl1-4)

I do not know whether this is appropriate or not.

-- 
Rafael


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

Re: hotplug blacklists

[Eldon Koyle]

On  Sep 19 18:25+0200, Marco d'Itri wrote:
> On Sep 19, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:



> It's arguable how much drivers blacklisting is critical.

  I've had a fair amount of trouble with hotplug loading modules that
cause a kernel panic (esp. on laptops).  In this case, what would you
recommend as a replacement for blacklisting?

> It's uncommon for users to do it, and as long as they read the
> NEWS.Debian email before rebooting nothing bad will happen anyway.

  How many people really read those, anyway? ;)

--
Eldon Koyle

-- 
Our swords shall play the orators for us.
-- Christopher Marlowe


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

Re: hotplug blacklists

[Marco d'Itri]

On Sep 27, Eldon Koyle <[EMAIL PROTECTED]> wrote:

>   I've had a fair amount of trouble with hotplug loading modules that
> cause a kernel panic (esp. on laptops).  In this case, what would you
> recommend as a replacement for blacklisting?
module-init-tools blacklisting.
Anyway, I implemented support for /etc/hotplug/blacklist.d/ in modprobe,
and in one or two days I will upload the new udev which fully replaces
hotplug.

> > It's uncommon for users to do it, and as long as they read the
> > NEWS.Debian email before rebooting nothing bad will happen anyway.
>   How many people really read those, anyway? ;)
Everybody who has apt-listchanges installed, for a start.
And if they don't, too bad for them.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Accepted grep 2.5.1.ds2-1 (source i386 sparc)

[Nicolas François]

Hello,

On Tue, Sep 27, 2005 at 11:12:07AM +1000, Aníbal Monsalve Salazar wrote:
> On Mon, Sep 26, 2005 at 08:04:24PM +0200, Adeodato Simó wrote:
> >found 181378 2.5.1.ds2-1
> >thanks
> >
> >* Anibal Monsalve Salazar [Mon, 26 Sep 2005 05:47:06 -0700]:
> >
> >>   * Removed 64-egf-speedup.patch, 65-dfa-optional.patch,
> >> 66-match_icase.patch and 67-w.patch from debian/patches,
> >> closes: #329876.
> >
> >  Those patches fixed a bug (and two merged) that had been opened for 2
> >  and a half years. I think it'd be useful if you tried to contact the
> >  authors of the patches, and try to fix them instead of removing them?
> 
> Sure, the grep maintainers decided to pull out them and will go
> trough the patches again.


I wondered if I introduced this issue while porting the Fedora patches to
Debian, so I tried Fedora's grep...which has the same issue.

You can reproduce it with this simple command:
echo foobar | grep -Fw ""

This was introduced by the patch I named '64-egf-speedup.patch'

You can fix it by changing the 'while (1)' by 'while (len)' (or by
embedding this while loop in a 'if (len){...}', I don't know if there is a
real difference, and what is the best way).
Tim Waugh, who wrote the original patches, may have a better understanding
of the grep's code.

The testsuite still pass with this patch.


BTW, I don't know if you received a mail I sent to [EMAIL PROTECTED],
which indicated that the additional patches (which I submitted because
they helped passing the testsuite) were fixing: #209194 #218873 #226397
#238167

If you plan to re-introduce these patches, please tell me. While checking
for this issue (#329876), I've seen that there was one issue fixed in a
Fedora update, related to this patch:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161700
I can update 64-egf-speedup.patch if you want.

Kind Regards,
-- 
Nekral


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

Re: Accepted grep 2.5.1.ds2-1 (source i386 sparc)

[Aníbal Monsalve Salazar]

On Tue, Sep 27, 2005 at 11:53:41PM +0200, Nicolas François wrote:
>On Tue, Sep 27, 2005 at 11:12:07AM +1000, Aníbal Monsalve Salazar wrote:
>>On Mon, Sep 26, 2005 at 08:04:24PM +0200, Adeodato Simó wrote:
>>>* Anibal Monsalve Salazar [Mon, 26 Sep 2005 05:47:06 -0700]:
>>>
   * Removed 64-egf-speedup.patch, 65-dfa-optional.patch,
 66-match_icase.patch and 67-w.patch from debian/patches,
 closes: #329876.
>>>
>>>  Those patches fixed a bug (and two merged) that had been opened for 2
>>>  and a half years. I think it'd be useful if you tried to contact the
>>>  authors of the patches, and try to fix them instead of removing them?
>>
>>Sure, the grep maintainers decided to pull them out and will go
>>trough the patches again.
>
>I wondered if I introduced this issue while porting the Fedora patches to
>Debian, so I tried Fedora's grep...which has the same issue.
>
>You can reproduce it with this simple command:
>echo foobar | grep -Fw ""
>
>This was introduced by the patch I named '64-egf-speedup.patch'
>
>You can fix it by changing the 'while (1)' by 'while (len)' (or by
>embedding this while loop in a 'if (len){...}', I don't know if there is a
>real difference, and what is the best way).
>Tim Waugh, who wrote the original patches, may have a better understanding
>of the grep's code.
>
>The testsuite still pass with this patch.
>
>BTW, I don't know if you received a mail I sent to [EMAIL PROTECTED],
>which indicated that the additional patches (which I submitted because
>they helped passing the testsuite) were fixing: #209194 #218873 #226397
>#238167

I received it, thanks. I'll close the bugs.

>If you plan to re-introduce these patches, please tell me. While checking
>for this issue (#329876), I've seen that there was one issue fixed in a
>Fedora update, related to this patch:
>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161700
>I can update 64-egf-speedup.patch if you want.

Yes, please. I would like to reapply 64-egf-speedup.patch
(and 6[567]-*.patch) and an updated version will be very much
appreciated.

>Kind Regards,
>-- 
>Nekral

Regards,

Aníbal Monsalve Salazar
--
 .''`. Debian GNU/Linux
: :' : Free Operating System
`. `'  http://debian.org/
  `-   http://v7w.com/anibal


signature.asc
Description: Digital signature

ATTN openofficeorg developers

[Martin]

ATTN  developers of openoffice org (and gnumeric)
Hi
I was succesfully running openoffice org  on a testing debian running 
KDE.  
Last 
week after recent security and library updates openoffice org on testing is 
busted.  

(fortunately I have another machine running debian stable KDE.  openoffice  
still 
runs ok there. That machine was also updated with the lastest *.debs)

I know you want to scold me because this is not a formal bug report.  I 
find 
that form overwhelming.  BUT I certainly want to help move testing to stable 
SO if developer(s) ask me specific questions I will do my best to answer.  

Last week I reported a problem with gnumeric on kde on testing.  Are 
these 
problems related?

Regards 
Martin


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

Re: libpng10(/2) gone, [gdk-]imlib1 and GNOME 1 going -- check yourpackages

[Nathanael Nerode]

Thomas Bushnell wrote:
>Do not delete packages just because you think nobody *should* use
>them; delete them because nobody *does* use them.
I am suggesting deleting them because nobody *can* use them.

Unless libpng10 is  brought back, none of these packages are usable.  Are you 
volunteering to package and maintain libpng10?  If so, good for you!  If not, 
I believe that permanently uninstallable packages should be removed.

Now, the removal of libpng10 was probably premature, and I wouldn't have done 
it with so many packages still depending on it.  I would have orphaned it 
instead.  But it's been done now.  There are two ways to deal with that: put 
it back in the archive, or remove the things which depend on it.

I sent this message to debian-devel because I realized that this massive 
increase in uninstallability had probably happened without the notice of most 
of the involved maintainers.  It wasn't my doing!

>Right now, the 
>gnome-1 packages are still used.
Not in a fresh install of unstable they aren't; they're uninstallable.

Andreas Tille wrote:
>... same for imlib1 which is used as well.

It's uninstallable, and the maintainer is abandoning it.
You want to keep it?  Maintain it.  And maintain libpng10 while you're at it, 
because imlib1 won't work without it.

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

"(Instead, we front-load the flamewars and grudges in
the interest of efficiency.)" --Steve Lanagasek,
http://lists.debian.org/debian-devel/2005/09/msg01056.html


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

gdk-imlib1 may yet live (was Re: Removing GNOME 1 (was Re: orbit2cpp

[Nathanael Nerode]

Steve Langasek wrote (in reference to gdk-imlib1):
>No, there isn't.  It should only need to be rebuilt against the newer
>libpng.
Ah, excellent news.  Why wasn't this done *before* removing libpng10?
Because the imlib package maintainer is dropping them and nobody else 
understood the state of the imlib packages?  (I certainly find it very 
confusing.)

In any case that should be done soon.  Someone who cares needs to make some 
sort of upload for the imlib packages.

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

"(Instead, we front-load the flamewars and grudges in
the interest of efficiency.)" --Steve Lanagasek,
http://lists.debian.org/debian-devel/2005/09/msg01056.html


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

pbuilder status update

[Junichi Uekawa]

Hi,


pbuilder is doing as usual; it's now switched over to 
cdebootstrap and cdebootstrap has been working fine.

However, you do need to use the sid version of pbuilder
and cdebootstrap for things to work.

Also, with changes to 'su'; pbuilder stable backports
to be a requirement.

I've moved over my development files to alioth[1], and 
created a mailinglist for pbuilder[2] (I considered
that it might be more convenient than having to file 
a bug in the BTS).

[1] http://alioth.debian.org/projects/pbuilder
[2] pbuilder-maint at lists.alioth.debian.org


I'm hoping to move the development into co-maintenance.
And interested people should contact me.



debootstrap test:
[FAIL] create-sid-debootstrap
[FAIL] build-sid-dsh
[FAIL] pdebuild-sid-dsh
[FAIL] pdebuild-internal-sid-dsh
[OK]   create-sarge-debootstrap
[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-debootstrap
[FAIL] build-etch-dsh
[FAIL] pdebuild-etch-dsh
[FAIL] pdebuild-internal-etch-dsh
[FAIL] update-etch-sid.log
[FAIL] update-etch-sid-experimental.log

cdebootstrap test:
[OK]   create-sid-cdebootstrap
[OK]   build-sid-dsh
[OK]   pdebuild-sid-dsh
[OK]   pdebuild-internal-sid-dsh
[OK]   create-sarge-cdebootstrap
[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
[OK]   create-etch-cdebootstrap
[OK]   build-etch-dsh
[OK]   pdebuild-etch-dsh
[OK]   pdebuild-internal-etch-dsh
[OK]   update-etch-sid.log
[OK]   update-etch-sid-experimental.log


regards,
junichi
-- 
Junichi Uekawa, Debian Developer   http://www.netfort.gr.jp/~dancer/
183A 70FC 4732 1B87 57A5  CE82 D837 7D4E E81E 55C1 



pgpm0xKWV9aYp.pgp
Description: PGP signature

Someone to take over XMTLV packages

[Kenneth Pronovici]

Hi,

I maintain the Debian XMLTV packages.  I no longer use these packages,
and I would like to give up maintaining them.  I would normally just
file an O: and be done with it, but there are a lot of XMLTV users, and
I don't want to leave them completely hanging.  So, I'm looking for
someone to take over these packages, and then I'm willing to stick
around as a co-maintainer for a while if that would be useful.

The packages are clean and relatively bug free, with both existing bugs
related to upstream problems.

Anyone who wants to take these packages over should probably be willing
to follow the upstream mailing lists (if possible), because the most
frequent bug reports are for grabbers that are fixed in CVS but have not
yet made it into an official upstream release (like #320409).  The new
maintainer should also consider maintaining a backport to sarge like I
have been doing, since at least some of the grabbers are likely to break
in a permanent way before etch is released.

Upstream is reasonably active, although they have not been releasing as
often lately as they were in 2003 and 2004.  I have a good relationship
with them and I'm listed as a SourceForge developer for the project, so
I can make introductions as needed.  I'm also willing to help with
debugging in the future, even if I'm not listed as a co-maintainer.  If
I have to, I will also continue to host the backport APT repository,
although I would prefer not to.

Any takers?

Thanks,

KEN

-- 
Kenneth J. Pronovici <[EMAIL PROTECTED]>


pgpavjO4pmRVs.pgp
Description: PGP signature

Re: libpng10(/2) gone, [gdk-]imlib1 and GNOME 1 going -- check yourpackages

[Steve Langasek]

On Tue, Sep 27, 2005 at 07:01:26PM -0400, Nathanael Nerode wrote:
> Thomas Bushnell wrote:
> >Do not delete packages just because you think nobody *should* use
> >them; delete them because nobody *does* use them.
> I am suggesting deleting them because nobody *can* use them.

> Unless libpng10 is  brought back, none of these packages are usable.

Because recompiling against new upstream versions of a library is a lost
art?

libpng12 doesn't even export a different ABI than libpng10, it just suffers
from an upstream who doesn't know enough about library ABI handling to have
done the right thing.

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


signature.asc
Description: Digital signature

Re: Someone to take over XMTLV packages

[Mathias Weyland]

On Tue, Sep 27, 2005 at 06:48:39PM -0500, Kenneth Pronovici wrote:

Hi

> I maintain the Debian XMLTV packages.  I no longer use these packages,
> and I would like to give up maintaining them.

I use xmltv and I'd like to adopt it.


> I'm willing to stick around as a co-maintainer for a while if that would
> be useful.

That would be nice since I do maintain some debian packages but I'm not DD
yet.


> Anyone who wants to take these packages over should probably be willing
> to follow the upstream mailing lists

That's no problem.


> The new maintainer should also consider maintaining a backport to sarge
> like I have been doing

I don't see any problem in maintaing such a backport.

Best regards

Mathias Weyland


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

Re: Someone to take over XMTLV packages

[Kenneth Pronovici]

On Wed, Sep 28, 2005 at 02:10:19AM +0200, Mathias Weyland wrote:
> On Tue, Sep 27, 2005 at 06:48:39PM -0500, Kenneth Pronovici wrote:
> > I maintain the Debian XMLTV packages.  I no longer use these packages,
> > and I would like to give up maintaining them.
> 
> I use xmltv and I'd like to adopt it.

Ok.  I'm glad to hear that.

> > I'm willing to stick around as a co-maintainer for a while if that would
> > be useful.
> 
> That would be nice since I do maintain some debian packages but I'm not DD
> yet.

Would you need me to sponsor your uploads?  The reason I ask is, I'm
trying to give up maintaining XMLTV due to time constraints.  Sponsoring
someone else's packages would potentially take almost as much time as
just maintaining them myself.  

It would be great if we could find another DD who had the time to work
more closely with you than I can afford to. I could then stay on as
co-maintainer just to help out a bit when needed.

> > Anyone who wants to take these packages over should probably be willing
> > to follow the upstream mailing lists
> 
> That's no problem.

Cool.  I recommend following both xmltv-devel and xmltv-users, and
traffic is low enough lately to be manageable.

> > The new maintainer should also consider maintaining a backport to sarge
> > like I have been doing
> 
> I don't see any problem in maintaing such a backport.

Where do you think you would host the backported packages?  As I said,
I'd prefer to avoid hosting them myself if possible (currently, they're
served off my own site, cedar-solutions.com).

KEN

-- 
Kenneth J. Pronovici <[EMAIL PROTECTED]>


pgpcMp7krqONJ.pgp
Description: PGP signature

Re: libpng10(/2) gone, [gdk-]imlib1 and GNOME 1 going -- check yourpackages

[Thomas Bushnell BSG]

Nathanael Nerode <[EMAIL PROTECTED]> writes:

> Thomas Bushnell wrote:
>>Do not delete packages just because you think nobody *should* use
>>them; delete them because nobody *does* use them.
> I am suggesting deleting them because nobody *can* use them.
>
> Unless libpng10 is brought back, none of these packages are usable.
> Are you volunteering to package and maintain libpng10?  If so, good
> for you!  If not, I believe that permanently uninstallable packages
> should be removed.

Sure.  Why was it removed??

> Now, the removal of libpng10 was probably premature, and I wouldn't
> have done it with so many packages still depending on it.  I would
> have orphaned it instead.  But it's been done now.  There are two
> ways to deal with that: put it back in the archive, or remove the
> things which depend on it.

So this is why I plead with the gnome maintainers not to delete
packages because they think they are obsolete.

Thomas


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

Re: libpng10(/2) gone, [gdk-]imlib1 and GNOME 1 going -- check yourpackages

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Tue, Sep 27, 2005 at 07:01:26PM -0400, Nathanael Nerode wrote:
>> Thomas Bushnell wrote:
>> >Do not delete packages just because you think nobody *should* use
>> >them; delete them because nobody *does* use them.
>> I am suggesting deleting them because nobody *can* use them.
>
>> Unless libpng10 is  brought back, none of these packages are usable.
>
> Because recompiling against new upstream versions of a library is a lost
> art?
>
> libpng12 doesn't even export a different ABI than libpng10, it just suffers
> from an upstream who doesn't know enough about library ABI handling to have
> done the right thing.

This is good to know.  I'm happy to drop libpng10 on the assurance
that it's source-compatible.

So what we need now is for the imlib source package to build and
package the gdk_imlib library files, which are currently only provided
by imlib+png2.  At that point, those things which are currently using
imlib+png2 can be rebuild against imlib (the only real offender here
is gnome-libs) and we can drop imlib+png2 and everything will be
happy.

I have already sent email to Steve Robbins requesting that he do this
in imlib.

Thomas


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

Re: gdk-imlib1 may yet live (was Re: Removing GNOME 1 (was Re: orbit2cpp

[Thomas Bushnell BSG]

Nathanael Nerode <[EMAIL PROTECTED]> writes:

> Steve Langasek wrote (in reference to gdk-imlib1):
>>No, there isn't.  It should only need to be rebuilt against the newer
>>libpng.
> Ah, excellent news.  Why wasn't this done *before* removing libpng10?
> Because the imlib package maintainer is dropping them and nobody else 
> understood the state of the imlib packages?  (I certainly find it very 
> confusing.)
>
> In any case that should be done soon.  Someone who cares needs to make some 
> sort of upload for the imlib packages.

I was under the mistaken impression that imlib was maintained, and
imlib+png2 was in RFA status.  But it turns I was wrong; both are
RFA.  So I will adopt imlib, have it build gdk_imlib too, upload, and
maybe all this can be straightened out.

Thomas


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

Re: Patch² : Maintaining a patch for a debian package

[Paul TBBle Hampson]

On Tue, Sep 27, 2005 at 05:39:59PM +0200, Sylvain Beucler wrote:
> On Mon, Sep 26, 2005 at 12:15:11AM +1000, Paul TBBle Hampson wrote:
>> On Sat, Sep 24, 2005 at 11:19:30PM +0200, Sylvain Beucler wrote:
> >> On Sat, Sep 24, 2005 at 12:39:14AM +1000, Paul TBBle Hampson wrote:
> >>> On Fri, Sep 23, 2005 at 03:10:34PM +0200, Sylvain Beucler wrote:
> > >  I got an issue though, but I think it is related to glibc itself:
> > >  after installing the built source packages, aptitude/apt-get
> > >  absolutely want to upgrade them with the binary versions:
> > > : The following packages will be upgraded:
> > > :   libc6 libc6-dbg libc6-dev libc6-prof

> > >  Is this normal?

> >  It is if you've not updated the changelog to be a new version, as
> >  apt-get will prioritise remote versions of a package over currently
> >  installed versions, if the metadata differs (as it will when you
> >  rebuild a package locally)

> >> Curiously this doesn't seem to happen for all packages. libc6 and
> >> dtach, for example, will be replaced; mutt and dpatch won't (for stable).

>> That is weird. Check apt-cache policy for those packages, and see what
>> it says. My understanding is that it should happen for any package,
>> as locally install packages have priority 100, and nothing else gets a
>> lower priority by default.

> Let's see :)

> dmc:~# aptitude upgrade
> [...]
> The following packages will be upgraded:
>   dtach

> dmc:~# apt-cache policy libc6 # +0.1 trick
> libc6:
>   Installed: 2.3.2.ds1-22.1
>   Candidate: 2.3.2.ds1-22.1
>   Version Table:
>  *** 2.3.2.ds1-22.1 0
> 100 /var/lib/dpkg/status
>  2.3.2.ds1-22 0
> 500 http://ftp.fr.debian.org sarge/main Packages

> dmc:~# apt-cache policy dtach # apt wants to replace it
> dtach:
>   Installed: 0.7-1
>   Candidate: 0.7-1
>   Version Table:
>  0.7-1 0
> 500 http://ftp.fr.debian.org sarge/main Packages
>  *** 0.7-1 0
> 100 /var/lib/dpkg/status

> dmc:~# apt-cache policy mutt # apt says nothing for those
> mutt:
>   Installed: 1.5.9-2
>   Candidate: 1.5.9-2
>   Version Table:
>  *** 1.5.9-2 0
> 500 http://ftp.fr.debian.org sarge/main Packages
> 100 /var/lib/dpkg/status
> dmc:~# apt-cache policy dpatch
> dpatch:
>   Installed: 2.0.10
>   Candidate: 2.0.10
>   Version Table:
>  *** 2.0.10 0
> 500 http://ftp.fr.debian.org sarge/main Packages
> 100 /var/lib/dpkg/status

> Apparently apt considers mutt and dpatch to be equivalent to the
> remote versions, which is after what I want.

> Any clue? :/

Apt is acting exactly like you'd expect. You've managed to rebuild
mutt and dpatch and get the same metadata. This is probably the reason
binary NMUs have to increment the version by .0.1, as otherwise they
won't actually be automatically selected... And the whole "can't upload
versions that already exist." I guess.

I guess my question is, did you actually change dpatch and mutt, or just
rebuild? It might be enlightening to debdiff the Debian and local .deb
files for these two and see if they differ in a way that apt doesn't
actually care about. (Which might be a bug... Or might be a feature)

> > >>> Is there a way to automatically update a locally modified package, or
> > >>> can't we avoid a manual processing?

> >>> You could use dch -i to increment the version, or dch -n to increment
> >>> the NMU version.

> >>> You could hack dch to have a --local-build switch, which increments the
> >>> Debian version by 0.0.0.1 and will therefore be greater than the source
> >>> you built, and less than a bin-NMU of the package. And then send the
> >>> patch as a wishlist bug to devscripts. I think it'd be generally useful,
> >>> to be honest.

> >> Some other tricky stuff happens when multiple binary packages are
> >> built from a single source one - the versions in the binary packages
> >> dependencies may need to be resynchronized (eg libc6-i686 Depends on
> >> the same version of libc6).

>> Where this happens, I hope they're using the various macros provided for
>> that sort of thing (${Source-Version} etc) so updating the changelog
>> file is all that's neccessary. Nothing I'm rebuilding has shown any
>> issues for .0.0.1 increments in the version. (Mind you, I'm not
>> rebuilding anything libc. I like my system to keep running. ^_^)

> Hmmm:
> Package: libc6-i686
> Pre-Depends: libc6 (= ${Source-Version})

> Well I guess I missed something. Maybe apt-src tried to install the
> built packages one by one... I have to retry and build (sigh :))

> (Note that I want my system running as well, it's just that
> sysconf(SC_NGROUPS_MAX) returns 32 instead of 65536 and I need that
> fixed :))

Erk. ^_^

Admittedly, it's prolly worth casting an eye over the shlibdeps-building
stuff. You occasionally see bad NMUs when the NMUer forgot to check that
the version-munging code to build a not-too-restrictive shlib deps
version isn't prepared to parse NMU version numbers.

Happily, you mor

Re: ATTN openofficeorg developers

[Andreas Tille]

On Tue, 27 Sep 2005, Martin wrote:


I know you want to scold me because this is not a formal bug report.  I 
find
that form overwhelming.


What form?  Do you know reportbug?
Your chances to reach the relevant people are drastically higher if you file
a bug report against the package in question than posting quite unspecific
mails to Debian devel.


Last week I reported a problem with gnumeric on kde on testing.  Are 
these
problems related?


Probably not and I posted at least a workaround for this problem.

Kind regards

 Andreas.

--
http://fam-tille.de


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

Re: libpng10(/2) gone, [gdk-]imlib1 and GNOME 1 going -- check yourpackages

[Thomas Bushnell BSG]

Nathanael Nerode <[EMAIL PROTECTED]> writes:

> Now, the removal of libpng10 was probably premature, and I wouldn't
> have done it with so many packages still depending on it.  I would
> have orphaned it instead.  But it's been done now.  There are two
> ways to deal with that: put it back in the archive, or remove the
> things which depend on it.

We're in progress on the right strategy, I think.  I have now uploaded
and adopted imlib.  This now builds gdk_imlib libraries too, which the
existing version did not.  Once this gets past NEW processing, I will
file a bug report against gnome-libs requesting that it depend on the
new library.  Then we can request those things using gnome-libs to
depend on the new gnome-libs.

I am happy to adopt gnome-libs, but it has not been orphaned.  Let me
know if you would like me to take it over.

Thomas


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

Re: hotplug blacklists

[Christian Perrier]

Quoting Marco d'Itri ([EMAIL PROTECTED]):

> Everybody who has apt-listchanges installed, for a start.
> And if they don't, too bad for them.


Well, I agree that people using unstable really should install
apt-listchanges.

However, what about testing and future stable users?

Our installer does not install apt-listchanges by default so we can't
just assume that announcing potential transition problems in
NEWS.Debian is enough*if these transition affect testing and
future upgrades from sarge*

This is maybe not relevant to this discussion but this has to be said:
as long as we do not install apt-listchanges by default we can't
expect all our users to get information from there only.

debconf notes could be better suited in some cases. I'm the first
fighting useless debconf notes as "debconf abuse" but they also exist
with a real purpose and using them in some cases could be the best
solution if we have something important to say to users.



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

Re: Re: Re: better init.d/* : who carres ?

[Alfie Costa]

Wed, 21 Sep 2005 09:32:41 +, Gerrit Pape wrote:


On Wed, Sep 21, 2005 at 05:07:31AM -0400, Alfie Costa wrote:

Russ Allbery <[EMAIL PROTECTED]> wrote:
> I find constructs like ${string#*=} particularly difficult to read,
> since they require that I remember what all the different punctuation
> characters inside this sort of parameter expansion do.  According to
> the bash manual, there are sixteen of them, and I had to read the
> description of ${parameter#word} three times before I completely
> understood what it said.



1) The man page descriptions of these functions could probably be
improved.  


There shouldn't be any problems with
 $ man dash
 /%word


OK, so maybe you'd concede the 'bash' version is knotty:

  % man bash | grep -A 12 "r%word"
  Reformatting bash(1), please wait...
  ${parameter%word}
  ${parameter%%word}
   The word is expanded to produce a pattern just  as  in  pathname
   expansion.   If  the  pattern  matches a trailing portion of the
   expanded value of parameter, then the result of the expansion is
   the  expanded value of parameter with the shortest matching pat-
   tern (the ``%'' case)  or  the  longest  matching  pattern  (the
   ``%%''  case)  deleted.   If  parameter  is  @ or *, the pattern
   removal operation is applied to  each  positional  parameter  in
   turn,  and the expansion is the resultant list.  If parameter is
   an array variable subscripted with @ or *, the  pattern  removal
   operation  is  applied  to each member of the array in turn, and
   the expansion is the resultant list.

Now 'dash':

  % man dash | grep -A 4 "r%word"
  Reformatting dash(1), please wait...
  ${parameter%word}   Remove Smallest Suffix Pattern.  The word is
  expanded to produce a pattern.  The parameter
  expansion then results in parameter, with the
  smallest portion of the suffix matched by the pat-
  tern deleted.


...IS better, but it's like saying that McDonald's burgers are lower fat 
than Wendy's.  Both texts just seem to clog the reader's mental arteries.


Some may infer a distaste for the above texts as invincible ignorance -- 
and yet I understand what both are trying to say, and have  programmed 
with those useful constructs, (see previous attachment), and wish they 
were used more.  The trouble is that on receiving such tweaks for a slow 
script, some weary maintainers complain code like that is Greek, 
"nobody" uses it, it's hard to maintain, they don't want any.


It'd be nice to write an obvious improvement of the '${parameter%word}' 
text.  A few years back I attempted it, (not publicly), but the results 
weren't satisfactory**.  Which is not to suggest it can't be done, but 
failing then was what inspired thoughts of sidestepping the difficulty 
using wrapper functions with easy syntax and mnemonic names instead of 
arbitrary chars like '#' and '%'.


(**A low-budget quandary: finding human guinea pigs to test read such 
revisions.  Preferably it should be somebody who doesn't know anything 
about it -- if they can understand it, it's probably lucid. 
Unfortunately such persons are usually so prejudiced against, or

intimidated by, tech text that they often blame themselves or try to
avoid it, saying "oh it's fine, I'm too dumb to understand it", 
especially if there's no immediate reward.  Sadly, experts who are eager 
to help are often bad test readers, they know too much; it's like asking 
a weight lifter if some common object is heavy.)


More about the arbitrariness of '%' and '#' -- besides there being no 
natural connection between a percent sign and a suffix, it's anyone's 
guess why two percent signs '%%' should mean largest, and one sign '%' 
should mean smallest.  There are mnemonic tricks to help remember 
arbitrary sets, like:


The Great Lakes / HOMES
Huron
Ontario
Michigan
Erie
Superior

...or, which is which:

stalagmite  'g' for ground
stalactite  'c' for ceiling

...but try come up with a rule of thumb for '%%' (big suffix), '#' 
(small prefix), etc.?  Maybe the 'p' in percent is for Prefix -- but no, 
the Prefix is the hash symbol; two signs are bigger than one, like Roman 
numerals... it's a puzzle.


That's why the wrapper functions.


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