Re: /etc under svk

[Marc Haber]

On Wed, 16 Feb 2005 12:54:37 +0100, Olaf Conradi <[EMAIL PROTECTED]>
wrote:
>You should ask yourself whether you're interested in the history or
>not. If you are store them in a repository. If you just want the
>latest version put them in a backup.

Handling a directory with _some_ files under version control and
others not is a pain, even with subversion.

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: all new Debian diagram - now with less chaos!

[Kevin Mark]

On Wed, Feb 16, 2005 at 10:53:28AM +0100, Frank Küster wrote:
> Kevin Mark <[EMAIL PROTECTED]> wrote:
> 
> > although, now I am getting confused about the difference between a
> > debian developer and a debian maintainer. I labeled most items with 'DD'
> > thinking that's who did stuff. More things to research.
> 
> The maintainer is the guy (or entity) who is listed in the Maintainer:
> field of debian/control, and who gets all the mail for the package¹. 
> 
> A debian developer is anybody with an account @debian.org, who can do
> uploads to the archive.  A Debian developer need not be the maintainer
> of any package (doing mainly QA work, or buildd administration, or
> whatever), and a package maintainer need not be a Debian developer: They
> can have their packages uploaded by a developer who reviewed the
> package, but doesn't want to do all the work.
> 
> Regards, Frank
> 
> 
> ¹others can subscribe to this, too, via the package tracking system
> 
> -- 
Hi Frank,
I have incorparated your info. In my diagram, most of the tasks are done
by maintainers and the buildd stuff would be done by developers.
I have not yet added QA, ftpmaster or security stuff.
-Kev
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!

(__)
(oo)
  /--\/
 / |||
*  /\---/\
   ~~   ~~
"Have you mooed today?"...


signature.asc
Description: Digital signature

Re: Please make Moria free (was: Moria, as in the Author of)

[William Ballard]

On Thu, Feb 17, 2005 at 07:44:53AM +0430, Robert Koeneke wrote:
> 
> Ok, I am working on getting the correct GPL statement put together so this
> game on all the games based on it don't have any restrictions to
> distribution.  It was never my intention to make it hard to share, just to
> make certain my name stayed with the game and future variants of it.
> 
> Sheesh, I should have gone into game design I guess.  I had no idea people
> were still playing these games.  Did anyone ever add the Moria V5.0 new
> features to the game?  Liquids (pools, streams, lava, etc), orbs, and
> recipes for building magic weapons?  There were other things but that's the
> stuff I remember off-hand.
> 
> In case you can't tell, I am no longer a part of the coding community.  I
> moved up the corporate chain to the point of all I do is design enterprise
> systems; no one lets me touch code anymore.
> 
> Enjoy.
> 
> Robert Alan Koeneke
> Enterprise Architect

I hope someone forwards this to the press.  Sheer beauty.


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

apt-src cannot build

[Marcus Sundman]

I do the following (irrelevant output omitted):
8<
/usr/src/tmp$ apt-src install foo
/usr/src/tmp$ cd foo-version
/usr/src/tmp/foo-version$ apt-src build foo
E: Not installed
/usr/src/tmp/foo-version$ 
>8

Any idea what might be wrong?


- Marcus Sundman


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

Kasket Records - Show Dates / Audio / Forum

[Kasket Kyle]

March 5th @ The Brickhouse in St Albans WV
-Brain Trauma
-MoHrG
-Bag Of Hammers
-Psych Ward
-Puddle Of Blood

ALL AGES - $7 at the door - Doors open at 6PM

The Brickhouse is located @ 52 Old Main Plaza, St. Albans, WV



Download the official Brain Trauma - Flatline EP Sampler by following
the link Below...

http://www.kasketrecords.com/media/BrainTrauma-FlatlineSampler.mp3



Also, The official Kasket Records forum is now up, Be the first to know
when shit is going on at Kasket Records by joining and posting at...

http://www.kasketrecords.com/forum/

-Kyle
http://www.kasketrecords.com


To be removed from this list, please respond with REMOVE in the SUBJECT
LINE!


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.8 - Release Date: 2/14/2005


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

Re: Bug#295430: ITP: cpufrequtils -- Tools to access to the Linux kernel cpufreq subsystem

[Hamish Moffatt]

On Wed, Feb 16, 2005 at 02:24:34PM +0100, Daniel Baumann wrote:
> Currently, the priority was not so high to get it uploaded since NEW is 
> on hold.

Is it? Did I miss the memo?


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


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

RE: Please make Moria free (was: Moria, as in the Author of)

[Robert Koeneke]

Ok, I am working on getting the correct GPL statement put together so this
game on all the games based on it don't have any restrictions to
distribution.  It was never my intention to make it hard to share, just to
make certain my name stayed with the game and future variants of it.

Sheesh, I should have gone into game design I guess.  I had no idea people
were still playing these games.  Did anyone ever add the Moria V5.0 new
features to the game?  Liquids (pools, streams, lava, etc), orbs, and
recipes for building magic weapons?  There were other things but that's the
stuff I remember off-hand.

In case you can't tell, I am no longer a part of the coding community.  I
moved up the corporate chain to the point of all I do is design enterprise
systems; no one lets me touch code anymore.

Enjoy.

Robert Alan Koeneke
Enterprise Architect

-Original Message-
From: Erik Schanze [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, February 16, 2005 12:15 PM
To: debian-devel@lists.debian.org
Cc: Clint Adams; Jeroen van Wolffelaar; Robert Koeneke; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Please make Moria free (was: Moria, as in the Author of)

Hi all!

Clint Adams <[EMAIL PROTECTED]>:
> > Do you think moria still has a place in Debian? Or do you gather it
> > might be better removed?
>
> A better question is whether Mr. Koeneke is willing to relicense his
> code under a free software license so that moria and angband and
> derivatives can finally be free.
>
That would be nice and increase the chance that anybody adopt the Debian 
package, I think.


Kindly regards,
Erik


-- 
 www.ErikSchanze.de *
 Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB *
  * Linux-Info-Tag in Dresden, am 29. Oktober 2005  *
 Info: http://www.linux-info-tag.de *



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

Re: help needed with mips build failure

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

> Note that it's not sufficient for the fixed package to reach unstable, the
> buildd admins also (and more importantly) need to clean up the build chroots
> by manually reconciling the status of the xfree86-common package.

Yeah, I'd like to think it's not my job to make sure this happens.
Are the buildd admins aware of the problem?  Do I just need to send an
email asking them to requeue the failing builds?

> It looks like it, though now that I've figured out what was keeping me from
> updating to libtool 1.5 (and speaking of questionable upstream practices),
> I'm surprised to see that your changes in -7 don't run afoul of the fact
> that acinclude.m4 includes a complete local copy of the libtool autoconf
> macros...

lol, isn't it a dream?!

>   sed -i -n -e'/g-wrap.m4/,$p' acinclude.m4 && libtoolize --force --copy \
>   && aclocal-1.4 -I macros && autoconf
> 
> looks like there's some manual fiddling that has to be done in
> po/Makefile.in.in as well; I'll send you a full patch privately once I have
> it building all the way through.

That would be gorgeous.  Many thanks for helping out on this, it is
very much appreciated.

> > Upstream reports that no 1.8 releases should be expected for things
> > like the build system;
> 
> Yeah, a reasonable policy, though it would be nice if they used sane build
> scripts for any future releases on the 1.8 branch.  Is the gnome-2 branch
> already using libtool 1.5?

No, but it will be.  It is using the newer autoconf I'm told, and they
intend to switch to libtool 1.5 before release.

Thomas


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

Re: help needed with mips build failure

[Steve Langasek]

On Wed, Feb 16, 2005 at 05:09:37PM -0800, Thomas Bushnell BSG wrote:
> > That would be RC bug #295175 in the xfree86-common package.  I don't imagine
> > gnucash would've fared any better under these circumstances without the
> > libtool update, either.

> Ah, ok!  I'm glad you are up on these things; I would not have guessde
> to look there.  I'll just wait until that gets into unstable on all
> the arch's and then maybe we can see what gnucash problems remain.

Note that it's not sufficient for the fixed package to reach unstable, the
buildd admins also (and more importantly) need to clean up the build chroots
by manually reconciling the status of the xfree86-common package.

> > Though it might be nice if gnucash's configure script called, and used the
> > output from, the AC_PATH_X macro if it's going to be including X11/Xlib.h
> > (and why does a GNOME application need to directly include X headers,
> > anyway?).

> See, gnucash is big and complicated. :)

> gnucash installs its own Xlib error handler.

Oh, well, ick then. :)

> > Yes, libtool updates are not as nice as they ought to be -- frequently
> > complicated by upstreams' use of questionable practices where autoconf
> > macros (aclocal.m4) are concerned.  I still haven't gotten gnucash playing
> > nicely with libtool 1.5, FWIW, after several iterations...

> Thanks for trying. :)  Maybe once the xfree86-common problems are
> stamped out by Branden, gnucash 1.8.10-7 won't have a severe an issue
> with the older libtool.

It looks like it, though now that I've figured out what was keeping me from
updating to libtool 1.5 (and speaking of questionable upstream practices),
I'm surprised to see that your changes in -7 don't run afoul of the fact
that acinclude.m4 includes a complete local copy of the libtool autoconf
macros...

