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

[Josip Rodin]

On Tue, Jun 19, 2007 at 10:47:24AM +0200, Goswin von Brederlow wrote:
> >   debian/rules build-arch || (test $? -eq 2 && debian/rules build)
> >
> > must work and exit with a status of 0.
> 
> Which causes double builds in case something fails with error 2.

How often does something fail with error 2? Can someone try that over
the whole archive, and produce a statistic?

I'm thinking we are being too concerned with what seems likely to be
a corner case. It makes sense to either substantiate that concern or
ignore it; this kind of a limbo is pointless.

-- 
 2. That which causes joy or happiness.


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

Re: Bug#430335: ITP: nsd3 -- authoritative name domain server

[Thijs Kinkhorst]

Hi Pierre,

On Saturday 23 June 2007 15:57, Pierre Habouzit wrote:
> * Package name: nsd3

>NSD3 is an fast, authoritative only, high performance, simple
>and open source name server.

Good that you want to work on this. Did you coordinate this with the 
maintainer of the current nsd package, Ondřej Surý? He told me in #406978
that he plans to package it.


Thijs


pgphGIViECJYs.pgp
Description: PGP signature

Re: I don't understand Debian

[ignatius]

[It's a general answer]

I'm happy that you don't see me as a troll.

I've already heard all these arguments that are _not_ arguments. For me 
the perfect distribution doesn't exist and never will (because of 
upstream). I have a simple dream : that Debian stable ships for instance 
linux 2.16 which is still maintained, a stable version of xorg 
(maintained for several months), etc.
I don't know how to translate it : les distributions ne savent pas faire 
la part des choses ~: A distribution either is too stable, either too 
unstable, there is no compromise.

And I'm not in Windows.
I will not make you lose your time.


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

Re: Nexuiz 2.3

[Jiri Palecek]

Jonas Meurer wrote:

> On 21/06/2007 [EMAIL PROTECTED] wrote:
>> On Thu, Jun 21, 2007 at 01:39:41PM +0100, [EMAIL PROTECTED]
>> wrote:
>> > Both packages have been uploaded at the same time, and I could not
>> > forsee that it has still not been built and uploaded on sparc on time.
>> > I think to avoid this situation in the future the correct way was to
>> > use a versioned "Breaks" field on nexuiz-data:
>> > 
>> > Breaks: nexuiz (<< 2.3)

