Re: Mass bug filing: Dependency/file list predictability

[Russ Allbery]

Hendrik Sattler <[EMAIL PROTECTED]> writes:
> Am Freitag 20 Juli 2007 17:47 schrieb Russ Allbery:

>> So in addition to having a --with-krb5 flag specifying the paths to the
>> libraries, I also need to add a --without-* flag for every Kerberos
>> implementation that I support which disables probing for that
>> implementation?  That's kind of lame, and it also means that one would
>> prevent compilation against the generic mechglue layer by using
>> --without-heimdal, which is just weird.

> Can't you assign values to the --with- options? I imagine something like
>   --with-krb5=heimdal

--with-krb5 takes the path to the Kerberos libraries, not the name of the
Kerberos implementation.  This is needed for the common case of users who
build Kerberos themselves.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Bug#434029: ITP: qfsm -- A graphical tool for designing finite state machines

[Luca Brivio]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---

* Package name: qfsm
  Version : 0.44
  Upstream Author : Stefan Duffner <[EMAIL PROTECTED]>
* URL : http://qfsm.sourceforge.net
* License : GPL
  Description : A graphical tool for designing finite state machines

 Qfsm is a graphical editor for finite state machines written in C++ using Qt.
 Finite state machines are a model to describe complex objects or systems in
 terms of the states they may be in. In practice they can used to design
 integrated circuits or to create regular expressions, scanners or other
 program code.
 
 Current features of Qfsm are: 
 - Drawing, editing and printing of diagrams
 - Binary, ASCII and "free text" condition codes
 - Multiple windows
 - Integrity check
 - Interactive simulation
 - AHDL/VHDL/Verilog HDL/KISS export
 - State table export in Latex, HTML and plain text format
 - Ragel file export (used for C/C++, Java or Ruby code generation)

--
Luca Brivio


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

Re: Thoughts about the bug tracking system

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/20/07 17:52, Carl Fürstenberg wrote:
[snip]
> 
> The major problem with the current system, is that it requires that
> the reporter has access to a mail server, if they want to use the more
> easier variant by using reportbug script. their other alternative is
> to send an email from their webmail (I assume that they don't have
> access to an smtp server, and are prohibited to use one by them self
> by port 25 blocking) using a complicated syntax to be able to send
> "correct" reports.

That hasn't been true for at least 2 years.  "reportbug --configure"
will let you tell it to use your ISP's smtp server.

(Even so, you should configure your MTA to relay all outbound emails
to smtp.yourisp.net.  Why?  To show that you are more than Just A User.)

- --
Ron Johnson, Jr.
Jefferson LA  USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!

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

iD8DBQFGoVvvS9HxQb37XmcRAgcWAKC3x3y5pXTc2RCTv+NRvPvvVqiyUQCfc6mX
CmNDb8vELeUr9rxKBrWcqho=
=amSF
-END PGP SIGNATURE-


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

Re: Thoughts about the bug tracking system

[Carl Fürstenberg]

On 7/21/07, Osamu Aoki <[EMAIL PROTECTED]> wrote:


port 25 blocking may be circumvented using ssl(tls) access to smtp
server like one offered by gmail. Read the manpage of reportbug for its
command line options.

Many ISP now requests to use non-port 25 for outgoing mail.  That may
be accomodated by specifying port on command line of report bug.

If you are totally isolated from IP network, you can still use reportbug
with e.g. -M option to start mutt.  Then before sending the mail text
created, save mail text to a file and move it to other machine to send
it by mail or web mail.



That might be true, but wonder how many "non super technical" people
are able to do a stunt like that :)

I remember the first time I was using the reportbug, and I really
didn't know what to do when the email was just displayed in the
terminal.

/Carl


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

Re: Thoughts about the bug tracking system

[Sune Vuorela]

On 2007-07-20, Carl Fürstenberg <[EMAIL PROTECTED]> wrote:
> I don't know if there has been any discussions about some redesign of
> the system, to make it a bit more user friendly, but perhaps it's time

Please read up on the differences between 'user friendly' and 'beginner
friendly'

I am a user of the debian bts  -  and I consider it very userfriendly
for my use.

/Sune


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

Re: Thoughts about the bug tracking system

[Osamu Aoki]

Hi,

On Sat, Jul 21, 2007 at 12:52:43AM +0200, Carl Fürstenberg wrote:
> When I'm locking at the BTS, I sometimes get the feeling it was either
> designed a long time ago, or that it was designed by real hardcore
> developers. Not that it isn't effective, as when you have learned the
> whole system, you can query it pretty fast, but the threshold is
> pretty steep.
>
> I don't know if there has been any discussions about some redesign of
> the system, to make it a bit more user friendly, but perhaps it's time
> to do something? (or perhaps you only want "real" bug reports from
> "real" developers, and pass "users" to ubuntu or similar? :)).
>
> The major problem with the current system, is that it requires that
> the reporter has access to a mail server, if they want to use the more
> easier variant by using reportbug script. their other alternative is
> to send an email from their webmail (I assume that they don't have
> access to an smtp server, and are prohibited to use one by them self
> by port 25 blocking) using a complicated syntax to be able to send
> "correct" reports.

port 25 blocking may be circumvented using ssl(tls) access to smtp
server like one offered by gmail. Read the manpage of reportbug for its
command line options.

Many ISP now requests to use non-port 25 for outgoing mail.  That may
be accomodated by specifying port on command line of report bug.

If you are totally isolated from IP network, you can still use reportbug
with e.g. -M option to start mutt.  Then before sending the mail text
created, save mail text to a file and move it to other machine to send
it by mail or web mail.

> Perhaps I'm out on deep water here, but just wanted to give a thought.
> perhaps a web-based solution (with backward compabillity to current
> system) would be the most optimal solution?

The only ready made web interface input is to report SPAM on BTS.

Osamu