In any case, I have things mostly working here with libtool 1.5 now; the
update process is basically:

  sed -i -n -e'/g-wrap.m4/,$p' acinclude.m4 && libtoolize --force --copy \
  && aclocal-1.4 -I macros && autoconf

looks like there's some manual fiddling that has to be done in
po/Makefile.in.in as well; I'll send you a full patch privately once I have
it building all the way through.

> Upstream reports that no 1.8 releases should be expected for things
> like the build system;

Yeah, a reasonable policy, though it would be nice if they used sane build
scripts for any future releases on the 1.8 branch.  Is the gnome-2 branch
already using libtool 1.5?

> It is possible that these problems will stymie work on 1.8.10 for
> Debian, at least, not before sarge release.  If that's true, I can
> hobble together an interim version based on the old version in woody,
> which backports the important bugfixes since then, but I would rather
> avoid such a procedure if possible.

I think the path to getting 1.8.10 into sarge is fairly straightforward from
here.  

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: help needed with mips build failure

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

> That would be RC bug #295175 in the xfree86-common package.  I don't imagine
> gnucash would've fared any better under these circumstances without the
> libtool update, either.

Ah, ok!  I'm glad you are up on these things; I would not have guessde
to look there.  I'll just wait until that gets into unstable on all
the arch's and then maybe we can see what gnucash problems remain.

> Though it might be nice if gnucash's configure script called, and used the
> output from, the AC_PATH_X macro if it's going to be including X11/Xlib.h
> (and why does a GNOME application need to directly include X headers,
> anyway?).

See, gnucash is big and complicated. :)

gnucash installs its own Xlib error handler.

> Yes, libtool updates are not as nice as they ought to be -- frequently
> complicated by upstreams' use of questionable practices where autoconf
> macros (aclocal.m4) are concerned.  I still haven't gotten gnucash playing
> nicely with libtool 1.5, FWIW, after several iterations...

Thanks for trying. :)  Maybe once the xfree86-common problems are
stamped out by Branden, gnucash 1.8.10-7 won't have a severe an issue
with the older libtool.

Upstream reports that no 1.8 releases should be expected for things
like the build system; 1.8.10 was a data corruption bug and 1.8.11 was
to fix a release engineering mistake in 1.8.10 (already corrected in
the Debian package, so I haven't bothered with 1.8.11).

The gnome-2 branch of gnucash is still nowhere near ready; release is
expected "later this year".  

It is possible that these problems will stymie work on 1.8.10 for
Debian, at least, not before sarge release.  If that's true, I can
hobble together an interim version based on the old version in woody,
which backports the important bugfixes since then, but I would rather
avoid such a procedure if possible.

Thomas




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

Re: help needed with mips build failure

[Steve Langasek]

On Wed, Feb 16, 2005 at 04:33:04PM -0800, Thomas Bushnell BSG wrote:
> > Considering Debian is the only mainstream desktop distribution with a mips
> > port, and gnucash upstream has in the past disavowed all responsibility for
> > compatibility with non-i386 archs, this seems laughably false.  Also,
> > there's the fact that we've been dealing with this failure of libtool 1.4 to
> > build working shared libs on mips for years, as evidenced by the fact that
> > there *is* a boilerplate response, and no one made the problem up out of
> > whole cloth...
> So as an example of the disasters that this is causing, take a look at
> the build failures for the -6 and -7 versions.  A simple "just
> upgrade, see it's easy" doesn't work, even for the *old* versions of
> the tools.

> Take a look at this one:

> http://buildd.debian.org/fetch.php?&pkg=gnucash&ver=1.8.10-7&arch=mipsel&stamp=1108591154&file=log&as=raw

> It fails because the new tools, for some curious reason, define
> include makefile variable differently than the ones included in
> gnucash.  Gnucash expects to be able to include  and have
> it work.  Supposedly the xfree86-common package provides a symlink from
> /usr/include/X11 to the right place.  But on mipsel (and others) this
> doesn't seem to work, and if you note from the build log linked to
> above, buildd doesn't actually *install* xfree86-common (even though I
> added a Build-Depends), but instead says it is "already installed".

That would be RC bug #295175 in the xfree86-common package.  I don't imagine
gnucash would've fared any better under these circumstances without the
libtool update, either.

Though it might be nice if gnucash's configure script called, and used the
output from, the AC_PATH_X macro if it's going to be including X11/Xlib.h
(and why does a GNOME application need to directly include X headers,
anyway?).

> I'm a little frustrated, because the actual distributed gnucash
> sources work on nearly every arch, but the "oh, just use the new
> tools, here's how" instructions almost perpetually fail and cause me
> extra headache and frustration.

Yes, libtool updates are not as nice as they ought to be -- frequently
complicated by upstreams' use of questionable practices where autoconf
macros (aclocal.m4) are concerned.  I still haven't gotten gnucash playing
nicely with libtool 1.5, FWIW, after several iterations...

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: help needed with mips build failure

[Thomas Bushnell BSG]

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

> As for it being complicated, well, I believe you.  But you need not be
> upstream to change the build system, I have done that three or four times
> already.  It is not the most gratifying work in the world, at all... but the
> result is far easier to keep up-to-date and maintain by a LONG margin.

Have you looked at gnucash?  It's really insanely complicated; it's by
some measures the biggest gnome-1 program that gnome-1 ever had; it
has a bajillion separate shared libraries, uses gnome, and guile, and
plenty of other wonderful stuff too.

It's got a build system about as complicated as what we cooked up for
the Hurd or for libc, and those are not pretty either.

So anyone who is willing to offer some help, PLEASE do; I'm a little
frustrated because I never see any problems on *my* systems, which are
powerpc and i386.

Thomas


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

Re: help needed with mips build failure

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

> Considering Debian is the only mainstream desktop distribution with a mips
> port, and gnucash upstream has in the past disavowed all responsibility for
> compatibility with non-i386 archs, this seems laughably false.  Also,
> there's the fact that we've been dealing with this failure of libtool 1.4 to
> build working shared libs on mips for years, as evidenced by the fact that
> there *is* a boilerplate response, and no one made the problem up out of
> whole cloth...

Fair enough.

So as an example of the disasters that this is causing, take a look at
the build failures for the -6 and -7 versions.  A simple "just
upgrade, see it's easy" doesn't work, even for the *old* versions of
the tools.

Take a look at this one:

http://buildd.debian.org/fetch.php?&pkg=gnucash&ver=1.8.10-7&arch=mipsel&stamp=1108591154&file=log&as=raw

It fails because the new tools, for some curious reason, define
include makefile variable differently than the ones included in
gnucash.  Gnucash expects to be able to include  and have
it work.  Supposedly the xfree86-common package provides a symlink from
/usr/include/X11 to the right place.  But on mipsel (and others) this
doesn't seem to work, and if you note from the build log linked to
above, buildd doesn't actually *install* xfree86-common (even though I
added a Build-Depends), but instead says it is "already installed".

Never mind that the link is manifestly not in place.

So what should I do, O workers of wonders?

I'm a little frustrated, because the actual distributed gnucash
sources work on nearly every arch, but the "oh, just use the new
tools, here's how" instructions almost perpetually fail and cause me
extra headache and frustration.

Thomas


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

Re: please post listing and status of NEW queue

[Anibal Monsalve Salazar]

On Sat, Feb 12, 2005 at 08:30:13AM +0100, Petter Reinholdtsen wrote:
>[Anibal Monsalve Salazar]
>>http://qa.debian.org/~anibal/debian-NEW.html

It's now redirected to http://ftp-master.debian.org/new.html

The web page on ftp-master is Ganneff's work. It's updated once
every hour from the authorative archive. The archive on merkel is
updated once every day.

I would like to work with Ganneff to make changes to the page on
ftp-master.

>Great.  This is much better than my crude hack. If you plan to
>keep this updated all the time, I'll close down my page and point
>people to your page.
>
>>Any input is welcome.
>
>It would be nice if the changelog for the uploaded package is
>available too.
>
>Another feature I've been wishing for is making more statistics,
>for example of averaget waiting time (keeping track of when
>packages come and go), and perhaps an history to know when how
>often a given package have been in the NEW queue. Some packages
>return (shared libraries changing sonames, mplayer, etc), and it
>would be nice to let this system tell us instead of trusting
>memory.
>
>I've also considered looking at "out-of-order" processing of
>queue entires, to see if there is a pattern for packages processed
>faster than the rest of the queue.
>
>None of this is really important, but it would be nice to have the
>information more easily available.  Problem is, of course, that as
>this isn't important I haven't spent any time to make it happen.
>Too much more important stuff to take care of. :)
>
>Thank you again, for making a much better presentation of the NEW
>queue. :)

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


signature.asc
Description: Digital signature

Re: what is /.udev for ?