Does the testing script look at this? If not, (AFAIK it doesn't), you will
create an uninstallable package in testing, which is not really good.

>> 
>>   I might have completely missed your point, but if you have nexuiz-data
>>   Depends on nexuiz (2.3), then
>> it wouldn't get installed, would it ? Or is there a problem to have
>> nexuiz Depends nexuiz-data (2.3) and nexuiz-data Depends on nexuiz (2.3)
>> ?
> 
> This sounds like it would introduce circular dependencies, which tend to
> break upgrades. Using a Breaks: header should be the right thing to do.

What are the real problems? There are many bugs like "Update had problems
due to circular dependency", but the real problem was not mentioned.
The only problem I see is when the configuration ordering is undefined, but
I think it is not a problem for nexuiz as -data doesn't have any post/pre
inst/rm scripts.

Regards
   Jiri Palecek


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

Re: Bug#430335: ITP: nsd3 -- authoritative name domain server

[Pierre Habouzit]

On Sun, Jun 24, 2007 at 12:35:25PM +0200, Thijs Kinkhorst wrote:
> Hi Pierre,
> 
> On Saturday 23 June 2007 15:57, Pierre Habouzit wrote:
> > * Package name: nsd3
> 
> >NSD3 is an fast, authoritative only, high performance, simple
> >and open source name server.
> 
> Good that you want to work on this. Did you coordinate this with the 
> maintainer of the current nsd package, Ondřej Surý? He told me in #406978
> that he plans to package it.

  Yes, I contacted him, he promised me an answer in the week, ... 3
weeks ago. He is welcomed to be a co-maintainer if he wants this.


-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpBpBoNPhpKX.pgp
Description: PGP signature

making in stable or testing

[linux]

Hello devolpers,

I want devolp packages for debian, must I make it in stable or testing?

Regards,
polopolo


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

Re: making in stable or testing

[Luis Matos]

Dom, 2007-06-24 às 17:05 +0200, [EMAIL PROTECTED] escreveu:
> Hello devolpers,
> 
> I want devolp packages for debian, must I make it in stable or testing?

check your timetable ... do you want to develop your application to
start to use in th next two months or 2 years?

the first one, develop in stable.
the second develop in testing, because by the time you finish, the
actual stable will be in shortly replaced, or will already be.
> 
> Regards,
> polopolo
> 
> 


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

Re: making in stable or testing

[Luis Matos]

LOL ... i don't know why, i understand that he wanted to develop some
application for debian ... well .. i must not be in one of my days!

Dom, 2007-06-24 às 18:02 +0200, Guus Sliepen escreveu:
> On Sun, Jun 24, 2007 at 05:25:29PM +0100, Luis Matos wrote:
> 
> > Dom, 2007-06-24 às 17:05 +0200, [EMAIL PROTECTED] escreveu:
> > > Hello devolpers,
> > > 
> > > I want devolp packages for debian, must I make it in stable or testing?
> > 
> > check your timetable ... do you want to develop your application to
> > start to use in th next two months or 2 years?
> > 
> > the first one, develop in stable.
> > the second develop in testing, because by the time you finish, the
> > actual stable will be in shortly replaced, or will already be.
> 
> You should develop packages in unstable, never in testing. If you also
> want people who are currently running stable to use your package, then
> you can also build the package in stable, but this will not be part of
> any official Debian repository. You might try to get it in the backports
> archive though.
> 


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

Re: making in stable or testing

[Guus Sliepen]

On Sun, Jun 24, 2007 at 05:25:29PM +0100, Luis Matos wrote:

> Dom, 2007-06-24 às 17:05 +0200, [EMAIL PROTECTED] escreveu:
> > Hello devolpers,
> > 
> > I want devolp packages for debian, must I make it in stable or testing?
> 
> check your timetable ... do you want to develop your application to
> start to use in th next two months or 2 years?
> 
> the first one, develop in stable.
> the second develop in testing, because by the time you finish, the
> actual stable will be in shortly replaced, or will already be.

You should develop packages in unstable, never in testing. If you also
want people who are currently running stable to use your package, then
you can also build the package in stable, but this will not be part of
any official Debian repository. You might try to get it in the backports
archive though.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Automated mails to maintainers of packages with serious problems

[Joey Schulze]

Lucas Nussbaum wrote:
> > Also nice would be links to the BTS.
> 
> Well, links in text emails use a lot of space...

The BTS uses this nice abbreviation 
which does not use too much space compared with the bug title that
often is longer.

Regards,

Joey

-- 
No question is too silly to ask, but, of course, some are too silly
to answer.   -- Perl book

Please always Cc to me when replying to me on the lists.


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

Re: Bug#430206: ITP: iodine -- tool for tunneling IPv4 data through a DNS server

[gregor herrmann]

On Sat, 23 Jun 2007 15:35:07 +0200, Tollef Fog Heen wrote:

(cc'ing the ITP bug to have this opinion documented there, too)

> | How is iodine different from nstx?
> - Works on !i386
> - Source code that does not make me cry and run away.
> It's slightly less performant (in my experience), but I still much
> prefer it.

Thanks for sharing your experience!

Cheers,
gregor 
-- 
 .''`.   http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' :  debian: the universal operating system - http://www.debian.org/
 `. `'   member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `-BOFH excuse #94:  Internet outage 


signature.asc
Description: Digital signature

Re: Proposed new release goal: Dependency/file list predictability

[Steinar H. Gunderson]

On Fri, Jun 22, 2007 at 09:23:16AM +0200, Lucas Nussbaum wrote:
> However, with this setup, you only check that building packages in
> non-clean environments doesn't significantly affect the package. It
> would be interesting to check as well if the resulting package matches
> what is in the archive, to some point.

I already do that, but mainly as an optimization at this point.

I do agree with your goal, though, but it's very hard to determine what's a
bug and what's not. "This package hasn't transitioned to newer libfoo yet"
is, IMO, not a bug in itself.

BTW, I've built everything in optional up to the letter c (plus all of
required, standard and important), and so far, 28 bugs have showed up. (Also,
44 FTBFS bugs have showed up, but I haven't filtered out those that FTBFS in
clean chroots yet, and I guess those would account for nearly all.)
Extrapolating from that, it would seem that slightly over 200 bugs of this
class exist in the archive. I only started the full build on hydra (thanks,
Joey) yesterday, so I assume I'll have a first approximation of the number of
bugs in a couple of days.

> - some files will differ, because of:
>   + date/time information
>   + newer compiler versions causing better optimization
>   + ...

Yes, diffing binary files properly is very hard.

> So, I'd like to extend this release goal to something like "binary packages
> predictability (to some extend)". This would mostly result in a lot of binNMUs
> to update the binary packages to the current state of unstable, so in most
> cases, it shouldn't put a lot of load on maintainers.
> The number of issues is unknown ; it depends on how close we want packages
> to match.
> 
> Do you think it's a good idea?

I'm unsure. I do like the idea, but I'm concerned it would be difficult to
determine what's an acceptable difference and what is not.

> Steinar, do you want to merge your release goal with that one, or do you 
> prefer
> me to file a seperate release goal? The main reason why I think they should be
> merged is that the way to detect issues is similar.

I'd prefer to have it as a separate release goal, or at least a different
usertag (which is really all that matters; release goals are not binary
achieved/not achieved anyway).

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


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

Re: [EMAIL PROTECTED] Package

[Frank Küster]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Le vendredi 22 juin 2007 à 14:20 -0400, Zachary Palmer a écrit :
>> This software package has pretty much the best reason for 
>> being closed source that I've encountered; they want to prevent 
>> falsified results from damaging the research.
>
> This is probably one of the worst excuses I could find. The software
> being closed source doesn't prevent *AT ALL* any kind falsification.
> Relying on such a blatantly wrong security scheme is the best way to
> discover falsification too late.

As I understood it, the idea was more to keep information *comparable*,
which wouldn't be the case if someone "improved" the script by using a
faster minimizer, linking against an improved libfoo or whatever.  You
simply cannot publish a work based on "input which clients sent to us
that are somehow more or less the same as what we describe in the
methods section", it needs to match exactly what's in the methods
section.  It's not a means against evil attackers, but against
goodwilling "helpers".


By the way, I seem to recall that I once interacted, as a potential
sponsor, with someone who wanted to upload a package similar to that
proposed by Zachary, and it was called "fah".  I would even tend to
think that there was a version in the archive, but I'm not sure I ever
uploaded something (I remember arguments with the sponsee about the
maintainer scripts).  I'm currently offline and therefore cannot verify
it, it should be (partly) in the -mentors archive.

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

Re: Nexuiz 2.3

[Reinhard Tartler]

Jiri Palecek <[EMAIL PROTECTED]> writes:

> Jonas Meurer wrote:
>
>> On 21/06/2007 [EMAIL PROTECTED] wrote:
>>> On Thu, Jun 21, 2007 at 01:39:41PM +0100, [EMAIL PROTECTED]
>>> wrote:
>>> > Both packages have been uploaded at the same time, and I could not
>>> > forsee that it has still not been built and uploaded on sparc on time.
>>> > I think to avoid this situation in the future the correct way was to
>>> > use a versioned "Breaks" field on nexuiz-data:
>>> > 
>>> > Breaks: nexuiz (<< 2.3)
>
> Does the testing script look at this? If not, (AFAIK it doesn't), you will
> create an uninstallable package in testing, which is not really good.

Which is the current state, so no regression here. apt 0.7 now
understands breaks, other tools (britney, dpkg) still need to be fixed.

>> This sounds like it would introduce circular dependencies, which tend to
>> break upgrades. Using a Breaks: header should be the right thing to do.
>
> What are the real problems?

Confusing britney and apt, making upgrade paths hard.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


pgpjcqjv3SWlu.pgp
Description: PGP signature

Re: [EMAIL PROTECTED] Package

[Gabor Gombas]

On Sun, Jun 24, 2007 at 05:51:29PM +0200, Frank Küster wrote:

> As I understood it, the idea was more to keep information *comparable*,
> which wouldn't be the case if someone "improved" the script by using a
> faster minimizer, linking against an improved libfoo or whatever.  You
> simply cannot publish a work based on "input which clients sent to us
> that are somehow more or less the same as what we describe in the
> methods section", it needs to match exactly what's in the methods
> section.  It's not a means against evil attackers, but against
> goodwilling "helpers".

Josselin is right here, being closed source does not protect against
these kind of problems _AT ALL_. We're running a BOINC project that runs
a closed source application, but that did not prevent a guy with some
free time to dissassemble the code and produce a binary patch to speed
up the program in order to gain more credits.

There is ongoing research about how to make public distributed computing
more reliable and tampering more detectable, but being closed source does
not help at all.

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: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

[Steinar H. Gunderson]

On Fri, Jun 22, 2007 at 09:27:49AM -0700, Russ Allbery wrote:
> Hoard is a replacement memory allocator that can be used instead of glibc
> malloc without recompiling binaries.  It is faster and more efficient
> under many load patterns than the default glibc malloc, and is particularly
> good for multithreaded programs running on multiple processors.

What's the downsides? I'd guess that if it's GPLed and not in glibc, there's
a catch somehow.

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


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

Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

[Bernd Zeimetz]

>> Hoard is a replacement memory allocator that can be used instead of glibc
>> malloc without recompiling binaries.  It is faster and more efficient
>> under many load patterns than the default glibc malloc, and is particularly
>> good for multithreaded programs running on multiple processors.
>> 
>
> What's the downsides? I'd guess that if it's GPLed and not in glibc, there's
> a catch somehow.
>   
there're also the google perftools[1], which are suppsed to work very well and 
we have libgoogle-perftools in Debian. [2] is very interesting to read in this 
case.
I'd be really interested to know why one of those implementations is not the 
default in glibc, and if hoard or perftools provides the better/faster malloc.


[1] http://sourceforge.net/projects/goog-perftools/
[2] http://bugs.mysql.com/bug.php?id=27063




Best regards,

Bernd Zeimetz


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

Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

[Steve Greenland]

On 24-Jun-07, 17:46 (CDT), "Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote: 
> On Fri, Jun 22, 2007 at 09:27:49AM -0700, Russ Allbery wrote:
> > Hoard is a replacement memory allocator that can be used instead of glibc
> > malloc without recompiling binaries.  It is faster and more efficient
> > under many load patterns than the default glibc malloc, and is particularly
> > good for multithreaded programs running on multiple processors.
> 
> What's the downsides? I'd guess that if it's GPLed and not in glibc, there's
> a catch somehow.

Without having any knowledge of the specifics of hoard, the phrase
"faster and more efficient under many load patterns" does not eliminate
the possibility of "pathologically horrible behaviour under other load
patterns". Bubble sort works pretty well if the input data is already
sorted :-)

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: Proposed new release goal: Dependency/file list predictability

[Marcus Better]

Matthew Johnson wrote:
> Also, you should consider build systems which switch using the
> alternatives system. Debian Java policy says that debian/rules must
> specify the build system to use explicitly, but there are a number of
> packages which don't.

If you know of any such packages, please file bug reports. That should
really be fixed.

Marcus



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

Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

[Russ Allbery]

Steve Greenland <[EMAIL PROTECTED]> writes:

> Without having any knowledge of the specifics of hoard, the phrase
> "faster and more efficient under many load patterns" does not eliminate
> the possibility of "pathologically horrible behaviour under other load
> patterns". Bubble sort works pretty well if the input data is already
> sorted :-)