>
> p.s. if this is wrong list, please shoot me...

Thoughts about the bug tracking system

[Carl Fürstenberg]

When I'm locking at the BTS, I sometimes get the feeling it was either
designed a long time ago, or that it was designed by real hardcore
developers. Not that it isn't effective, as when you have learned the
whole system, you can query it pretty fast, but the threshold is
pretty steep.

I don't know if there has been any discussions about some redesign of
the system, to make it a bit more user friendly, but perhaps it's time
to do something? (or perhaps you only want "real" bug reports from
"real" developers, and pass "users" to ubuntu or similar? :)).

The major problem with the current system, is that it requires that
the reporter has access to a mail server, if they want to use the more
easier variant by using reportbug script. their other alternative is
to send an email from their webmail (I assume that they don't have
access to an smtp server, and are prohibited to use one by them self
by port 25 blocking) using a complicated syntax to be able to send
"correct" reports.

Perhaps I'm out on deep water here, but just wanted to give a thought.
perhaps a web-based solution (with backward compabillity to current
system) would be the most optimal solution?

/Carl Fürstenberg

p.s. if this is wrong list, please shoot me...

Re: [updated] Mass bug filing: Dependency/file list predictability

[Lucas Nussbaum]

On 20/07/07 at 10:22 +0200, Steinar H. Gunderson wrote:
> On Thu, Jul 19, 2007 at 02:13:26AM +0200, Steinar H. Gunderson wrote:
> > Full build logs are available at
> > http://people.debian.org/~sesse/enriched-chroot/ -- look at the bottom to
> > find the differences. Note that these builds were made some time ago, so 
> > they
> > might not be 100% up-to-date -- I will rebuild all affected packages in
> > latest sid versions before actually filing the bugs.
> 
> Here's the updated list with updated and in sync chroots; down to 263. I
> haven't filtered out the unsermake ones -- there are only five of them anyway
> (kxmleditor, knetworkanager, kpowersave, konserve, kde-style-polyester) from
> what I can see.

I'm surprised by the fact that you only found 263 broken packages. Have
you installed all packages listed as a Build-Dependancy in the Sources
file in your 'dirty' chroot?
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: Bug#433812: ITP: pssh -- Parallel versions of the OpenSSH tools

[Lucas Nussbaum]

On 19/07/07 at 18:07 -0400, Joey Hess wrote:
> Nico Golde wrote:
> > Do we need package descriptions anybody can understand even 
> > without knowing anything about the topic or what?
> 
> Compare the description for pssh as posted with the descriptions for
> what I assume are similar tools, clusterssh and dsh. 

Note that taktuk (also in the archive) is another similar package. The
description doesn't match 'ssh' currently, I'll fix this in the next
upload.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: Looking for new FTP assistants

[Oleg Verych]

>> This require some work from sender's side, how is using plain MUA<->ML
>> interaction. For things like Gmane or reportbug anti-spam rules are
>> customizable and known at least.
>
> While defending against spam is being long enough on user's side [0],
> why not to apply this little addition to sender's duty, hm?

Another idea is tickets for first message (thread start, opening bug
report {0}) and requirement to have in-reply-to in any other message.
It's already requirement in rfc2822(SHOULD) to have it in replies. What
is ticket, then? When one wants to send message{0}, request is sent to ML
handling service or watch dog (helper service), ack is sent. Then
replying on that message will bring in-reply-to header as a ticket.

Currently some tools (bts) don't make threads in bug report, i.e. do
not include reference on at least last message in bug report, while
producing manipulations. Changing this will have 100% chance to remove
anything non related, unless more intelligent noise maker will appear.



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

Re: [updated] Mass bug filing: Dependency/file list predictability

[Steinar H. Gunderson]

On Fri, Jul 20, 2007 at 06:50:03PM +0200, Alexander Schmehl wrote:
> Could it be, that you are now filtering to strict?  I could swear, that
> when I looked at the list yesterday I saw fillets-ng which had a new lib
> according to the log...

It seems fillets-ng was never completely built in the second run, most likely
due to some error on the buildd (the scripts are rather shaky). I'd expect it
is still buggy.

In any case, I hope to be able to move to a lot more stable framework for the
next rebuild; the plan is to make these more or less regularly, so don't
worry, if a package is missed this time, it probably won't the next. :-)

> You still had the old logs?

They're still on http://peopple.debian.org/~sesse/enriched-chroot/ .

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


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

Re: Mass bug filing: Dependency/file list predictability

[Hendrik Sattler]

Am Freitag 20 Juli 2007 17:47 schrieb Russ Allbery:
> So in addition to having a --with-krb5 flag specifying the paths to the
> libraries, I also need to add a --without-* flag for every Kerberos
> implementation that I support which disables probing for that
> implementation?  That's kind of lame, and it also means that one would
> prevent compilation against the generic mechglue layer by using
> --without-heimdal, which is just weird.

Can't you assign values to the --with- options? I imagine something like
  --with-krb5=heimdal

Since you can only give one value there, it doesn't need any extra option and 
is mutually exclusive. Some configure should should detect the different 
possibilites though and fail if the chosen one is not detected.

HS


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

Re: Bug#433812: ITP: pssh -- Parallel versions of the OpenSSH tools

[Andrew Pollock]

On Thu, Jul 19, 2007 at 11:37:23PM +0200, Josselin Mouette wrote:
> Le jeudi 19 juillet 2007 à 09:02 -0700, Andrew Pollock a écrit :
> >   Description : Parallel versions of the OpenSSH tools
> 
> >  These tools are good for controlling large collections of nodes, where 
> > faster
> >  alternatives such as gexec and pcp are not available.
> 
> What does this software bring over pdsh ?

The person who asked me to package it tells me prsync (at least).

regards

Andrew


signature.asc
Description: Digital signature