[Marco d'Itri]

On Feb 17, Lucas de Sousa <[EMAIL PROTECTED]> wrote:

> I understand that there only a few places to it.
It /will/ be moved to /dev/.old-dev/dev/ at some point in the future
(I need to coordinate this with at least the makedev maintainer), but for
a different reason (#294968).

> I do believe that the right thing is to be disabled by default.
No.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: what is /.udev for ?

[Lucas de Sousa]

On that scenario does not seem a unreasonable action to delete it without 
looking. It just 15 minutes to take it back.
I would take more time google'ing it, than reinstaling it. 

But you missed my point. 

Even the people here that supports the /.dev mount agrees that is not the 
right place for it. It does not match the FHS, and it is a bit weird.

I understand that there only a few places to it.

I do believe that the right thing is to be disabled by default.
But this is for the policy guys to begin long flames about.

Em Seg 14 Fev 2005 11:14, Tollef Fog Heen escreveu:
> * Peter Samuelson
>
> | [Tollef Fog Heen]
> |
> | > Assume makes an ass of u an' me.
> |
> | Why do people keep circulating this saying?  It makes no sense.
> | Normally, assuming only ever has the power to make an ass of the person
> | who did the assuming, i.e. "me", not "u and me".  And even then, it's
> | not like you could get very far in life without making any assumptions,
> | so at best even that part is only sometimes true.
>
> It's assuming without actually checking first.  «This looks like junk,
> so I'll just rm -rf it» rather than «this looks like junk -- uhm.
> *think*.  google around a bit and then removing it the right way.»
>
> --
> Tollef Fog Heen   
> ,''`. UNIX is user friendly, it's just picky about who its friends are 
> : :' : `. `' `-

-- 
Lucas de Sousa

e-mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
Cell: (48) 9102-6650 / Trabalho: (48) 216-9249 
msn: [EMAIL PROTECTED] / icq: 1859216 / aol: lcs589

problem of savelog

[Atsuhito Kohda]

Hi all,

I found yesterday that mails were not delivered since about
6:30 in the morning so I investigated a problem and found
that /var/log/exim/paniclog said /var/log/exim/mainlog had 
a wrong owner/permission;

2005-02-16 06:33:49 1D1AKL-0005JC-00 Cannot open main log file "/var/log/exim/m\
ainlog": Permission denied: euid=8 egid=8

In fact "ls -l" looked like

-rw---  1 root adm  0 2005-02-16 06:33 mainlog

so I changed its owner/permission then I got mails.

However I found today that the situation was worse than yesterday;

not only wrong owner/permission of mainlog
-rw---  1 root adm  0 2005-02-17 06:33 mainlog

but also wrong owner/permission of paniclog(?)
-rw---  1 root adm  0 2005-02-17 06:33 paniclog

so paniclog told me nothing today.

I suspect that savelog in /etc/cron.daily/exim didn't work
correctly but I couldn't find any bug in BTS.

My machine is Alpha and system is of unstable.  

ii  debianutils2.12.0 Miscellaneous utilities specific to Debian
ii  exim   3.36-13An MTA (Mail Transport Agent)

Is there anyone who encountered the same problem or is this 
Alpha specific or even specific to my machine?

Thanks in advance.
2005-2-17(Thu)
-- 
 Debian Developer & Debian JP Developer - much more I18N of Debian
 Atsuhito Kohda <[EMAIL PROTECTED]>
 Department of Math., Univ. of Tokushima


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

Re: help needed with mips build failure

[Henrique de Moraes Holschuh]

On Wed, 16 Feb 2005, Thomas Bushnell BSG wrote:
> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
> > On Wed, 16 Feb 2005, Thomas Bushnell BSG wrote:
> > > Now, it should be noted, upstream uses autoconf 2.13, and libtool
> > > 1.4c.  So these errors should not be happening, and seem to imply
> > > problems in the Debian auto* packages.
> > 
> > Both are deprecated, outdated crap.  Methinks you have some work to do to
> > get these up to 2.5x and libtool 1.5.x...
> 
> Nonsense; I'm not upstream and this is a very complicated package.
> 
> Upstream is distributing perfectly working source.

No, if they are using libtool 1.4, they are not. Unless you have patched
libtool-generated stuff throughoutly, that is.  It is not a bug *yet*, but I
understand we will force-deprecate libtool << 1.5.6 post sarge, due to
library dependency problems.

As for it being complicated, well, I believe you.  But you need not be
upstream to change the build system, I have done that three or four times
already.  It is not the most gratifying work in the world, at all... but the
result is far easier to keep up-to-date and maintain by a LONG margin.

When they're not willing to change things upstream, I just fork the build
system for Debian (and pester them with patches every two or three
releases).

IMO it takes less effort to do the initial port, and maintain a automake-1.9
tree on my own (usually I only need to edit one or two lines per new
upstream release) than to get automake-1.4 stuff to play nice all the time.

If it is a matter of an old libtool and gettext, I don't even *try* to use
whatever was provided upstream, I forward-port the build system to whatever
we have latest in sid before the first upload to Debian is done.

-- 
  "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: help needed with mips build failure

[Steve Langasek]

On Wed, Feb 16, 2005 at 01:02:58PM -0800, Thomas Bushnell BSG wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:

> > Clearly not, or it wouldn't have failed to build on mips and mipsel.  There
> > is nothing "perfectly working" about that version of libtool, and moreover,
> > its effects are not limited to the mips architectures -- as the obscenely
> > long list of library dependencies of the gnucash package are almost
> > certainly also caused by use of this old, buggy version of libtool.

> I'm pretty sure that the upstream sources build on ordinary mips
> distributions, but I'm not certain of this.

Considering Debian is the only mainstream desktop distribution with a mips
port, and gnucash upstream has in the past disavowed all responsibility for
compatibility with non-i386 archs, this seems laughably false.  Also,
there's the fact that we've been dealing with this failure of libtool 1.4 to
build working shared libs on mips for years, as evidenced by the fact that
there *is* a boilerplate response, and no one made the problem up out of
whole cloth...

> Perhaps mips is so rare that they wouldn't get bug reports.

Infinitely more likely. :)

> > Let me know if you would like help updating this package to use libtool 1.5
> > (and preferably getting that change pushed upstream).  This probably
> > requires updating to autoconf2.5 at the same time, but should not require
> > changing the version of automake you're using.

> If someone were to present me with suitable patches, I would gladly
> and happily send them upstream.  I don't really have the time to work
> on it myself; I have just sent a message to the upstread development
> list suggesting that the next release should use current tools, and
> I'll see what they say.  Perhaps the release manager there is happy to
> do it.

Ok, I'll take a look at getting a libtool 1.5 update together for you.

Thanks,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: help needed with mips build failure

[Thiemo Seufer]

Thomas Bushnell BSG wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> 
> > Clearly not, or it wouldn't have failed to build on mips and mipsel.  There
> > is nothing "perfectly working" about that version of libtool, and moreover,
> > its effects are not limited to the mips architectures -- as the obscenely
> > long list of library dependencies of the gnucash package are almost
> > certainly also caused by use of this old, buggy version of libtool.
> 
> I'm pretty sure that the upstream sources build on ordinary mips
> distributions, but I'm not certain of this.

I doubt that, simply because Debian _is_ the ordinary Linux/MIPS
distribution. :-) The alternatives are Gentoo, a very outdated
Redhat port, or one of the commercial embedded Linux distributions.


Thiemo


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

Re: Package xxx has broken dep on yyy: normal?

[Goswin von Brederlow]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>
>> Dan Jacobson <[EMAIL PROTECTED]> writes:
>> 
>> > Well OK, but please be aware of the cases where a kid leaves his
>> > village for a trip to the big city and his single chance to do an
>> > apt-get dist-upgrade.  He can't just try again tomorrow if things
>> > don't work out.
>> 
>> So what? Then they don't have the bleading edge version of the package
>> but their old non upgrade one. Big deal.
>
> I think the point is that dist-upgrade can sometimes do the Wrong
> Thing in cases like this.

As sid user you are supposed to look what apt-get will do before
letting it remove like 500 packages.

No pitty for anyone doing that before leaving town. :)

MfG
Goswin


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

Re: Regarding XEN kernel images

[Philipp Hug]

> > 2nd: I tried your kernels but wasn't successful.
>
> Yes, they are broken. This was a first try without success.
>
Ok, I'll have a look at them. I thought it was my mistake ;-)

> It seams that you are running a SCSI RAID. Did you compiled all drivers
> staticly? Which .config did you used? I've a k7 confiration where only
> few options are disabled due to compilation problems.
>
I used the kernel-image provided by upstream, and they "just worked". I think 
the config is included in the upstream package.
but I'll try again with debian kernels... were you able to successfully build 
new packages?


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

Re: help needed with mips build failure

[Petter Reinholdtsen]

[Thomas Bushnell BSG]
> Perhaps mips is so rare that they wouldn't get bug reports.

Perhaps.  http://popcon.debian.org/ > reports:

1   0.02% kfreebsd-i386
1   0.02% ppc64
1   0.02% hurd-i386
2   0.04% mipsel
2   0.04% m68k
2   0.04% arm
4   0.07% mips
4   0.07% s390
9   0.16% ia64
   12   0.21% hppa
   33   0.58% alpha
   49   0.86% sparc
   80   1.41% powerpc
  258   4.54% amd64
 5229  91.95% i386
 5687 100.00% total (ignored 1125 without arch info)

I wish more non-x86 archs would report into popularity-contest.


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

Re: help needed with mips build failure

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

> Clearly not, or it wouldn't have failed to build on mips and mipsel.  There
> is nothing "perfectly working" about that version of libtool, and moreover,
> its effects are not limited to the mips architectures -- as the obscenely
> long list of library dependencies of the gnucash package are almost
> certainly also caused by use of this old, buggy version of libtool.

