Re: i386-uclibc debian

[Riku Voipio]

On Wednesday 28 September 2005 18:12, Daniel Ruoso wrote:
> I'm interested in maintaining a i386-uclibc architecture, which is, like
> the name says, i386 binaries linked with uClibc. My plans are:

> 1) Build all the packages used by debootstrap to generate a basedebs.tgz
> 2) Certify this basedebs works with a fresh instalation.
> 3) Start building a incresing number of packages, but certainly only a
> small subset of the i386 architecture.

Similar thing was already done for woody, so you may not have to start from
scratch:

http://people.debian.org/~andersee/uwoody/

> The i386 packages won't be compatible with my i386-uclibc environment
> (as I won't have glibc installed). So I started calling the architecture
> i386-uclibc with gnu name i386-uclibc-linux. And I'd like to ask: Is it
> OK?

The naming might need some adjusting, and you may have to maintain it for 
quite a while under unofficial banner, but I think the idea is great.


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

[Edward Betts]

Joey Hess <[EMAIL PROTECTED]> wrote:
> 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
[-SNIP-]
> Edward Betts <[EMAIL PROTECTED]>
>joystick
> 

Thanks, I'll upload a package sometime later today.

-- 
Edward


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

Re: How to prevent a library transition

[Josselin Mouette]

Le jeudi 29 septembre 2005 à 19:18 +0200, Frank Küster a écrit :
> Josselin Mouette <[EMAIL PROTECTED]> wrote:
> 
> > Please don't do that. A library transition breaks packages in unstable
> > for a while, but if we have both versions, we're going to have to deal
> > with them for several *years*. That's what happened for libpng, and
> > believe me, it's a nightmare.
> 
> Why do you think that we would have to deal with both versions for
> years?  I expect no problems in compiling and using packages with the
> new version, even if their upstream is dead for a while.

Then you'll notice that many Debian developers don't rebuild their
packages against new library versions, even when told to, until the
package becomes uninstallable.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: hotplug blacklists

[Thomas Hood]

> Anyway, I implemented support for /etc/hotplug/blacklist.d/ in modprobe...

N.B. Currently a module that is blacklisted for hotplug (i.e. its name
is listed in /etc/hotplug/blacklist or in a file in
/etc/hotplug/blacklist.d/) can still be loaded on boot by adding its
name to /etc/modules.  For backward compatibility that behavior should
probably be preserved.

When a final decision has been made about how hot plug blacklisting
will be implemented in the future, please file a bug report against
alsa-base explaining what changes need to be made, if any.
-- 
Thomas Hood


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

Re: hotplug blacklists

[Marco d'Itri]

On Sep 30, Thomas Hood <[EMAIL PROTECTED]> wrote:

> N.B. Currently a module that is blacklisted for hotplug (i.e. its name
> is listed in /etc/hotplug/blacklist or in a file in
> /etc/hotplug/blacklist.d/) can still be loaded on boot by adding its
> name to /etc/modules.  For backward compatibility that behavior should
> probably be preserved.
modprobe blacklists are only applied to targets of alias expansion, so
nothing has been changed.

> When a final decision has been made about how hot plug blacklisting
> will be implemented in the future, please file a bug report against
> alsa-base explaining what changes need to be made, if any.
The final decision has been made long ago, and it is to use blacklist
statements in a file in /etc/modprobe.d/.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: How to prevent a library transition

[Frank Küster]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Le jeudi 29 septembre 2005 à 19:18 +0200, Frank Küster a écrit :
>> Josselin Mouette <[EMAIL PROTECTED]> wrote:
>> 
>> > Please don't do that. A library transition breaks packages in unstable
>> > for a while, but if we have both versions, we're going to have to deal
>> > with them for several *years*. That's what happened for libpng, and
>> > believe me, it's a nightmare.
>> 
>> Why do you think that we would have to deal with both versions for
>> years?  I expect no problems in compiling and using packages with the
>> new version, even if their upstream is dead for a while.
>
> Then you'll notice that many Debian developers don't rebuild their
> packages against new library versions, even when told to, until the
> package becomes uninstallable.

That's why I asked about the RC'iness of those bugs:  I expect that
after a short while, most packages have been recompiled, and it has
turned out that there are no problems.  Then I submit patches to the
remaining packages' bugs, wait for some time, raise severity, wait
again, NMU, and can remove the old library.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

information about DFRC

[export]

Sir 
I want help for you can you give me detail 
information about
DFRC please reply urgently. 
Best Regard
Pravin 

Re: curl status update

[Richard Atterer]

On Thu, Sep 29, 2005 at 03:19:18PM -0700, Steve Langasek wrote:
> On Thu, Sep 29, 2005 at 03:27:30PM +0200, Richard Atterer wrote:
> > On Thu, Sep 29, 2005 at 02:37:35PM +0200, Marco d'Itri wrote:
> > > Why is openssl the default?
> > > I think everybody agrees that in the long period everybody will want to
> > > use gnutls,
> 
> > No, as has been shown by the discussions in the last weeks, there is *no* 
> > agreement on which SSL library should be the default.
> 
> There isn't?  I saw some arguments that explain why it's not possible to
> convert all curl-using applications from OpenSSL to GNUTLS without a
> recompile due to unavailable ABI changes, but I thought it was pretty clear
> that the default going forward should be the one whose license is maximally
> compatible with that of applications using libcurl (i.e., GNUTLS).

Yes - I should clarify what I said: _In_the_long_run_ the agreed goal was 
to move to GnuTLS. However, above Marco asked why the _current_ default 
isn't GnuTLS. I'm not so sure whether it should be: Upstream's choice will 
remain OpenSSL for the foreseeable future, GnuTLS is allegedly still 
slightly more buggy than OpenSSL (does anyone have any details?) and is 
lacking some features.

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯


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

unsubscribe

[Mihai Felseghi]

Bug#330932: ITP: avscan -- GTK frontend for the Clam AntiVirus scanner (ClamAV)

[Christoph Berg]

Package: wnpp
Severity: wishlist
Owner: Christoph Berg <[EMAIL PROTECTED]>

* Package name: avscan
  Version : 0.4.1
  Upstream Author : Wolfpack Entertainment
* URL : http://wolfpack.twu.net/Endeavour2/contrib/index.html#avscan
* License : GPL
  Description : GTK frontend for the Clam AntiVirus scanner (ClamAV)

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


signature.asc
Description: Digital signature

Re: attention to bug 321435

[Adam Thornton]

On Sep 30, 2005, at 1:46 AM, Thomas Bushnell BSG wrote:



Please see http://bugs.debian.org/321435.

This bug is that gs-gpl fails to work on s390.  I recall just seeing
a principal s390 developers say he was no longer doing the Debian s390
port.  I don't know what effect this has on the bug.

This bug is blocking a number of packages, at the very least, ifhp and
scummvm.  Something needs to happen...

I'm not sure what.


I wrote to Gerhard Tonn indicating my willingness to be a maintainer  
of last resort if no one more suitable for the s390 port stepped  
forward, but I did not receive a reply and I do not know whether  
someone else has been found.  It's not clear to me that the buildd  
maintainer's duties exactly are, or, critically, how much time per  
week it takes.


I guess that the thing to do is to build gs-gpl with debugging turned  
on, as well as scummvm, and try to find out in what function things  
are rupturing.  I'm going to hazard a guess that it's an assumption  
about signed/unsigned characters, but that's purely a guess based on  
what my gut feeling for most of the portability bugs I've seen on  
s390 are about.  I myself am not likely to have time to do this  
before the middle of next week.


Adam


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

Apt, custom packages, and package dependencies

[Michael S. Peek]

Hello developers, I'm a n00b.

I've got my own little http debian package repository.  It shows up with apt
and dselect.

In this repository I've got a custom package that I'm working on that depends
on a bunch of ldap stuff, and contains configuration files and installation
scripts to install and configure ldap for me.

In this package's control file are the following lines:

  Package: tiem.ldap-server-config
  Architecture: all
  Depends: slapd ldap-utils libnss-ldap libpam-ldap
  Pre-Depends: slapd ldap-utils libnss-ldap libpam-ldap

My problem is, according to dselect, there are no dependencies or
pre-dependencies listed, and apt won't try to install any of the depencies
before installing my package.

Other custom packages that I have built have their dependencies listed in
dselect, but not this one.  And I have both completely erased and rebuilt my
repository on the server and run "apt update" on the client several times.

I figure the problem is in one of two places.  Either:

a) There's a cache file somewhere that apt isn't updating when I type "apt
update", or

b) There's a file that needs to be updated on my repository -- even though
I've totally deleted and rebuilt the repository several times.

