Re: egroupware upgrade drops several applications -- suggestions?

[Adrian von Bidder]

On Friday 16 June 2006 13:52, Peter Eisentraut wrote:
> The upgrade to the new egroupware upstream drops several applications 
> [...]  On the other hand, if a sarge->etch 
> upgrade potentially throws away a bunch of functionality and data, users
> won't be happy.
>
> What to do?

Rename the package, and drop the old package name from etch.  Add a section 
to the release notes that users wanting to upgrade must manually do so but 
will lose functionality, while users wanting to retain the functionality 
will have no security support anymore.

Technically probably a clean solution, but since "nobody" ever reads the 
release notes, it *will* create problems in terms of some nasty "Debian 
lets egroupware users standing in the rain" /. article or so.

cheers
-- vbi

-- 
Best file compression around: "DEL *.*" = 100% compression


pgpz3ExTJtzDg.pgp
Description: PGP signature

Re: some Debian Apache Maintainer here ?

[Adrian von Bidder]

On Thursday 15 June 2006 16:06, Marc Chantreux wrote:

> Is there a way to help/join/"have news from" the apache team ?

Have you tried contacting the apache maintainers directly? (I'd cc such 
mails to the [EMAIL PROTECTED] list, just for the record)

The changelog.Debian.gz of apache2 and apache lists
 * Adam Conrad (apaprently currently the only active apache person)

Yep. That's right, Adam seems to be the Debian Apache Team at the moment.  
No wonder he doesn't need a mailing list to coordinate with himself... :-/  
There have been some uploads by Amaya, Fabio and Thoma May, but that was 
back in 2004.

Without knowing or having asked Adam, this seems like help might be welcome.

cheers
-- vbi

-- 
this email is protected by a digital signature: http://fortytwo.ch/gpg


pgpDdTKKrgPuc.pgp
Description: PGP signature

Re: message/rfc822

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Don Armstrong wrote:
> On Fri, 16 Jun 2006, Tyler MacDonald wrote:
>> You may think this is a poor question to ask debian-devel, but the
>> reason I am asking is because debian BTS doesn't expand rfc822
>> inlines (so when you click on one from BTS in debian firefox it asks
>> you if you want to download an EML file),
> 
> All messages are actually sent to your browser with
> Content-Disposition: inline; it's up to your browser to decide what to
> do with the file and its Content-Type.
> 
>> and while that'd be a nice feature for BTS, it'd be an even nicer
>> feature for debian as a whole. My favourite MTA is mutt, but it
>> expects a proper mbox, not just one message
> 
> Just one message is a proper mbox with a single message; mutt has no
> problem opening them and viewing them.
> 
> If there's a specific bug that's showing a problem, let me know, or
> file a bug against debbugs or bugs.debian.org.