I'm pretty sure that the upstream sources build on ordinary mips
distributions, but I'm not certain of this.  Perhaps mips is so rare
that they wouldn't get bug reports.

> Let me know if you would like help updating this package to use libtool 1.5
> (and preferably getting that change pushed upstream).  This probably
> requires updating to autoconf2.5 at the same time, but should not require
> changing the version of automake you're using.

If someone were to present me with suitable patches, I would gladly
and happily send them upstream.  I don't really have the time to work
on it myself; I have just sent a message to the upstread development
list suggesting that the next release should use current tools, and
I'll see what they say.  Perhaps the release manager there is happy to
do it.

Thomas


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

Re: help needed with mips build failure

[Steve Langasek]

On Wed, Feb 16, 2005 at 12:39:44PM -0800, Thomas Bushnell BSG wrote:
> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:

> > On Wed, 16 Feb 2005, Thomas Bushnell BSG wrote:
> > > Now, it should be noted, upstream uses autoconf 2.13, and libtool
> > > 1.4c.  So these errors should not be happening, and seem to imply
> > > problems in the Debian auto* packages.

> > Both are deprecated, outdated crap.  Methinks you have some work to do to
> > get these up to 2.5x and libtool 1.5.x...

> Nonsense; I'm not upstream and this is a very complicated package.

> Upstream is distributing perfectly working source.

Clearly not, or it wouldn't have failed to build on mips and mipsel.  There
is nothing "perfectly working" about that version of libtool, and moreover,
its effects are not limited to the mips architectures -- as the obscenely
long list of library dependencies of the gnucash package are almost
certainly also caused by use of this old, buggy version of libtool.

Let me know if you would like help updating this package to use libtool 1.5
(and preferably getting that change pushed upstream).  This probably
requires updating to autoconf2.5 at the same time, but should not require
changing the version of automake you're using.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Regarding XEN kernel images

[Raphael Bossek]

Hi Philipp,

> I was able to get Xen running. But you need at least the 2.0.4-4
> packages, as  the -3 packages were missing the xen.gz code.
yes, I've patches the xen packages (2.0.4-3.1) to get the /boot/xen.gz
file.

> 2nd: I tried your kernels but wasn't successful.
Yes, they are broken. This was a first try without success.

> This is how my grub menu.lst looks like (using the xen0 kernel from
> the xen  website):
> kernel  /boot/xen.gz dom0_mem=131072
> module  /boot/vmlinuz-2.6.10-xen0 root=/dev/cciss/c0d0p1 ro 
> console=tty0
My grub configuration match but I use a initrd file too created manually
because the default postinst script from kernel-package is out of sync
with the main images. This should be fixed.

It seams that you are running a SCSI RAID. Did you compiled all drivers
staticly? Which .config did you used? I've a k7 confiration where only
few options are disabled due to compilation problems.

> how do you use your kernels? just within domains>0?
I intent to boot with xen0 and start multiple xenU domains then. I'll
use it as replacement for chroot environments.

-- 
Raphael Bossek


pgpxRF7jsXlVM.pgp
Description: PGP signature

Re: Regarding XEN kernel images

[Philipp Hug]

Raphael,

I was able to get Xen running. But you need at least the 2.0.4-4 packages, as 
the -3 packages were missing the xen.gz code.

2nd: I tried your kernels but wasn't successful. I assume that it shouldn't be 
used for the Domain-0 as Xen seems to expect the kernels in ELF format...

This is how my grub menu.lst looks like (using the xen0 kernel from the xen 
website):
kernel  /boot/xen.gz dom0_mem=131072
module  /boot/vmlinuz-2.6.10-xen0 root=/dev/cciss/c0d0p1 ro 
console=tty0

how do you use your kernels? just within domains>0?

thanks philipp
On Wednesday 16 February 2005 20.45, Raphael Bossek wrote:
> Hi Lars,
>
> I could today achieve a big step forward. I found a configuration that
> worked for k7 (AMD). I've also created a initrd file (manually) and booted
> with the Xen loaded. And here starts my problems. I was not able to boot
> because the ide-generic Linux driver dumps a segmentation fault :( I'll see
> what the xen-devel lists says.
>
> Until now I can say that there are some additional modification on the xen
> 2.0.4-3 required. I think also that the kernel-package will be updated.
> I'll see if I find the time to publish these patches on my server.
>
> It would be interesting to hear more about people who try the same and
> their expiriences with Xen.
>
> --
> Raphael Bossek


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

Re: help needed with mips build failure

[Thomas Bushnell BSG]

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

> On Wed, 16 Feb 2005, Thomas Bushnell BSG wrote:
> > Now, it should be noted, upstream uses autoconf 2.13, and libtool
> > 1.4c.  So these errors should not be happening, and seem to imply
> > problems in the Debian auto* packages.
> 
> Both are deprecated, outdated crap.  Methinks you have some work to do to
> get these up to 2.5x and libtool 1.5.x...

Nonsense; I'm not upstream and this is a very complicated package.

Upstream is distributing perfectly working source.


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

Bug#242281: (no subject)

[Don Armstrong]

clone 242281 -1
reassign -1 ftp.debian.org
retitle -1 Please remove mush from the archive as we do not have permision to 
distribute it
thanks


On Tue, 28 Dec 2004, Don Armstrong wrote:
> On Tue, 28 Dec 2004, Pawel Wiecek wrote:
> > On Dec 28,  2:03am, Don Armstrong wrote:
> > > However, waiting for 8 months to resolve such a simple issue seems a
> > I do have some time at last, so I'll finally do something about this
> > and some other bugs.
> 
> Ok, cool. Let me know if you need any assistance.

It's been a month and a half, and still no movement on this bug. As we
don't even have permision to distribute the binaries, and are clearly
in violation here, the package really needs to be removed, without
prejudice to it's insertion once the maintainer has time to package it
as a source only package (ala qmail).


Don Armstrong

-- 
THERE IS NO GRAVITY THE WORLD SUCKS
 -- Vietnam War Penquin Lighter
http://gallery.donarmstrong.com/clippings/vietnam_there_is_no_gravity.jpg

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


signature.asc
Description: Digital signature

Re: Bug#295430: ITP: cpufrequtils -- Tools to access to the Linux kernel cpufreq subsystem

[Mattia Dongili]

On Wed, Feb 16, 2005 at 07:48:51PM +0100, Daniel Baumann wrote:
> Brian Nelson wrote:
> >Well, you didn't send the mail to the submitter (only to
> >[EMAIL PROTECTED], which doesn't go to the submitter--you need to
> >Cc him manually), so he probably never saw it...
> 
> I did send him privatly seveal times without getting any response.

I didn't received any of them. (I was wondering what you meant with
'serveral pings' actually). As you can see [1] the upload has been
slowed because my first RFS on d-mentors didn't get any response.

I'm currently interested in the package (co-authored) and I'll soon need
it for cpufreqd too.

[1]: http://lists.debian.org/debian-mentors/2004/12/msg00295.html
-- 
mattia
:wq!


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

Re: Take APT 0.6 discussion public!

[Thaddeus H. Black]

Rats.  Posted to the wrong list.  Please do not reply
to parent on -devel, but on -project.  Sorry.


pgpmFt12eWFCQ.pgp
Description: PGP signature

Re: Regarding XEN kernel images

[Raphael Bossek]

Hi Lars,