Anybody have any idea where I would go about finding out what's wrong?

Thanks for your help,

Michael Peek


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

Offer Of Hand Embroidery Badge & Emblems

[DM Embroidery]

Dear Sirs, We are really happy to approach you and want to be your dependable PRODUCERS regarding All Kinds of Military & Civil HAND EMBROIDERED Badges, Emblems, Crests,Insignia, Regalia, Logos, Sashes, Pennants, Patches, Family Crests,Coat of Arms, Bands, Ranks, Flags & All Uniform Accessories etc. We must want to know your interested items, so we shall send you Free of Cost Samples and Quotations. Please spare a few moments in considering our message and then see that how we are good to work with you smoothly.It is a fact that when u will see our quality, compare our prices, then u may change your mind and take a decision to work with us continuously.We must assure you that each shipment will be made well in-time and we shall keep you satisfy at each stage of business. Please work with us with full confidence and expand your business. Awaiting your valuable answer, for which we thank you very much in advance.BEST REGARDS,
 
Your Truly
 Mr.javeed Sadiq
 
Dm Embroidery
www.dmemb.com

Re: Apt, custom packages, and package dependencies

[Michael S. Peek]

I knew I would figure it out as soon as I sent this...  I forgot to put commas
between the package names in Depends and Pre-Depends.