Re: [updated] Mass bug filing: Dependency/file list predictability

[Alexander Schmehl]

Hi!

* Steinar H. Gunderson <[EMAIL PROTECTED]> [070720 10:22]:

[..]
> Alexander Schmehl <[EMAIL PROTECTED]>
>ht

Could it be, that you are now filtering to strict?  I could swear, that
when I looked at the list yesterday I saw fillets-ng which had a new lib
according to the log...

You still had the old logs?


Yours sincerely,
  Alexander

-- 
http://learn.to/quote/
http://www.catb.org/~esr/faqs/smart-questions.html


signature.asc
Description: Digital signature

Bug#433954: RFP: softflowd -- Flow-based network traffic analyser

[Florian Weimer]

Package: wnpp
Severity: wishlist

* Package name: softflowd
  Version : 0.9.8
  Upstream Author : Damien Miller <[EMAIL PROTECTED]> et.al.
* URL : http://www.mindrot.org/projects/softflowd
* License : BSD
  Description : Flow-based network traffic analyser

Quoting the URL above:
 Softflowd is a flow-based network traffic anaylser capable of Cisco
 Netflow data export. Softflowd semi-statefully tracks traffic flows
 recorded by listening on a network interface or by reading a packet
 capture file. These flows may be reported via NetFlow to a collecting
 host or summarised within softflowd itself.

-- 
Florian Weimer<[EMAIL PROTECTED]>
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Bug#433955: ITP: libperl6-junction-perl -- Perl6 style Junction operators in Perl5.

[Krzysztof Krzyzaniak (eloy)]

Package: wnpp
Severity: wishlist
Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]>


* Package name: libperl6-junction-perl
  Version : 1.3
  Upstream Author : Carl Franks
* URL : http://www.cpan.org/
* License : Perl (GPL/Artistic)
  Programming Lang: Perl
  Description : Perl6 style Junction operators in Perl5.

 Perl6::Junction is a lightweight module which provides 'Junction' operators,
 the most commonly used being any and all.
 .
 Inspired by the Perl6 design docs, 
 http://dev.perl.org/perl6/doc/design/exe/E06.html.
 .
 Provides a limited subset of the functionality of Quantum::Superpositions.

 This package is needed for uploading new version of libdata-formvalidator-perl

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core)
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/bash


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

Re: Can we require build-arch/indep targets for lenny?

[Russ Allbery]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> writes:

>> I really don't think that declaring the majority of packages in Debian
>> buggy in this fashion is viable, particularly when nearly all packages
>> in Debian will not benefit from this.  My guess is that something on
>> the order of 1% of packages have a meaningful distinction between
>> build-arch and build-indep, if that, but that includes some packages
>> that benefit a *lot*.  Wouldn't it be better to only have to work on
>> modifying the packages that will specifically benefit instead of making
>> every other package maintainer in Debian add a new target that really
>> isn't meaningful for their package?

> Already 25% of all packages do have the targets and I assume a lot
> more than 1% to benefit.

I'd be curious to see your reasoning there.

All of my packages have build-arch and build-indep targets.  None of them
benefit from them at all.  I expect many other people have similarly added
the targets just because, or have the targets provided by a build system
such as CDBS, even though they don't benefit.

> Weigh that against the cost, adding a % to the build target or adding
> 'build-%: build', for the packages without meaningful distinction.

As many people have previously pointed out, that's not the real cost.

I really don't see any justification for forcing all packages to change
when we have a proposed solution that lets only the packages that benefit
change.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Mass bug filing: Dependency/file list predictability

[Russ Allbery]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> writes:

>> I don't know of any Kerberos software, among dozens of packages, that
>> works this way.  This simply isn't how multiple Kerberos
>> implementations have ever been handled; they all just check for Heimdal
>> and MIT Kerberos and use whichever one is found.  This has always
>> worked in the past since Heimdal and MIT Kerberos dev packages conflict
>> with each other (not only in Debian but everywhere else as well).  Now
>> we're adding a new, rather useless GSSAPI library that uses the same
>> library names as Heimdal but doesn't actually work and doesn't conflict
>> with MIT Kerberos.

> Maybe then the gssapi-dev should also conflict?

It doesn't really have a technical reason for conflicting other than that
it breaks the assumptions of existing configure scripts, so I understand
why the maintainer didn't set it up that way.

> In the test if libheimdal exists you first check if --with-heimdal (or
> --without) was used and only otherwise do the actual test. [Or you can
> test and see if it finds a lib if --with-heimdal was given and file if
> not].

So in addition to having a --with-krb5 flag specifying the paths to the
libraries, I also need to add a --without-* flag for every Kerberos
implementation that I support which disables probing for that
implementation?  That's kind of lame, and it also means that one would
prevent compilation against the generic mechglue layer by using
--without-heimdal, which is just weird.

