Re: Switchconf: Orphaning or removing?

[Henning Sprang]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Shaul Karl wrote:

> I am forwarding this to linux-fai at uni-koeln dot de. I believe
> many people interested in this discussion hang out there.
>
> On Wed, Mar 09, 2005 at 12:35:45PM +0100, Steinar H. Gunderson
> wrote:
>
>> On Mon, Mar 07, 2005 at 10:44:25AM +0200, Shaul Karl wrote:
>>
>>> 60 PCs with Debian and there exist 4 different configurations?
>>> In case each PC has a nic, it sounds like the fai package
>>> suits your situation.
>>
>> Or cfengine2 (optionally coupled with pkgsync).
>>
>> /* Steinar */ -- Homepage: http://www.sesse.net/


According to the short snippet I read there, there's not much more to
state but that this really sounds like a case for FAI, which uses
cfengine for some tasks during installation, too.

While the actual version of FAI only takes care of installation, there
are already patches/additions that take care of updating without full
installation and plans to integrate these additions into FAI.

There: http://www.informatik.uni-koeln.de/fai/ you find lots more of
information, and we here on the list are glad to help you with further
questions :)

Henning


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCM++DOzXGJHJLmQIRAicLAJ9WZxERlYLCpk5vsMMCBUQioqF3xQCgw4pf
MqNdolbELXAQo+QYMMLP1yI=
=p9rO
-END PGP SIGNATURE-


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

Re: Is Anthony Fok MIA?

[Jan Nieuwenhuizen]

Martin Michlmayr writes:

> No, it's a private alias.

Ok.  I hope Anthony is well.

>> We are a bit concerned with old LilyPond packages, and a potential
>> new maintainer (Pedro Kroger) with his sponsor going mia.
>
> Who was going to sponsor him?

I don't think Pedro told me that.  Pedro?

Jan.

-- 
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien   | http://www.lilypond.org


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

Re: Restrictive SMTP server

[Bartosz Fenski aka fEnIo]

On Sat, Mar 12, 2005 at 04:18:06PM -0300, Daniel Ruoso wrote:
> I'm with a problem about sending emails @debian.org. My ESP (email
> service provider) has a restrictive rule about sending emails with a
> >From header different of the account you actually have.
> 
> This wouldn't be a problem, as I could set up a mail server in my
> machine, but I am in a DSL network which is completely blacklisted due
> to spammers.
> 
> The fact is that I am unable to send emails with my debian.org address.
> Does someone has some idea of how can I fix that?

`apt-get install msmtp` and use some other account where such problem
doesn't exist.

That's what I'm using ;)

regards
fEnIo

-- 
  ,''`.  Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo
 : :' :   32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland
 `. `'   phone:+48602383548 | proud Debian maintainer and user
   `-  http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001


signature.asc
Description: Digital signature

Re: Restrictive SMTP server

[Matthew Palmer]

On Sun, Mar 13, 2005 at 09:58:49AM +0100, Bartosz Fenski aka fEnIo wrote:
> On Sat, Mar 12, 2005 at 04:18:06PM -0300, Daniel Ruoso wrote:
> > I'm with a problem about sending emails @debian.org. My ESP (email
> > service provider) has a restrictive rule about sending emails with a
> > >From header different of the account you actually have.
> > 
> > This wouldn't be a problem, as I could set up a mail server in my
> > machine, but I am in a DSL network which is completely blacklisted due
> > to spammers.
> > 
> > The fact is that I am unable to send emails with my debian.org address.
> > Does someone has some idea of how can I fix that?
> 
> `apt-get install msmtp` and use some other account where such problem
> doesn't exist.
> 
> That's what I'm using ;)

I'm willing to provide an OpenVPN tunnel to an SMTP server for any DD who is
unable to find alternate lodgings, and I'm pretty sure I'm not the only one.

- Matt


signature.asc
Description: Digital signature

Offer to take over the shadow package (passwd and login binary packages)

[Christian Perrier]

Hello folks,

The shadow package is officially maintained by Karl Ramm, with
assistance by Sam Hartman. It is the source package for "login" and
"passwd", two important pieces of Debian base system.

I have helped Karl in collecting the package translations (both
debconf and programs translations) for more than one year now.

Since July 2004, I've got no news from Karl and any further attempt to
get in touch with him has been unsuccessful. Even before this, it
became quite obvious that the package is not very actively maintained.

Karl is listed in the MIA lists and it becomes quite obvious that he
is really MIA. I had exchanges with the MIA lists maintainers about this.

I have announced in many places my intent to take over the package
development, which I'm in fact doing since mid 2004 (with NMUs).

As I feel that I don't have the whole required skills for doing so, I
have made my best to gather a mini team of contributors. The team is
quite small at this momennt but I expect more motivated people to join
in. 

For instance, Tomasz KÅoczko, the upstream maintainer has joined the
package development list. Tomasz has given a very strong push to the
upstream development and I expect a very good collaboration with him
to make shadow utilities better...and the Debian implementation better
as well.

Sam Hartman also mentioned he may bring some help and is of course
very welcomed.

All other Debian developers (or contributors) who want to contribute
are welcomed to contact me. We will probably specifically need people
with well established skills about system security.

This is is the official announcement of my intent to take over the package
development. I hesitated a lot before doing so as the alternative
would have been to keep a NMU version as the last version released
with sarge. For more clarity on this topic, I finally decided it would
be better to officially act as the package maintainer.

I intent to soon upload a version with the
[EMAIL PROTECTED] mailing list as
"Maintainer:", so that the lists gets the bug reports and all other
stuff related to the package development and myself and Sam Hartman as
"Uploader:".

This will be the 4.0.3-31 release of the package. It will be exactly
similar to the current 4.0.3-30.10 release of the package except the
maintainer and uploader changes.

The plans for the future are:

-Before sarge release:

 -continue to improve the l10n in shadow, if still possible, with no
  other update, except of course RC issues. This will be the
  4.0.3-31sarge series
  Even the request for making login non setuid is delayed post-sarge
  after advice received from the release managers.

 -maybe launch some work in experimental to integrate upstream 4.0.7
  (see below)

-In Etch (ie after sarge release)

 -examine all Debian-specific patches to upstream sources one by one
  and discuss them with upstream. My intent is to minimize them as
  much as possible and have them integrated upstream if possible

  For this, the 4.0.3-32 release will use dpatch to isolate all these
  patches. This is already made in the CVS on Alioth, indeed, thus the
  devel list members may already begin to review these patches


 -integrate all this to upstream's 4.0.7 release, looking one by one
  to Debian specific changes and decide whether:
  -they're already here in 4.0.7
  -they are not and should be dropped
  -they are not, should be kept and integrated upstream
  -they are not, should be kept but should be kept as Debian specific

  The goal here is to have a Debian version which is as close as
  possible from the upstream version.

  These last plans may of course be changed, depending on the
  discussions we will have on the package development list.

Please, feel free to comment about all this. Any input is welcomed.

-- 





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

Re: Offer to take over the shadow package (passwd and login binary packages)

[Ralf Hildebrandt]

* Christian Perrier <[EMAIL PROTECTED]>:

> Since July 2004, I've got no news from Karl and any further attempt to
> get in touch with him has been unsuccessful. Even before this, it
> became quite obvious that the package is not very actively maintained.

Same goes for his xscreensaver package, which is in a pitiful state
 
> Karl is listed in the MIA lists and it becomes quite obvious that he
> is really MIA. I had exchanges with the MIA lists maintainers about this.

Ah.
> 
> I have announced in many places my intent to take over the package
> development, which I'm in fact doing since mid 2004 (with NMUs).

Would you also take over xscreensaver and maybe let me co-maintain it?

-- 
Ralf Hildebrandt (i.A. des IT-Zentrum)  [EMAIL PROTECTED]
Charite - Universitätsmedizin BerlinTel.  +49 (0)30-450 570-155
Gemeinsame Einrichtung von FU- und HU-BerlinFax.  +49 (0)30-450 570-962
IT-Zentrum Standort CBF send no mail to [EMAIL PROTECTED]


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

Re: Is Anthony Fok MIA?

[Abel Cheung]

æ æï2005-03-13 æ 09:06 +0100ïJan Nieuwenhuizen æåï
> Martin Michlmayr writes:
> 
> > No, it's a private alias.
> 
> Ok.  I hope Anthony is well.
> 

Anthony is overloaded with lots of work from company and local
community, so very likely he won't be able to update debian lilypond
package... well, that's just what I heard from friends who know his
whereabouts, so if he speaks up this is definitely better. But if you
still hear nothing from him after some days, you can assume he agrees to
change in maintainership.

Abel


> >> We are a bit concerned with old LilyPond packages, and a potential
> >> new maintainer (Pedro Kroger) with his sponsor going mia.
> >
> > Who was going to sponsor him?
> 
> I don't think Pedro told me that.  Pedro?
> 
> Jan.
> 
-- 
Abel Cheung <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Re: automake/autoconf in build-dependencies

[Henning Makholm]

Scripsit Daniel Schepler <[EMAIL PROTECTED]>

> - Putting autoconf-generated files in the source package is nearly as
> fragile as generating them at build time.  If there are changes in
> autoconf which break the configure.ac etc, then the next time you want
> to make other changes or bring your changes forward to a new upstream
> version, you'll have to fix things anyway.  This to my mind pretty
> much reduces the "future buildability" benefits to nearly nothing.

That's a reason *contra* in my opinion.

When I include the configure script in my source packages, I can feel
pretty confident that they package I upload will stay buildable even
if a week from now autoconf or automake gets updated to something not
backwards compatible.

The next time I upload I am going to either reuse the working
configure script from the previous package (if I'm managing things by
hand) or try to generate a new one with the tools I have available by
then (if I'm using cvs-buildpackage or one of its equivalents).  In
the latter case, if anything stops working I will _find out_ before I
upload, both because I have to run the script myself as part of
building and because as a matter of course I run debdiff to compare
with the latest version before I upload.

However, if I left it to the source package to run autoconf by itself
weach time it is build, it could slide into unbuildability _without me
or anybody else noticing_ before it is too late and we have
not-buildable-anymore code sitting around in the archive, and most
likely even in testing.

> - The extra space in the diff.gz expands the size needed on every
> single Debian mirror, as opposed to the short one-time penalties on a
> few buildd's.

That's a real issue, but I still think the least bad solution is to
ship finished, known-to-work build scripts in the source package.

-- 
Henning Makholm   "Larry wants to replicate all the time ... ah, no,
   all I meant was that he likes to have a bang everywhere."


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

Re: automake/autoconf in build-dependencies

[Henrique de Moraes Holschuh]

On Sun, 13 Mar 2005, Henning Makholm wrote:
> Scripsit Daniel Schepler <[EMAIL PROTECTED]>
> > - Putting autoconf-generated files in the source package is nearly as
> > fragile as generating them at build time.  If there are changes in
> > autoconf which break the configure.ac etc, then the next time you want
> > to make other changes or bring your changes forward to a new upstream
> > version, you'll have to fix things anyway.  This to my mind pretty
> > much reduces the "future buildability" benefits to nearly nothing.

Experience tells me you are wrong.  

> When I include the configure script in my source packages, I can feel
> pretty confident that they package I upload will stay buildable even
> if a week from now autoconf or automake gets updated to something not
> backwards compatible.

Yes. That's how I see it as well.

> > - The extra space in the diff.gz expands the size needed on every
> > single Debian mirror, as opposed to the short one-time penalties on a
> > few buildd's.

Unfortunatelly, it is still a good tradeoff.  I am not even bothering about
CPU time in the buildds anymore, since I got told by buildd admins and
porters a number of times not to.  BUT the long-term package quality
benefits are worth the increase in space.

> That's a real issue, but I still think the least bad solution is to
> ship finished, known-to-work build scripts in the source package.

Agreed.  That's the current best practice for Debian, as far as I am
concerned.

In fact, best practice for Debian also requires that you use config.sub and
config.guess from autotools-dev if your configure script needs them. Just a
shameless plug for autotools-dev :-)

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond

  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: automake/autoconf in build-dependencies