Oops.

Nevermind, but thanks anyway.

Michael

> Hello developers, I'm a n00b.
> 
> I've got my own little http debian package repository.  It shows up with apt
> and dselect.
> 
> In this repository I've got a custom package that I'm working on that depends
> on a bunch of ldap stuff, and contains configuration files and installation
> scripts to install and configure ldap for me.
> 
> In this package's control file are the following lines:
> 
>   Package: tiem.ldap-server-config
>   Architecture: all
>   Depends: slapd ldap-utils libnss-ldap libpam-ldap
>   Pre-Depends: slapd ldap-utils libnss-ldap libpam-ldap
> 
> My problem is, according to dselect, there are no dependencies or
> pre-dependencies listed, and apt won't try to install any of the depencies
> before installing my package.
> 
> Other custom packages that I have built have their dependencies listed in
> dselect, but not this one.  And I have both completely erased and rebuilt my
> repository on the server and run "apt update" on the client several times.
> 
> I figure the problem is in one of two places.  Either:
> 
> a) There's a cache file somewhere that apt isn't updating when I type "apt
> update", or
> 
> b) There's a file that needs to be updated on my repository -- even though
> I've totally deleted and rebuilt the repository several times.
> 
> Anybody have any idea where I would go about finding out what's wrong?
> 
> Thanks for your help,
> 
> Michael Peek
> 


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

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

[Andreas Rottmann]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> 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.
>
I assume you mean GNOME 2, not guile-2.

To clarify the situation: I've included mininimal wrappers for GLib
that work with both GLib 1.x and GLib 2.x in G-Wrap, mainly to support
GnuCash. These wrappers are built against GLib 1.x, since currently
GnuCash/GNOME2 is not ready for prime-time, and GNOME2 programs
written in Guile should use the bindings of GLib in guile-gnome
anyway, since these are much more complete. When GnuCash/GNOME2
finally arrives, either G-Wrap has to build the GLib bindings against
GLib 2.x, or GnuCash has to switch to use guile-gnome.

So, we *can* finally get rid of gwrapguile, even before GnuCash/GNOME2
arrives.

Regards, Rotty
-- 
Andreas Rottmann | [EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL 
PROTECTED]
http://yi.org/rotty  | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint  | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62
v2sw7MYChw5pr5OFma7u7Lw2m5g/l7Di6e6t5BSb7en6g3/5HZa2Xs6MSr1/2p7 hackerkey.com