The root problem is that the generic mechglue layer is indistinguishable
from Heimdal, at least so far as I know.  Maybe I can figure out some
other symbol to check (that isn't internal) to determine that it's not
Heimdal and disqualify it.

The whole point of Kerberos implementations, and, for that matter, GSS-API
implementations, is that they're supposed to be interchangeable and
implement the same API precisely so that users aren't subjected to this
sort of thing and software just quietly builds with what you have
installed on your system.  I guess that points to the other basic problem,
which is that distribution packaging is a special case and probably needs
its own solution.

I guess I could add a --without-heimdal (and --without-mit) specifically
for distributions and just advise normal users to ignore those flags
unless they have the same problem of multiple libraries installed in the
same prefix.

It's tempting to just Build-Conflict with libgssapi-dev, though.  It's a
lot less work and I'm not sure I believe in the likelihood of this problem
for anyone outside of Debian.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Mass bug filing: Dependency/file list predictability

[Russ Allbery]

Gabor Gombas <[EMAIL PROTECTED]> writes:

> Ideally everything should use libgssapi2 (or some other mechglue
> implementation) and nothing should build directly aginst the
> Kerberos-specific GSSAPI implementations.

Your statement is true for software that really doesn't care what GSS-API
mechanism it uses, which is true of only a tiny minority of GSS-API
software out there right now.  For the most part, GSS-API is being used to
negotiate Kerberos authentication.

> The only question is how hard it would be to make Heimdal work with
> libgssapi2. I know there was some mechglue-related work in Heimdal but I
> did not follow that.

Getting it to work with Heimdal does nothing for me.  The default Kerberos
implementation in Debian is MIT, which already provides its own generic
mechglue implementation.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Bug#433939: ITP: jfreereport -- java class library for generating reports

[Arnaud Vandyck]

X-Debbugs-CC: [EMAIL PROTECTED], debian-devel@lists.debian.org
Package: wnpp
Owner: Arnaud Vandyck <[EMAIL PROTECTED]>
Severity: wishlist

* Package name: jfreereport
 Version : 0.9.1
 Upstream Authors :
 dkincade 
 Dave Waddell 
 ELassad 
 Gretchen Moran 
 Schoemer, Joerg 
 Michael D'Amour 
 Mimil 
 Michael Tennes 
 David Gilbert 
 Ocke Janssen 
 Piotr Bzdyl 
 Taq 
 Martin Schmid 
 Will Gorman 
* URL or Web page : http://reporting.pentaho.org/development/
http://sourceforge.net/projects/jfreereport/
* License : GNU Library or Lesser General Public License (LGPL)
 Description : java class library for generating reports
XML-based templates provide flexible reporting and printing
functionality using data from multiple sources and supports output to
display devices, printers, PDF, Excel, HTML, XHTML, PlainText, XML and
CSV files.


A lot of source packages will be needed:
http://sourceforge.net/project/showfiles.php?group_id=51669

This package is needed for pentaho-reportdesigner and OpenOffice

--
Arnaud Vandyck


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

Re: Bug#433791: ITP: telaen -- simple and fast webmail

[Thijs Kinkhorst]

On Thursday 19 July 2007 15:08, Joao Eriberto Mota Filho wrote:
> Telaen is a web-based e-mail client written in PHP. It is fast, lean and
> simple, but also extremely powerful.

This seems a bit buzzworded to me: "extremely" powerful? Yet "fast", "lean" 
and "simple"? A more factual description of what it can and cannot do might 
be more appropriate.

> Telaen was originally based on Uebimiau and runs under any server
> supporting PHP with Sendmail or QMAIL.

The two most used mailservers in Debian are Postfix and Exim. Most probably 
Telaen works with them too, but it seems a bit strange to mention sendmail 
and qmail explicitly in that case.


Thijs


pgpZVTmtY02UC.pgp
Description: PGP signature

Re: Bug#433472: ITP: dirbuster -- Directory & file brute forcing, with a twist

[Kevin B. McCarty]

Tim Brown wrote:

>   Description : Directory & file brute forcing, with a twist
> 
> DirBuster is a multi threaded java application designed to brute force
> directories and files names on web/application servers. Often is the case
> now of what looks like a web server in a state of default installation is
> actually not, and has pages and applications hidden within. DirBuster
> attempts to find these

What's the "twist"?

Just as a wording nitpick, I would rewrite the second sentence as
"Often, a web site that still displays the web server's default
installation page actually has real web pages, data, and applications
hidden within."

best regards,

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544


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

Injection mold maker from China

[April/KingTech]

Dear Sir,

 

We learned your information from internet and now writing to you for the
possibility of business cooperation. 

 

KingTech Mould is a professional Mould maker, Designer and Molding factory
in China, which is certified and committed to the comprehensive ISO 9001
quality system standard. We are familiar with all kinds of international
mould building standards, and export hundreds sets of moulds every year to
United state, Europe….

 

Our engineering and mould-making technology include:

1. Pro/ENGINEER (3D Modeling)

2. SolidWorks (3D Modeling)

3. AutoCAD (2D Modeling)

4. MoldFlow Mold Advisor (Plastic flow/deform simulation)

5. MasterCAM (CNC Programming)

6. Unigraphics (CNC Programming)

7. CNC Machining Center (1600*1400mm)

8. CNC EDM (Electro-Discharge Machining)

9. Wire-Cut Machines

10. Injection Machine Center

 

File Type:

1.3D - native Solid Works .PRT or step or IGES or SAT

2.2D - native Cadkey .PRT or DXF or DWG

 

Mold standards

1.Mold Steel:  ASSAB (Sweden), DAIDO (Japan), FINKL(America),AUBERT
& DUVAL(France), GS（Germany）, LKM (China)

2.Mold Base:  DME, HASCO, FUTABA, LKM.

3.Hot Runner: MOULD MASTER, Master TIP, HUSKY, HASCO, DME, YUDO,
INCOE, THERMOPLAY

4.Standard Parts:  DME, HASCO, NEAREST ANSI STANDARD, NEAREST DIN
STANDARD, LKM

5.Texture: Mold-tech, Yick Sang, Tanazawa etc

 

For more details, please visit our website http://www.kingtech-mould.com
  .If you have any interests or RFQ, please
contact us. We are ready for you in real-time.

 

Thanks and best wishes。

 

 

April 

 

KING TECH MOULD CO., LIMITED 

Tel: 0086-755-86182410

Fax: 0086-755-86182740

E-mail:[EMAIL PROTECTED]

  Msn: [EMAIL PROTECTED]


Add: 9E New Hold found Building, Shennan Road, Nanshan District, Shenzhen,
China 



   Our goal is to provide the Highest quality, On-time delivery and
Cost-Effective solution to achieve your tooling and molding demands.

 4 to 6 weeks
delivery promised according to your requirement.

 

 

Re: Mass bug filing: Dependency/file list predictability

[Gabor Gombas]

On Thu, Jul 19, 2007 at 11:02:39AM -0700, Russ Allbery wrote:

> Now, I'm willing to lead the way for Kerberos packages going forward, I
> guess, if I can figure out a good way to do that, but I don't know how
> that configure logic would even work or what those --with flags would look
> like.  The problem would be avoided if I required krb5-config be
> available, but I don't really want to do that, both because older versions
> of Kerberos don't have it and because krb5-config adds a bunch of needless
> shared library dependencies that create unnecessary interpackage
> dependencies in Debian.

Ideally everything should use libgssapi2 (or some other mechglue
implementation) and nothing should build directly aginst the
Kerberos-specific GSSAPI implementations. That would allow users to
select at run-time between different Kerberos versions or use other
GSSAPI implementations. It would also solve the dependency problems you
mentioned.

The only question is how hard it would be to make Heimdal work with
libgssapi2. I know there was some mechglue-related work in Heimdal but I
did not follow that.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: RFH: Removals - outstanding bugs need to be analysed

[Don Armstrong]

On Fri, 20 Jul 2007, Magnus Holmgren wrote:
> I find that "From other Branch bugs" label confusing, not to mention
> what an ordinary user would make of it. When, exactly, is a bug
> categorised as "From other Branch"? It's not just when the package
> has been removed, from what I've seen, I think.

From other branch means that the bug does not apply to the
distribution of debian which you have indicated, either because the
bug is neither found nor fixed in the version in that distribution, or
because that distribution does not distribute that package.

The latter case is when the package has been removed.

In the bug status parlance, such bugs are called 'absent'.


Don Armstrong

-- 
This message brought to you by weapons of mass destruction related
program activities, and the letter G.

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

Re: RFH: Removals - outstanding bugs need to be analysed

[Magnus Holmgren]

On Friday 20 July 2007 12:19, Don Armstrong wrote:
> On Fri, 20 Jul 2007, Magnus Holmgren wrote:
> > It would be nice, I think, if the BTS would automatically notice
> > when a package has been removed from unstable and annotate the bugs
> > appropriately.
>
> It actually already does this; see
>
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=exim;dist=unstable
>
> for an example.

I find that "From other Branch bugs" label confusing, not to mention what an 
ordinary user would make of it. When, exactly, is a bug categorised as "From 
other Branch"? It's not just when the package has been removed, from what 
I've seen, I think.

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)

  "Exim is better at being younger, whereas sendmail is better for 
   Scrabble (50 point bonus for clearing your rack)" -- Dave Evans