[Kurt Roeckx]

On Sun, Mar 13, 2005 at 12:04:59PM +, Henning Makholm wrote:
> Scripsit Daniel Schepler <[EMAIL PROTECTED]>
> 
> > - Putting autoconf-generated files in the source package is nearly as
> > fragile as generating them at build time.  If there are changes in
> > autoconf which break the configure.ac etc, then the next time you want
> > to make other changes or bring your changes forward to a new upstream
> > version, you'll have to fix things anyway.  This to my mind pretty
> > much reduces the "future buildability" benefits to nearly nothing.
> 
> That's a reason *contra* in my opinion.
> 
> When I include the configure script in my source packages, I can feel
> pretty confident that they package I upload will stay buildable even
> if a week from now autoconf or automake gets updated to something not
> backwards compatible.

Some arches for instance have problems with old versions of
libtool resulting in a broken configure on only those arches.
Now they have to file a bug report asking for a libtool update to
the latest (debian) version.  It _could_ be handy that such
requests weren't needed.

Note that I do understand your argument that a new version could
break.  But we do have autoconf, autoconf2.13, automake1.4,
automake1.6, automake1.7, automake1.8, automake1.9, libtool,
libtool1.4.  You can build-depend on the version that you
require.

However, I do understand that if you just build-depend on
autoconf and you suddenly have to change to autoconf2.13 because
they changed the version to 2.5x and your script doesn't work
with autoconf 2.5x you have a problem.  But sooner or later you
will have to do something about the problem anyway.  You can't
stay using autoconf2.13 for ever.  Some day that version will get
removed from the archive.  Just like libtool1.4 is already
orphaned and planned to be removed after sarge gets released.


An other argument that was only vaguely mentioned was that you
can look at configure.in/ac as source.  Some people seem to
disagree with this but I haven't seen their arguments for it.
I don't think I can agree to their arguments anyway.  The same
goes for things like bison.

We do not have a requirement that everything is build from
source, only that we should be able to do so.  But I think it's a
good idea to always build everything from sources.  If you have
to fix something, it's always going to be easier to fix in the
source.  And how can you know you can actually build it if you
never tried it?


Kurt


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

Re: automake/autoconf in build-dependencies

[Henning Makholm]

Scripsit Kurt Roeckx

> And how can you know you can actually build it if you
> never tried it?

That's the point, actually: If I build-depend on autoconf, I *cannot*
know that it will actually build after the next update to autoconf,
because most likely nobody will try it.

When I provide a configure script in the source package it means, on
the contrary, that I *have* tried it and therefore has some kind of
evidence that it will probably work for other people too.

-- 
Henning Makholm "That's okay. I'm hoping to convince the
  millions of open-minded people like Hrunkner Unnerby."


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

Re: automake/autoconf in build-dependencies

[Kurt Roeckx]

On Sun, Mar 13, 2005 at 02:02:29PM +, Henning Makholm wrote:
> Scripsit Kurt Roeckx
> 
> > And how can you know you can actually build it if you
> > never tried it?
> 
> That's the point, actually: If I build-depend on autoconf, I *cannot*
> know that it will actually build after the next update to autoconf,
> because most likely nobody will try it.

If it's known that a new major version of autoconf is uploaded to
the archive that might break some packages, it's rather easy to
see which packages build depend and you can very if they still
work or not.  This goes for all build dependencies for a package.

Also, there are some people (including me) who rebuild the whole
archive regularly (but uncoordinated) to look for pacakges that
no longer build.  There are more things than just autoconf
updates that make packages suddenly fail to build.

Or are you saying that all build dependencies should be removed,
since they all can cause you problems.  Maybe you want to have
everything your packages requires to build in your .orig.tar.gz
file?  Including things like all headers from libc and gcc.  You
know, gcc might change some day and your package might no longer
build because it's more strict about some things, maybe you
should also include your own copy of gcc in it for all arches.

I find the argument that it might break some time because of new
version your package build depends on a bad reason.  Where
does that stop?  Some packages for instance have their own
copy of libz or gettext included.  I find that a bad thing, they
should all be changed to build depend on the packages that
provide it and not use the included version if possible.  There
are several reasons why you want that, one of them being that
it's alot easier to have all packages fixed if there is a
security bug found in one of those packages.


Kurt


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

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Goswin von Brederlow]

[remove -release, nothing they can do about it]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Sat, Mar 12, 2005 at 03:01:28PM -0800, Thomas Bushnell BSG wrote:
>> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>
>> > Remember that the buildd queue is not FIFO at all. The queue has a
>> > completly static order. Any changes to the queue are just packages
>> > hiding because they are not "needs-build". I consider that the biggest
>> > flaw of all in wanna-build.
>
>> This is news to me.
>
>> It means that when one is told "just wait, your package will get
>> rebuilt"; it is not necessarily true at all.  There is no upper bound
>> at all on time to wait for building, and that's a disaster.  People
>> should stop repeating the fiction then that "just wait" means "your
>> package will eventually get built".
>
> Er, packages *do* eventually get built; they just don't get built in any

The only way to get the last package in the queue (zvbi or something)
build is when the queue is empty. Unfortunately some archs are on the
border of being too slow which means the time between empty queues is
long.

The effect of being (too) slow is that some few package will not be
build for weeks/month instead of all packages being build a few days
late as a simple FIFO would do.

> kind of FIFO order.  I don't particularly care for this arrangement myself
> (it means there are plenty of times that a high-priority bug in a
> low-priority package stays on the release team's watchlist for far too
> long), but I don't have any proof that a different queue ordering would
> actually work better for the project, and the buildd admins *are* committed
> to keeping up with the queue even though hardware circumstances sometimes
> prevent it from time to time.
>
> -- 
> Steve Langasek
> postmodern programmer

Check
http://unstable.buildd.net/buildd/Needs-Build_stats.png

Queue not empty since:

arm Feb 18th
mipsel  Feb 26th
s390Mar  6th
mipsMar 10th (possibly)

That means (just an example) that an upload of zsh on Feb. 18th didn't
get build at all on arm while the 5 uploads of ash all got build.

Does that sound fair? Just because ash starts with an 'a' it gets
prefered treatment?


I see the point of sorting by priority to get the essentials build
with priority in case of backlogs.

I don't see a point in sorting by section as base is already done
through priority and an automatic Dep-Wait would get libs build
first.

And last I feel the sorting by name is actualy harmfull. That should
be exchanged with the time of upload, i.e. FIFO if the rest matches.
We all know FIFO isn't the best but it is simple, fair, predictable
and does not starve. I think it would avoid a lot of those "Why am I
stuck in the buildd queue?" questions.

MfG
Goswin


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

Re: Bug#299242: ITP: ha-prosper -- improved LaTeX class for writing transparencies

[Andreas Tille]

On Sun, 13 Mar 2005, Michael Prokop wrote:
I think replacing the prosper-package with ha-prosper wouldn't be
a good choice. I'd like to provide ha-prosper in a separate package
so when TeXciting is available there aren't any breakages with
prosper.
Recently I investigated some time in LaTeX based presentation tools.
The consequence was:
  1. Prosper is nice but development tsopped since about 3 years.
  2. HA-prosper was kind of continuing the work of prosper.  It is
 more enhanced and I even builded some packages for my private
 use of it until I noticed latex-beamer (see below).  My impression
 was that while it is superior about prosper and should prosper
 replace regarding to this fact it is not really worth packaging
 because development is stalled as well because of the new
 TeXciting project.
  3. LaTeX-Beamer has compatibility modes for prosper and ha-prosper.
 It is much more feature complete and flexible than both above.
 There is absolutely no reson to investigate time into any
 *prosper package because LaTeX-Beamer is the package your
 really want.  For an example see
   http://people.debian.org/~tille/talks/200503_peking_cdd/index_en.html
 I do not know anything about TeXciting and thus I can not compare
 but before crowding the archive with a package like ha-prosper
 try LaTeX-Beamer.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Restrictive SMTP server

[Stephen Gran]

This one time, at band camp, Matthew Palmer said:
> On Sun, Mar 13, 2005 at 09:58:49AM +0100, Bartosz Fenski aka fEnIo wrote:
> > On Sat, Mar 12, 2005 at 04:18:06PM -0300, Daniel Ruoso wrote:
> > > I'm with a problem about sending emails @debian.org. My ESP (email
> > > service provider) has a restrictive rule about sending emails with a
> > > >From header different of the account you actually have.
> > > 
> > > This wouldn't be a problem, as I could set up a mail server in my
> > > machine, but I am in a DSL network which is completely blacklisted due
> > > to spammers.
> > > 
> > > The fact is that I am unable to send emails with my debian.org address.
> > > Does someone has some idea of how can I fix that?
> > 
> > `apt-get install msmtp` and use some other account where such problem
> > doesn't exist.
> > 
> > That's what I'm using ;)
> 
> I'm willing to provide an OpenVPN tunnel to an SMTP server for any DD who is
> unable to find alternate lodgings, and I'm pretty sure I'm not the only one.

I can offer something as well - I would probably lean towards just
auth+ssl instead of over VPN, but it's up to you.  I just don't happen
to have a VPN set up yet, so it's less ovrhead for me :)
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


pgpZ8QUwxXbya.pgp
Description: PGP signature

Re: automake/autoconf in build-dependencies

[Torsten Landschoff]

Hi Kurt, 

On Sun, Mar 13, 2005 at 03:40:23PM +0100, Kurt Roeckx wrote:
> > That's the point, actually: If I build-depend on autoconf, I *cannot*
> > know that it will actually build after the next update to autoconf,
> > because most likely nobody will try it.
> 
> If it's known that a new major version of autoconf is uploaded to
> the archive that might break some packages, it's rather easy to
> see which packages build depend and you can very if they still
> work or not.  This goes for all build dependencies for a package.

Great. And while most people continue telling that it is always easy to
fix autoconf breakage that is not always true. I am using autoconf and
automake for my own programs but they are hardly as complicated as for
example the OpenLDAP autoconf setup. 

I am glad the I can create a configure script with autoconf2.50 for
OpenLDAP but upstream still is at 2.13 and seems not likely to update. 
Which is a lot of fun if you need current libtool etc. 

Basically as long as it works don't even think about touching it. Much
less if upstream is not going to accept your changes.

> Also, there are some people (including me) who rebuild the whole
> archive regularly (but uncoordinated) to look for pacakges that
> no longer build.  There are more things than just autoconf
> updates that make packages suddenly fail to build.

... but we are discussing autoconf now. Surely something else can break
as well but this is not a reason to say "okay, one more weak spot".

> Or are you saying that all build dependencies should be removed,
> since they all can cause you problems.  Maybe you want to have
> everything your packages requires to build in your .orig.tar.gz
> file?  Including things like all headers from libc and gcc.  You
> know, gcc might change some day and your package might no longer
> build because it's more strict about some things, maybe you
> should also include your own copy of gcc in it for all arches.

There is a C standard. If the program does not conform to it it is
broken. There is no autoconf standard. autoconf is a moving target. 