There is that too.  :)  Hoard is particularly good for applications that
are either multithreaded or that allocate memory once and then use it
frequently.  Applications that don't fit either of those profiles may see
little benefit.  I don't know if there are pathological cases; I've
personally only used it with OpenLDAP.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

[Russ Allbery]

Bernd Zeimetz <[EMAIL PROTECTED]> writes:

>> What's the downsides? I'd guess that if it's GPLed and not in glibc,
>> there's a catch somehow.

glibc is not GPL'd.  It's LGPL.

> there're also the google perftools[1], which are suppsed to work very
> well and we have libgoogle-perftools in Debian.

Hoard is noticably better for OpenLDAP's load profile than Google
perftools (although both of them annihilate the glibc allocator).

> [2] is very interesting to read in this case.  I'd be really interested
> to know why one of those implementations is not the default in glibc,
> and if hoard or perftools provides the better/faster malloc.

> [1] http://sourceforge.net/projects/goog-perftools/
> [2] http://bugs.mysql.com/bug.php?id=27063

Well, I don't know if this is a full explanation, but at least Hoard would
have to be relicensed to LGPL to be included in glibc.  It's also written
in C++, which I expect would be a problem.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Proposed new release goal: Dependency/file list predictability

[Frank Küster]

Bill Allombert <[EMAIL PROTECTED]> wrote:

> This should be fixed by rebuilding af. However, since we are moving
> to a new menu structure, the menu file will need to be updated[1], so
> the packages will need a new sourceful upload anyway.

The footnote was missing, unfortunately:  I'm really curious about the
plans for the menu structure update.

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

Re: Official presentation template

[Andreas Tille]

[Vor DebConf visitors: I'm just replying into a thread that was started in
 Debian-devel list and which concerns more or less the LaTeX beamer BOF
  https://penta.debconf.org/~joerg/events/34.en.html ]

On Sat, 23 Jun 2007, Sebastian Harl wrote:


Afaik, there is no such thing. However, there has been a short discussion on
this topic during Debconf [1] and Andreas Tille collected some ideas about a
design. You might want to contact him.


I tried to sum up the results of our little boof in DebConf.  Perhaps some
open discussion might not harm.  Please note that all shown images are NOT
the proposed theme but do instead illustrate one feature whe would like to
have.  Once we decided about the features we want we should ask some graphics
experts to realise these professional.

Kind regards

Andreas - back from DebConf 7, which was really nice.  Thanks to the 
organisers.

--
http://fam-tille.de


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