pgpk63Nq19iAv.pgp
Description: PGP signature

Re: RFH: Removals - outstanding bugs need to be analysed

[Don Armstrong]

[this seemed to have been eaten; resending]

On Wed, 18 Jul 2007, Martin Michlmayr wrote:
> * Stefan Fritsch <[EMAIL PROTECTED]> [2007-07-18 18:31]:
> > is it really a good idea to close the bug reports while the packages
> > are still in stable? Shouldn't they be left open for reference until
> > etch is at least oldstable?
> 
> I don't believe leaving them open is a great idea because bug
> submitters should be informed that these packages are no longer
> supported.  However, it would be nice if BTS's version tracking would
> show the status of these bugs properly.

The bugs should be closed in the last version which was present in
unstable if they no longer exist. That way they'll be shown as present
in stable.

If they're closed without a Version: pseudoheader, the BTS will assume
that the bug was closed for all versions.


Don Armstrong

-- 

The signature formerly in this location has been deemed to offensive
for audiences under the age of 18. In it's place, we offer the
following koan: Why is a mouse when it spins?

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


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

Re: Bug#433812: ITP: pssh -- Parallel versions of the OpenSSH tools

[Hamish Moffatt]

On Fri, Jul 20, 2007 at 07:25:21AM +0200, Christian Perrier wrote:
> I just completed the translation of a few Hamradio packages and, wow,
> the hamradio jargon they use is about as intelligible as Sanskrit to
> me...:-). It even sometimes takes ages before one can *understand*
> that the package deals with hamradio.

That's an interesting point. These applications are in their own section
(hamradio) so we assume a certain lingo that most of the target audience
would understand. 

Is this reasonable? We could explain in more detail, it's probably true
that if you don't understand the description, the package isn't what
you're looking for (within the hamradio section).


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


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

Re: RFH: Removals - outstanding bugs need to be analysed

[Don Armstrong]

On Fri, 20 Jul 2007, Magnus Holmgren wrote:
> It would be nice, I think, if the BTS would automatically notice
> when a package has been removed from unstable and annotate the bugs
> appropriately.

It actually already does this; see

http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=exim;dist=unstable

for an example.


Don Armstrong

-- 
One day I put instant coffee in my microwave oven and almost went back
in time.
 -- Steven Wright

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


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

Re: debdelta service back on track

[A Mennucc]

hi

Mark Brown ha scritto:
> On Tue, Jul 17, 2007 at 11:23:53AM +0200, A Mennucc wrote:
> 
>> The problem was due to a subtle change in zlib1g: in newer versions, the
>> compressed output has 0x02 instead of 0x00 at the 10th byte (that is in
>> the header). This change occurred somewhere between version 1.2.3-13 and
>> 1.2.3.3.dfsg-5 .
> 
> Byte 10 is the XFL field which contains compression method specific
> flags.  For deflate a value of two indicates that the compressor was
> aiming for maximum compression and a value of zero indicates nothing in
> particular.  The code was previously not bothering to provide any
> information about how hard it was trying to compress things.

thanks for the explanation (I was too lazy to go look into it myself :-)

>>  Since dpkg-deb uses zlib1g, this changed the .deb files. So a file
>> reconstructed by "debpatch" would be different with the original in 2
>> bytes.
> 
> Two bytes?