> I find the argument that it might break some time because of new
> version your package build depends on a bad reason.  Where
> does that stop?  Some packages for instance have their own
> copy of libz or gettext included.  I find that a bad thing, they
> should all be changed to build depend on the packages that
> provide it and not use the included version if possible.  There
> are several reasons why you want that, one of them being that
> it's alot easier to have all packages fixed if there is a
> security bug found in one of those packages.

You are right. But until upstream supports that it is often easier to go
with the upstream choice. We all know there are a lot of things we'd
rather have changed for the better. But in the end the user wants
current and working packages. And if I can save some time by putting
generated configure scripts into my packages I will do that and carry
on. 

Greetings

Torsten


signature.asc
Description: Digital signature

Re: automake/autoconf in build-dependencies

[Henning Makholm]

Scripsit Kurt Roeckx <[EMAIL PROTECTED]>

> Or are you saying that all build dependencies should be removed,
> since they all can cause you problems.

I am saying that this particular build dependency can be removed
without causing problems that have anywhere near the severity of the
problems that can be avoided by removing it.

I am not stupid enough to claim that this applies to all
build-dependencies, so I am not going to play strawman to the
rest of your "argument".

-- 
Henning Makholm"Jeg køber intet af Sulla, og selv om uordenen griber
planmæssigt om sig, så er vi endnu ikke nået dertil hvor
   ordentlige mennesker kan tillade sig at stjæle slaver fra
 hinanden. Så er det ligegyldigt, hvor stærke, politiske modstandere vi er."

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Torsten Landschoff]

On Sun, Mar 13, 2005 at 05:19:25PM +0100, Goswin von Brederlow wrote:
 
> And last I feel the sorting by name is actualy harmfull. That should
> be exchanged with the time of upload, i.e. FIFO if the rest matches.
> We all know FIFO isn't the best but it is simple, fair, predictable
> and does not starve. I think it would avoid a lot of those "Why am I
> stuck in the buildd queue?" questions.

I second that.

Greetings

Torsten


signature.asc
Description: Digital signature

Re: automake/autoconf in build-dependencies

[Scott James Remnant]

On Thu, 2005-03-10 at 12:05 -0600, Adam Heath wrote:

> On Fri, 11 Mar 2005, Paul Hampson wrote:
> 
> > * timestamp skew means that the autobuilt makefiles will try
> >   to rebuild configure from configure.in even if configure is patched by
> >   dpkg-source at the same time as configure.in
> >   * A solution for this is in the above-mentioned README.Debian
> 
> New dpkg-source support will work too.
> 
Really?  Perhaps you'd like to share your ideas and/or code with people
who've actually touched dpkg in the last 18 months?

debian-dpkg@lists.debian.org or www.dpkg.org, in case it's been so long
that you've forgotten.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?


signature.asc
Description: This is a digitally signed message part

Bug#295760: ktoon depends on libming

[Juan Manuel Garcia Molina]

Package: wnpp
Followup-For: Bug #295760
Owner: Juan Manuel Garcia Molina <[EMAIL PROTECTED]>

Hi.

After working a bit on creating the package, I discovered it depends on
libming. Unfortunately, libming is not in Debian sid.

I have been trying to hack the code in order to let the package compile
without libming, but it does not appear to be a good idea, because it
would let the package without a very interesting feature.

I write this just to let you know I keep on working on ktoon. Maybe I
should work on get libming again on Debian or wait for the next release
of ktoon.


Regards,
Juanma.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Is there Linux operating system for Nokia mobile devices?

[Mikko Ma Aaltonen]

Hi Debian developers. (My first time post here.)

I'm here to ask, if anyone of you know,
has someone done some development work to get a Nokia (or some other
brand) mobile to work with some other operating system than Symbian?

I'd be interested if anyone is attempting to create "mobile Linux".
And I would like more than gladly see a cell phone that runs Linux
(Debian perhaps).

Please, contact me if you have a working mobile device with Linux
operating system or if you're interested to create one.

Br, Mikko


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

Re: Is there Linux operating system for Nokia mobile devices?

[Neil McGovern]

On Sun, Mar 13, 2005 at 09:19:09PM +0200, Mikko Ma Aaltonen wrote:
> Hi Debian developers. (My first time post here.)
> 
> I'm here to ask, if anyone of you know,
> has someone done some development work to get a Nokia (or some other
> brand) mobile to work with some other operating system than Symbian?
> 
> I'd be interested if anyone is attempting to create "mobile Linux".
> And I would like more than gladly see a cell phone that runs Linux
> (Debian perhaps).
> 
> Please, contact me if you have a working mobile device with Linux
> operating system or if you're interested to create one.
> 

http://tuxmobil.org/

HTH,
Neil
-- 
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?
gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li B345BDD3


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

Bug#299349: ITP: moodle-dialogue -- moodle module to allow internal mail

[Juan Manuel Garcia Molina]

Package: wnpp
Severity: wishlist
Owner: Juan Manuel Garcia Molina <[EMAIL PROTECTED]>

* Package name: moodle-dialogue
  Version : 1.4.4
  Upstream Author : Ray Kingdon 
* URL : http://moodle.org/download/modules/
* License : GPL
  Description : moodle module to allow internal mail

 This Moodle module allows students or teachers to start two-way
 dialogues with another person.
 .
 The funcionality of this module will eventually be made part
 of a standard messaging function in future versions of Moodle.
 
-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: Offer to take over the shadow package (passwd and login binary packages)

[Christian Perrier]

> > I have announced in many places my intent to take over the package
> > development, which I'm in fact doing since mid 2004 (with NMUs).
> 
> Would you also take over xscreensaver and maybe let me co-maintain it?


I'm afraid I have to decline. More packages would be, for me, a bit
too much and I have no strong motivation for xscreensaver.



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

Re: Offer to take over the shadow package (passwd and login binary packages)

[Ralf Hildebrandt]

* Christian Perrier <[EMAIL PROTECTED]>:

> > Would you also take over xscreensaver and maybe let me co-maintain it?
> 
> I'm afraid I have to decline. More packages would be, for me, a bit
> too much and I have no strong motivation for xscreensaver.

Just asking, since somebody would have to do it.

-- 
_

  Charité - Universitätsmedizin Berlin
_

  Ralf Hildebrandt
   i.A. des IT-Zentrum | Netzwerkdienste
   Stabsstelle des Klinikumsvorstandes
   Campus Benjamin Franklin
   Hindenburgdamm 30 | Berlin
   Tel. +49 30 450 570155 | Fax +49 30 450 570962
   [EMAIL PROTECTED]
   http://www.charite.de


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

Re: Offer to take over the shadow package (passwd and login binary packages)

[Josselin Mouette]

Le dimanche 13 mars 2005 Ã 21:52 +0100, Ralf Hildebrandt a Ãcrit :
> * Christian Perrier <[EMAIL PROTECTED]>:
> 
> > > Would you also take over xscreensaver and maybe let me co-maintain it?
> > 
> > I'm afraid I have to decline. More packages would be, for me, a bit
> > too much and I have no strong motivation for xscreensaver.
> 
> Just asking, since somebody would have to do it.

Don't take this as a promise to take it over, but I'll see what I can
do.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

ITO: oftc-hybrid, bubblefishymon

[Martin Wuertele]

Hi!

Due to lack of time and since I stopped using it quite a while ago I
intendo to orphan oftc-hybrid. The package is outdated, current upstream
version is oftc-hybrid-1.4.0pre4.

Since nor weasel nor I use bubblefishymon we intend to orphan this one
as well. There is no more upstream work in progress and there seems to
be a problem with 2.6 kernels.

yours maxx
-- 
<[EMAIL PROTECTED]>  Debian GNU/Linux - The Universal Operation System


signature.asc
Description: Digital signature

Re: Offer to take over the shadow package (passwd and login binary packages)

[Anibal Monsalve Salazar]

On Sun, Mar 13, 2005 at 09:52:25PM +0100, Ralf Hildebrandt wrote:
>* Christian Perrier <[EMAIL PROTECTED]>:
>
>>>Would you also take over xscreensaver and maybe let me co-maintain it?
>>
>>I'm afraid I have to decline. More packages would be, for me, a bit
>>too much and I have no strong motivation for xscreensaver.
>
>Just asking, since somebody would have to do it.

If you prepare a new source package with you as the maintainer, I'll
help you uploading it.

>-- 
>_
>
>  Charité - Universitätsmedizin Berlin
>_
>
>  Ralf Hildebrandt
>   i.A. des IT-Zentrum | Netzwerkdienste
>   Stabsstelle des Klinikumsvorstandes
>   Campus Benjamin Franklin
>   Hindenburgdamm 30 | Berlin
>   Tel. +49 30 450 570155 | Fax +49 30 450 570962
>   [EMAIL PROTECTED]
>   http://www.charite.de

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


signature.asc
Description: Digital signature

Bug#299379: ITP: moodle-book -- moodle module for multi-page resources

[Juan Manuel Garcia Molina]

Package: wnpp
Severity: wishlist
Owner: Juan Manuel Garcia Molina <[EMAIL PROTECTED]>

* Package name: moodle-book
  Version : 1.4.4
  Upstream Author : Petr Skoda 
* URL : http://moodle.org/download/modules/
* License : GPL
  Description : moodle module for multi-page resources

 This Moodle module makes it easy to create multi-page
 resources with a book-like format.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) (ignored: 
LC_ALL set to [EMAIL PROTECTED])


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

Re: Offer to take over the shadow package (passwd and login binary packages)

[Ralf Hildebrandt]

* Josselin Mouette <[EMAIL PROTECTED]>:

> > > I'm afraid I have to decline. More packages would be, for me, a bit
> > > too much and I have no strong motivation for xscreensaver.
> > 
> > Just asking, since somebody would have to do it.
> 
> Don't take this as a promise to take it over, but I'll see what I can
> do.

I already made an attempt:
http://www.stahl.bau.tu-bs.de/~hildeb/debian/
The i386 desb and xscreensaver_4.20-0.tar.gz contains the debianized source.

-- 
_

  Charité - Universitätsmedizin Berlin
_

  Ralf Hildebrandt
   i.A. des IT-Zentrum | Netzwerkdienste
   Stabsstelle des Klinikumsvorstandes
   Campus Benjamin Franklin
   Hindenburgdamm 30 | Berlin
   Tel. +49 30 450 570155 | Fax +49 30 450 570962
   [EMAIL PROTECTED]
   http://www.charite.de


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

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Andreas Barth]

* Thomas Bushnell BSG ([EMAIL PROTECTED]) [050312 02:05]:
> Since the all but one of the other arch buildd's have empty
> needs-build queues, it is harmless to force them to execute a
> recompile and costs no scarce resources.  I did check this before
> uploading. 

Even in the case the buildds otherwise idleing, it costs time of the
buildd admin to check the log and sign the upload.

> If, perhaps, there was a clear indication of the buildd ordering
> policy, then it could be properly used.  Until then, I go on the basis
> of guesswork.  

The ordering applied is (in this order, first difference wins)
- >= standard
- not uncompiled
- priority of the package
- priority of the section
- name

That all is BTW visible from the code (or you could just ask).


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Andreas Barth]

* Thomas Bushnell BSG ([EMAIL PROTECTED]) [050312 04:25]:
> Steve Langasek <[EMAIL PROTECTED]> writes:

> > The queue ordering is entirely automatic, and AIUI the queue(s) is (are)
> > sorted by:
> > 
> > - target suite
> >   - package priority
> > - package section
> >   - package name
> > 
> > I personally believe it would be beneficial to prioritize by upload urgency
> > as well (probably as a sort criterion between package priority and package
> > section), but the w-b maintainers disagree.
 
> I see, the problem is clearly that gnucash is in the "Extra" priority
> instead of the "Optional" section where it belongs.  I'll request the
> ftpmasters to change it.

Our goal is that the queue gets empty from time to time, and so,
priority shouldn't prevent a package from being built.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Andreas Barth]

* Matthew Palmer ([EMAIL PROTECTED]) [050312 05:25]:
> On Fri, Mar 11, 2005 at 07:14:35PM -0800, Steve Langasek wrote:
> > The queue ordering is entirely automatic, and AIUI the queue(s) is (are)
> > sorted by:
> > 
> > - target suite
> >   - package priority
> > - package section
> >   - package name
> > 
> > I personally believe it would be beneficial to prioritize by upload urgency
> > as well (probably as a sort criterion between package priority and package
> > section), but the w-b maintainers disagree.

> I'm trying to work out why package *section* matters at all.  Package name
> is a bit odd, too, but including the section in there is just totally whack. 

Because we want packages in base to be preferred, as well as packages in
libs.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

d-i has 99% support for filesystem labels (was: Re: Serious kernel problems on new i386 hardware)

[Andrew Pollock]

On Fri, Mar 11, 2005 at 01:20:00PM +0100, Andreas Tille wrote:
> On Fri, 11 Mar 2005, Miros/law Baran wrote:
> 
> >>it worked.  I really regard this problem as serious because it
> >>probably leaves people with SATA hardware with an unbootable system
> >>after kernel-image updates, because the kernel image packages just
> >>reinsert "root=/dev/hda?" into grub's menu.lst. Any idea how to
> >>solve this problem?
> >
> >...by using partition labels in fstab?
> Sorry, I do not know anything about partition labels but if this is
> the solution it should be done in the installer and if this works in
> Grub menu.lst this should be done here as well.
> 

I gave some of the relevant people in the d-i team an education on the
benefits of filesystem labels, to to the point where partman will create
filesystems with a label, however I didn't manage to convince them to mount
by the label in /etc/fstab

regards

Andrew

-- 
linux.conf.au 2005   -  http://linux.conf.au/  -  Birthplace of Tux
April 18th to 23rd   -  http://linux.conf.au/  -   LINUX
Canberra, Australia  -  http://linux.conf.au/  -Get bitten!


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

Re: Bug#299379: ITP: moodle-book -- moodle module for multi-page resources

[Ben Burton]

Hi,

>  This Moodle module makes it easy to create multi-page
>  resources with a book-like format.

When you create the actual packages it might be nice to explain what
moodle is, for those of us who have no idea.  e.g.:

  This Moodle module makes it easy to create multi-page
  resources with a book-like format.
  .
  Moodle (Modular Object-Oriented Dynamic Learning Environment) is a
  course management system 

Ben.


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

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Andreas Barth]

* Ingo Juergensmann ([EMAIL PROTECTED]) [050312 14:15]:
> On Sat, Mar 12, 2005 at 02:06:24PM +0100, Martin Zobel-Helas wrote:

> > As it has been said earlier, the machines are back, but just need to
> > catch up. So just waiting might be the easiest thing to do.
 
> More machines can catch up faster than few can do. 
> When one machine out of a dozen machines is unavailable, it has less impact
> than one machine failure out of two machines, although the chances will
> raise that a machine will fail somewhen with more machines. But the impact
> is less critical... 

If you take a look at
http://buildd.debian.org/stats/graph2-week-big.png, you can e.g. see for
mipsel exactly at which date the slow and at which the fast machine
became available again. The fast machine alone is able to keep up with
the usual upload rates.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: Bug#299242: ITP: ha-prosper -- improved LaTeX class for writing transparencies

[Michael Prokop]

* Andreas Tille <[EMAIL PROTECTED]> [20050313 18:15]:
>  On Sun, 13 Mar 2005, Michael Prokop wrote:

> > I think replacing the prosper-package with ha-prosper wouldn't be
> > a good choice. I'd like to provide ha-prosper in a separate 
> > package
> > so when TeXciting is available there aren't any breakages with
> > prosper.

>  Recently I investigated some time in LaTeX based presentation tools.
>  The consequence was:

> 1. Prosper is nice but development tsopped since about 3 years.

> 2. HA-prosper was kind of continuing the work of prosper.  It is
>more enhanced and I even builded some packages for my private
>use of it until I noticed latex-beamer (see below).  My impression
>was that while it is superior about prosper and should prosper
>replace regarding to this fact it is not really worth packaging
>because development is stalled as well because of the new
>TeXciting project.

> 3. LaTeX-Beamer has compatibility modes for prosper and ha-prosper.
>It is much more feature complete and flexible than both above.
>There is absolutely no reson to investigate time into any
>*prosper package because LaTeX-Beamer is the package your
>really want.  For an example see

>  http://people.debian.org/~tille/talks/200503_peking_cdd/index_en.html
>I do not know anything about TeXciting and thus I can not compare
>but before crowding the archive with a package like ha-prosper
>try LaTeX-Beamer.

I do know many people who are used to ha-prosper and haven't
switched to LaTeX-Beamer yet.

ha-prosper needs less space than latex-beamer (not taking care of
dependencies but ratio should be equalent):

[EMAIL PROTECTED] ~ # apt-cache show ha-prosper | grep Installed-Size
Installed-Size: 516
[EMAIL PROTECTED] ~ # apt-cache show latex-beamer | grep Installed-Size
Installed-Size: 3364
[EMAIL PROTECTED] ~ #

And TeXciting might never be released, quoting Hendri - the author
of ha-prosper:

| I have reconsidered whether it will be possible
| to finish this project. Taking into account also
| the work that I'm doing on other packages and
| my involvement in LaTeX3, I conclude that it will
| unfortunately be very unlikely, that I will ever
| finish that project.

See his posting on ha-prosper-mailinglist for more details:
http://listserv.surfnet.nl/scripts/wa.exe?A2=ind0503&L=ha-prosper&F=&S=&P=777

So in my opinion it would be useful to provide a debian package of
ha-prosper.

regards,
-mika-


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

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Ingo Juergensmann]

On Sun, Mar 13, 2005 at 11:25:33PM +0100, Andreas Barth wrote:

> > More machines can catch up faster than few can do. 
> > When one machine out of a dozen machines is unavailable, it has less impact
> > than one machine failure out of two machines, although the chances will
> > raise that a machine will fail somewhen with more machines. But the impact
> > is less critical... 
> If you take a look at
> http://buildd.debian.org/stats/graph2-week-big.png, you can e.g. see for
> mipsel exactly at which date the slow and at which the fast machine
> became available again. The fast machine alone is able to keep up with
> the usual upload rates.

And? Where's the conflicting part of what I've said?

If you go back just long enough in time, you would see that there was a time
when kullervo had no problems with keeping up at all. And then you see that
arrakis helped kullervo in doing that job. 
And coming back to today, you'll notice that m68k has no problems with
keeping up at all. 

Spot the differences to other archs yourself.

BTW: don't forget to apply the passwords to your buildds for status updates. 

-- 
Ciao...  // 
  Ingo \X/


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

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Andreas Barth]

* Matthew Palmer ([EMAIL PROTECTED]) [050313 01:05]:
> On Sat, Mar 12, 2005 at 03:12:12PM -0800, Steve Langasek wrote:
> > Er, packages *do* eventually get built; they just don't get built in any
> > kind of FIFO order.

> Er, no.  Unless there's some sort of aging process (not yet described in the
> threads here) which will result in an extra package called zappa in section
> x11 from eventually being promoted above a package aardvark in section
> admin, it is entirely possible that package will never be built.  All it
> requires is for the rate of new packages entering the queue before zappa to
> be equal to or greater than the rate of packages leaving the queue due to
> having been built or removed.

If that happens for a too long period, we might consider such an
architecture to be too slow to keep up, and will eventually discuss
about kicking it out of the architectures we wait for testing migration
at all, or even kicking it out of testing at all. Not waiting for such
an arch has happened and might happen again.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: Offer to take over the shadow package (passwd and login binary packages)

[Norbert Tretkowski]

* Ralf Hildebrandt wrote:
> * Josselin Mouette <[EMAIL PROTECTED]>:
> > Don't take this as a promise to take it over, but I'll see
> > what I can do.
> 
> I already made an attempt:
> http://www.stahl.bau.tu-bs.de/~hildeb/debian/

Please don't build it as a native Debian package, so there's a
separate orig.tar.gz and the diff.gz which includes the Debian
changes.

Btw, if you need a sponsor for an upload, just drop me a mail.

Norbert


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

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Matthew Palmer]

On Sun, Mar 13, 2005 at 11:17:52PM +0100, Andreas Barth wrote:
> * Matthew Palmer ([EMAIL PROTECTED]) [050312 05:25]:
> > On Fri, Mar 11, 2005 at 07:14:35PM -0800, Steve Langasek wrote:
> > > The queue ordering is entirely automatic, and AIUI the queue(s) is (are)
> > > sorted by:
> > > 
> > > - target suite
> > >   - package priority
> > > - package section
> > >   - package name
> > > 
> > > I personally believe it would be beneficial to prioritize by upload 
> > > urgency
> > > as well (probably as a sort criterion between package priority and package
> > > section), but the w-b maintainers disagree.
> 
> > I'm trying to work out why package *section* matters at all.  Package name
> > is a bit odd, too, but including the section in there is just totally 
> > whack. 
> 
> Because we want packages in base to be preferred, as well as packages in
> libs.

I think I slightly misunderstood the "ordering by section" bit -- I was
assuming an alphabetical ordering by section.  So once base and libs have
had their priority building, what's the ordering after that?  Alphabetical
by section, or does it go straight into a alphabetical by package name?

- Matt


signature.asc
Description: Digital signature

Re: Bug#299242: ITP: ha-prosper -- improved LaTeX class for writing transparencies

[Josselin Mouette]

Le dimanche 13 mars 2005 Ã 23:10 +0100, Michael Prokop a Ãcrit :

> And TeXciting might never be released, quoting Hendri - the author
> of ha-prosper:
> 
> | I have reconsidered whether it will be possible
> | to finish this project. Taking into account also
> | the work that I'm doing on other packages and
> | my involvement in LaTeX3, I conclude that it will
> | unfortunately be very unlikely, that I will ever
> | finish that project.
> 
> See his posting on ha-prosper-mailinglist for more details:
> http://listserv.surfnet.nl/scripts/wa.exe?A2=ind0503&L=ha-prosper&F=&S=&P=777
> 
> So in my opinion it would be useful to provide a debian package of
> ha-prosper.

If TeXciting isn't likely to be released soon, that makes the point of
making a separate package from prosper moot, doesn't it?
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Kurt Roeckx]

On Mon, Mar 14, 2005 at 09:44:33AM +1100, Matthew Palmer wrote:
> On Sun, Mar 13, 2005 at 11:17:52PM +0100, Andreas Barth wrote:
> > Because we want packages in base to be preferred, as well as packages in
> > libs.
> 
> I think I slightly misunderstood the "ordering by section" bit -- I was
> assuming an alphabetical ordering by section.  So once base and libs have
> had their priority building, what's the ordering after that?  Alphabetical
> by section, or does it go straight into a alphabetical by package name?


There is a list in wanna-build for each section.

The start of it looks like:
libs
debian-installer
base
devel
shells
perl
python