I could today achieve a big step forward. I found a configuration that worked 
for
k7 (AMD). I've also created a initrd file (manually) and booted with the Xen
loaded. And here starts my problems. I was not able to boot because the 
ide-generic
Linux driver dumps a segmentation fault :( I'll see what the xen-devel lists 
says.

Until now I can say that there are some additional modification on the xen 
2.0.4-3
required. I think also that the kernel-package will be updated. I'll see if I 
find
the time to publish these patches on my server.

It would be interesting to hear more about people who try the same and their
expiriences with Xen.

--
Raphael Bossek


pgpXmBODRX56s.pgp
Description: PGP signature

Re: (forw) Packages not using po-debconf - more active actions to come

[Lucas Wall]

On 02/16/05 07:00, Tollef Fog Heen wrote:
* Christian Perrier 

| Please find below the alphabetical list of the relevant packages
| (main, then contrib, then non-free).
.. as usual, please include maintainer names with package lists like
this.  (And thanks for assembling the list. :)
Adam C. Powell, IV <[EMAIL PROTECTED]>
  ccc, cfal, cfalrtl, cpml, cxml, cxx, libots
Adam D. McKenna <[EMAIL PROTECTED]>
  daemontools-installer
Angus Lees <[EMAIL PROTECTED]>
  libapache-sessionx-perl
Anthony Fok <[EMAIL PROTECTED]>
  chdrv
Anthony Towns <[EMAIL PROTECTED]>
  netkit-base
Ashley Clark <[EMAIL PROTECTED]>
  bottlerocket
Bastian Blank <[EMAIL PROTECTED]>
  zope-loginmanager
Blars Blarson <[EMAIL PROTECTED]>
  suck
Bob Hilliard <[EMAIL PROTECTED]>
  dict-gcide
Brad Stewart <[EMAIL PROTECTED]>
  moobot
Bradley Bell <[EMAIL PROTECTED]>
  razzle
Camm Maguire <[EMAIL PROTECTED]>
  cxref, gcl, gclcvs
Cord Beermann <[EMAIL PROTECTED]>
  jove, nn
Daniel Franklin <[EMAIL PROTECTED]>
  printbill
David Coe <[EMAIL PROTECTED]>
  libsafe
David Spreen <[EMAIL PROTECTED]>
  lids-2.4
Debian Edu Developers 
  debian-edu-config
Debian Install System Team 
  lowmem, usb-discover
Debian Mono Group <[EMAIL PROTECTED]>
  mod-mono
Debian Mono group <[EMAIL PROTECTED]>
  xsp
Debian Perl Group <[EMAIL PROTECTED]>
  libmail-bulkmail-perl
Debian QA Group <[EMAIL PROTECTED]>
  blootbot, ftape, ftape-tools, hunglish
Discover Workers <[EMAIL PROTECTED]>
  discover
Dynamic DNS Tools and Services <[EMAIL PROTECTED]>
  ddt
Edward Betts <[EMAIL PROTECTED]>
  joystick
Federico Sevilla III <[EMAIL PROTECTED]>
  zope-docfindereverywhere
Felix Kröger <[EMAIL PROTECTED]>
  ddclient
Hakan Ardo <[EMAIL PROTECTED]>
  ftpwatch
Hans Freitag <[EMAIL PROTECTED]>
  fvwm-shell
Isaac Jones <[EMAIL PROTECTED]>
  haskell-mode
James W. Penny <[EMAIL PROTECTED]>
  python-popy, zope-zshell
Jamie Wilkinson <[EMAIL PROTECTED]>
  quake2-data
Jamin W. Collins <[EMAIL PROTECTED]>
  moviemate
Jeff Bailey <[EMAIL PROTECTED]>
  diffmon
Jeff Licquia <[EMAIL PROTECTED]>
  diald
Jon Marler <[EMAIL PROTECTED]>
  qmail
Joshua Kwan <[EMAIL PROTECTED]>
  hybserv
Kalle Kivimaa <[EMAIL PROTECTED]>
  ispell-fi
Karl Ramm <[EMAIL PROTECTED]>
  zephyr
Karsten Merker <[EMAIL PROTECTED]>
  delo
Kevin M. Rosenberg <[EMAIL PROTECTED]>
  acl-installer, lw-per-installer, lw-pro-installer, lw-pro-installer-43
Krzysztof Krzyzaniak (eloy) <[EMAIL PROTECTED]>
  libdbd-sqlite-perl
Mario Joussen <[EMAIL PROTECTED]>
  mdctl
Mario Lang <[EMAIL PROTECTED]>
  filterproxy
Martin Loschwitz <[EMAIL PROTECTED]>
  gidentd
Martin Waitz <[EMAIL PROTECTED]>
  freenet6
Masahito Omote <[EMAIL PROTECTED]>
  anthy
Masayuki Hatta (mhatta) <[EMAIL PROTECTED]>
  ndtpd
Matt Kern <[EMAIL PROTECTED]>
  laptop-netconf
Matt Zimmerman <[EMAIL PROTECTED]>
  cricket
Mickael Profeta <[EMAIL PROTECTED]>
  prelude-nids
Norbert Tretkowski <[EMAIL PROTECTED]>
  mailgraph
Ola Lundqvist <[EMAIL PROTECTED]>
  ntop
Oliver Kurth <[EMAIL PROTECTED]>
  ifplugd, masqmail, waproamd
Oohara Yuuma <[EMAIL PROTECTED]>
  lsh
Paul Martin <[EMAIL PROTECTED]>
  radioclk
Philippe Troin <[EMAIL PROTECTED]>
  am-utils
Progeny Debian Packaging Team <[EMAIL PROTECTED]>
  localeconf
Radovan Garabik <[EMAIL PROTECTED]>
  efingerd
Roberto Suarez Soto <[EMAIL PROTECTED]>
  mped
Roderick Schertler <[EMAIL PROTECTED]>
  hearse
Russell Coker <[EMAIL PROTECTED]>
  fcron
Ryan Murray <[EMAIL PROTECTED]>
  gdm
Sam Hartman <[EMAIL PROTECTED]>
  kerberos-configs
Sam Hocevar (Debian packages) <[EMAIL PROTECTED]>
  ez-ipupdate
Simon Richter <[EMAIL PROTECTED]>
  asterisk-chan-misdn
Steve Dunham <[EMAIL PROTECTED]>
  x-symbol
Steve Langasek <[EMAIL PROTECTED]>
  freetds
Søren Boll Overgaard <[EMAIL PROTECTED]>
  mlmmj
Taku YASUI <[EMAIL PROTECTED]>
  nttcp
Takuo KITAME <[EMAIL PROTECTED]>
  lukemftpd
Teófilo Ruiz Suárez <[EMAIL PROTECTED]>
  boa
Thomas Bushnell, BSG <[EMAIL PROTECTED]>
  miscfiles
Thomas Scheffczyk <[EMAIL PROTECTED]>
  mason
Tim Peeler <[EMAIL PROTECTED]>
  webcalendar
Turbo Fredriksson <[EMAIL PROTECTED]>
  libroxen-imho, nagat
Uwe Steinmann <[EMAIL PROTECTED]>
  php4-pecl-ps
Yu Guanghui <[EMAIL PROTECTED]>
  dvipdfmx
--
Lucas Wall <[EMAIL PROTECTED]>  .''`.
Buenos Aires, Argentina: :ø :   Debian GNU/Linux
http://www.kadath.com.ar   `. `'  http://www.debian.org
PGP: 1024D/84FB46D6  `-
 5D25 528A 83AB 489B 356Ahttp://people.debian.org/~lwall
 4087 BC9B 4733 84FB 46D6mailto:[EMAIL PROTECTED]


signature.asc
Description: OpenPGP digital signature

Re: Bug#295328: general: Help messages to stderr should be banned

[Francesco P. Lovergine]

On Tue, Feb 15, 2005 at 09:13:32AM -0800, Thomas Bushnell BSG wrote:
> "Francesco P. Lovergine" <[EMAIL PROTECTED]> writes:
> 
> > Quite difficult if the function is the same. In both cases it uses stderr.
> 
> Oh good grief.  Add an argument to the function saying where to direct
> the output.  How hard is this?
> 

Oh, well guys, I did not say it's correct. Just, a lot of people out
there are too lazy to write the code in the right manner. Even if trivial. 
Well, a lot of people is also too lazy to use snprintf() instead of sprintf().
That is a bit worst :-D

-- 
Francesco P. Lovergine


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

Re: Take APT 0.6 discussion public!

[Thaddeus H. Black]

martin f krafft asks,

> Obviously, for reasons unknown to the mere mortals,
> the above only applies to topics of the mere mortals
> of Debian, not to certain members of the cabal. Some
> vital components of the Debian project are better kept
> away from the public, or they could be flooded with
> opinions or suggestions for improvement, or even
>  help (ftpmasters, are you listening?).

AJ Towns replies,

> Yes. If we weren't we might wake up one day and
> mistakenly think it might be possible to have
> discussions on Debian lists that didn't involve
> gratuitous insults.

AJ, having respect for and deference to your inestimable
Debian work, nevertheless I object.  When have you ever
seen Martin F. Krafft gratuitously insult anyone?  Has
he not earned the benefit of the doubt?  It is hard to
imagine someone so passionate about Debian who
habitually tries so hard to avoid insult, as Martin F.
Krafft.

Martin's valid question stands.  Someone has advised
Martin to plan his APT work in the full glare of the
lists.  Whether this is good advice to Martin, I do not
know; but all Martin wants to know is, if the advice is
good for the APT team, then why not for ftpmaster?

It is a fair question, asked by many others on this list
in various ways, and never really answered in my
opinion.  I have never asked the question but
respectfully I do so now.  Why can so many DDs
apparently not determine to their satisfaction why and
how ftpmaster works, or what they can do to help when
ftpmaster seems broken?  Are these DDs somehow
delinquent?  Do they need to RTFM?  Are they as
children, who just do not understand?  But how can they
understand what has so long been hidden?  Are they
unreasonable to expect gentle illumination, moderate
collegiality, and some ongoing public engagement?  Are
they actually getting these things, only they don't
realize it?  On the other hand, does ftpmaster feel
besieged?  Is the problem that Debian development is too
open, too undisciplined for practical collegiality?  Yet
the release team answer questions publicly: not everyone
agrees with everything they do, but few seem to wonder
what dark secrets they keep.  And when you, AJ, served
as release manager, did you ever raise a tangled hedge
to keep information in and eyes and voices out?  I do
not think that you did.  The same can be said of the
dpkg and installer teams: at least they converse.  What
is this shroud which hides ftpmaster?

It may be observed that there has recently been good
progress on the DAM front, and this is true.  However,
the question was about ftpmaster not the DAM.  Either
the two are separate roles or they are not.  The matter
can be debated under either premise, but either way,
similar questions arise.

It is doubtful whether anyone can do much useful work in
the continuous, full glare of general public scrutiny.
This is admitted.  It is also admitted that anything
ftpmaster publishes about its internal works invites
unsettling, perhaps even unwarranted criticism, costing
ftpmaster patience and time---and even opening the
possibility of a direct challenge: "I can do ftpmaster's
job better.  Watch."  However, the body of DDs are not
the general public, and Martin has never asked for hot
spotlights to focus on every tiny ftpmaster move.  He
has asked: if gentle illumination and moderate
transparency matter in APT work, then how much more so
in ftpmaster work?

If the question in any of its several forms is found
insulting by some, I hope that they will pardon Martin,
me, and the several others who have asked it.
(Certainly it would be extremely easy to punish me, who
after nearly three years of Debian development am soon
to go for final DAM review.)  I intend no more insult
than Martin does.  Not a DD, I have earned no right to
demand an answer; but it were cowardice to leave Martin
standing alone today, and I would respectfully request
an answer nevertheless.

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED]