a .deb file is an "ar" archive containing both a control.tar.gz and a
data.tar.gz


BTW: let me remind that one goal of debdelta is to obtain "perfect
reconstruction". The change in zlib1g did break "perfect
reconstruction"; but the reconstructed .deb files were OK in all other
respects.

>> I have added a workaround for that problem in 'debdelta' version 0.21 ,
>> and I have installed it in the server that prepares deltas for
>> 'debdelta-upgrade' . Now it should work again as expected. (If it does
>> not, mail me, or send a bug in the BTS).
> 
> I'm not sure exactly what debdelta is doing here but it sounds like
> it ought to have specific code for handing the reconstruction of this
> header in order to be robust against reasonable upstream changes.

that is what I did. Currently  a delta file also saves the header file
and then puts it back forcibly.

> There
> are several fields in there which are informational and could be varied
> by the compressor pretty much at will.

debdelta relies on the fact that dpkg-deb uses zlib1g to compress
control.tar.gz and a data.tar.gz ; so debdelta calls "minigzip", that
obtains the same exact result - unless zlib1g changes, of course.


"debdelta" currently is not robust w.r.t. strong changes in zlib1g ...
the only way to achieve robustness would be that I should ship a copy of
the source code of zlib1g inside the debdelta package (but that is
inconvenient in other respects).

a.



signature.asc
Description: OpenPGP digital signature

Re: RFH: Removals - outstanding bugs need to be analysed

[Magnus Holmgren]

On Wednesday 18 July 2007 18:31, Stefan Fritsch wrote:
> Bugs that affect the newer upstream versions could be cloned, of
> course.

Bugs that affect the newer upstream versions should already have been cloned 
or filed against both packages from the beginning. That doesn't always 
happen, of course.

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)

  "Exim is better at being younger, whereas sendmail is better for 
   Scrabble (50 point bonus for clearing your rack)" -- Dave Evans


pgpbFaTSRYi4I.pgp
Description: PGP signature

Re: RFH: Removals - outstanding bugs need to be analysed

[Magnus Holmgren]

On Wednesday 18 July 2007 21:47, Martin Michlmayr wrote:
> * Stefan Fritsch <[EMAIL PROTECTED]> [2007-07-18 18:31]:
> > is it really a good idea to close the bug reports while the packages
> > are still in stable? Shouldn't they be left open for reference until
> > etch is at least oldstable?
>
> I don't believe leaving them open is a great idea because bug
> submitters should be informed that these packages are no longer
> supported.  However, it would be nice if BTS's version tracking would
> show the status of these bugs properly.  I'm not sure it'll handle the
> situation correctly though. (CCing Don.  The question is what happens
> to the status of a bug belonging to a package that was removed from
> the archive and where the bug was closed by mail to -done w/o Version
> info)

It would be nice, I think, if the BTS would automatically notice when a 
package has been removed from unstable and annotate the bugs appropriately. 
It can happen that a dead package chooses to walk the earth again, can't it 
(not in these cases, but in some)?

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)


pgpBBPUGBkAGR.pgp
Description: PGP signature

Re: Mass bug filing: Dependency/file list predictability

[Michael Biebl]

Steinar H. Gunderson schrieb:
> On Fri, Jul 20, 2007 at 12:31:57AM +0200, Michael Biebl wrote:
>>> Michael Biebl <[EMAIL PROTECTED]>
>>>knetworkmanager
>>>kpowersave
>> These two are affected because of unsermake being installed and so the
>> build fails completely.
> 
> Define "fails completely". The build creates a .deb, it just loses a lot of

Well, the make (install) run doesn't produce anything. The deb thus is
completely empty (besides stuff that is installed by dh_* tools).

> files and dependencies. Should not the build fail in this case, then, instead
> of dying silently?

Well, that is an issue of cdbs and unsermake. Something I cant really
control. But as I said, please just wait, until unsermake has been
removed and these problems will vanish automatically.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Mass bug filing: Dependency/file list predictability

[Thijs Kinkhorst]

On Friday 20 July 2007 00:31, Michael Biebl wrote:
> These two are affected because of unsermake being installed and so the
> build fails completely.
> unsermake though is scheduled/requested to be removed [1].
> So please, don't file bugs for these two packages or better, wait until
> unsermake has been removed and rerun the test, so I actually have build
> results that I can compare.

A removed package will not be automatically removed from user's systems. It 
could make sense to add a build-conflicts on unsermake for this. Especially 
when the package is actually removed this shouldn't have a high cost, but can 
prevent build problems.


Thijs


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

Re: libquicktime transition

[Steve Langasek]

Hi Fabian,

On Thu, Jul 19, 2007 at 09:52:03PM +0200, Fabian Greffrath wrote:
> finally (and thanks to Lioc Minier a.o.) the new upstream version 1.0.0
> of the libquicktime library has made it into Debian unstable.

> The library involves an ABI change relative to its successor 0.9.7 and
> had its soname bumped. I already asked all maintainers of rdepending
> packages to test-build against the new library when it was still in
> experimental. Since obviously no issues occured, I expect the transition
> to run smooth. The affected packages should however be rebuilt/bin-NMUd
> against the new version:

> Roland Mas <[EMAIL PROTECTED]> (smilutils)

The timing is unfortunate, because smilutils is already tied to the glib1.2
transition and had not yet been built on all architectures.  So these two
library transitions now appear to be linked.  Fortunately the set of
reverse-deps for libquicktime is fairly small, so this probably won't have
too much of an effect on the timing as long as other library transitions
don't surprise us mid-process.

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


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

Re: [updated] Mass bug filing: Dependency/file list predictability

[Steinar H. Gunderson]

On Thu, Jul 19, 2007 at 02:13:26AM +0200, Steinar H. Gunderson wrote:
> Full build logs are available at
> http://people.debian.org/~sesse/enriched-chroot/ -- look at the bottom to
> find the differences. Note that these builds were made some time ago, so they
> might not be 100% up-to-date -- I will rebuild all affected packages in
> latest sid versions before actually filing the bugs.