If you want to full list, look at the source.


Kurt


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

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Thomas Bushnell BSG]

Andreas Barth <[EMAIL PROTECTED]> writes:

> Because we want packages in base to be preferred, as well as packages in
> libs.

I think that is a given, but it's not uploads to base and libs that
are hosing the recompilation of gnucash at present.

I think it's worth looking at the perverse incentives that the current
system offers.  (A perverse incentive is one that rewards people for
doing the wrong thing.)

My top release priority is getting my own packages in shape, which
means closing all release critical bugs and fixing all the important
bugs which can be.  Gnucash in stable and testing currently has a very
serious RC bug which can cause massive data loss, *in an accounting
application* where such data loss is all the more serious.

My second release priority is doing what I can to fix RC bugs in other
packages, and clean up and monitor the QA packages as  best as I can.

But I will not be fixing any RC bugs in other packages or making any
QA uploads, because nearly every such package comes ahead of gnucash
in the list, and not because they are base and libs, but because they
are optional and gnucash has the wrong priority (extra).  Any work I
do on my second release priority will delay my top release priority.
I believe that taking care of my own packages' bugs should be my top
priority--as it should be for every DD--and if I do any uploads of
other packages, it will delay that first priority.

So the current system is creating a perverse incentive for me to sit
on my hands, and only fix bugs in other packages once gnucash has
*finally* gotten rebuilt, which may well be three months from the date
the bug was fixed.

The bug was reported January 21; I confirmed the bug, implemented the
fix, and uploaded the fixed package the same day.  This, it seems to
me, is what should happen for such a dangerous bug.  It is now nearly
two months later, and the fix still isn't in testing.  And I will do
nothing to further hose gnucash users by delaying more the bug's entry
into sarge.

In the past two days, gnucash has slipped from being 90th on s390 to
being 189th, and has moved essentially not at all on arm and mipsel.
It may well be another month before it actually gets rebuilt.  Any
upload I do for any other package, any bug fix I suggest which some
other maintainer uploads, further hoses my primary responsibility.

I want a system where I can fix bugs in other packages while I'm
waiting, and upload them, *without* it hosing my primary
responsibility.  

Thomas




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

Re: Bug#299379: ITP: moodle-book -- moodle module for multi-page resources

[Juan Manuel Garcia Molina]

Hi, Ben and folks.

On Sunday 13 March 2005 23:22, you wrote:
> Hi,
>
> >  This Moodle module makes it easy to create multi-page
> >  resources with a book-like format.
>
> When you create the actual packages it might be nice to explain what
> moodle is, for those of us who have no idea.  e.g.:
>
>   This Moodle module makes it easy to create multi-page
>   resources with a book-like format.
>   .
>   Moodle (Modular Object-Oriented Dynamic Learning Environment) is a
>   course management system 

Nice suggestion. I'll include a paragraph explaining what Moodle is in both 
«moodle-book» and «moodle-dialogue».


Regards,
Juanma.

-- 
Juan Manuel  Garcia Molina
Debian GNU/Linux Developer
[EMAIL PROTECTED] http://www.debian.org


pgpeLC5NXYEdu.pgp
Description: PGP signature

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Andreas Barth]

* Andreas Barth ([EMAIL PROTECTED]) [050313 23:15]:
> * Thomas Bushnell BSG ([EMAIL PROTECTED]) [050312 02:05]:
> > If, perhaps, there was a clear indication of the buildd ordering
> > policy, then it could be properly used.  Until then, I go on the basis
> > of guesswork.  

> The ordering applied is (in this order, first difference wins)
> - >= standard
> - not uncompiled
> - priority of the package
> - priority of the section
> - name

Which goes in front of that ordering is that all buildds check
wanna-build in the order of the priority of the suites, i.e. security
uploads first, than stable, ..., but only take packages not in noauto,
and, if all queues are empty, also take up packages in noauto_weak in
the same order (both are individual settings at each buildd).


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: Is Anthony Fok MIA?

[Thomas Bushnell BSG]

Martin Michlmayr <[EMAIL PROTECTED]> writes:

> > We are a bit concerned with old LilyPond packages, and a potential
> > new maintainer (Pedro Kroger) with his sponsor going mia.
> 
> Who was going to sponsor him?

I use lilypond all the time, so I'm happy to adopt it if necessary.
I'm a bad mentor/sponsor however.

Thomas


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

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Andreas Barth]

* Matthew Palmer ([EMAIL PROTECTED]) [050313 23:50]:
> I think I slightly misunderstood the "ordering by section" bit -- I was
> assuming an alphabetical ordering by section.  So once base and libs have
> had their priority building, what's the ordering after that?  Alphabetical
> by section, or does it go straight into a alphabetical by package name?

It is a highly ordered list, more or less libs+base first, than devel, shells,
perl, python. After that graphics, admin, utils. Just to look at the
other side of the sorting order, at the end of the list is hamradio,
non-US and embedded. The large ones like gnome and kde are in the middle
of the list. Please see wanna-builds source for the full list.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: automake/autoconf in build-dependencies

[Junichi Uekawa]

Hi,

> However, if I left it to the source package to run autoconf by itself
> weach time it is build, it could slide into unbuildability _without me
> or anybody else noticing_ before it is too late and we have
> not-buildable-anymore code sitting around in the archive, and most
> likely even in testing.

IMO, it should be the other way around;
it will slide into unbuildability without anybody noticing if 
we don't auto-generate using autoconf and automake.
People do rebuild Debian packages regularly.

By autogenerating autoconf/automake data at build time
it is possible to ensure that users can edit configure.ac and
Makefile.am safely.

It will better serve users to notice autoconf/automake incompatibility
earlier than when trying to modify the source.


The current practice and trend is going the other way, 
but I strongly recommend for using autoconf/automake in build scripts.



regards,
junichi



pgpjd1I92BS0L.pgp
Description: PGP signature

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Hamish Moffatt]

On Sun, Mar 13, 2005 at 11:16:56PM +0100, Andreas Barth wrote:
> Our goal is that the queue gets empty from time to time, and so,
> priority shouldn't prevent a package from being built.

How often should the queue be emptied, or when will an architecture be
declarared not-keeping-up?

According to
http://people.debian.org/~igloo/needs-build-graph/index.php?days=30
arm hasn't been empty in over 3 weeks, and it's getting worse still.
s390 is also rising steeply.


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


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

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Hamish Moffatt]

On Mon, Mar 14, 2005 at 12:01:59AM +0100, Andreas Barth wrote:
> It is a highly ordered list, more or less libs+base first, than devel, shells,
> perl, python. After that graphics, admin, utils. Just to look at the
> other side of the sorting order, at the end of the list is hamradio,
> non-US and embedded. The large ones like gnome and kde are in the middle
> of the list. Please see wanna-builds source for the full list.

Given how low hamradio (and the like) are prioritised, I suggest that we
get smarter about 'tesing' and omit some sections on some architectures.

Frankly there are not likely to be any users for hamradio on s390, mips*
arm, or m68k. Nor electronics. Instead those architectures just prevent
the migration to testing for those packages, for no good reason.

I'm in favour of building all packages on all architectures (when time
permits), and FTBFS bugs should be release-critical. But do we need to
actually make those packages critical for release? For zero users?

Having half your packages prioritised last in the build queue is rather
insulting to be honest..

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


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

Re: Switchconf: Orphaning or removing?

[Jose Manuel dos Santos Calhariz]

On Sat, Mar 12, 2005 at 10:34:19PM +0100, Florian Möllers wrote:
> Hi,
> 
> can you just give us (at the fai mailing list) a brief description of
> what you are discussing?!
> 
> Let me guess, and I migth be totally wrong, but you are discussing ways
> to install 60 PCs with Debian and you have 4 different configurations to
> install.
> 

But it have some extra difficulties.  English is not my main language
so is dificult to me to explain the problem well.  

I have 6 labs in the University with about 60 computers, dual
booting Windows XP and linux.  This computers will be used by the
students to do work for the classes and as desktop for general work
and leisure.

Some of the software for Windows is complicated to install.  For
example to setup "Tomcat for Java Web Services" and "Java Web Services
Developer Pack", with other software, I have a manual with 22 pages of
requirements before it can be used in classes.  I tried to setup the
same software in Linux -- as way to promote Linux in a very Windows
centered University -- but my ignorance of JWSDP was too much and I had
to give up.  It's normal after the first deployment and after the
starting the classes to correct problems with the software or install
more.

This computers are installed by imaging a disk from the reference
computer to the 60 computers in the labs, using Symantec Ghost.  To
reduce the effort there only one image of windows and one of linux,
that have to adapt to the different kinds hardware.  If are found
problems with the setup of the software, the reference computer is
updated, and new images are copied to the computers in the labs.

This year I made one Debian installation with the software for the
classes using Linux plus GNOME and KDE.  As the computers are of 4
different kind I have a script that look into the PCI bus during boot
and change XF86Config-4 gpm.conf to suit the hardware and another do a
reverse name of the IP, and set the hostname and the mailname.  It's
during the boot that I use switchconf to change XF86Config-4 and
gpm.conf.

From the experience I have, it seams to be faster to have a reference
computer with the software already installed, that are after copied
using ghost to the 60 computers in the labs.  Because the only thing
that change with this computers is the VGA Display, the monitor and
the mouse and I have to suport Windows XP on NTFS.

The classes have already started and exist some minor problems and
others not so minor problems with the Debian installation and the
Symantec Ghost is not working well, so this time is needed more manual
work, so every computer have to be booted by hand using a floppy.

If you have a way to read Portuguese you may read the site I made for
the teachers to request software and follow the production of the
installations for the labs.  Altavista maybe a help for you.

http://web.tagus.ist.utl.pt/~jose.calhariz/LabIndexCiist.html

Excuse simplistic style of the pages I wanted to be very easy to
make.

As a conclusion:

I don't know how much time it takes installing 10 computers at same
time using FAI or how much work is need  to setup cfengine2.

So I believe is better to have one reference machine that is copied to
the 60 computers, using ghost to install Windows XP and Linux, because
after the first deployment is normal to produce two or more updates.
Possibly I will use other way to update only the Linux, because this
year Windows XP alread finished and I have more work to do on the
Linux part.  May bet is going to use ramind, I use it to update a lab
of 15 iMacs with OS X 10.2 and think it will feat well on Linux too.

http://rsug.itd.umich.edu/software/radmind/

FAI is a good way for the students to install Debian on there's personal
computers, already configured for the classes and for the network in
the University?

  Jose Calhariz


-- 
Nao ha nada como o sonho para criar o futuro. Utopia hoje, 
carne e osso amanha.
-- Victor Hugo


signature.asc
Description: Digital signature

Re: Orphaning three packages

[Martin Michlmayr]

* Neil McGovern <[EMAIL PROTECTED]> [2005-02-12 14:30]:
> I'm orphaning three packages:
> hawhaw-doc - the documentation for HAWHAW and HAWXY
> hawxy - a script that makes PHP-enabled webservers to HAWHAW proxies
> libphp-hawhaw - a PHP toolkit to create universal mobile applications
...
> If no one wants them, I'll ask for their removal.

It has been over a month and nobody has indicated interest.  Since
these packages have never been part of a stable release, I think
removing them would make sense.  Is it okay with you to go ahead with
this?
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Re: orphaning some of my packages

[Martin Michlmayr]

* Joerg Wendland <[EMAIL PROTECTED]> [2005-02-08 12:09]:
> I have neither time for nor interest in maintaining the following
> packages any more.
> 
>  fam  - the file alteration monitor
>  pam-pgsql - PAM module for authentication against PostgreSQL
>  ulogd - netfilter userspace logging daemon