(I would quietly ask that this post not be referenced in
the Weekly News.  The Weekly News is great and has the
honorable right to reference anything it sees fit.
Personally I do not mind either way.  However, if
mention in the Weekly News tempted a certain non-Debian
forum to open a clueless thread on the topic, then I am
not sure what good purpose it would serve.  Anyone who
is really interested can read about it here.  This is
all.)


pgpWjjjTVsuAc.pgp
Description: PGP signature

Re: Bug#295430: ITP: cpufrequtils -- Tools to access to the Linux kernel cpufreq subsystem

[Daniel Baumann]

Brian Nelson wrote:
Well, you didn't send the mail to the submitter (only to
[EMAIL PROTECTED], which doesn't go to the submitter--you need to
Cc him manually), so he probably never saw it...
I did send him privatly seveal times without getting any response.
--
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  [EMAIL PROTECTED]
Internet:   http://people.panthera-systems.net/~daniel-baumann/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#295430: ITP: cpufrequtils -- Tools to access to the Linux kernel cpufreq subsystem

[Brian Nelson]

On Wed, Feb 16, 2005 at 02:24:34PM +0100, Daniel Baumann wrote:
> Javier Setoain wrote:
> >* Package name: cpufrequtils
> >  Version : 0.2-pre1
> >  Upstream Author : Dominik Brodowski <[EMAIL PROTECTED]>
> >* URL : http://www.example.org/
> >* License : GPL
> >  Description : Tools to access the Linux kernel cpufreq subsystem
> 
> I did a package already since the original holder of the ITP didn't 
> respond to several pings.

Well, you didn't send the mail to the submitter (only to
[EMAIL PROTECTED], which doesn't go to the submitter--you need to
Cc him manually), so he probably never saw it...

-- 
Society is never going to make any progress until we all learn to
pretend to like each other.


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

Re: (forw) Packages not using po-debconf - more active actions to come

[Christian Perrier]

Quoting Tollef Fog Heen ([EMAIL PROTECTED]):
> * Christian Perrier 
> 
> | Please find below the alphabetical list of the relevant packages
> | (main, then contrib, then non-free).
> 
> .. as usual, please include maintainer names with package lists like
> this.  (And thanks for assembling the list. :)


Lucas Wall is setting up a status page for this po-debconf transition
work. I've just suggested him to add the package maintainer's name.



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

Re: mirror the Packages files _after_ the packages!

[Frank Küster]

Dan Jacobson <[EMAIL PROTECTED]> schrieb:

> Does http://www.debian.org/mirror/ at least have the
> two-phase-mirroring script?

Why don't you go and look? And if you find the information too sparse,
submit a bug report with a patch?

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

Re: (forw) Packages not using po-debconf - more active actions to come

[Lars Wirzenius]

ke, 2005-02-16 kello 11:00 +0100, Tollef Fog Heen kirjoitti:
> .. as usual, please include maintainer names with package lists like
> this.  (And thanks for assembling the list. :)

I seem to have written a little script for this (attached). I don't see
a similar thing in devscripts. Is that the right place to look for one?
Would it be useful to have mine there or is there something better out
there somewhere? If so, I'll write a manual page and maybe improve the
script a little bit.



dd-list
Description: application/python

Re: mirror the Packages files _after_ the packages!

[Dan Jacobson]

Jeroen> Debian could promote this two-phase mirroring a bit more
Jeroen> maybe, and/or provide nice scripts, that's probably why #6786
Jeroen> is still open.

I suppose Debian is promoting one-phase mirroring and two phase
mirroring is "roll your own".

If you want me to tell my administrator to do something, I need
something succinct, like "apt-get install two-phase-mirroring".

Jeroen> #6786 doesn't need to be fixed for this, the mirror admin of
Jeroen> xx.linux.org.xx just needs to implement two-phase mirroring,
Jeroen> something that anyone with a bit shell/rsync foo can implement on
Jeroen> his/her own, and ttbomk, already a lot of mirrors actually _do_.

If this two-phase-mirroring is the way to go, then there ought to be a
standard package to do it. How can there be 1+ packages but no
package to make sure the 1+ packages get mirrored properly?

Any approved recommended debugged method would certainly have its own
package, where the administrator would merely enter some configuration
parameters in some /etc file.

Does http://www.debian.org/mirror/ at least have the
two-phase-mirroring script?

Is there any official documentation?


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

Re: /etc under svk

[Florian Weimer]

* Marc Haber:

> Also, the repository needs to be protected as /etc itself is, as it
> contains passwords and other system confidential data.

Well, typically you wont store such files in the repository because it
makes automatically generated commit messages too sensitive to be sent
by email.


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

Re: Bug#295430: ITP: cpufrequtils -- Tools to access to the Linux kernel cpufreq subsystem

[Daniel Baumann]

Javier Setoain wrote:
* Package name: cpufrequtils
  Version : 0.2-pre1
  Upstream Author : Dominik Brodowski <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : GPL
  Description : Tools to access the Linux kernel cpufreq subsystem
I did a package already since the original holder of the ITP didn't 
respond to several pings.

Currently, the priority was not so high to get it uploaded since NEW is 
on hold.

I will have a look at the 'status' of getting it in.
Regards,
Daniel
--
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  [EMAIL PROTECTED]
Internet:   http://people.panthera-systems.net/~daniel-baumann/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: apt: replace /etc/apt/trusted.gpg with /etc/apt/trusted-keys/

[martin f krafft]

also sprach Peter Palfrader <[EMAIL PROTECTED]> [2005.02.16.1337 +0100]:
> The following patch makes apt use a directory in etc/apt named
> trusted-keys/.  Keys are simply placed in that directory if the
> user wants to trust them for signing the Release file.

This is a great idea. I have briefly reviewed the patch, and it
looks okay. Thanks!

Florian, what's the status now? How do we proceed?

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature

apt: replace /etc/apt/trusted.gpg with /etc/apt/trusted-keys/

[Peter Palfrader]

On Mon, 14 Feb 2005, Martin Schulze wrote:

> Quoting Andreas Barth from the release team:
> 
> |   Actually, we discussed about apt 0.6 within the release team and
> |   with the maintainers. IIRC, the two blocking issues are:
> |
> |   1. All the concepts
> |  - default installation,
> |  - key management,

Currently, apt 0.6 uses a single binary file as its keyring in /etc/apt.
This has the disadvantage that modifying it requires special tools like
apt-key, and so key management is a pain.

The following patch makes apt use a directory in etc/apt named
trusted-keys/.  Keys are simply placed in that directory if the user
wants to trust them for signing the Release file.

[EMAIL PROTECTED]:~$ ls -l /etc/apt/trusted-keys 
total 12
-rw-rw-r--  1 root root  902 Feb 16 10:00 debian-amd-2004.asc
-rw-r--r--  1 root root  751 Feb 16 09:53 debian-archive-2004.asc
-rw-r--r--  1 root root 1430 Feb 16 09:53 debian-archive-2005.asc


On demand apt builds a keyring in /var/cache/apt/gpghome/trusted.gpg and
uses that when checking signatures.


The patch below does that.  The package doesn't migrate your current
/etc/apt/trusted.gpg to the new layout, tho that could be trivially
added should people feel the need.

As should be obvious, I'm not a C++ hacker, so let me know what needs
cleaning and fixing.  It works for me at least :)

I think this patch should be applied to apt before it goes into sarge,
as it makes some key issues easier to deal with.

Peter
diff -Nur apt-0.6.25/debian/changelog apt-0.6.25.1/debian/changelog
--- apt-0.6.25/debian/changelog 2004-06-09 14:33:17.0 +0200
+++ apt-0.6.25.1/debian/changelog   2005-02-16 13:25:50.663561131 +0100
@@ -1,3 +1,18 @@
+apt (0.6.25.1) experimental; urgency=low
+
+  * Do away with /etc/apt/trusted.gpg.  Instead we have a
+/etc/apt/trusted-keys/ directory which holds files with keys.
+The gpgv method updates /var/cache/apt/gpghome/trusted.gpg on
+demand from the keys in /etc/apt/trusted-keys/.
+  * Remove apt-key, as it is no longer needed.
+  * Install the default debian key in /etc/apt/trusted-keys,
+not in /usr/share/apt/debian-archive.gpg
+  * Remove debian/apt.postinst.  All it handled was copying
+the initial trusted.gpg to /etc.
+  * Add amd64 to the archtable.
+
+ -- Peter Palfrader <[EMAIL PROTECTED]>  Wed, 16 Feb 2005 13:25:44 +0100
+
 apt (0.6.25) experimental; urgency=low
 
   * Fix handling of two-part sources for sources.list deb-src entries in