Here's the updated list with updated and in sync chroots; down to 263. I
haven't filtered out the unsermake ones -- there are only five of them anyway
(kxmleditor, knetworkanager, kpowersave, konserve, kde-style-polyester) from
what I can see.


Guenter Geiger (Debian/GNU) <[EMAIL PROTECTED]>
   jack-rack

Marc Dequènes (Duck) <[EMAIL PROTECTED]>
   pyopenal

Anibal Avelar (Fixxxer) <[EMAIL PROTECTED]>
   centericq
   idesk

Laszlo Boszormenyi (GCS) <[EMAIL PROTECTED]>
   tuxeyes

Adam Cécile (Le_Vert) <[EMAIL PROTECTED]>
   aqualung
   audacious-plugins

J.H.M. Dassen (Ray) <[EMAIL PROTECTED]>
   traceproto

Richard A Nelson (Rick) <[EMAIL PROTECTED]>
   libnss-ldap

Daniel Leidert (dale) <[EMAIL PROTECTED]>
   gnome-chemistry-utils

Masayuki Hatta (mhatta) <[EMAIL PROTECTED]>
   insight

Jari Aalto <[EMAIL PROTECTED]>
   jwm

Michael Ablassmeier <[EMAIL PROTECTED]>
   streamripper

Moray Allan <[EMAIL PROTECTED]>
   matchbox-window-manager

Russ Allbery <[EMAIL PROTECTED]>
   sident

Bill Allombert <[EMAIL PROTECTED]>
   flwm

Ben Armstrong <[EMAIL PROTECTED]>
   xletters
   xpilot-ng

Khalid Aziz <[EMAIL PROTECTED]>
   kexec-tools

Wolfgang Baer <[EMAIL PROTECTED]>
   kaffe (U)

Jeff Bailey <[EMAIL PROTECTED]>
   mailutils (U)

Michael Banck <[EMAIL PROTECTED]>
   gnome-chemistry-utils (U)

Dima Barsky <[EMAIL PROTECTED]>
   m2crypto

Daniel Baumann <[EMAIL PROTECTED]>
   cdrdao
   ipac-ng
   libextractor-python
   libungif4

Christian Bayle <[EMAIL PROTECTED]>
   cvsnt (U)

Edelhard Becker <[EMAIL PROTECTED]>
   netrik

Dave Beckett <[EMAIL PROTECTED]>
   cairomm
   cairomm (U)

Bradley Bell <[EMAIL PROTECTED]>
   kaptain
   libgdamm1.3

Hilko Bengen <[EMAIL PROTECTED]>
   nail

Chris Vanden Berghe <[EMAIL PROTECTED]>
   ccrypt

Jon Bernard <[EMAIL PROTECTED]>
   e16menuedit2

Edward Betts <[EMAIL PROTECTED]>
   gcal

Michael Biebl <[EMAIL PROTECTED]>
   knetworkmanager
   kpowersave

Eduard Bloch <[EMAIL PROTECTED]>
   lufs

Phil Blundell <[EMAIL PROTECTED]>
   dillo (U)

Jay Bonci <[EMAIL PROTECTED]>
   libimager-perl

Fathi Boudra <[EMAIL PROTECTED]>
   kbfx (U)
   kdeadmin (U)
   kftpgrabber (U)
   ksynaptics (U)
   kvpnc (U)

John Bovey <[EMAIL PROTECTED]>
   libnjb

Chris Boyle <[EMAIL PROTECTED]>
   klogic

Paul Brossier <[EMAIL PROTECTED]>
   freewheeling

Mark Brown <[EMAIL PROTECTED]>
   ftnchek

Matt Brown <[EMAIL PROTECTED]>
   libtrace3

Luca Bruno <[EMAIL PROTECTED]>
   gtk-gnutella
   istanbul

Ross Burton <[EMAIL PROTECTED]>
   onak (U)

Giacomo Catenazzi <[EMAIL PROTECTED]>
   knapster2

Cyril Chaboisseau <[EMAIL PROTECTED]>
   qgo

Pierre Chifflier <[EMAIL PROTECTED]>
   prelude-lml (U)
   prelude-manager (U)

Volker Christian <[EMAIL PROTECTED]>
   orange

Luk Claes <[EMAIL PROTECTED]>
   ht (U)

Rodrigo Tadeu Claro <[EMAIL PROTECTED]>
   kpreg

Isaac Clerencia <[EMAIL PROTECTED]>
   kdeadmin (U)
   kdebindings (U)
   kdemultimedia (U)

Adam Conrad <[EMAIL PROTECTED]>
   apr (U)

Kevin Coyner <[EMAIL PROTECTED]>
   bbtime

Paul Cupis <[EMAIL PROTECTED]>
   guidedog

Gerardo Curiel <[EMAIL PROTECTED]>
   swi-prolog

Artur R. Czechowski <[EMAIL PROTECTED]>
   rrdcollect

Vincent Danjean <[EMAIL PROTECTED]>
   hgsvn
   mercurial
   tailor

Julien Danjou <[EMAIL PROTECTED]>
   lirc (U)

LI Daobing <[EMAIL PROTECTED]>
   qterm

Debian Apache Maintainers <[EMAIL PROTECTED]>
   apr

Debian Bluetooth Maintainers <[EMAIL PROTECTED]>
   bluez-gnome

Debian Cryptsetup Team <[EMAIL PROTECTED]>
   cryptsetup

Debian GGZ Maintainers <[EMAIL PROTECTED]>
   ggz-kde-client

Debian Hamradio Maintainers <[EMAIL PROTECTED]>
   kptc
   phaseshift
   qsstv