These packages have not been adopted yet.  Can you please file proper
WNPP bugs for them (see http://www.debian.org/devel/wnpp).
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Thomas Bushnell BSG]

Hamish Moffatt <[EMAIL PROTECTED]> writes:

> Given how low hamradio (and the like) are prioritised, I suggest that we
> get smarter about 'tesing' and omit some sections on some architectures.

I don't think those sections are causing the problem.  There are also
not so many uploads for them.  The problem from my perspective is that
"optional" packages all have to be built before any "extra" packages
get considered.  That's what's hosing gnucash.

Removing a few sections also wouldn't help the perverse incentives
that the current system offers.

Thomas


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

> Some maintainers have already opted to move their GFDL documentation
> to non-free for sarge, but the vast remainder will need to be dealt
> with soon after sarge's release to keep us on track for etch.

I assume you mean that the documentation will need to be dealt with,
not the maintainers. :)

My first thought is that the first part of this (reducing the number
of archs that get official releases) is a good idea and the criteria
seem reasonable.  But the second part seems unnecessary.  We can
easily take the archs that we don't intend to mirror and put them on a
different place from ftp.gnu.org; why would they need to be removed
from it enterely?  Also, the first part has a clear statement of which
archs pass its tests at present; but the second does not that I could
see.

Thomas


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Steve Langasek]

On Sun, Mar 13, 2005 at 08:57:14PM -0800, Thomas Bushnell BSG wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:

> > Some maintainers have already opted to move their GFDL documentation
> > to non-free for sarge, but the vast remainder will need to be dealt
> > with soon after sarge's release to keep us on track for etch.

> I assume you mean that the documentation will need to be dealt with,
> not the maintainers. :)

Er... yes. ;)

> My first thought is that the first part of this (reducing the number
> of archs that get official releases) is a good idea and the criteria
> seem reasonable.  But the second part seems unnecessary.  We can
> easily take the archs that we don't intend to mirror and put them on a
> different place from ftp.gnu.org; why would they need to be removed
> from it enterely?  Also, the first part has a clear statement of which
> archs pass its tests at present; but the second does not that I could
> see.

For clarification, the plan is that those existing ports no longer
distributed via ftp.debian.org will continue to be distributed via some
alternate hostname (and mirrors), in theory scc.debian.org.  This
"second part" is actually the plan that's been in the works for quite
some time already, and is the precondition to being able to add amd64 to
ftp.debian.org because of lack of disk space.  The ports that are
release candidates for sarge that wouldn't be candidates for etch are
all still (at least today) candidates for scc.debian.org.

The sh and hurd-i386 ports don't currently meet the SCC requirements, as
neither has a running autobuilder or is keeping up with new packages.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: automake/autoconf in build-dependencies

[Henrique de Moraes Holschuh]

On Mon, 14 Mar 2005, Kurt B. Kaiser wrote:
> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
> >> When I include the configure script in my source packages, I can feel
> >> pretty confident that they package I upload will stay buildable even
> >> if a week from now autoconf or automake gets updated to something not
> >> backwards compatible.
> >
> > Yes. That's how I see it as well.
> 
> 
> However, these files (as generated by the Debian maintainer's autotools
> run before the upload) should be included in the source package via the
> .diff.gz. so that the user doesn't need autotools.

OR, if you have a damn good reason to (e.g. you dpatch configure.ac), you
run autotools on the build tree...

> 1. How does one configure CVS to run the autogen.sh?