diff -Nur apt-0.6.25/buildlib/archtable apt-0.6.25.1/buildlib/archtable
--- apt-0.6.25/buildlib/archtable   2002-11-09 20:59:10.0 +0100
+++ apt-0.6.25.1/buildlib/archtable 2005-02-16 08:53:08.274317000 +0100
@@ -24,3 +24,4 @@
 ia64   ia64
 s390   s390
 s390x  s390x
+x86_64 amd64
diff -Nur apt-0.6.25/cmdline/apt-key apt-0.6.25.1/cmdline/apt-key
--- apt-0.6.25/cmdline/apt-key  2004-01-15 21:19:18.0 +0100
+++ apt-0.6.25.1/cmdline/apt-key1970-01-01 01:00:00.0 +0100
@@ -1,60 +0,0 @@
-#!/bin/sh
-
-set -e
-
-usage() {
-echo "Usage: apt-key [command] [arguments]"
-echo
-echo "Manage apt's list of trusted keys"
-echo
-echo "  apt-key add   - add the key contained in  ('-' 
for stdin)"
-echo "  apt-key del  - remove the key "
-echo "  apt-key list- list keys"
-echo
-}
-
-command="$1"
-if [ -z "$command" ]; then
-usage
-exit 1
-fi
-shift
-
-if [ "$command" != "help" ] && ! which gpg >/dev/null 2>&1; then
-echo >&2 "Warning: gnupg does not seem to be installed."
-echo >&2 "Warning: apt-key requires gnupg for most operations."
-echo >&2
-fi
-
-# We don't use a secret keyring, of course, but gpg panics and
-# implodes if there isn't one available
-
-GPG="gpg --no-options --no-default-keyring --keyring /etc/apt/trusted.gpg 
--secret-keyring /etc/apt/secring.gpg --trustdb-name /etc/apt/trustdb.gpg"
-
-case "$command" in
-add)
-$GPG --quiet --batch --import "$1"
-echo "OK"
-;;
-del|rm|remove)
-$GPG --quiet --batch --delete-key --yes "$1"
-echo "OK"
-;;
-list)
-$GPG --batch --list-keys
-;;
-finger*)
-$GPG --batch --fingerprint
-;;
-adv*)
-echo "Executing: $GPG $*"
-$GPG $*
-;;
-help)
-usage
-;;
-*)
-usage
-exit 1
-;;
-esac
diff -Nur apt-0.6.25/cmdline/makefile apt-0.6.25.1/cmdline/makefile
--- apt-0.6.25/cmdline/makefile 2003-12-25 00:09:17.0 +0100
+++ apt-0.6.25.1/cmdline/makefile   2005-02-16 09:49:30.201016123 +0100
@@ -46,9 +46,3 @@
 LIB_MAKES = apt-pkg/makefile
 SOURCE = apt-extracttemplates.cc 
 include $(PROGRAM_H)
-
-# The apt-key program
-SOURCE=apt-key
-TO=$(BIN)
-TARGET=program
-include $(COPY_H)
diff -Nur apt-0.6.25/configure apt-0.6.25.1/configure
--- apt-0.6.25/configure2004-06-09 14:34:09.0 +0200
+++ apt-0.6.25.1/configure  2005-02-16 08:49:55.950520272 +010

Re: Ubuntu for packaging for Debian

[Scott James Remnant]

On Tue, 2005-02-15 at 22:24 -0800, Matt Zimmerman wrote:

>On Wed, Feb 16, 2005 at 02:04:17AM -0400, Maykel Moya wrote:
>
>> I'd recently adquire a little laptop (p3 900, 256 MB RAM). I'm been
>> thinking to install Ubuntu in it cause Ubuntu is optimized for desktop,
>> but I'd like to package some stuff for Debian.
>> 
>> Is it advisable to use a pure Debian instead ?
>
>You can use Ubuntu and do Debian development in a chroot, or use Debian and
>do Ubuntu development in a chroot.  So, you're free to pick whichever you
>prefer, but it will be more convenient to run the system where you will do
>(more of) your development.
>
A chroot is especially helpful if, for example, there's a C++ ABI
difference between Ubuntu and Debian and you accidentally upload to
unstable with dependencies that can only be satifised in Debian
experimental ... :o)

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

Re: /etc under svk

[Olaf Conradi]

On Wed, 16 Feb 2005 09:00:37 +0100, Marc Haber
<[EMAIL PROTECTED]> wrote:
> Another topic that needs to be addressed with putting /etc under
> version control is file modes and owner/group. cvs doesn't handle that
> well at all.

Version management is different from backups, while both share some
common functionality. With backups you just want an easy way to
restore them. Version management is to keep track of who changed what
and when (and even why in a changelog).

I use subversion to manage a portion of my /etc tree.

Most of the files in my repository are the ones I modified from a
standard package install. Sometimes I put unmodified files in there to
keep track of package upgrades. But little of them are generated
files. I keep passwd itself in there, but not the shadow files with
the actual passwords. There are a lot of symlinks outside the /etc
tree, so don't put them in the repository (alternatives, ssl
certificates, etc).

As subversion does not keep keep track of file permissions, it is not
really suited for backups. You can not easily restore a checkout.
That's why weekly or daily backups are handy. Just restore the latest
backup and synchronize with your repository. This way you do not need
to keep a lot of backup files around, as most interesting information
is in your repository anyway.

With tools like trac, websvn or viewcvs it is very easy to take a peek
at how a certain file changed over time. I use trac myself, as it has
an integrated wiki to document various things.

Recently I've been looking whether it's worthwhile to switch to arch
(with bazaar) and I think it stores file permissions. But I don't
think it's worth the switch yet.

> Also, the repository needs to be protected as /etc itself is, as it
> contains passwords and other system confidential data.

So don't store them in a repository.

You should ask yourself whether you're interested in the history or
not. If you are store them in a repository. If you just want the
latest version put them in a backup.

 -Olaf


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

Re: xresprobe pachage inside of Debian

[Petter Reinholdtsen]

[Otavio Salvador]
> I talked with Daniel Stone about it and I'll maintain it inside of
> Debian.

Good.  I look forward to getting ddcprobe back in Debian.  I send an
email asking about this earlier, but never saw the answer. :(

> The current lack is it have some xorg specific issues and then we
> need to address it. Or leave it as is and use ddcprobe with
> xdebconfigurator by now.

It is because of ddcprobe I want the package in Debian. :)


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

Re: /etc under svk

[Otavio Salvador]

|| On Wed, 16 Feb 2005 09:00:37 +0100
|| Marc Haber <[EMAIL PROTECTED]> wrote: 

mh> On Sat, 12 Feb 2005 23:16:31 +0100, Florian Weimer <[EMAIL PROTECTED]>
mh> wrote:
>> * Torsten Landschoff:
>>> Wanted to do that - but! Does svk handle symlinks? Thinking of
>>> /etc/rc?.d and /etc/alternatives... Wrote my own scripts to handle svn
>>> for /etc but they are still quite hackish...
>> 
>> Subversion 1.1 and svk 0.18 both support symlinks natively.

mh> Another topic that needs to be addressed with putting /etc under
mh> version control is file modes and owner/group. cvs doesn't handle that
mh> well at all.

mh> Also, the repository needs to be protected as /etc itself is, as it
mh> contains passwords and other system confidential data.

In case of use SVK to it you can change the  repository mask and the
checkout if you need. No problem. It won't be accessible by network so
it's mostly safe. Another possibility is use SVN server to host it and
only mirror it locally. In this case you need a more secure server but
this is also possible.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."


pgpQS5Jk3cy44.pgp
Description: PGP signature

xresprobe pachage inside of Debian [was Re: Ubuntu for packaging for Debian]

[Otavio Salvador]

|| On Wed, 16 Feb 2005 08:36:59 +0100
|| Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: 

pr> (If only Ubuntu would do an effort to get their "home-made" packages
pr> like xresprobe into Debian. :)

I talked with Daniel Stone about it and I'll maintain it inside of
Debian.

The current lack is it have some xorg specific issues and then we need
to address it. Or leave it as is and use ddcprobe with
xdebconfigurator by now.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."


pgpS9LWbafLxV.pgp
Description: PGP signature

Re: all new Debian diagram - now with less chaos!

[Kevin Mark]

On Wed, Feb 16, 2005 at 08:04:21AM +0100, martin f krafft wrote:


Hi Martin,

> 
> source package: dsc + (diff) + orig.tar.gz
> binary package: deb
> source upload: changes + list of files therein

I added some of this to my diagram. not 100% yet.

 
> nah, we turn software into debian packages by debianising them, and
> then using dpkg-genchanges to create the changes file. Please read
> its manpage, in particular about the -sa, -sd, and -si options to
> see which files the changes file will list.
> 
> the upload consists of the source package and the binary package,
> unless the debian revision is greater than 1, in which case the
> orig.tar.gz file is not included.

I added some of this, too.

> > > h. There are more rules as to when packages migrate from unstable to
> > >testing.
> > 
> > ACK. I'm not familar with all possibilities and also not sure how much
> > space it would take to include it. maybe a 'subprocess' box?
> 
> you could just say "meets requirements for testing"



> > > To get our graphs onto www.debian.org, I assume we file bugs against
> > > that pseudo-package.
> > 
> > there is an existing package that could include these? or to make an
> > ITP?
> 
> www.debian.org is a pseudo package:
> 
>   http://www.debian.org/Bugs/pseudo-packages