Debian Hebrew Packaging Team <[EMAIL PROTECTED]>
   kkbswitch

Debian Java Maintainers <[EMAIL PROTECTED]>
   kaffe

Debian KDE Extras Team <[EMAIL PROTECTED]>
   basket
   kbfx
   kftpgrabber
   krename
   ksynaptics
   kvpnc

Debian Nagios Maintainer Group <[EMAIL PROTECTED]>
   nsca

Debian Python Modules Team <[EMAIL PROTECTED]>
   ipy
   pydb (U)
   pyopenal (U)

Debian Qt/KDE Maintainers <[EMAIL PROTECTED]>
   kdeadmin
   kdebindings
   kdemultimedia
   kdenetwork

Debian Ruby Extras Maintainers <[EMAIL PROTECTED]>
   libwww-mechanize-ruby (U)

Debian Scientific Computing Team <[EMAIL PROTECTED]>
   qd

Debian Telepathy maintainers <[EMAIL PROTECTED]>
   telepathy-salut

Debian VoIP Team <[EMAIL PROTECTED]>
   kphone
   libexosip2

Sebastien Delafond <[EMAIL PROTECTED]>
   python-fuse

Randall Donald <[EMAIL PROTECTED]>
   nvclock

Eric Dorland <[EMAIL PROTECTED]>
   libassa

Joe Drew <[EMAIL PROTECTED]>
   lxdoom

Benjamin Drieu <[EMAIL PROTECTED]>
   xbvl

Roma

Re: Can we require build-arch/indep targets for lenny?

[Goswin von Brederlow]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>> Russ Allbery <[EMAIL PROTECTED]> writes:
>
>>> I would much prefer to see a new control field that explicitly lists
>>> the supported features.  We're going to need that *anyway* for any
>>> feature that's only a should or recommended and not a must (such as
>>> supporting noopt or nostrip), and making every should into a must just
>>> so that we can use this interpretation of Standards-Version is not a
>>> solution.
>
>> So far I have not seen anything that would require it.
>
> I think it would be useful to advertise the optional capabilities of a
> package (noopt, nostrip, parallel) without forcing people to do trial and
> error.  I suppose that's not a "require," but it certainly would be nice.

As for parallel I don't think build-options is enough. The amount of
parallelism usefull depends too much on the system and package. For
example a simple C source can build fine with -j4 and 256MB ram. But
any c++ source with templates will just swap to death with the same.

In a discussion last year I suggested providing a tool to ask the
system for the prefered parallelism to be used during compile. The
tool would get a few parameters such as what language is used or how
much ram the compiler roughly needs. It would check that against the
systems config and resources and then reply with a parallelism level
the source could use.

>> The build-arch target should be a must so no extra build option flag
>> needed.
>
> I really don't think that declaring the majority of packages in Debian
> buggy in this fashion is viable, particularly when nearly all packages in
> Debian will not benefit from this.  My guess is that something on the
> order of 1% of packages have a meaningful distinction between build-arch
> and build-indep, if that, but that includes some packages that benefit a
> *lot*.  Wouldn't it be better to only have to work on modifying the
> packages that will specifically benefit instead of making every other
> package maintainer in Debian add a new target that really isn't meaningful
> for their package?

Already 25% of all packages do have the targets and I assume a lot
more than 1% to benefit. If one single Build-Depends can be moved into
Build-Depends-Indep that is already a benefit.

Weigh that against the cost, adding a % to the build target or adding
'build-%: build', for the packages without meaningful distinction. I
just feel that the cost is so small that any smarter solution than
just requiring build-arch/indep tragets is more waste.

And yes, 75% of the archive would become theoretically buggy the
instance we declare it a must. But nothing breaks and nothing is
actually buggy unless the standards-version gets increased by the
maintainer. At least that is how I see it.

MfG
Goswin


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

Re: Mass bug filing: Dependency/file list predictability

[Steinar H. Gunderson]

On Fri, Jul 20, 2007 at 12:31:57AM +0200, Michael Biebl wrote:
>> Michael Biebl <[EMAIL PROTECTED]>
>>knetworkmanager
>>kpowersave
> These two are affected because of unsermake being installed and so the
> build fails completely.

Define "fails completely". The build creates a .deb, it just loses a lot of
files and dependencies. Should not the build fail in this case, then, instead
of dying silently?

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


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

Re: Mass bug filing: Dependency/file list predictability

[Goswin von Brederlow]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>
>> If the libraries have different names then there should be
>> --with/--without switches possible for configure.
>
> (I'm also upstream for several of these packages.)
>
> I don't know of any Kerberos software, among dozens of packages, that
> works this way.  This simply isn't how multiple Kerberos implementations
> have ever been handled; they all just check for Heimdal and MIT Kerberos
> and use whichever one is found.  This has always worked in the past since
> Heimdal and MIT Kerberos dev packages conflict with each other (not only
> in Debian but everywhere else as well).  Now we're adding a new, rather
> useless GSSAPI library that uses the same library names as Heimdal but
> doesn't actually work and doesn't conflict with MIT Kerberos.

Maybe then the gssapi-dev should also conflict?

> Now, I'm willing to lead the way for Kerberos packages going forward, I
> guess, if I can figure out a good way to do that, but I don't know how
> that configure logic would even work or what those --with flags would look
> like.  The problem would be avoided if I required krb5-config be
> available, but I don't really want to do that, both because older versions
> of Kerberos don't have it and because krb5-config adds a bunch of needless
> shared library dependencies that create unnecessary interpackage
> dependencies in Debian.

In the test if libheimdal exists you first check if --with-heimdal (or
--without) was used and only otherwise do the actual test. [Or you can
test and see if it finds a lib if --with-heimdal was given and file if
not].

That is basically how all the --with/--without constructs wotk that
can also autodetect. There should be plenty of code examples all
around.

MfG
Goswin


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