Any technology not indistinguishable from magic is insufficiently advanced.
   -- Terry Pratchett


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

Bug#330953: RFA: rocks -- Make network sockets reliable in a transparent way

[Guus Sliepen]

Package: wnpp
Severity: normal

I request an adopter for the rocks package.

The package description is:
 Rocks protect sockets-based applications from network failures, particularly
 failures common to mobile computing, including:
 .
  - Link failures (e.g., unexpected modem disconnection);
  - IP address changes (e.g., laptop movement, DHCP lease expiry);
  - Extended periods of disconnection (e.g., laptop suspension).
 .
 Rock-enabled programs continue to run after any of these events; their broken
 connections recover automatically, without loss of in-flight data, when
 connectivity returns. Rocks work transparently with most applications,
 including SSH clients, X window applications, and network service daemons.

The current package does not work at all anymore (although it still
builds from source). Upstream told me more than a year ago they would
fix it, but nothing has happened since then. I also think there are not
many users of this package. If noone adopts it, I will ask for its
removal.

-- 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.13-rc6
Locale: LANG=nl_NL, LC_CTYPE=nl_NL (charmap=ISO-8859-1)


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

Re: curl status update

[Marco d'Itri]

On Sep 30, Richard Atterer <[EMAIL PROTECTED]> wrote:

> remain OpenSSL for the foreseeable future, GnuTLS is allegedly still 
> slightly more buggy than OpenSSL (does anyone have any details?) and is 
> lacking some features.
If you had taken some time to investigate these claims you would have
discovered that they are either false or totally irrelevant for almost
every application.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

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

[Thomas Bushnell BSG]

Andreas Rottmann <[EMAIL PROTECTED]> writes:

> To clarify the situation: I've included mininimal wrappers for GLib
> that work with both GLib 1.x and GLib 2.x in G-Wrap, mainly to support
> GnuCash. These wrappers are built against GLib 1.x, since currently
> GnuCash/GNOME2 is not ready for prime-time, and GNOME2 programs
> written in Guile should use the bindings of GLib in guile-gnome
> anyway, since these are much more complete. When GnuCash/GNOME2
> finally arrives, either G-Wrap has to build the GLib bindings against
> GLib 2.x, or GnuCash has to switch to use guile-gnome.

It is simply not important to me to "get rid of things" for its own
sake.

I don't want to make potentionally destabilizing changes, and I
*especially* don't want to make changes like this which result in
upstream saying "you're totally on your own now."

I'm happy maintaining gwrapguile right now.  It's extremely stable and
isn't causing any problems that I know of.

Thomas


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

Re: Apt, custom packages, and package dependencies

[Thomas Bushnell BSG]

"Michael S. Peek" <[EMAIL PROTECTED]> writes:

> In this package's control file are the following lines:
>
>   Package: tiem.ldap-server-config
>   Architecture: all
>   Depends: slapd ldap-utils libnss-ldap libpam-ldap
>   Pre-Depends: slapd ldap-utils libnss-ldap libpam-ldap
>
> My problem is, according to dselect, there are no dependencies or
> pre-dependencies listed, and apt won't try to install any of the depencies
> before installing my package.

You need to separate the dependencies with commas.

Thomas


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

Re: Future of s390 port

[Bastian Blank]

On Mon, Sep 26, 2005 at 05:25:55PM +0200, Gerhard Tonn wrote:
> Due to lack of time I am not able to do the s390 porting work anymore. I 
> am looking for someone
> who is interested to take over the s390 port.

I'm interrested in taking over the s390 port.

Bastian

-- 
The best diplomat I know is a fully activated phaser bank.
-- Scotty


signature.asc
Description: Digital signature

Re: attention to bug 321435

[Bastian Blank]

On Fri, Sep 30, 2005 at 09:33:09AM -0500, Adam Thornton wrote:
>   It's not clear to me that the buildd  
> maintainer's duties exactly are, or, critically, how much time per  
> week it takes.

I'm able to handle the buildds. I already did that some time ago.

Bastian

-- 
Beam me up, Scotty!


signature.asc
Description: Digital signature

Re: attention to bug 321435

[Gerhard Tonn]

Thomas Bushnell BSG wrote:

Please see http://bugs.debian.org/321435.

This bug is that gs-gpl fails to work on s390.  I recall just seeing
a principal s390 developers say he was no longer doing the Debian s390
port.  I don't know what effect this has on the bug.

This bug is blocking a number of packages, at the very least, ifhp and
scummvm.  Something needs to happen...

I'm not sure what.


I have already looked into the bug and it seems to be a rather 
complicated issue. I will debug it in more detail this weekend.


Regards,
Gerhard


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

Re: time seen at top of /var/log/boot

[Dan Jacobson]

I'm curious about the times seen in /var/log/boot.
Please do
# perl -nwe 'next unless /Setting the System Clock/..
/System Clock set/; s/: S.*//;print' /var/log/boot
Wed Sep 28 08:18:54 2005
Wed Sep 28 00:18:54 2005

What is the timezone of first time?
No its not my BIOS time. It appears to be a timezone 4 timezones east
of New Zealand, GMT+16, i.e., out of this world. How about on your machine?


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

Bug#142164: Packages files should be in UTF-8

[Kurt Roeckx]

On Thu, Sep 29, 2005 at 11:32:13PM -0500, Manoj Srivastava wrote:
> reassign 142164 general
> thanks
> 
> Hi,
> 
> Just because a topic has been discussed on the policy
>  discussion list is not reason enough to assign the bug to
>  policy. 

Note that bug has been reassigned to the policy in 2003.  Spam
closed it, and it was just reopened.

>  This has nothing to do with creating a package, and certainly
>  not the place of policy  to lead out by mandating stuff. Again, this
>  problem needs to be worked out abd put into effect by the bits that
>  put the Package ile together, and once we have a working solution, we
>  can start examing the bits of policy that may need to be changed for
>  the solution.

I agree that the policy shouldn't mandate that the Packages
file should be encoded in UTF-8.  But I think it should say
the the control and changelog files are, and I believe that is in
the scope of the policy.  This would of course have as side
effect that the Packages file ends up as UTF-8 too.

Note it says that is is "recommended" to encode the changelog in
UTF-8 (C.2.2), it does not say any such thing about the control
file.  I think we should say that both should be encoded in
UTF-8, or maybe a must.  But we can change that to a must at a
later date.


Kurt



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

[Joey Hess]

Gerfried Fuchs wrote:
>  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?

It seemed a bit excessive to mail everyone just to get in touch with 286
maintainers. Also I like to encourage the proper use of debian-devel.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: pbuilder status update

[Joey Hess]

Junichi Uekawa wrote:
> debootstrap test:
> [FAIL] create-sid-debootstrap
> [FAIL] build-sid-dsh
> [FAIL] pdebuild-sid-dsh
> [FAIL] pdebuild-internal-sid-dsh
> [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

This suggests to me that you're not passing --resolve-deps to
debootstrap, which will always be necessary for it to work reliably for
unstable/testing.

Debootstrap has sucessfully installed unstable and testing in every one
of my daily tests for at least the last three months.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: attention to bug 321435

[Gerhard Tonn]

Gerhard Tonn wrote:

Thomas Bushnell BSG wrote:


Please see http://bugs.debian.org/321435.

This bug is that gs-gpl fails to work on s390.  I recall just seeing
a principal s390 developers say he was no longer doing the Debian s390
port.  I don't know what effect this has on the bug.

This bug is blocking a number of packages, at the very least, ifhp and
scummvm.  Something needs to happen...

I'm not sure what.



I have already looked into the bug and it seems to be a rather 
complicated issue. I will debug it in more detail this weekend.




For some reason a recompiled version works now. I have uploaded a binary 
NMU and will rebuild dependent packages tomorrow.


Gerhard


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

Re: pbuilder status update

[Junichi Uekawa]

Hi,

> > debootstrap test:
> > [FAIL] create-sid-debootstrap
> > [FAIL] build-sid-dsh
> > [FAIL] pdebuild-sid-dsh
> > [FAIL] pdebuild-internal-sid-dsh
> > [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
> 
> This suggests to me that you're not passing --resolve-deps to
> debootstrap, which will always be necessary for it to work reliably for
> unstable/testing.
> 
> Debootstrap has sucessfully installed unstable and testing in every one
> of my daily tests for at least the last three months.

Yes, I don't have --resolve-deps, in the hope that 
priorities are fixed by ftp-masters.

There needs to be a decision somewhere:
1. ignore priorities and go back to what it was before
 and make --resolve-deps the default in debootstrap
2. try to fix priorities/section


regards,
junichi


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

[Junichi Uekawa]

Hi,

> 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

It's not entirely clear from the posting, but all that's required 
on the maintainer part is to edit debian/control and change

debconf
to
debconf | debconf-2.0


I've tried to search for what debconf-2.0 specification is;
and how it's different from debconf, but it's not obvious.
What's missing from the picture is the changelog of debconf
specification (presumably from 1.0), and what's changed.




regards,
junichi


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

[Maurizio Lemmo - Tannoiser]

* lunedì 26 settembre 2005, alle 19:57, Joey Hess scrive:
> 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

Thank you Joey and sorry for that.
I'll prepare my package, and I'll ask my sponsor to upload it ASAP (i'm
a sponsored maintainer).

-- 
  Maurizio - Tannoiser - Lemmo
 Founder Member of ERLUG http://erlug.linux.it
---
Joyce: "They only don't have calories if I make them for you. Mom logic."
--Buffy the Vampire Slayer: Bad Girls


signature.asc
Description: Digital signature

Re: SoBeFOTO Has Received Your Email - PLEASE READ MESSAGE

[Cecile Castany]

Bonjour,

 

Pourquoi les prix en
dollars deviennent-il des euros sur le site e-bay

 

(ex : Sigma
70-200mm F2,8 DG APO HSM EX Nikon D2H/D70s/D50
Fabriqué au JAPON pas en Chine ! GARANTI Sigma
France !. 
$719.95
EUR 599.41
Fin : 08-oct.-05 00:20:33 donné ci-dessus

Lorsque
l’on click sur le lien nous allons sur le site où le prix devient 719.95
EUR, pourquoi ?

Y a-t-il
une erreur ?

 

Cécile

 

 

 

-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 
Envoyé : mercredi 28
septembre 2005 22:24
À : [EMAIL PROTECTED]
Objet : Nouveaux objets de
vos vendeurs favoris !

 


 
  
  
  
   

eBay
a envoyé ce message à cecile castany  (mimineetdede).
Le nom que vous avez saisi lors de votre inscription est inclus pour
montrer que ce message provient d'eBay. Pour en
savoir plus 

   
  
   
  
   




Sélections des Vendeurs favoris 


 




   
  
  Afficher toutes les Sélections des Vendeurs favoris
  Sélections de Big-Red-Photo
  4 objets affichés ; 310 objets en vente actuellement 
  
   

  


NEUF
Canon EF 28-105mm f/4-5.6 USM 28-105 f4-5.6 350D 
GARANTIE Constructeur 1 an + 3 ans GARANTIE
Mondiale!!!. 
$205.00
EUR 170.68
Fin : 08-oct.-05 00:20:34 Paris


 


  


NEUF
Sigma 24-135mm f/2.8-4.5 IF AF Nikon D70s D70 D50
Produit GARANTIE Pas Besoin de le Renvoyer
en CHINE/USA. 
$340.00
EUR 283.07
Fin : 08-oct.-05 00:20:34 Paris

   
   

 

   
   




 


 


 


 


 

   
   

  


Sigma
70-200mm F2,8 DG APO HSM EX Nikon D2H/D70s/D50
Fabriqué au JAPON pas en Chine ! GARANTI
Sigma France !. 
$719.95
EUR 599.41
Fin : 08-oct.-05 00:20:33 Paris


 


  


NEUF
Sigma 55-200mm 55-200 f4-5.6 DC Nikon D70 D100 D2H
SAV dans votre PAYS car NOS produits sont
GARANTIES !. 
$170.00
EUR 141.54
Fin : 08-oct.-05 00:20:33 Paris


 

   
   

  Visiter
la Boutique de ce vendeur : Big-Red-Photo


 

   
  
  
  
  
   
  Liens utiles
  Boutiques
  et vendeurs favoris - Suivez vos Boutiques et vendeurs favoris
  Rechercher
  sur eBay - Trouvez d'autres objets qui vous intéressent 
  Recherche
  approfondie - Trouvez les objets de vos Vendeurs favoris
  Mon eBay
  - Suivez vos activités d'achat et de vente depuis un point unique
  Forums
  - Obtenez de l'aide d'autres membres eBay
  Aide
  eBay - Trouvez les réponses à vos questions
  
  
  
  Règles d'achat et de vente
  
   

eBay ne vous demandera pas de fournir des données personnelles
telles que votre mot de passe ou votre numéro de carte de crédit par e-mail.
Comment protéger
votre compte. 
Merci d'utiliser eBay
! 

   
  
  
  
  
  
   

 
Cette
notification a été envoyée à [EMAIL PROTECTED], comme indiqué dans vos
Préférences de notification par e-mail. Pour ne plus recevoir cette
notification par e-mail, cliquez
ici. Si vous souhaitez recevoir cet e-mail au format texte uniquement, cliquez ici. eBay vous a envoyé cet e-mail car vos Préférences
de notification par e-mail indiquent que vous souhaitez recevoir des
informations concernant les Sélections des Vendeurs favoris. 
Si vous ne voulez plus recevoir d'informations
concernant les Sélections des Vendeurs favoris, il vous suffit de vous
désinscrire ou de changer vos préférences de notification par e-mail à
partir de Mon eBay > Mon compte > Préférences > Préférences de
notification par e-mail. Veuillez noter qu'il peut falloir jusqu'à 10 jours
pour que votre requête soit traitée. 
Pour toute question, veuillez consulter notre Règlement
sur le respect de la vie privée ainsi que nos Conditions
d'utilisation. 
Copyright
© 2005 eBay Inc. Tous droits réservés.
Les marques commerciales et marques mentionnées appartiennent à leurs
propriétaires respectifs. 
eBay
et le logo eBay sont des marques déposées de eBay Inc. 
La société eBay est située à 2145 Hamilton Avenue, San Jose, CA 95125 USA. 

   
  
  
  
 


 

 

--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.7/112 - Release Date: 26/09/2005

 

--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 /
Virus Database: 267.11.8/114 - Release Date: 28/09/2005

 








--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.9/115 - Release Date: 29/09/2005
 

  

bogus lintian warning

[Thomas Bushnell BSG]

The lintian warning source-contains-CVS-dir is bogus.

I agree that upstream should not put CVS in their tarballs.  But
sometimes they do.

When they do, it is a violation of Debian standards to remove it from
the orig.tar.gz file.  So there is no question of doing that.

If you remove the CVS files from your unpacked build directory, that's
well and good, but dpkg-source refuses to honor this, printing helpful
messages like 
dpkg-source: warning: ignoring deletion of directory stylesheet/CVS

Of course dpkg-source ignores these because the packaging manual says
that the .diff.gz can't specify deletions.  (Never mind that patch is
perfectly capable of handling deletions.)

So, it's a bogus warning.  It should be removed from lintian.

Thomas


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

Re: bogus lintian warning

[Laszlo Boszormenyi]

On Fri, 2005-09-30 at 23:34 -0700, Thomas Bushnell BSG wrote:
> The lintian warning source-contains-CVS-dir is bogus.
 It is not.

> I agree that upstream should not put CVS in their tarballs.  But
> sometimes they do.
 Unfortunately.

> When they do, it is a violation of Debian standards to remove it from
> the orig.tar.gz file.  So there is no question of doing that.
 Where do you read that? May be true, but can't remember any place ATM.

> If you remove the CVS files from your unpacked build directory, that's
> well and good, but dpkg-source refuses to honor this, printing helpful
> messages like 
> dpkg-source: warning: ignoring deletion of directory stylesheet/CVS
 That's correct. You should remove it from .orig.tar.gz .

> So, it's a bogus warning.  It should be removed from lintian.
 Changing the .orig.tar.gz is not forbidden. So the lintian warning can
stay IMHO. The same with .svn/ dirs, don't forget them if CVS/ is on
topic.

Regards,
Laszlo/GCS


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

Re: bogus lintian warning

[Russ Allbery]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> The lintian warning source-contains-CVS-dir is bogus.

> I agree that upstream should not put CVS in their tarballs.  But
> sometimes they do.

It's still useful for native packages, so it isn't completely bogus even
if one agrees with the point about non-native packages.  It would also be
a good idea to make sure such things didn't turn up in the diff (caused by
the Debian package maintainer importing the source into a revision control
system when packaging it and then not building the source package
properly, for instance).

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: bogus lintian warning

[Thomas Bushnell BSG]

Laszlo Boszormenyi <[EMAIL PROTECTED]> writes:

>> When they do, it is a violation of Debian standards to remove it from
>> the orig.tar.gz file.  So there is no question of doing that.

>  Where do you read that? May be true, but can't remember any place ATM.

What do you think "orig" means in "orig.tar.gz"?  We make a necessary
exception when an upstream tarball contains files that are not
DFSG-free (and then we relabel the name of the tarball accordingly);
otherwise, the whole *point* of the orig.tar.gz file is to be the
original upstream source.

>> If you remove the CVS files from your unpacked build directory, that's
>> well and good, but dpkg-source refuses to honor this, printing helpful
>> messages like 
>> dpkg-source: warning: ignoring deletion of directory stylesheet/CVS

>  That's correct. You should remove it from .orig.tar.gz .

Hogwash.  It should not be removed at all.

Next will you be saying that other bugs in upstream packaging should
be marked by lintian?  

It is not a mistake to have a CVS directory; lintian is declaring a
standard for *upstream* authors packaging practices, not Debian.
Having a "no CVS" warning makes as much sense as requiring packages to
have a README and an INSTALL in the top-level source directory.  

It does make sense to warn against Debian developers who have *added*
a CVS directory not present in the upstream source, but that's a
different matter.

Thomas


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

Re: bogus lintian warning

[Russ Allbery]

Laszlo Boszormenyi <[EMAIL PROTECTED]> writes:
> On Fri, 2005-09-30 at 23:34 -0700, Thomas Bushnell BSG wrote:

>> When they do, it is a violation of Debian standards to remove it from
>> the orig.tar.gz file.  So there is no question of doing that.

>  Where do you read that? May be true, but can't remember any place ATM.

I assume the reference is to the Developer's Reference, section 6.7.8.2,
which says in part:

There may be cases where it is desirable to repackage the source even
though upstream distributes a .tar.gz that could in principle be used
in its pristine form. The most obvious is if significant space savings
can be achieved by recompressing the tar archive or by removing
genuinely useless cruft from the upstream archive. Use your own
discretion here, but be prepared to defend your decision if you
repackage source that could have been pristine.

and the ftp-master reject FAQ, which says:

Repackage orig.tar.gz
  Do not repackage your orig.tar.gz unless you have to. If you need to
  remove files due to license issues - OK. But for example to have the
  directory in the tarball named pkgname-ver you DO NOT repackage.
  dpkg-source completely doesn't care about that.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: bogus lintian warning

[Thomas Bushnell BSG]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
>
>> The lintian warning source-contains-CVS-dir is bogus.
>
>> I agree that upstream should not put CVS in their tarballs.  But
>> sometimes they do.
>
> It's still useful for native packages, so it isn't completely bogus even
> if one agrees with the point about non-native packages.  It would also be
> a good idea to make sure such things didn't turn up in the diff (caused by
> the Debian package maintainer importing the source into a revision control
> system when packaging it and then not building the source package
> properly, for instance).

Quite right.

It is reasonable to warn about CVS directories that are not in the
upstream source.  (This includes, of course, native packages, since
there is no upstream source.)

It is also reasonable to warn about mentions of CVS files in patch
files, since dpkg-source -i can take care of those.

Those are different than the case I'm bothered by, and I have no
problem with those tests if they were to be added.

Thomas


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