I saw this[1]. So the bug would be something like:
"www.debian.org: needs development diagram from package life cycle
(and oh BTW, I have one here[2] and here[3]!)"

[1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=www.debian.org
[2] http://kmark.pipeline.com/newdebian.png
[2] http://kmark.pipeline.com/newdebian.dia

-Kev


-- 
counter.li.org #238656 -- goto counter.li.org and be counted!

(__)
(oo)
  /--\/
 / |||
*  /\---/\
   ~~   ~~
"Have you mooed today?"...


signature.asc
Description: Digital signature

Re: all new Debian diagram - now with less chaos!

[Frank Küster]

Kevin Mark <[EMAIL PROTECTED]> wrote:

> although, now I am getting confused about the difference between a
> debian developer and a debian maintainer. I labeled most items with 'DD'
> thinking that's who did stuff. More things to research.

The maintainer is the guy (or entity) who is listed in the Maintainer:
field of debian/control, and who gets all the mail for the package¹. 

A debian developer is anybody with an account @debian.org, who can do
uploads to the archive.  A Debian developer need not be the maintainer
of any package (doing mainly QA work, or buildd administration, or
whatever), and a package maintainer need not be a Debian developer: They
can have their packages uploaded by a developer who reviewed the
package, but doesn't want to do all the work.

Regards, Frank


¹others can subscribe to this, too, via the package tracking system

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

Re: help needed with mips build failure

[Henrique de Moraes Holschuh]

On Wed, 16 Feb 2005, Thomas Bushnell BSG wrote:
> Now, it should be noted, upstream uses autoconf 2.13, and libtool
> 1.4c.  So these errors should not be happening, and seem to imply
> problems in the Debian auto* packages.

Both are deprecated, outdated crap.  Methinks you have some work to do to
get these up to 2.5x and libtool 1.5.x...

> First, from automake, errors referring to all the Makefile.am's in the

Automake?  1.4 is also crap.  Need to upgrade.  Which requires upgrading
libtool and autoconf too.

-- 
  "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: (forw) Packages not using po-debconf - more active actions to come

[Tollef Fog Heen]

* Christian Perrier 

| Please find below the alphabetical list of the relevant packages
| (main, then contrib, then non-free).

.. as usual, please include maintainer names with package lists like
this.  (And thanks for assembling the list. :)

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

Re: all new Debian diagram - now with less chaos!

[Frank Küster]

Adeodato Simó <[EMAIL PROTECTED]> wrote:

> * Kevin Mark [Tue, 15 Feb 2005 21:09:03 -0500]:
>
>> so, there is no 'bug' to the bts to orphan a package, simply a note to
>> debian-devel? So folks are expected to troll it to pickup packages?
>> ok. I will change the ITO to 'read about orphanded package on
>> debian-devel'.
>
>   Please compare [1], [2], and [3]. Basically:
>
> 1. maintainer writes -devel
> 2. maintainer writes -devel and files RFAs
> 3. maintainer submits O: bug against wnnp and CC's -devel

That is what I wanted to say.

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

Re: all new Debian diagram - now with less chaos!

[Frank Küster]

Kevin Mark <[EMAIL PROTECTED]> schrieb:

> On Tue, Feb 15, 2005 at 01:11:33PM +0100, Frank Küster wrote:
>> martin f krafft <[EMAIL PROTECTED]> wrote:
>> 
>> > h. There are more rules as to when packages migrate from unstable to
>> >testing.
>> > i. You use both meanings of "priority" (changelog and control)
>> >without making it clear which one is meant.
>> 
>> Furthermore, for testing propagation i'ts "urgency" that matters, isn't
>> it? 
>
> Hi Frank,
> isnt that addressed by the tag "Urgency: Low|Medium|High"?

In the white box between the green "testing" and "unstable" boxes, the
text says: "unstable packages propagate to testing based upon priority
tags and no additional RC bugs".

I think this should be "based upon the urgency tag and...". I am not
aware of any influence of the priority field from debian/control on the
testing transition (except that base might be frozen earlier), and I am
also not aware of a priority field in debian/changelog.

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

Re: all new Debian diagram - now with less chaos!

[Kevin Mark]

On Wed, Feb 16, 2005 at 07:34:27AM +0100, Adeodato Simó wrote:
> * Kevin Mark [Tue, 15 Feb 2005 21:09:03 -0500]:
> 
> > > And I've never read "ITO" as a tag for orphaning bug. Either one mails
> > > to -devel (or wherever) saying that they intend to give away or orphan
> > > some packages, but this isn't a bug, just conversation. In the BTS, I
> > > think the tag is simply "O".
> 
> > so, there is no 'bug' to the bts to orphan a package, simply a note to
> > debian-devel? So folks are expected to troll it to pickup packages?
> > ok. I will change the ITO to 'read about orphanded package on
> > debian-devel'.
> 
>   Please compare [1], [2], and [3]. Basically:
> 
> 1. maintainer writes -devel
> 2. maintainer writes -devel and files RFAs
> 3. maintainer submits O: bug against wnnp and CC's -devel
> 
> [1] http://lists.debian.org/debian-devel/2005/02/msg00346.html
> [2] http://lists.debian.org/debian-devel/2005/02/msg00534.html
> [3] http://lists.debian.org/debian-devel/2005/02/msg00676.html
> 
>   But orphaning bugs can be filed without sending mail to -devel, though
>   this makes them less effective.
> 
Hi Adeodato,
thanks for the info. I tried to add it.
although, now I am getting confused about the difference between a
debian developer and a debian maintainer. I labeled most items with 'DD'
thinking that's who did stuff. More things to research.
see you in the funny pages,
Kev

-- 
counter.li.org #238656 -- goto counter.li.org and be counted!

(__)
(oo)
  /--\/
 / |||
*  /\---/\
   ~~   ~~
"Have you mooed today?"...


signature.asc
Description: Digital signature

Re: help needed with mips build failure

[Thomas Bushnell BSG]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> Steve Langasek <[EMAIL PROTECTED]> writes:
> 
> > You're using an old (and broken) version of libtool.  C.f.
> >  for
> > Ryan's boilerplate explanation for fixing this problem.
> 
> Thanks a bunch, this is surely the problem, but applying the solution
> is causing problems.  autoreconf --force blows chunks.

Ah, with the help of the handy page Anibal Salazar pointed me to,
things seem to be proceeding swimmingly.  I was being over-aggressive
in which "new" libtool I should use.  Let's hope :)

Thomas


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

Re: help needed with mips build failure

[Anibal Monsalve Salazar]

On Tue, Feb 15, 2005 at 11:30:00PM -0800, Steve Langasek wrote:
>On Tue, Feb 15, 2005 at 11:22:01PM -0800, Thomas Bushnell BSG wrote:
>
>>Can someone with mips and/or libtool expertise examine the build
>>failure for gnucash below, and see if they can diagnose the problem?
>
>>http://buildd.debian.org/fetch.php?&pkg=gnucash&ver=1.8.10-5&arch=mips&stamp=1107337123&file=log&as=raw
>
>  checking how to recognise dependant libraries... file_magic ELF 
> [0-9][0-9]*-bit [LM]SB (shared object|dynamic lib )
>
>You're using an old (and broken) version of libtool.  C.f.
> for
>Ryan's boilerplate explanation for fixing this problem.

See also http://people.debian.org/~keybuk/libtool-updating.html

>Thanks,
>-- 
>Steve Langasek
>postmodern programmer

Regards,

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


signature.asc
Description: Digital signature

Re: help needed with mips build failure

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

> You're using an old (and broken) version of libtool.  C.f.
>  for
> Ryan's boilerplate explanation for fixing this problem.

Thanks a bunch, this is surely the problem, but applying the solution
is causing problems.  autoreconf --force blows chunks.

Now, it should be noted, upstream uses autoconf 2.13, and libtool
1.4c.  So these errors should not be happening, and seem to imply
problems in the Debian auto* packages.

First, from automake, errors referring to all the Makefile.am's in the
package, complaining that variable such as GNOME_LIBDIR, GNOMEUI_LIBS,
GUILE_LIBS, and so forth, are all not defined.  It should be noted
that gnucash uses gnome version 1, so if the "compatibility" automake
2.13 stuff (which gnucash also needs) does not still correctly support
the relevant macros, we're in trouble.

Then I get the oh-so-pleasing error messages from autoconf:

  autoconf: Undefined macros:
  ***BUG in Autoconf--please report*** AC_HELP_STRING
  ***BUG in Autoconf--please report*** AC_HELP_STRING
  ***BUG in Autoconf--please report*** AC_CONFIG_COMMANDS
  ***BUG in Autoconf--please report*** AC_COMPUTE_INT
  ***BUG in Autoconf--please report*** AC_COMPUTE_INT
  ***BUG in Autoconf--please report*** AC_COMPUTE_INT

followed by complaints about the way AC_TRY_RUN is being called.

Then the truly weird stuff from autoheader, such as:

  /usr/bin/autoheader2.13: line 243: _snprintf, and to 0 if you dont.: command 
not found

(never mind that line 243 of autoheader2.13 contains only whitespace)

The same errors occur if I run the commands individually instead of
using autoreconf.

Thomas


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