$ file ~/*eml
/home/me/message_rfc822.eml: smtp mail text

$ file /home/me/download/pgsql-performance.2006-06.mbox
/home/me/download/pgsql-performance.2006-06.mbox: ISO-8859 mail
text, with very long lines

- --
Ron Johnson, Jr.
Jefferson LA  USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEk6IYS9HxQb37XmcRAulKAKDRSi1/T67Zr3uIx65r1lxMmKYPugCguCKs
pDW5soSBdFfzrUefF/NasUg=
=rFAV
-END PGP SIGNATURE-


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

Re: message/rfc822

[Don Armstrong]

On Fri, 16 Jun 2006, Tyler MacDonald wrote:
> You may think this is a poor question to ask debian-devel, but the
> reason I am asking is because debian BTS doesn't expand rfc822
> inlines (so when you click on one from BTS in debian firefox it asks
> you if you want to download an EML file),

All messages are actually sent to your browser with
Content-Disposition: inline; it's up to your browser to decide what to
do with the file and its Content-Type.

> and while that'd be a nice feature for BTS, it'd be an even nicer
> feature for debian as a whole. My favourite MTA is mutt, but it
> expects a proper mbox, not just one message

Just one message is a proper mbox with a single message; mutt has no
problem opening them and viewing them.

If there's a specific bug that's showing a problem, let me know, or
file a bug against debbugs or bugs.debian.org.


Don Armstrong

-- 
Debian's not really about the users or the software at all. It's a
large flame-generating engine that the cabal uses to heat their coffee
 -- Andrew Suffield (#debian-devel Fri, 14 Feb 2003 14:34 -0500)

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

message/rfc822

[Tyler MacDonald]

Is there any (console|gui) package in debian that can easily be used to open
a message/rfc822 attachment and "browse" it like a regular email?

You may think this is a poor question to ask debian-devel, but the reason I
am asking is because debian BTS doesn't expand rfc822 inlines (so when you
click on one from BTS in debian firefox it asks you if you want to download
an EML file), and while that'd be a nice feature for BTS, it'd be an even
nicer feature for debian as a whole. My favourite MTA is mutt, but it
expects a proper mbox, not just one message, so I may consider contributing
this to that project as well, but if there's something in debian that can
fix this already, I'd be really interested in helping close that link.

Thanks,
Tyler



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

Re: GCC 4.1 now the default GCC version for etch

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Darren Salt wrote:
> I demand that Goswin von Brederlow may or may not have written...
> 
> 
> [snip]
>> But other sources pass a pointer as int and there you loose 32
>> valuable bits and get a segfault when the int is used as
>> pointer again. [...]
> 
> And here's me thinking that you lose them. :-)

You loose them to roam the ether.  Think of them as free-range bits.

- --
Ron Johnson, Jr.
Jefferson LA  USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEk1OXS9HxQb37XmcRAmbJAJ4oLV8AudxQDxxkUmF5Lx8Vr4o48QCcClvZ
wU992EYchlBIrmGec6c/u3Y=
=/cEw
-END PGP SIGNATURE-


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

Re: GCC 4.1 now the default GCC version for etch

[Darren Salt]

I demand that Goswin von Brederlow may or may not have written...

[snip]
> But other sources pass a pointer as int and there you loose 32 valuable
> bits and get a segfault when the int is used as pointer again. [...]

And here's me thinking that you lose them. :-)

-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Buy local produce. Try to walk or cycle. TRANSPORT CAUSES GLOBAL WARMING.

It seems to make a car driver mad if he misses you.


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

Re: GCC 4.1 now the default GCC version for etch

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Goswin von Brederlow wrote:
> Falk Hueffner <[EMAIL PROTECTED]> writes:
> 
>> On Thu, Jun 08, 2006 at 07:58:23AM +0200, Bastian Blank wrote:
>>> On Wed, Jun 07, 2006 at 11:53:24PM +0100, Darren Salt wrote:
[snip]
>> So in summary, if you don't care about portability to 64-bit windows,
>> assuming sizeof(void*) == sizeof(long) is just fine.
> 
> Unless you compile with range checking pointers.

Has Pascal risen from the grave?  No, that's range checking arrays.
 Never mind.

Of course, we could always use COBOL and never have to worry about
such issues...

- --
Ron Johnson, Jr.
Jefferson LA  USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEk085S9HxQb37XmcRAkWlAKCfKXy0p7+2zCkaKCzqbeb42barIwCfZcX8
svcwsJbULFgnJ3zMhQCnSCQ=
=hbXV
-END PGP SIGNATURE-


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

Re: GCC 4.1 now the default GCC version for etch

[Goswin von Brederlow]

Falk Hueffner <[EMAIL PROTECTED]> writes:

> On Thu, Jun 08, 2006 at 07:58:23AM +0200, Bastian Blank wrote:
>> On Wed, Jun 07, 2006 at 11:53:24PM +0100, Darren Salt wrote:
>> > The others are trivially fixable; of these, the one in libavcodec is 
>> > already
>> > fixed in CVS. I've committed the rest (they're basically s/int/long/) and 
>> > am
>> > forwarding them appropriately.
>> 
>> long is not appropriate to save pointers, you need to use intptr_t or
>> uintptr_t.
>
> C90 basically promised it would work, and it is widely considered a
> bug in C99 that there is no such guarantee. sizeof(void*) ==
> sizeof(long) is also assumed all over the place in Linux, and there is
> not a chance in hell that will ever change. The only relevant system
> that does not have sizeof(void*) == sizeof(long) is 64-bit windows.
>
> So in summary, if you don't care about portability to 64-bit windows,
> assuming sizeof(void*) == sizeof(long) is just fine.

Unless you compile with range checking pointers.

MfG
Goswin


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

Re: GCC 4.1 now the default GCC version for etch

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Falk Hueffner wrote:
> On Thu, Jun 08, 2006 at 07:58:23AM +0200, Bastian Blank wrote:
>> On Wed, Jun 07, 2006 at 11:53:24PM +0100, Darren Salt wrote:
>>> The others are trivially fixable; of these, the one in libavcodec is already
>>> fixed in CVS. I've committed the rest (they're basically s/int/long/) and am
>>> forwarding them appropriately.
>> long is not appropriate to save pointers, you need to use intptr_t or
>> uintptr_t.
> 
> C90 basically promised it would work, and it is widely considered a
> bug in C99 that there is no such guarantee. sizeof(void*) ==
> sizeof(long) is also assumed all over the place in Linux, and there is

"Linux == kernel" or "Linux == distro"?

> not a chance in hell that will ever change. The only relevant system
> that does not have sizeof(void*) == sizeof(long) is 64-bit windows.
> 
> So in summary, if you don't care about portability to 64-bit windows,
> assuming sizeof(void*) == sizeof(long) is just fine.
> 


- --
Ron Johnson, Jr.
Jefferson LA  USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEk0duS9HxQb37XmcRArB5AJ9JoHqZYhbzp9FrlDXfnfMMXudjSwCfR9gU
2xTOchvxvlHJ+9R0zsulklA=
=aJHY
-END PGP SIGNATURE-


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

Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition

[Goswin Brederlow]

Package: debian-policy
Severity: normal

Hi,

the current use and definition of Build-Depends/Conflicts[-Indep] in
policy 7.6 don't match. Both use and definition also greatly reduce
the usefullness of these fields. This issue has come up again and
again over the last few years and nothing has been done about it. I
hope this proposal provides a elegant and non disruptive way out so we
can finaly do something about it.


Currently policy reads:

| 7.6 Relationships between source and binary packages -
| Build-Depends, Build-Depends-Indep, Build-Conflicts,
| Build-Conflicts-Indep
|
| Source packages that require certain binary packages to be installed
| or absent at the time of building the package can declare
| relationships to those binary packages.
|
| This is done using the Build-Depends, Build-Depends-Indep,
| Build-Conflicts and Build-Conflicts-Indep control file fields.
|
|Build-dependencies on "build-essential" binary packages can be
|omitted. Please see Package relationships, Section 4.2 for more
|information.
|
|The dependencies and conflicts they define must be satisfied (as
|defined earlier for binary packages) in order to invoke the targets in
|debian/rules, as follows:[42]
|
|Build-Depends, Build-Conflicts
|
|The Build-Depends and Build-Conflicts fields must be satisfied
|when any of the following targets is invoked: build, clean,
|binary, binary-arch, build-arch, build-indep and binary-indep.

This comes down to Build-Depends have to be always installed. Buildds
always and only install Build-Depends.

|Build-Depends-Indep, Build-Conflicts-Indep
|
|The Build-Depends-Indep and Build-Conflicts-Indep fields must be
|satisfied when any of the following targets is invoked: build,
|build-indep, binary and binary-indep.  

But buildds do call the build targets (via dpkg-buildpackage) and
don't honor Build-Depends/Conflicts-Indep. And since build calls
build-indep that means anything needed to build the architecture
independent part needs to be included in Build-Depends. This make the
Build-Depends-Indep quite useless.

[Side note: Buildds/dpkg-buildpackage has no robust way of telling if
the optional build-arch field exists and must call build. This is
wastefull for both build dependencies and build time.]


Proposal:
-

Two new fields are introduced:

Build-Depends-Arch, Build-Conflicts-Arch

The Build-Depends-Arch and Build-Conflicts-Arch fields must be
satisfied when any of the following targets is invoked:
build-arch, binary-arch.

The existance of either of the two makes build-arch mandatory.


The old fields change their meaning:

Build-Depends, Build-Conflicts

The Build-Depends and Build-Conflicts fields must be satisfied
when any target is invoked.

Build-Depends-Indep, Build-Conflicts-Indep

The Build-Depends-Indep and Build-Conflicts-Indep fields must be
satisfied when any of the following targets is invoked:
build-indep, binary-indep.

The existance of either of the two makes build-indep mandatory.

The use of Build-Depends/Conflicts-Arch/Indep is optional but should
be used in architecture "all/any" mixed packages. If any of them is
omitted the respective Build-Depends/Conflicts field must be suffient
already.

### End of Proposal ###



Why is this proposal better than others that have failed before?

- non disruptive: Current buildd behaviour will continue to build all
  existing packages.

- Packages will not instantly have RC bugs.

- Simple to implement.
  + Trivial change in dpkg for the new field.
  + dpkg-checkbuilddeps has to parse 3 fields (2 with -B option)
instead of 2 (1).
  + sbuild, same change
  + Simple change for 'apt-get build-dep'

- Buildds/dpkg-buildpackage can use the build-arch target
  + reduces Build-Depends field and install time of same
  + build-indep is no longer called, reduces compile time and disk
space

- Build-Depends/Conflicts-Indep becomes usefull, build-indep becomes
  usefull

  Large packages no longer have to build indep stuff in the
  binary-indep target to avoid building it on buildds.

MfG
Goswin

-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.16-rc4-xen
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Re: GCC 4.1 now the default GCC version for etch

[Philip Brown]

On Fri, Jun 16, 2006 at 11:15:32PM +0200, Falk Hueffner wrote:
> Henning Makholm wrote:
> 
> > Another related bug type that I found lurking in my packages when I
> > investigated the warnings in this list, is trying to format a size_t
> > value with a %u or %d format string, which will break if size_t is 64
> > bits (unless the actual number is small and it is the last argument
> > and the endianness of the architecture happens to match its stack
> > growth direction).
> 
> Since any sane ABI pads arguments to word size, this is only a problem
> on big endian 64-bit architectures (that is, no current release
> architecture).
> 

odd..

there appears to currently be a sparc release of debian,

http://www.debian.org/ports/sparc/

and it appears to claim to support some kind of limited 64bit support.

There are some unstated things from the page that I would like to bring to
the table as relevant:

1. since it is sparc, I would presume debian/sparc is "big endian"
2. since the amd64 arch now has 64bit applications (?) I would guess that
   at some point, the debian sparc folks may follow suit.


So to deliberately ignore an issue, becuase 
"we dont support big-endian 64bit *right now*", would seem to be rather
short sighted to me.


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

Re: GCC 4.1 now the default GCC version for etch

[Steve Greenland]

On 16-Jun-06, 08:18 (CDT), Henning Makholm <[EMAIL PROTECTED]> wrote: 
> Another related bug type that I found lurking in my packages when I
> investigated the warnings in this list, is trying to format a size_t
> value with a %u or %d format string, which will break if size_t is 64
> bits (unless the actual number is small and it is the last argument
> and the endianness of the architecture happens to match its stack
> growth direction). This too produces a warning on all relevant gcc
> versions, but only when compiling to a 64-bit target.

Actually, it will provide a warning on 32-bit platforms too, if one chooses the 
appropriate options (-Wall, or specifically -Wformat):

$ cat tprint.c
#include 

int main(void) {

int i;
size_t st;

printf("%d %lu\n", i, st);
return 0;
}

$ gcc -Wall tprint.c 
tprint.c: In function 'main':
tprint.c:8: warning: format '%lu' expects type 'long unsigned int', but 
argument 3 has type 'size_t'

Steve



-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: GCC 4.1 now the default GCC version for etch

[Falk Hueffner]

Henning Makholm wrote:

> Another related bug type that I found lurking in my packages when I
> investigated the warnings in this list, is trying to format a size_t
> value with a %u or %d format string, which will break if size_t is 64
> bits (unless the actual number is small and it is the last argument
> and the endianness of the architecture happens to match its stack
> growth direction).

Since any sane ABI pads arguments to word size, this is only a problem
on big endian 64-bit architectures (that is, no current release
architecture).

-- 
Falk


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

Re: installing a package from "Config-files" state earlier than the most recent stable release

[Frank Küster]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:

> On 16 Jun 2006, Frank Küster told this:
>
>> Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>>
>>> On 14 Jun 2006, Steve Langasek outgrape:
>>>
 Just like there's no guarantee that saying "no" to a conffile
 prompt when upgrading across stable releases will give you a
 usable package.
>>>
>>> I prefer in that case not to install the new version of the
>>> package; since questions can be missed in a dist-upgrade.  Some of
>>> my packages default to not upgrading unless some questions are
>>> answered affirmatively -- so the end result is still a working
>>> package (as long as the dependencies still exist).
>>
>> How do you achieve this?  The conffile questions are displayed after
>> the new package is unpacked, so isn't a failing postinst all you can
>> get?  How do you get back to the old version?
>
> I ask the questions in preinst.

So you aren't talking about dpkg's conffile questions, right?  Or is
there a trick?

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: GCC 4.1 now the default GCC version for etch

[Falk Hueffner]

On Thu, Jun 08, 2006 at 07:58:23AM +0200, Bastian Blank wrote:
> On Wed, Jun 07, 2006 at 11:53:24PM +0100, Darren Salt wrote:
> > The others are trivially fixable; of these, the one in libavcodec is already
> > fixed in CVS. I've committed the rest (they're basically s/int/long/) and am
> > forwarding them appropriately.
> 
> long is not appropriate to save pointers, you need to use intptr_t or
> uintptr_t.

C90 basically promised it would work, and it is widely considered a
bug in C99 that there is no such guarantee. sizeof(void*) ==
sizeof(long) is also assumed all over the place in Linux, and there is
not a chance in hell that will ever change. The only relevant system
that does not have sizeof(void*) == sizeof(long) is 64-bit windows.

So in summary, if you don't care about portability to 64-bit windows,
assuming sizeof(void*) == sizeof(long) is just fine.

-- 
Falk


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

Re: installing a package from "Config-files" state earlier than the most recent stable release

[Manoj Srivastava]

On 16 Jun 2006, Frank Küster told this:

> Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>
>> On 14 Jun 2006, Steve Langasek outgrape:
>>
>>> Just like there's no guarantee that saying "no" to a conffile
>>> prompt when upgrading across stable releases will give you a
>>> usable package.
>>
>> I prefer in that case not to install the new version of the
>> package; since questions can be missed in a dist-upgrade.  Some of
>> my packages default to not upgrading unless some questions are
>> answered affirmatively -- so the end result is still a working
>> package (as long as the dependencies still exist).
>
> How do you achieve this?  The conffile questions are displayed after
> the new package is unpacked, so isn't a failing postinst all you can
> get?  How do you get back to the old version?

I ask the questions in preinst.

manoj
-- 
"Absolutely nothing should be concluded from these figures except that
no conclusion can be drawn from them." Joseph L. Brothers,
Linux/PowerPC Project
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: installing a package from "Config-files" state earlier than the most recent stable release

[Frank Küster]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:

> On 14 Jun 2006, Steve Langasek outgrape:
>
>> Just like there's no guarantee that saying "no" to a conffile prompt
>> when upgrading across stable releases will give you a usable
>> package.
>
> I prefer in that case not to install the new version of the
>  package; since questions can be missed in a dist-upgrade.  Some of my
>  packages default to not upgrading unless some questions are answered
>  affirmatively -- so the end result is still a working package (as
>  long as the dependencies still exist).

How do you achieve this?  The conffile questions are displayed after the
new package is unpacked, so isn't a failing postinst all you can get?
How do you get back to the old version?

Yet an other approach:  The teTeX packages have the problem that if some
conffile questions are answered "no" and the old versions kept, the
postinst will fail when building the formats.  Instead of trying to do
that, we check for the critical changes, and let the postinst exit with
a debconf error message. (In fact it's tex-common's postinst).

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Bug#54138: my chance

[Tyree]

Do not ignore me please,
I found your email somewhere and now daebcided to write you.
I am comibng to your place in few weeks aand thought we 
cban meet each other. Let me know if you do not mind.
I am a nice pretty girl. Don't reply to this emaila. 
Email me direclty at [EMAIL PROTECTED]




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

Re: egroupware upgrade drops several applications -- suggestions?

[Florian Weimer]

* Peter Eisentraut:

> The upgrade to the new egroupware upstream drops several applications such as 
> the trouble-ticket system and the forum (because they were unmaintained or 
> the functionality was picked up by something else).  I'm not sure how to 
> arrange an upgrade to this new version.  On the one hand, no one wants to 
> maintain the old stuff anymore, so it should disappear from the Debian 
> distribution.  On the other hand, if a sarge->etch upgrade potentially throws 
> away a bunch of functionality and data, users won't be happy.
>
> What to do?

Drop them.  IIRC, the forum part (née FUD Forum) has a poor security
record.

Re: installing a package from "Config-files" state earlier than the most recent stable release

[Manoj Srivastava]

On 14 Jun 2006, Steve Langasek outgrape:

> Just like there's no guarantee that saying "no" to a conffile prompt
> when upgrading across stable releases will give you a usable
> package.

I prefer in that case not to install the new version of the
 package; since questions can be missed in a dist-upgrade.  Some of my
 packages default to not upgrading unless some questions are answered
 affirmatively -- so the end result is still a working package (as
 long as the dependencies still exist).

manoj
-- 
Only wimps use tape backup: _real_ men just upload their important
stuff on ftp, and let the rest of the world mirror it ;) -- Linus
Torvalds, about his failing hard drive
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: GCC 4.1 now the default GCC version for etch

[Andreas Metzler]

Henning Makholm <[EMAIL PROTECTED]> wrote:
> Scripsit Andreas Metzler <[EMAIL PROTECTED]>
>> On 2006-06-07 Matthias Klose <[EMAIL PROTECTED]> wrote:
>>> We did pick two compiler warnings and scanned the build logs of one
>>> archive rebuild on alpha (64bit), where wrong code may be generated.
>>>  - cast from pointer to integer of different size
>>>cast to pointer from integer of different size

>> i.e. if a package is currently in the archive, suffers from this
>> issues and the binary packages *currently* in the archive have been
>> built with gcc-4.0, should I
>> b) simply continue, as the package won't be broken more with gcc-4.1
>> than it was with gcc-4.0?

> If the code is really nont 64bit-clean (i.e. it tries to store a
> pointer in a 32-bit integer and expects to be able to cast it back and
> still locate the data the original pointer pointed to), I cannot see
> how gcc-4.0 would have been able to create working code either.

I have since talked to upstream, and it seems to be more of a cosmetic
issue, they are storing 32bit integers in pointers. Following glib's
example and depending on the size of void on an arch either casting 
p = (void*) (long) 42;
or
p = (void*) 42;
will get rid of the warnings, too.

Thanks for your explanations (also to Goswin), cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.(c) Jasper Ffforde


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

Re: python2.3/2.4 installation failure (and workaround)

[Wolfgang Pfeiffer]

On Fri, Jun 16, 2006 at 06:18:58PM +0200, Wolfgang Pfeiffer wrote:
> Your workaround does, as it seems, not workaround, if the mess already
> happened:
> 
  [ ... ]
> 
> What now?

# dpkg --configure -a   
Setting up python-central (0.4.17) ...
Setting up python2.4-minimal (2.4.3-7) ...

Setting up python2.4 (2.4.3-7) ...

Setting up python2.3 (2.3.5-14) ...

Setting up python-minimal (2.3.5-9) ...
Setting up python (2.3.5-9) ...


Sorry for noising

Regards
Wolfgang
-- 
Wolfgang Pfeiffer: /ICQ: 286585973/ + + +  /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer

Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on


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

[MEETINGS] D-I team meeting RESCHEDULED to Saturday June 24th 16:00UTC

[Christian Perrier]

Because of very last minute commitments for myself, as D-I meetings
moderator, and Frans Pop, as D-I release manager, we have decided to
reschedule the Debian Installer team meeting to Saturday June 24th 16:00:

> The next Debian Installer team opened meeting is scheduled for
> Saturday June 24th 16:00 UTC.
> 
> The meeting will happen on #debian-boot ON irc.debian.org, NOT, I
> REPEAT, NOT on irc.freenode.net.
> 
> This meeting will mostly be centered about the next release schedule,
> with regards of the general Etch release plans.
> 
> The Wiki page is opened for the meeting agenda.
> 
> http://wiki.debian.org/DebianInstaller/Meetings
> 
> I will add timings to the agenda at the last minute, as usual, so
> probably on Saturday morning. Expect a meeting duration of about
> 1h30.




signature.asc
Description: Digital signature

RE: python2.3/2.4 installation failure (and workaround)

[Wolfgang Pfeiffer]

Your workaround does, as it seems, not workaround, if the mess already
happened:

I got the know error when dist-upgrading the system today:

dpkg: error processing python2.4-minimal (--configure):
 subprocess post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of python-minimal:
 python-minimal depends on python2.3 (>= 2.3.5-1); however:
  Package python2.3 is not configured yet.
dpkg: error processing python-minimal (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of python:
 python depends on python2.3 (>= 2.3.5-1); however:
  Package python2.3 is not configured yet.
dpkg: error processing python (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of python2.4:
 python2.4 depends on python2.4-minimal (= 2.4.3-7); however:
  Package python2.4-minimal is not configured yet.
dpkg: error processing python2.4 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 python2.3
 python2.4-minimal
 python-minimal
 python
 python2.4


Now trying your workaround I get this:


# dpkg -i python-central_0.4.17_all.deb 
(Reading database ... 108424 files and directories currently installed.)
Preparing to replace python-central 0.4.17 (using 
python-central_0.4.17_all.deb) ...
Unpacking replacement python-central ...
dpkg: dependency problems prevent configuration of python-central:
 python-central depends on python (>= 2.3.5-9); however:
  Package python is not configured yet.
dpkg: error processing python-central (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 python-central


What now?

Thanks in anticipation
Wolfgang

 
-- 
Wolfgang Pfeiffer: /ICQ: 286585973/ + + +  /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer

Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on


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

Bug#373966: ITP: qonk -- Small build-and-conquer strategy game with very simple rules

[Martin Ferrari]

Package: wnpp
Severity: wishlist
Owner: Martin Ferrari <[EMAIL PROTECTED]>


* Package name: qonk
  Version : 0.0.2beta1
  Upstream Author : Anthony Liekens <[EMAIL PROTECTED]>
* URL : http://anthony.liekens.net/index.php/Computers/Qonk
* License : GPL
  Programming Lang: C++, C
  Description : Small build-and-conquer strategy game with very simple rules

The setting of the game is a solar system of planets. Your goal is to
conquer all of the planets in the game by sending ships there. Planets
that are under your control generate new ships. Simple AI players are
playing against you. As you gain more experience throughout the game,
more AI players have to be kicked out of bigger solar systems.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (901, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-2-686
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8)



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

Re: GCC 4.1 now the default GCC version for etch

[Goswin von Brederlow]

Andreas Metzler <[EMAIL PROTECTED]> writes:

> On 2006-06-07 Matthias Klose <[EMAIL PROTECTED]> wrote:
> [...]
>> We did pick two compiler warnings and scanned the build logs of one
>> archive rebuild on alpha (64bit), where wrong code may be generated.
> [...]
>>  - cast from pointer to integer of different size
>>cast to pointer from integer of different size
>
>>These warnings may point to code which is not 64bit clean. They are
>>most likely not seen on 32bit architectures. See the amd64, alpha
>>and ia64 build logs for these architecture specific warnings.
> [...]
>
> Hello,
> as this was sent in conjunction with gcc 4.1, I wonder whether gcc 4.1
> is more strict in this matter, too.

This has always been a bug and great cause for segfaults. They just
have automated looking for the compiler warnings for the problem now
instead of users looking at segfaults.

> i.e. if a package is currently in the archive, suffers from this
> issues and the binary packages *currently* in the archive have been
> built with gcc-4.0, should I
>
> a) refrain from making a upload before the
> issue is fixed as the packages will break horribly with gcc-4.1,
>
> or
> b) simply continue, as the package won't be broken more with gcc-4.1
> than it was with gcc-4.0?
>
> thanks, cu andreas

The brokenness does not change, the generated code does not
change. The bug remains if it actualy is a bug. Sometimes you have
code that pases an int (and other things at different places) along as
void* and deeper down casts it back to int. This will generate the
warning, is bad C (implementation defined behaviour), but with gcc it
will work perfectly. The extra 32 high-bits you gain you loose
again. No harm done _in_this_case.

But other sources pass a pointer as int and there you loose 32
valuable bits and get a segfault when the int is used as pointer
again. The warnings ware the same.

MfG
Goswin


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

Re: Mass bug filing: lesstif1->lesstif2 transition

[Goswin von Brederlow]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Fri, Jun 16, 2006 at 10:39:29AM +0200, Petter Reinholdtsen wrote:
>> [Kai Hendry]
>> > Affected packages are:
>> [...]
>> > Petter Reinholdtsen <[EMAIL PROTECTED]>
>> >plan
>
>> How did you conclude that it depend on lesstif1?  Its build depend is
>> 'lesstif2-dev | lesstif-dev', to make sure it build with any version
>> of debian, but I believe it is built by lesstif2 by default.
>
> Only the i386 package of plan depends on lesstif1, so it looks like a
> problem with the build env at the time of the maintainer upload.  This
> should be fixable with a binNMU once lesstif1 is dropped from unstable (or
> maybe before).
>
> Cheers,

A "Build-Depends: lesstif2-dev | lesstif-dev" can only be fullfiled by

- lesstif-dev is already installed in the chroot [dirty chroot]
- lesstif2-dev gets installed by sbuild

in that order.

It is far more likely the i386 version was uploaded by the maintainer
and he still had lestiff-dev installed on his/her system (and I'm too
lazy to check).

A binNMU will fix this normaly.

MfG
Goswin


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

Re: some Debian Apache Maintainer here ?

[Josselin Mouette]

Le vendredi 16 juin 2006 à 15:27 +0200, Josselin Mouette a écrit :
> If you don't have any answer and are want to prepare a NMU, I am sure
> you will some developers (including me) would be happy to sponsor it.
  ^  ^
 find   who
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: SUMMARY -- Generic handling of WORD, EXCEL, FILE MANGER ...

[Josselin Mouette]

Le jeudi 15 juin 2006 à 13:31 +0300, Jari Aalto+usenet a écrit :
> PROPOSED SOLUTIONS
> 
> (1) It was discussed if /etc/alternatives could be used by providing
> configuration possiblitity through
> 
> update-alternatives --config 
> 
> Where items proposed for graphical programs could include:
> 
> x-word-processor
> x-spreadsheet
> x-file-manager
> x-archiver
> x-media-player  or "x-video-player"
> x-media-editor  or "x-media-mastering"
> x-music-player
> x-music-editor  think "audacity" etc.
> 
> This list is not comprehensive, only a start.
> 
> (2) Another proposed solution was to use existing MIME types
> framework in /etc/mime.types, /etc/mailcap.order and /etc/mailcap.
> It tackles the proposal like this:
> 
> application/msword; oowriter '%s'; edit=oowriter '%s'; ...
> application/msexcel; oocalc '%s'; edit=oocalc '%s';...

And (3) use the Freedesktop.org MIME database which already handles
incompatible command line interfaces. This proposal could be summed up
by "do nothing".
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: GCC 4.1 now the default GCC version for etch

[Henning Makholm]

Scripsit Andreas Metzler <[EMAIL PROTECTED]>
> On 2006-06-07 Matthias Klose <[EMAIL PROTECTED]> wrote:

>> We did pick two compiler warnings and scanned the build logs of one
>> archive rebuild on alpha (64bit), where wrong code may be generated.
>>  - cast from pointer to integer of different size
>>cast to pointer from integer of different size

> i.e. if a package is currently in the archive, suffers from this
> issues and the binary packages *currently* in the archive have been
> built with gcc-4.0, should I
> b) simply continue, as the package won't be broken more with gcc-4.1
> than it was with gcc-4.0?

If the code is really nont 64bit-clean (i.e. it tries to store a
pointer in a 32-bit integer and expects to be able to cast it back and
still locate the data the original pointer pointed to), I cannot see
how gcc-4.0 would have been able to create working code either.

As I read Matthias' posting, these warnings were ones that were found
as a kind of bonus outcome from the compile-everything-with-gcc4.1
experiment.


Another related bug type that I found lurking in my packages when I
investigated the warnings in this list, is trying to format a size_t
value with a %u or %d format string, which will break if size_t is 64
bits (unless the actual number is small and it is the last argument
and the endianness of the architecture happens to match its stack
growth direction). This too produces a warning on all relevant gcc
versions, but only when compiling to a 64-bit target.

Somebody ought to create a tool that could easily compare the
buildd logs for a package on different architectures and flag warnings
that appear only for some but not arches, indicating a possible
portability bug.

-- 
Henning Makholm"What the hedgehog sang is not evidence."


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

Re: some Debian Apache Maintainer here ?

[Josselin Mouette]

Le jeudi 15 juin 2006 à 16:37 +0200, Marc Chantreux a écrit :
> Olaf,
> 
> 
> > >I still apply my patch on every server i install, this is boring me.
> > >
> > >Is there a way to help/join/"have news from" the apache team ?
> > 
> > Try irc://irc.debian.org/debian-apache
> > Unfortunately, a more informative answer than it's fixed when it's
> > fixed shouldn't be expected.
> 
> thanks for your answer. In fact, the question i want to ask to them
> isn't "when will you fix ?"  but "can i do better ? can i help to fix
> ?".
> 
> I hope the answer will be more informative.

If you don't have any answer and are want to prepare a NMU, I am sure
you will some developers (including me) would be happy to sponsor it.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

egroupware upgrade drops several applications -- suggestions?

[Peter Eisentraut]

The upgrade to the new egroupware upstream drops several applications such as 
the trouble-ticket system and the forum (because they were unmaintained or 
the functionality was picked up by something else).  I'm not sure how to 
arrange an upgrade to this new version.  On the one hand, no one wants to 
maintain the old stuff anymore, so it should disappear from the Debian 
distribution.  On the other hand, if a sarge->etch upgrade potentially throws 
away a bunch of functionality and data, users won't be happy.

What to do?


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

Re: GCC 4.1 now the default GCC version for etch

[Andreas Metzler]

On 2006-06-07 Matthias Klose <[EMAIL PROTECTED]> wrote:
[...]
> We did pick two compiler warnings and scanned the build logs of one
> archive rebuild on alpha (64bit), where wrong code may be generated.
[...]
>  - cast from pointer to integer of different size
>cast to pointer from integer of different size

>These warnings may point to code which is not 64bit clean. They are
>most likely not seen on 32bit architectures. See the amd64, alpha
>and ia64 build logs for these architecture specific warnings.
[...]

Hello,
as this was sent in conjunction with gcc 4.1, I wonder whether gcc 4.1
is more strict in this matter, too.

i.e. if a package is currently in the archive, suffers from this
issues and the binary packages *currently* in the archive have been
built with gcc-4.0, should I

a) refrain from making a upload before the
issue is fixed as the packages will break horribly with gcc-4.1,

or
b) simply continue, as the package won't be broken more with gcc-4.1
than it was with gcc-4.0?

thanks, cu andreas

-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.(c) Jasper Ffforde


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

Re: Mass bug filing: lesstif1->lesstif2 transition

[Steve Langasek]

On Fri, Jun 16, 2006 at 10:39:29AM +0200, Petter Reinholdtsen wrote:
> [Kai Hendry]
> > Affected packages are:
> [...]
> > Petter Reinholdtsen <[EMAIL PROTECTED]>
> >plan

> How did you conclude that it depend on lesstif1?  Its build depend is
> 'lesstif2-dev | lesstif-dev', to make sure it build with any version
> of debian, but I believe it is built by lesstif2 by default.

Only the i386 package of plan depends on lesstif1, so it looks like a
problem with the build env at the time of the maintainer upload.  This
should be fixable with a binNMU once lesstif1 is dropped from unstable (or
maybe before).

Cheers,
-- 
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: Mass bug filing: lesstif1->lesstif2 transition

[Petter Reinholdtsen]

[Kai Hendry]
> Affected packages are:
[...]
> Petter Reinholdtsen <[EMAIL PROTECTED]>
>plan

How did you conclude that it depend on lesstif1?  Its build depend is
'lesstif2-dev | lesstif-dev', to make sure it build with any version
of debian, but I believe it is built by lesstif2 by default.

Patches to fix the problem you have detected are most welcome in the
BTS. :)

Friendly,
-- 
Petter Reinholdtsen


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

Re: some Debian Apache Maintainer here ?

[Julien Danjou]

On Thu, Jun 15, 2006 at 06:35:51PM +0200, Adrian von Bidder wrote:
> Marc cc:ed, not sure if you're on the list.
> 
> On Thursday 15 June 2006 16:06, Marc Chantreux wrote:
> > I've posted a patch to fix #350119, #342008, #350119 139 days ago and
> > have no news about it. I tried to contact the apache team to know if i
> > was able to help  but i have no news.
> 
> There is the debian-apache mailing list.  I don't ee much life there, 
> though, except for bts email.

It seems that apache maintainers try to see if the package
can be auto-self-maintained by itself.
Though, it seems not, so they will have to stop hiding themselves or
someone is gonna take this over.

Cheers,
-- 
Julien Danjou
.''`.  Debian Developer
: :' : http://julien.danjou.info
`. `'  http://people.debian.org/~acid
  `-   9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD


signature.asc
Description: Digital signature

Re: some Debian Apache Maintainer here ?

[Marc Chantreux]

le 15/06/2006,
Adrian von Bidder nous écrivait :
> There is the debian-apache mailing list.  I don't ee much life there, 
> though, except for bts email.

the irc chan looks like ghost city too ...

cheers
mc




-- 
téléphone : 03.90.24.00.19
courriel  : [EMAIL PROTECTED]
---