Module hooks in CVSROOT/* stuff.  I never did that, I prefer to have
debian/rules run autogen.sh if configure is missing.

> 2. If the autogen.sh invocation is done during the build by
>debian/rules it can't be done prior to "building the source
>package", which I interpret to mean creating the .diff.gz.  "Get
>this script to be run" implies a dependency of some kind: a missing
>configure script or a missing configure-stamp. And in that case,
>the buildds will also invoke it.

No, they won't.  See all the build logs for all my packages that
build-depend on autotools-dev for empiric proof.  In particular, get
rng-tools which is a small one and fairly simple to understand, and play
with it.

> 3. When using cvs-buildpackage, a clean copy of the repository is
>exported, but then dpkg-buildpackage kicks off without a chance for
>maintainer intervention to do something before the build.  Perhaps
>I could use the -H option to run autogen.sh?

There is no need to.  configure is missing, so make will run autogen.sh
which will create it.

This only works because dpkg-buildpackage calls the clean target before
doing anything, BTW.  And all things Debian follow its lead (i.e. pbuilder,
the buildds, sbuild, cvs-buildpackage, etc all either use dpkg-buildpackage
or do things as dpkg-buildpackage would do).

> If the Debian maintainer has run autotools before uploading, should
> the buildds re-run the autotools or not?

They need not to IMHO, but if you want them to, you can easily force that to
happen as well.   I would only do that if I needed to dpatch configure.ac,
or something like that.

> > Agreed.  That's the current best practice for Debian, as far as I am
> > concerned.

I should have added that doing it at build time if you have a good reason to
is also best-practice.

> README.Debian.gz is a little obscure in places, and answers to the
> above questions would be helpful to me.

Sure thing.  Did the above answers help any?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: automake/autoconf in build-dependencies

[Marc Haber]

On Mon, 14 Mar 2005 09:04:17 +0900, Junichi Uekawa
<[EMAIL PROTECTED]> wrote:
>The current practice and trend is going the other way, 
>but I strongly recommend for using autoconf/automake in build scripts.

Does cdbs do it right?

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: automake/autoconf in build-dependencies

[Kurt B. Kaiser]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:

>> When I include the configure script in my source packages, I can feel
>> pretty confident that they package I upload will stay buildable even
>> if a week from now autoconf or automake gets updated to something not
>> backwards compatible.
>
> Yes. That's how I see it as well.

As I understand your suggestions in autotools-dev:

Machine generated files (e.g. configure) constructed by autotools
should not be in CVS.

However, these files (as generated by the Debian maintainer's autotools
run before the upload) should be included in the source package via the
.diff.gz. so that the user doesn't need autotools.

Therefore, the Debian maintainer should run autotools using current
config.{sub,guess} before the diff.gz file is generated, possibly via
an 'autogen.sh' script.

The README.Debian.gz from autotools-dev states:

===
"One can either get this script [i.e. autogen.sh] to be run by
configuring CVS to do so, or by adding some Makefile rules in
debian/rules.

Do note that a properly done autogen.sh invocation runs before dpkg
has a chance to build the source package, so as to make sure an user
does NOT need any of the programs called by autogen.sh to build the
package. This will, in fact, ease the load on auto-builders as well
since the program will build much faster."
===

1. How does one configure CVS to run the autogen.sh?

2. If the autogen.sh invocation is done during the build by
   debian/rules it can't be done prior to "building the source
   package", which I interpret to mean creating the .diff.gz.  "Get
   this script to be run" implies a dependency of some kind: a missing
   configure script or a missing configure-stamp. And in that case,
   the buildds will also invoke it.

3. When using cvs-buildpackage, a clean copy of the repository is
   exported, but then dpkg-buildpackage kicks off without a chance for
   maintainer intervention to do something before the build.  Perhaps
   I could use the -H option to run autogen.sh?

>> > - The extra space in the diff.gz expands the size needed on every
>> > single Debian mirror, as opposed to the short one-time penalties on a
>> > few buildd's.
>
> Unfortunatelly, it is still a good tradeoff.  I am not even bothering about
> CPU time in the buildds anymore, since I got told by buildd admins and
> porters a number of times not to.  BUT the long-term package quality
> benefits are worth the increase in space.

If the Debian maintainer has run autotools before uploading, should
the buildds re-run the autotools or not?

>> That's a real issue, but I still think the least bad solution is to
>> ship finished, known-to-work build scripts in the source package.
>
> Agreed.  That's the current best practice for Debian, as far as I am
> concerned.
>
> In fact, best practice for Debian also requires that you use 
> config.sub and config.guess from autotools-dev if your configure
> script needs them. Just a shameless plug for autotools-dev :-)

README.Debian.gz is a little obscure in places, and answers to the
above questions would be helpful to me.

-- 
Thanks, KBK


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Andreas Tille]

On Sun, 13 Mar 2005, Steve Langasek wrote:
- it must first be part of (or at the very least, meet the criteria for)
 scc.debian.org (see below)
- the release architecture must be publicly available to buy new
- the release architecture must have N+1 buildds where N is the number
 required to keep up with the volume of uploaded packages
- the value of N above must not be > 2
- the release architecture must have successfully compiled 98% of the
 archive's source (excluding architecture-specific packages)
- the release architecture must have a working, tested installer
- the Security Team must be willing to provide long-term support for
 the architecture
(?)
- the Debian System Administrators (DSA) must be willing to support
 debian.org machine(s) of that architecture
(?)
- the Release Team can veto the architecture's inclusion if they have
 overwhelming concerns regarding the architecture's impact on the
 release quality or the release cycle length
(?)
- there must be a developer-accessible debian.org machine for the
 architecture.
IMHO all these facts with exception of those "social" facts I marked (?)
are fullfilled by Sparc.
- there must be a sufficient user base to justify inclusion on all
 mirrors, defined as 10% of downloads over a sampled set of mirrors
Hmmm, regarding to the fact that i386 makes a real lot of percentage it
might be a quite hard limit to have 10%.  I guess this reduces the number
of supported architectures by fitting to a previousely defined number
of architectures we are willing to support.
- the architecture must be freely usable (i.e., without NDAs)
- the architecture must be able to run a buildd 24/7 sustained
 (without crashing)
- the architecture must have an actual, running, working buildd
- the port must include basic unix functionality, e.g resolving
 DNS names and firewalling
- binary packages must be built from the unmodified Debian source
 (required, among other reasons, for license compliance)
- binaries for the proposed architecture must have been built and signed
 by official Debian developers
- the architecture must have successfully compiled 50% of the archive's
 source (excluding architecture-specific packages)
Seems also all be true for Sparc.
- 5 developers who will use or work on the port must send in
 signed requests for its addition
I'm DD and use Sparc (but do no active development to support this
hardware).
- the port must demonstrate that they have at least 50 users
Just did
wajig install popularity-contest
on my Sparc machines.  The problem is that I use a *minimum* set of packages
on a server and the machines I mainly use as servers are Sparcs.
These objective requirements would be applied both to the other eight
architectures being released with sarge that are not currently regarded
as candidates for release with etch, and also to any porter requests
asking for new architectures to be added to the archive.
I do not want to start a "This is my favourite architecture - just include
ist" flamewar.  It is just something I'm using and I feel the technical
parameters you mentioned (and which are very reasonable) fullfilled, while
I see reasons why SParc might show up more seldom in popularity contest for
certain reasons.
In general I would like to say that supporting a lot of architectures was
an important difference between Debian and other distributions.  I know the
drawbacks of this but I just do not want to hide my opinion that I do not
like the idea of reducing the number of supported architectures that drastical.
IMHO the effect would be that people will start forking Debian for porting
issues and we will loose the power of those porters while they will spend
time for things they would not have to do else.
I think we should at least vote about such a drastic change.
Kind regards
  Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Ingo Juergensmann]

On Mon, Mar 14, 2005 at 11:49:34AM +1100, Hamish Moffatt wrote:

> Given how low hamradio (and the like) are prioritised, I suggest that we
> get smarter about 'tesing' and omit some sections on some architectures.
> Frankly there are not likely to be any users for hamradio on s390, mips*
> arm, or m68k. Nor electronics. Instead those architectures just prevent
> the migration to testing for those packages, for no good reason.

How can archs prevent the migration when the software is already uptodate,
f.e. ax25-tools?
http://unstable.buildd.net/cgi/package_status?unstable_all_pkg=ax25-tools&searchtype=go

> I'm in favour of building all packages on all architectures (when time
> permits), and FTBFS bugs should be release-critical. But do we need to
> actually make those packages critical for release? For zero users?

Let the user decide. 
But a user can only use a package, when it's there. Hence the name user... 
 
> Having half your packages prioritised last in the build queue is rather
> insulting to be honest..

Instead of considering dropping archs or excluding archs from building, you
should consider improving the buildd process. The current wanna-build is
known to have many drawbacks. It's an ancient program that doesn't fit any
longer on todays needs. Patching it to death doesn't help much, imho. 

http://www.buildd.net/files/Multibuild-Draft.pdf

-- 
Ciao...  // 
  Ingo \X/


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

Re: d-i has 99% support for filesystem labels (was: Re: Serious kernel problems on new i386 hardware)

[Andreas Tille]

On Mon, 14 Mar 2005, Andrew Pollock wrote:
Sorry, I do not know anything about partition labels but if this is
the solution it should be done in the installer and if this works in
Grub menu.lst this should be done here as well.
I gave some of the relevant people in the d-i team an education on the
benefits of filesystem labels, to to the point where partman will create
filesystems with a label, however I didn't manage to convince them to mount
by the label in /etc/fstab
Well, may be it sounds convincible to file RC bugs for beeing left with
an unbootable system on SATA machines?  But I did not tried with RC3
candidates and I will not have the chance to do this installation
tests with my main working horse ...
Kind regards
 Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

> The sh and hurd-i386 ports don't currently meet the SCC requirements, as
> neither has a running autobuilder or is keeping up with new packages.

It is impossible for any port under development to meet the SCC
requirements.  We need a place for such ports.  Where will it be?

Thomas


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

Re: Restrictive SMTP server

[Kurt B. Kaiser]

Daniel Ruoso <[EMAIL PROTECTED]> writes:

> The fact is that I am unable to send emails with my debian.org address.
> Does someone has some idea of how can I fix that?

fastmail.fm has 'personalities',  'aliases', and smtp access.

-- 
KBK


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

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Wouter Verhelst]

Op za, 12-03-2005 te 16:24 -0800, schreef Thomas Bushnell BSG:
> Matthew Palmer <[EMAIL PROTECTED]> writes:
> 
> > Practically, buildd admins can notice a longer-than-usual queue and throw
> > hardware at the problem, and that seems to work well enough, and we could
> > reduce the rate of package inflow through various means, but the problem
> > still remains -- the queue prioritisation *can* lead to starvation.  I'm not
> > advocating that it be on the top of anyone's todo list to fix it, because we
> > have relatively effective workarounds, but it's not healthy to say the
> > problem does not exist, either.
> 
> What are these "relatively effective workarounds"?

Ask people on port-specific mailinglists to manually build a package for
you (not every Debian Developer on those are buildd admins). Build the
package on the port machine available to all Debian Developers (no, that
indeed doesn't work for all packages). Find someone with a machine of
the target architecture and build it on there yourself. Etcetera.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Wouter Verhelst]

Op za, 12-03-2005 te 15:01 -0800, schreef Thomas Bushnell BSG:
> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> 
> > Remember that the buildd queue is not FIFO at all. The queue has a
> > completly static order. Any changes to the queue are just packages
> > hiding because they are not "needs-build". I consider that the biggest
> > flaw of all in wanna-build.
> 
> This is news to me.
> 
> It means that when one is told "just wait, your package will get
> rebuilt"; it is not necessarily true at all.  There is no upper bound
> at all on time to wait for building, and that's a disaster.

This paragraph assumes nobody ever looks the length of the needs-build
queue of his architecture, and nobody feels bad when the queue is longer
than normal. That idea would be hilarious if it wasn't sad.

In reality, the upper bound is determined by motivated porters who try
hard to avoid the queue ever to grow too long, day after day.

> People
> should stop repeating the fiction then that "just wait" means "your
> package will eventually get built".

Why, if it is true?

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Wouter Verhelst]

Op za, 12-03-2005 te 15:19 +1100, schreef Matthew Palmer:
> I'm trying to work out why package *section* matters at all.

This is simply an attempt to avoid as much
needs-build->building->dep-wait cycles as possible; packages that are
usually build-dependencies are built before packages that are usually
build-depending.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: Is there Linux operating system for Nokia mobile devices?

[Wouter Verhelst]

Op zo, 13-03-2005 te 21:19 +0200, schreef Mikko Ma Aaltonen:
> Hi Debian developers. (My first time post here.)
> 
> I'm here to ask, if anyone of you know,
> has someone done some development work to get a Nokia (or some other
> brand) mobile to work with some other operating system than Symbian?

I'm not sure whether it actually runs on mobile phones; however, there
is a system called 'Familiar Linux' which is a distribution intended for
PDA-class systems.

That being said, this really isn't the right mailinglist for this kind
of question. If you have any further questions, please look on the
familiar mailinglists.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Wouter Verhelst]

Op vr, 11-03-2005 te 17:03 -0800, schreef Thomas Bushnell BSG:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> 
> > Re-uploading a package to provoke a buildd response is counterproductive,
> > *particularly* when the package is already in Needs-Build on the missing
> > architectures.  Re-uploading doesn't change its position in the queue, but
> > it *does* force buildds for all the other archs to needlessly rebuild the
> > package.  This is why the answer to your previous email was "please be
> > patient".
> 
> Unfortunately, the queue ordering policy is unclear.  I was guessing
> that the priority of the upload would have something to do with
> queueing policy.

As is explained on
, this is not the
case.

> Since the all but one of the other arch buildd's have empty
> needs-build queues, it is harmless to force them to execute a
> recompile and costs no scarce resources.

If everyone would reason like that, then it will cost scarce resources.
This is a bogus argument.

> I did check this before
> uploading. 
> 
> I made an upload because a related package (grisbi) just seemed to get
> compiled by all the buildd's in a nifty two-day round trip time.

You were lucky that time around, then.

> It
> was uploaded March 10, compiled by most buildds on the 10th, and by
> arm and mipsel on the 11th.  I concluded that the queue must take note
> of priority or something like that.

It does not.

[...]
> If, perhaps, there was a clear indication of the buildd ordering
> policy, then it could be properly used.  Until then, I go on the basis
> of guesswork.  

That indication is there, and it mainly boils down to 'buildd builds
packages in a more or less predefined order which a maintainer has no
direct influence on'. Of course, we can massage the ordering if
required, but that is only done in exceptional cases.

If your problem is 'my package will not migrate to testing!', then you
are wrong, too. There are precedents for release managers forcibly
moving packages to testing, even if the architectures are not in sync;
there are precedents for an architecture with a huge backlog being
temporarily ignored for the testing migration.

In any case, re-uploading to force a package rebuild is /always/ the bad
thing to do.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Wouter Verhelst]

Op vr, 11-03-2005 te 19:14 -0800, schreef Steve Langasek:
> The queue ordering is entirely automatic, and AIUI the queue(s) is (are)
> sorted by:
> 
> - target suite
   - previous compilation state (already built packages are prioritized
above packages never built for the target architecture)
>   - package priority
> - package section
>   - package name
> 
> I personally believe it would be beneficial to prioritize by upload urgency
> as well (probably as a sort criterion between package priority and package
> section), but the w-b maintainers disagree.

I agree with the w-b maintainers. The queue order is only interesting in
the case where there is a backlog; in other cases, packages are usually
built rather fast. In the case where there is a backlog, those trying to
fix the architecture (usually those that are working on it) should be in
charge of deciding what package gets built first, not the maintainer of
a random package -- /all/ package builds are urgent if there's a
backlog.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: buildd queue starvation (Was: Re: Do not make gratuitous source uploads just to provoke the buildds!)

[Wouter Verhelst]

Op za, 12-03-2005 te 21:12 -0800, schreef Thomas Bushnell BSG:
> Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes:
> 
> > If the queue is non-zero for a longer time, there is a problem in buildd
> > machine power, and the wanna-build admin has choosen to in this case
> > allocate the buildd power that remains to the building of packages that
> > are of higher priority, regardless of their age in the queue. The
> > allocation of a scarce resource is almost by definition a trade-off, and
> > this is the decision that has been made.
> 
> First off, I think much confusion has been caused by using the word
> queue here.  A queue is a FIFO list; if there isn't even the least bit
> FIFO in its management, which seems to be the case, then it shouldn't
> be called a queue.  If it were not called a queue, I would not have
> made many wrong assumptions, and I think others too, to assume that of
> course some kind of FIFO processing was happening.  So PLEASE change
> the name; stop calling it a queue.

None of the documentation calls it a 'queue', in fact; only people not
really involved in buildd stuff do.

> I can see excellent reasons why age in the list shouldn't matter.  But
> package "priority" and "section" are extremely poor bases to decide
> what the actual importance of a package is.

Why would that be the case? You're telling me you think gnome-games is
way more important than gcc for us to build?

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: Bug#299242: ITP: ha-prosper -- improved LaTeX class for writing transparencies

[Andreas Tille]

On Sun, 13 Mar 2005, Michael Prokop wrote:
I do know many people who are used to ha-prosper and haven't
switched to LaTeX-Beamer yet.
As I said - there is a compatibility mode - but I did not tested it yet.
ha-prosper needs less space than latex-beamer (not taking care of
dependencies but ratio should be equalent):
[EMAIL PROTECTED] ~ # apt-cache show ha-prosper | grep Installed-Size
Installed-Size: 516
[EMAIL PROTECTED] ~ # apt-cache show latex-beamer | grep Installed-Size
Installed-Size: 3364
Huh, what's this for an argument?
I guess today we do not really have to care for this and as I said, the
bigger size has its reasons ...
And TeXciting might never be released, quoting Hendri - the author
of ha-prosper:
| I have reconsidered whether it will be possible
| to finish this project. Taking into account also
| the work that I'm doing on other packages and
| my involvement in LaTeX3, I conclude that it will
| unfortunately be very unlikely, that I will ever
| finish that project.
See his posting on ha-prosper-mailinglist for more details:
http://listserv.surfnet.nl/scripts/wa.exe?A2=ind0503&L=ha-prosper&F=&S=&P=777
So this is no problem because we have latex-beamer.  BTW, I guess TeXciting
would have a similar size relation as you mentioned above and we would have
to keep ha-prosper anyway according to your reasoning.
So in my opinion it would be useful to provide a debian package of
ha-prosper.
In the end it is the business of people who are maintaining the package and
I really hope that they will do a good job in maintaining orphaned software.
So I can not keep you away from maintaining ha-prosper but my advise as
somebody who had thought about this on my own and knowing that you have
also to maintain a further package as dependency would be: Just have a
look at latex-beamer's compatibility mode and think twice about it if is
worth the effort.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Thomas Bushnell BSG]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> > It means that when one is told "just wait, your package will get
> > rebuilt"; it is not necessarily true at all.  There is no upper bound
> > at all on time to wait for building, and that's a disaster.
> 
> This paragraph assumes nobody ever looks the length of the needs-build
> queue of his architecture, and nobody feels bad when the queue is longer
> than normal. That idea would be hilarious if it wasn't sad.

There is no need-build queue; please don't call it that because it
causes people to misunderstand it.  "Queue" means "FIFO", at least to
some degree, where needs-build isn't FIFO in any degree.

I have plenty of evidence that the buildd maintainers look at the
length and feel bad when it's long.  But looking at it and feeling bad
aren't sufficient to get a package built.

> In reality, the upper bound is determined by motivated porters who try
> hard to avoid the queue ever to grow too long, day after day.

I have no doubt about their good intentions and trying hard.  

Thomas


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

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Thomas Bushnell BSG]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> I agree with the w-b maintainers. The queue order is only interesting in
> the case where there is a backlog; in other cases, packages are usually
> built rather fast. In the case where there is a backlog, those trying to
> fix the architecture (usually those that are working on it) should be in
> charge of deciding what package gets built first, not the maintainer of
> a random package -- /all/ package builds are urgent if there's a
> backlog.

First, there is no queue.  It's a list, but not a queue.

I agree that we need policy here, but a serious problem is that
currently when there is a backlog, maintainers of penalized packages
have a perverse incentive not to fix any bugs in any *other* package
because it will cause the penalty on their package to continue.



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

Re: buildd queue starvation (Was: Re: Do not make gratuitous source uploads just to provoke the buildds!)

[Thomas Bushnell BSG]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> None of the documentation calls it a 'queue', in fact; only people not
> really involved in buildd stuff do.

Does that include you?  In two recent messages, you referred to it as
a queue.

> > I can see excellent reasons why age in the list shouldn't matter.  But
> > package "priority" and "section" are extremely poor bases to decide
> > what the actual importance of a package is.
> 
> Why would that be the case? You're telling me you think gnome-games is
> way more important than gcc for us to build?

No.  I'm saying that when priorities are marked badly, the results are
disastrous.  I'm also saying that a static ordering produces a
perverse incentive, especially when a priority is marked badly, not to
upload fixes for any other package.

Thomas


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[dann frazier]

On Sun, 2005-03-13 at 20:45 -0800, Steve Langasek wrote:
> The much larger consequence of this meeting, however, has been the
> crafting of a prospective release plan for etch.  

Thank you to those individuals who worked on this plan; I think its a
good step in reducing our release turnaround time.

> - the release architecture must be publicly available to buy new

I'd like to see if we can clarify this text.  I can see some of the
problems this requirement would solve, such as guaranteed availability
of replacement parts for Debian machines, etc.  However, I wouldn't want
to see us drop an arch with a large user community because a company
decides to discontinue a product.

For example, although HP announced they are going to discontinue alpha,
there maybe a large number of alpha users/developers who want to see
stable releases continue, even after debian could no longer purchase a
new one[1].

If its really some side-effect of the discontinuation that's an issue,
let's list that side-effect instead; e.g., if the real issue is that we
need to have a reliable source for spare parts or replacement machines,
lets say that - there are other ways to assure part availability.  If
this requirement is a guideline to help us get down to a target number
of architectures, lets explicitly say that, versus listing it as a firm
requirement.

[1] I have no idea how many alpha users we have, nor how many want to
have a stable release - this is just an example.

-- 
dann frazier <[EMAIL PROTECTED]>
(Note: I'm employed by HP, but I'm not speaking on behalf of HP)


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Steve Langasek]

On Sun, Mar 13, 2005 at 10:47:15PM -0800, Thomas Bushnell BSG wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:

> > The sh and hurd-i386 ports don't currently meet the SCC requirements, as
> > neither has a running autobuilder or is keeping up with new packages.

> It is impossible for any port under development to meet the SCC
> requirements.  We need a place for such ports.  Where will it be?

On the contrary, the amd64 port does, and is currently maintained
completely outside official debian.org infrastructure.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Sun, Mar 13, 2005 at 10:47:15PM -0800, Thomas Bushnell BSG wrote:
> > Steve Langasek <[EMAIL PROTECTED]> writes:
> 
> > > The sh and hurd-i386 ports don't currently meet the SCC requirements, as
> > > neither has a running autobuilder or is keeping up with new packages.
> 
> > It is impossible for any port under development to meet the SCC
> > requirements.  We need a place for such ports.  Where will it be?
> 
> On the contrary, the amd64 port does, and is currently maintained
> completely outside official debian.org infrastructure.

The amd64 port did not always.  Ports under development take time; the
amb64 port is at a late state in its development.  I don't understand
why autobuilding is important to SCC; maybe if you could explain that
I would understand.

Thomas


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Steve Langasek]

Hi Andreas,

On Mon, Mar 14, 2005 at 07:37:51AM +0100, Andreas Tille wrote:
> On Sun, 13 Mar 2005, Steve Langasek wrote:

> IMHO all these facts with exception of those "social" facts I marked (?)
> are fullfilled by Sparc.

For reference, the killer for most archs is the "98% built" criterion;
from today's numbers:

wanna-build stats:
  alpha:97.57% up-to-date,  97.59% if also counting uploaded pkgs
  arm:  92.12% up-to-date,  92.15% if also counting uploaded pkgs
  hppa: 97.66% up-to-date,  97.68% if also counting uploaded pkgs
  hurd-i386:35.59% up-to-date,  35.59% if also counting uploaded pkgs
  i386: 99.83% up-to-date,  99.83% if also counting uploaded pkgs
  ia64: 97.39% up-to-date,  97.41% if also counting uploaded pkgs
  m68k: 97.75% up-to-date,  97.86% if also counting uploaded pkgs
  mips: 96.74% up-to-date,  96.79% if also counting uploaded pkgs
  mipsel:   93.01% up-to-date,  93.01% if also counting uploaded pkgs
  powerpc:  97.99% up-to-date,  98.00% if also counting uploaded pkgs
  s390: 94.31% up-to-date,  94.31% if also counting uploaded pkgs
  sparc:95.77% up-to-date,  95.77% if also counting uploaded pkgs

[curious that ia64 is lower than some others right now -- when we looked
last week, it was above 98%, so maybe etch would have a *different* 4
architectures. ;)]

This may be fixable for one or more architectures for etch by getting a
handle on any existing buildd problems, which I'd personally be happy to
see happen, but we also have to consider that there are some bits (like
ftp-master.d.o itself, as well as toolchains/kernel synchronization)
that just don't scale well to the number of architectures we currently
have.

The 98% mark may seem a little high, but in fact it's not.  Note that
there's been a thread on debian-devel just this week about autobuilders
holding up release-critical bugfixes, and the architectures in question
are still well above 90% -- and they're not the only architectures
delaying RC fixes, they're just the ones that stand out enough to flame
about.  Based on the experience we've had trying to keep sarge on track,
setting the barrier high for etch is definitely in our best interest,
IMHO.

For the specific case of sparc, it's worth noting that this architecture
was tied for last place (with arm) in terms of getting the ABI-changing
security updates for the kernel; it took over 2 months to get all
kernel-image packages updated for both 2.4 and 2.6 (which is a fairly
realistic scenario, since woody also shipped with both 2.2 and 2.4),
which is just way too unresponsive.  The call for sparc/arm kernel folks
in the last release update was intended to address this; correct me if
I'm wrong, but to my knowledge, no one else has stepped forward to help
the kernel team manage the sparc kernels.

> >- there must be a sufficient user base to justify inclusion on all
> > mirrors, defined as 10% of downloads over a sampled set of mirrors
> Hmmm, regarding to the fact that i386 makes a real lot of percentage it
> might be a quite hard limit to have 10%.  I guess this reduces the number
> of supported architectures by fitting to a previousely defined number
> of architectures we are willing to support.

This point is *not* about supported architectures, only about
architectures carried by the primary mirror network.  We did consider
having a single set of requirements for both "release architectures" and
"primary mirror architectures", and the structure of the announcement
might still reflect that, but I couldn't justify using "percent market
share" as a straight criterion for release architectures.

> >- 5 developers who will use or work on the port must send in
> > signed requests for its addition
> I'm DD and use Sparc (but do no active development to support this
> hardware).

Well, sparc is not in any danger of being dropped from SCC. :)  As I
said, none of the current sarge candidate architectures are.

> In general I would like to say that supporting a lot of architectures was
> an important difference between Debian and other distributions.  I know the
> drawbacks of this but I just do not want to hide my opinion that I do not
> like the idea of reducing the number of supported architectures that 
> drastical.
> IMHO the effect would be that people will start forking Debian for porting
> issues and we will loose the power of those porters while they will spend
> time for things they would not have to do else.

I certainly agree that portability is one of Debian's selling points,
and I also have a "pet" architecture that doesn't appear to make the
cut for etch; but I don't think it's a coincidence that the release
cycle got longer when we doubled the arch count between potato and
woody, and I *know* it's not a coincidence that we have a long release
cycle for sarge while trying to wrangle those same 11 architectures.
This proposal is a response to the reality that right now, the per-por

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Steve Langasek]

[please don't cc: me on this thread, one copy is plenty, thanks; and
please don't cc: debian-release unless there's a specific reason it's
on-topic there, which explaining wanna-build is not. ;)]

On Sun, Mar 13, 2005 at 11:30:45PM +0100, Wouter Verhelst wrote:
> Op vr, 11-03-2005 te 17:03 -0800, schreef Thomas Bushnell BSG:

> [...]
> > If, perhaps, there was a clear indication of the buildd ordering
> > policy, then it could be properly used.  Until then, I go on the basis
> > of guesswork.  

> That indication is there, and it mainly boils down to 'buildd builds
> packages in a more or less predefined order which a maintainer has no
> direct influence on'. Of course, we can massage the ordering if
> required, but that is only done in exceptional cases.

> If your problem is 'my package will not migrate to testing!', then you
> are wrong, too. There are precedents for release managers forcibly
> moving packages to testing, even if the architectures are not in sync;
> there are precedents for an architecture with a huge backlog being
> temporarily ignored for the testing migration.

Yes, though we're generally avoiding pushing packages into testing right
now because it's not clear that the t-p-u queue is picking up
out-of-date packages for building, particularly for archs that are
currently hardware strapped; so waiting on the package to build for all
archs in unstable may be the *quickest* way to get the package in sync
in testing.  It's an ugly trade-off, but I think we've erred on the side
of caution for long enough and will probably be more aggressive with
buildd-stalled RC fixes going forward.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Andre Lehovich]

> - there must be a sufficient user base to justify inclusion on all
>   mirrors, defined as 10% of downloads over a sampled set of mirrors

Only i386 currently meets this condition, with c. 97% of
downloads out of the four interesting archs, for details see
the tables below.  I suspect 97% is biased *low*, because
many leaf mirrors only carry i386.

--Andre

Number of downloads (data linked by [1], which also has a nice graph):
UKItaly SwedenAll three
 i386 6193118 96.4%  1762483 97.1%  1204913 97.3%   9160514 96.7%
amd64 N/AN/A   1822   .1%  1822   .0%
ppc/ppc64  182025  2.8%34420  1.9%23226  1.9%239671  2.5%
 ia64   46284   .7%18224  1.0% 8984   .7% 73492   .8%
  === =  === =  === =   === =
total 6421427  100%  1815127  100%  1238945  100%   9475499  100%

Number of hosts in popcon (data from [2]):
 i386 5196  93.5%
amd64  263   4.7%
ppc/ppc64   90   1.6%  (only 1 respondent is ppc64)
 ia64   10.2%
    =
total 5559   100%

The version of popularity-contest in Woody doesn't report
architecture info, so the popcon data mostly reflect
Sid/Sarge users.

[1] http://dirk.eddelbuettel.com/blog/2005/03/08/#more_download_by_arch
[2] http://popcon.debian.org



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