date:20060123

On Mon, Jan 23, 2006 at 11:07:29AM +0100, Xavier Roche wrote:
> Hi folks, 

> I have (in the httrack source package) a build-depends containing "zlib1g,
> zlib1g-dev" - is there anything wrong with this dependency ?

Yes, you should not be build-depending on zlib1g.

> Some builders seems to have troubles:

> http://buildd.debian.org/fetch.php?&pkg=httrack&ver=3.40.1-1&arch=ia64&stamp=1137978811&file=log&as=raw
> http://buildd.debian.org/fetch.php?&pkg=httrack&ver=3.40.1-1&arch=hppa&stamp=1137979475&file=log&as=raw

This isn't actually caused by the bug in your build-dependencies, though;
it's some strange problem on the buildds themselves.  I've asked the buildd
maintainer about it already, but he's not been on IRC much over the weekend
-- hopefully he'll be able to look at it tomorrow and figure out why the
unstable buildds are asking for sarge versions of packages.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

GPG keysigning in London and Paris

2006-01-23 Thread Filippo Giunchedi

Hi,
I'll be in London from 25 Jan to 27 Jan and in Paris from 28 Jan to 1 Feb.

If someone wants to meet for a beer/tea/whatever please drop me an email,
in Paris I plan to visit the debian booth at Solutions Linux Expo, so that
might also an occasion to meet.

filippo


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

Re: binNMU version detection

On Thu, Jan 19, 2006 at 02:42:54PM -0500, Nathanael Nerode wrote:

> Later, Steve Langasek wrote:
> > The primary aim of this change was to address the fact that there was no
> > consistent numbering scheme that satisfies the constraint
> > binNMU < security NMU < source NMU.

> The problems with this were due to security NMUs, weren't they?  The old 
> binNMU numbering scheme makes them consistently and reliably less than
> the source NMU numbering.

Um, the problems were due to being unable to choose version numbers for
security NMUs which would reliably sort between binNMUs and regular source
NMUs.

> So the binNMU numbering was changed so as to make it possible for the 
> security 
> team to name their uploads while guaranteeing that they would sort above 
> binNMUs and below regular NMUs?

Yes.

> Despite this, the current security team upload naming *doesn't work*.  I've 
> seen "5.8.4-8sarge3" in a recent upload of perl:
> $dpkg --compare-versions 5.8.4-8sarge3 gt 5.8.4-8+b1 || echo false
> false
> So this sorts below the binNMU.

Well, yes.  The security team also doesn't do uploads to testing, and there
are no packages so numbered in stable at present, so it's not exactly
critical that they change their practices immediately.

> > And contrary to Nathanael's 
> > protestations, this was discussed publically on debian-devel -- a year ago
> > -- and this solution arrived at with the input of an ftpmaster and the
> > then-current dpkg maintainer, among others.

> Ah.  I must have missed that discussion.  Pointer?



-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Bug#349493: binNMU version detection

Package: developers-reference
Version: 3.3.6
Tags: patch

Hi folks,

Please consider the attached patch to update the developer's reference
description of recompile-only binNMU versioning so that it matches the
current behavior of dak and sbuild.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/
diff -Nru /tmp/BG1jKelzmI/developers-reference-3.3.6/debian/changelog 
/tmp/SsOVUHjyJs/developers-reference-3.3.6/debian/changelog
--- /tmp/BG1jKelzmI/developers-reference-3.3.6/debian/changelog 2005-02-05 
02:10:02.0 -0800
+++ /tmp/SsOVUHjyJs/developers-reference-3.3.6/debian/changelog 2006-01-23 
03:52:33.0 -0800
@@ -1,3 +1,11 @@
+developers-reference (3.3.6-0.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Update documentation for binNMUs to use the versioning scheme currently
+supported by dak.
+
+ -- Steve Langasek <[EMAIL PROTECTED]>  Sat, 21 Jan 2006 22:53:56 -0800
+
 developers-reference (3.3.6) unstable; urgency=low
 
   * Andreas Barth
diff -Nru /tmp/BG1jKelzmI/developers-reference-3.3.6/developers-reference.sgml 
/tmp/SsOVUHjyJs/developers-reference-3.3.6/developers-reference.sgml
--- /tmp/BG1jKelzmI/developers-reference-3.3.6/developers-reference.sgml
2005-03-25 07:22:35.0 -0800
+++ /tmp/SsOVUHjyJs/developers-reference-3.3.6/developers-reference.sgml
2006-01-23 03:57:49.0 -0800
@@ -2761,12 +2761,21 @@
 get this wrong, the archive maintainers will reject your upload (due
 to lack of corresponding source code).

-The ``magic'' for a recompilation-only NMU is triggered by using the
-third-level number on the Debian part of the version.  For instance,
-if the latest version you are recompiling against was version
-``2.9-3'', your NMU should carry a version of ``2.9-3.0.1''.  If the
-latest version was ``3.4-2.1'', your NMU should have a version number
-of ``3.4-2.1.1''.
+The ``magic'' for a recompilation-only NMU is triggered by using a
+suffix appended to the package version number, following the form
++b.  For instance, if the latest version you are
+recompiling against was version ``2.9-3'', your NMU should carry a
+version of ``2.9-3+b1''.  If the latest version was ``3.4+b1'' (i.e, a
+native package with a previous recompilation NMU), your NMU should have
+a version number of ``3.4+b2''.
+
+
+In the past, such NMUs used the third-level number on the Debian part of 
+the revision to denote their recompilation-only status; however, this
+syntax was ambiguous with native packages and did not allow proper
+ordering of recompile-only NMUs, source NMUs, and security NMUs on the
+same package, and has therefore been abandoned in favor of this new
+syntax.

 Similar to initial porter uploads, the correct way of invoking
 dpkg-buildpackage is dpkg-buildpackage -B to only


signature.asc
Description: Digital signature

Re: Bug#349064: ITP: flash-plugin -- installer for Macromedia Flash Plugin

2006-01-23 Thread Alexander Sack

On Mon, Jan 23, 2006 at 10:39:00AM +0100, Petter Reinholdtsen wrote:
> 
> Why not just join forces with Takuo KITAME to maintain
> flashplugin-nonfree, and update it to behave the way you want it?  I
> do not see the point of two installer packages for macromedia flash.
> Please limit it to just one, and keep the old package name
> flashplugin-nonfree to make it easier for custom debian distros and
> upgrades.
> 

You mean take over the package? Have you ever succeeded to get any
communication started with Takuo during the last year or so?


 - Alexander

-- 
 GPG messages preferred.|  .''`.  ** Debian GNU/Linux **
 Alexander Sack | : :' :  The  universal
 [EMAIL PROTECTED]| `. `'  Operating System
 http://www.asoftsite.org/  |   `-http://www.debian.org/


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

Re: Bug#349064: ITP: flash-plugin -- installer for Macromedia Flash Plugin

2006-01-23 Thread Petter Reinholdtsen

[Alexander Sack]
> You mean take over the package?

If that is required, yes.  But I suspect a friendly reenforcement of
the maintainer team is a better solution if one is able to get in
touch with the maintainer.

> Have you ever succeeded to get any communication started with Takuo
> during the last year or so?

I have not tried, but notice he did a new upload a few months ago.
(Which surprised me and made me rephrase my suggestion, as I until I
checked belived the maintainer to be completely missing for a year or
two. :)

I focus more on the free flash implementations, and hope someone else
can take on the non-free flash issues. :)


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

Offline use of apt-cacher

2006-01-23 Thread Anuradha Ratnaweera

[Couldn't find any list related to apt-cacher or apt-cacher2, and I
noticed some discussions of them on debian-devel, so I am CCing debian
devel.  But if there is a better place to discuss this, please point
me to it, thanks!]

Hi Eduard and Jonathan,

Recently we started using apt-cacher2 extensively and are very happy
with it, great piece of work!  In fact, we standardize Saegiri, our
automated live CD build script, on apt-cacher
(http://taprobane.org/saegiri.php).

We found two cases where it could be a little better.  Before getting
hands dirty implementing any changes, I am very keen to hear some
feedback / suggestions.

We want to use apt-cacher in three different ways; the first one is
how it behaves now, and we are looking for ways to get the other two
behaviours. (I am just inventing some terminology here, just because
we need names. :-) )

- Online: good for system updates.  Looks like apt-cacher is making a
HEAD request to see if Packages/Release files are out of date, which
is the right thing.

- Lazy online: we like apt-cacher to fetch a Packages/Release file
only if it old as set by a timeout.  So if one runs apt-get update
many times during a short period, only the first one will need to make
a HEAD/GET request.  (Lazy online has one tricky case if Packages file
does get update before timeout, but that can be handled neatly and
transparently as we are online).

  This mode is going to be very useful when:
  - upgrading a large number of machines
  - running a script which _needs_ to run apt-get update many times
(and it can't be rewritten to do it otherwise)

- Offline: apt-cacher is totally offline.  Files (Packages/Release
files as well as DEBs) are served if available, and returns 503 if not
available.

  This mode is very useful for laptop users without 100% internet
connectivity, but want to play around with installer programs etc.

Looking forward for feedback.  Thanks in advance!

Anuradha
--
http://www.linux.lk/~anuradha/
http://anuradha-ratnaweera.blogspot.com

Re: Bug#349064: ITP: flash-plugin -- installer for Macromedia Flash Plugin

2006-01-23 Thread Pierre Habouzit

Le Lun 23 Janvier 2006 10:39, Petter Reinholdtsen a écrit :
> [Bart Martens]
>
> > The Debian package flash-plugin is meant as an alternative or as a
> > replacement for flashplugin-nonfree.
>
> Why not just join forces with Takuo KITAME to maintain
> flashplugin-nonfree, and update it to behave the way you want it?  I
> do not see the point of two installer packages for macromedia flash.
> Please limit it to just one, and keep the old package name
> flashplugin-nonfree to make it easier for custom debian distros and
> upgrades.
>
> Please update
> http://packages.qa.debian.org/f/flashplugin-nonfree.html>
> instead of making another installer package.

I agree here, there is no point in making two native packages that do 
the same, when the task is so small (and even if it's not small, it's 
prefered to concentrate the efforts in a team, rather than duplicating 
one's work over 3 distinct projects).
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpKyvMUuk4La.pgp
Description: PGP signature

Bug#349534: ITP: pyntor -- flexible and componized presentation program

2006-01-23 Thread Florian Ragwitz

Package: wnpp
Severity: wishlist
Owner: Florian Ragwitz <[EMAIL PROTECTED]>

* Package name: pyntor
  Version : 0.5
  Upstream Author : Josef Spillner
* URL : http://pyntor.coolprojects.org/
* License : GPL
  Description : flexible and componized presentation program

  Pyntor is a small, flexible and componentized presentation program. It
  is built upon Python and the SDL library (via pygame). Pyntor features
  a wiki-like presentation component, a HTML page component
  (Pyromaniac), and several more. Standard features like PDF/HTML
  export, page selection and interactivity are available, as are
  advanced features such as full-text search in the presentation slides.

  Due to the minimal size and maximum configurability, Pyntor is a nice
  alternative to conventional presentation programs.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

What's wrong with update-excuses?

2006-01-23 Thread Frank Küster

Hi,

http://qa.debian.org/developer.php?excuse=tetex-base

says that tetex-base is 0 days old.  However, unstable has 3.0-13 which
was uploaded on Jan 18th: 

http://lists.debian.org/debian-devel-changes/2006/01/msg01818.html

Is this just a bug in the qa scripts, or worse?

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

Autobuilding and the build-arch target, again

2006-01-23 Thread Simon Richter


Hi,

while I must admit that I was not at the latest IRC meeting where this 
topic came up, I am now bitten by this problem.


I maintain a bunch of kernel modules that can be either patched onto a 
kernel tree or built out-of-tree. No problem, have arch:all packages for 
patch and source and arch:any for the modules themselves. However, to 
build the kernel patch I need full kernel source, while kernel-headers 
is sufficient for the module builds.


Now what I'd like to do is to move kernel-source into 
Build-Depends-Indep, so the autobuilders don't need to install it. 
Wrong. Because the autobuilders invoke (via dpkg-buildpackage) the 
"build" target, which is supposed to build everything including the 
patch, I now need to have kernel sources around in order to generate a 
patch that is then thrown away.


There have been various proposals on that matter, and it always boils 
down to the same chicken-and-egg problem:


 - policy documents existing practice, which is to invoke "build".
 - the existing practice cannot be changed because it would break packages
 - the policy cannot be changed because there needs to be an 
implementation first.


To summarize the proposals so far:

 - "Scan debian/rules, invoke build-arch if present".

Has been tried, does not work.

 - "If a package has both Build-Depends and Build-Depends-Indep, it 
MUST have a build-arch target"


Would probably catch 95% of all cases. So far, I know no existing 
packages that don't have those targets but use both B-D and B-D-I. The 
drawback is that there are pretty ugly corner cases where you would have 
to jump through hoops to allow build-arch to be called (for example, if 
all the binaries you build can be built with just build-essential, but 
you need TeX for the documentation)


 - "If a package has Build-Depends-Indep and is to be autobuilt, it 
MUST have a build-arch target"


This would be special treatment for the autobuilders. Would work in more 
cases than the check for both B-D and B-D-I though. As we cannot know 
before the build whether a package will build any arch-dependent 
packages, we can only guess here. To gain something here, we would have 
to check whether any binaries for other architectures already exist, and 
only in this case build-arch could be invoked. Talk about ugly.


 - "Turn the SHOULD into a MUST in policy and have dpkg-buildpackage 
check the Standards-Version"


So far my favourite. It does not break any existing packages and can be 
easily implemented. The only drawback is that if your package doesn't 
need it and so you ignore the change, someone will NMU your package in 
order to bring it up to date with current standards. However the policy 
process gets in the way here: For this to work, we need a cutoff 
Standards-Version, and to have that, we need to be sure in which version 
of policy this will happen, however it is not going to become policy 
until we know it works (which is a good meta-policy IMO).


So my proposal to solve this would be:

 - create a policy revision that allows building a package with the 
"build-arch" and "build-indep" targets. However, the packages still need 
to build correctly when the "build" target is invoked, that is, their 
build-dependencies need to be complete for this target as well. This 
guarantees that we can pull out if anything goes wrong, as any packages 
that follow this standard will still build if we revert the change


 - if no problems occur, allow build-dependencies that are strictly for 
build-indep / binary-indep only to be moved to Build-Depends-Indep. This 
will break building those packages with older dpkg-buildpackage unless 
care is taken to also install B-D-I, so I'd have no problem at all to 
postpone this step until after the etch release.


Questions? Comments? Seconds?

   Simon


signature.asc
Description: OpenPGP digital signature

Re: For those who care about the GR

2006-01-23 Thread Anthony DeRobertis

On Sun, Jan 22, 2006 at 03:42:39PM -0800, Steve Langasek wrote:

> > And what? If someone tries to bring through a GR stating that
> >  MS office warez can be distributed in main since it meets the DFSG,
> >  one might rule that as frivolous and a waste of time.
> 
> I'm not convinced the constitution gives the secretary the power to make
> such a ruling.  There are no provisions in the constitution for the Project
> Secretary to dismiss a GR -- *even* a GR stating that the Debian Project
> holds the value of pi to be 3 -- so long as the GR has the requisite number
> of seconds.

I suspect the Secretary could effectively do so by declining to take the
vote under Section 2.1.1 ("[n]othing in this constitution imposes an
obligation on anyone to do work for the Project.") It seems then that
the secretary has no obligation to actually perform 4.2.3 or 7.1.1.

> 
> In the present case, I understand that the proposed ballot option is
> ambiguous wrt whether it constitutes an implicit amendment to the foundation
> docs, and that in the absence of clarification (in the form of a re-worded
> proposal) on the part of the proposer, it is the project secretary's
> prerogative to specify a supermajority requirement.

I think that under 7.1.3, it'd be the Secretary's job/power to determine
supermajority requirement regardless of what the proposed ballot option
says.

If 6 developers (K=5 currently, I think) can decide that the
supermajority requirements to not apply to a ballot option, then the
supermajority requirements are rather worthless.

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

Re: Autobuilding and the build-arch target, again

2006-01-23 Thread Russ Allbery

Simon Richter <[EMAIL PROTECTED]> writes:

>  - "If a package has both Build-Depends and Build-Depends-Indep, it 
> MUST have a build-arch target"

> Would probably catch 95% of all cases. So far, I know no existing
> packages that don't have those targets but use both B-D and B-D-I.

I know tons of such packages, namely all arch-independent Perl modules
that use debhelper with proper dependencies.  You have to put anything
required during debian/rules clean into B-D, not B-D-I.

However, the buildds won't see such packages, so that lack of compliance
with this proposal may not hurt.  But then it reduces to your next
proposal.

>  - "If a package has Build-Depends-Indep and is to be autobuilt, it 
> MUST have a build-arch target"

> This would be special treatment for the autobuilders. Would work in more
> cases than the check for both B-D and B-D-I though. As we cannot know
> before the build whether a package will build any arch-dependent
> packages, we can only guess here. To gain something here, we would have
> to check whether any binaries for other architectures already exist, and
> only in this case build-arch could be invoked. Talk about ugly.

I think the way of phrasing this is "if the source package has both
arch-specific and arch: all binary packages and B-D-I, it must have
build-arch and build-indep targets."  It's a pain to have the policy be
this conditional, but I think this is going to make the fewest packages
buggy while still accomplishing the goal.

>  - "Turn the SHOULD into a MUST in policy and have dpkg-buildpackage 
> check the Standards-Version"

Checking the standards version for this sort of thing seems rather evil to
me, but maybe I'm too conservative.

-- 
Russ Allbery ([EMAIL PROTECTED])   

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

Re: Bug#349534: ITP: pyntor -- flexible and componized presentation program

2006-01-23 Thread Andreas Tille


On Mon, 23 Jan 2006, Florian Ragwitz wrote:


 Due to the minimal size and maximum configurability, Pyntor is a nice
 alternative to conventional presentation programs.


What do you mean by "conventional" presentation programs. IMHO we
could differentiate into three groups of presentation programs:

 1. Text based with on syntax and own viewer
- MagicPoint
- probably others
 2. LaTeX based (mostly using PDF export or special DVI viewers)
- LaTeX - PDF
  - latex-beamer
  - prosper
  - many more
- LaTeX - DVI
  - advi
- Perhaps also pspresent falls into this large group
 3. GUI-based
- ooimpress
- kpresenter
- (what was the name of the thingy many people call a standard? ;-) )

I guess pyntor falls in group 1 and a comparison with members of this
group might be nice.

Kind regards

  Andreas.

--
http://fam-tille.de


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

Re: A great weekend for Debian

2006-01-23 Thread Amaya

Steinar H. Gunderson wrote:
> I think you're overly optimistic :-) Most of the simple RC bugs
> (related to the xlibs-dev transition) have been fixed; there aren't 90
> more like those.

I got home from work and have second thoughts about the email I
previously sent. I think I am a bit pissed off by this "simple RC bugs"
statement. I don't personally care about my own credit, but I think the
people who worked in this transition deserved the email Joseph Smidt
sent and an acknowledgement for their work. Some of us have been barely
doing anything else in our lives than this transition for 14 days.

I am talking about Marc 'HE' Brockschmidt, Thomas Viehmann, Nico Golde,
Steve Langasek, Victor Seva Lopez and Justin Pryzby, others I might not
be aware of, and Moritz Muehlenhoff, who provided the script that helps
find out the new Build-Depends.

Let me explain. In 14 days, we have gone from a total of 577 reported
bugs to
- Serious policy violations; Patch Available (5 bugs)
- Serious policy violations; Unclassified (34 bugs)
- Pending Upload bugs - Serious policy violations (9 bugs)

That is *impressive*. That amounts to 48 bugs to go. Some of them are
still "easy", and we are still working on them.

There is a *huge* amount of work behind those figures, whether the task
looks tedious, repetitive and low profile to you or not, someone had to
do it, and it has been done.

In the meantime we have also reported MIA maintainers and have given the
packages some love, ie fixing other RC bugs in our NMUs. Sometimes we
have felt inspired and provided "quality" uploads as opposed to fixing
"simple" RC bugs (related to the xlibs-dev transition).

See, for example your patch to libggiwmh, which only takes care of the
xlibs-transition:
http://bugs.debian.org/cgi-bin/bugreport.cgi/libggiwmh-0.1.0-1.1-nmu.diff?bug=349452;msg=5;att=1
as opposed to what would have been my pacth:
http://www.amayita.com/debian/xlibs-transition/libggiwmh_toolate/libggiwmh-0.1.0/debian/changelog
But when I wanted to attach my patch to 349452 I was late, you had already
uploaded :)

There is nothing wrong with your patch BTW. That's not what I mean.

The RC bug chart looks lovely:
http://bugs.debian.org/release-critical/

Most of the time, I just NMUed otehr people's changes, but also went
through testing, re-testing, and testing again, also trying to fix
other bugs in the packages, and giving them some love, as I explained
at: http://lists.debian.org/debian-mentors/2006/01/msg00168.html

I know it is not the NMU goal to go this far, but I had fun, and got to
work with wonderful people in the proccess. I am also aware I sometimes
fucked up (I broke links2, and have been reported to attach patches for
the wrong packages or to the wrong bug numbers) out of exhaustion :)

There is still major breakage to deal with. A list of up-for-adoption
packages to be reported, maintainers to be pinged, more bugs to me filed
(as in your package is in bad shape, either fix it or orphan it).

It has been also depressing to upload certaing packages in bad shape,
and in cases I have refused to upload at all because of packages being
in terrible shape. Some of the packages that still need to be fixed are
marked for removal.

If you look at http://haydn.debian.org/~thuriaux-guest/qa/ you will
discover that the QA team (which I am sadly not as active in as I would
want to be) is in fact doing quite well and the sad lesson for me to
learn is the incredible amount of people silently dissapearing and
neglecting their packages while we assume those packages have a
maintainer.

It leads me to think Debian accounts should expire in a year of no
activity and packages be automatically orphaned, but it is just a side
effect of RC over-dose, and I really need to go back to my own packages
when this is over.

To all of those who have walked this path kudos!

--
.''`. sleep: command not found
: :' :
`. `' Proudly running unstable Debian GNU/Linux
`- www.amayita.com www.malapecora.com www.chicasduras.com

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

Re: What's wrong with update-excuses?

2006-01-23 Thread Luk Claes

Frank Küster wrote:
> Hi,

Hi

> http://qa.debian.org/developer.php?excuse=tetex-base
> 
> says that tetex-base is 0 days old.  However, unstable has 3.0-13 which
> was uploaded on Jan 18th: 
> 
> http://lists.debian.org/debian-devel-changes/2006/01/msg01818.html
> 
> Is this just a bug in the qa scripts, or worse?

It's just a matter of britney not been running the last couple of days
AFAIK (though it has run today... so it will probably be shown as 1 days
old tomorrow?).

Cheers

Luk

-- 
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint:   D5AF 25FB 316B 53BB 08E7   F999 E544 DE07 9B7C 328D



signature.asc
Description: OpenPGP digital signature

Re: Autobuilding and the build-arch target, again

2006-01-23 Thread Michael Banck

On Mon, Jan 23, 2006 at 06:36:40PM +0100, Simon Richter wrote:
> To summarize the proposals so far:
> 
>  - "Scan debian/rules, invoke build-arch if present".
> 
> Has been tried, does not work.

AFAIK it is working as long as you assume debian/rules to be a Makefile,
which is a pretty safe assumption considered it is mandated by policy.

We had a talk about this in #debian-tech some days ago, and the general
consensus seemed to be that somebody should submit a patch for that to
dpkg.

I have attached the log.

cheers,

Michael
 okay. if somebody familiar with the build-{arch,indep} in rules story
wants to comment, I think this could work out (but have to re-read
#218893; did a while ago but did not make myself a summary):
 dato: I think dpkg-buildpackage needs to get changed to call build-arch
if available
 but I don't recall the whole discussion
 make Policy require the presence of build-{arch,indep}; this will need a
bump of Standards-Version, and of course packages are free to provide
the trivial implementation only.
 then, since dpkg-buildpackage receives a .dsc as argument, _check_ the
Standards-Version of that package, and invoke build-arch if appropriate
(dpkg-buildpackage -B) iff it's >= whatever verison introduced the
"must".
 err.
 why shouldn't dpkg-buildpackage -B not just check whether build-arch is
there, and call that?
 s#receives a .dsc as argument#has debian/control available#
 azeem: because a big part of the discussion was about how hackish, error
prone, and even impractical in some cases, that approach was.
 otoh, if a package updates its S-V, and does not provide build-arch,
that's a serious bug...
 but otoh^2, I'm not sure what the Policy editors will think about this,
but I see really no other way out.
 aba?
 why can't we just make binary-arch: depend on build-arch: instead of
build?
 because dpkg-buildpackage calls build first (as non-root), and
binary-arch afterwards.
 it does?
 indeed
 so I thought somebody came up with a sane way of checking for build-arch
 which, OTOH, relied that debian/rules be a Makefile, which some people
dispute (though Policy mandates it AFAIK)
 http://lists.debian.org/debian-policy/2004/05/msg6.html
 my personal order of preference is (1) Standards-Version bump, (2)
Build-Options, (3) Do nothing about the issue, (4) autodetect the
existance of build-arch
 what's wrong with what keybuk proposed? (i.e. make --dry-run | grep
^build-arch)
 keybuk proposed (2), didn't he?
 ah
 I read backwards.
 I didn't really read the first paragraph the first time round :)
 on the third try, I think I parsed it correctly, and went back to my
initial reading...
 aiui, historically, the reason is because the dpkg maintainer (wiggy)
wanted to support #!/bin/sh debian/rules riles
 fwiw, S-V bump detection in dpkg seems by a great length the most sane
choice to me
 atm Standards-Version is only advisory
 wouldn't the make -f check just fail then, and we assume no build-arch?
 i'm all for (4) -- immediate functionality with no extra changes, and
pretty minimal breakage
 (1) also gets our hands dirty in getting a bit a better way to be able to
introduce policy changes without making half the archive instanta-buggy
 did somebody send a good patch for (4) in, yet?
 it's very much against current practice, that no demand in policy can do
that, and that any demand in policy applies per direct to all packages,
but from a practical POV, being able to gradually introduce stuff into
policy this way is nice
 we could also test it on one of the lesser important buildds for a
while, e.g. (like armeb or hurd-i386, dunno=
 of course, it requires demanding a certain minimum version of policy after
a limited period
 I really don't see the point in mandating build-arch
 it is useful for a lot of packages, but pretty irrelevant for a lot as
well I guess
 having an environment variable that indicates binary: doesn't need to build
arch:all stuff is another option, though the functionality isn't as
immediate then
 azeem: probably so that lesser (in terms of power) arches don't need to
build huge masses of useless, because never uploaded documentation?
 DavidS: yes, but this can be introduced gradually for the packages which
needs it most
 instead of changing the whole archive
 azeem: not as long as stuff like dpkg-bp use build?
 DavidS: sure, I am assuming we go for (4)
 azeem: ah, reading helps (I did miss your earlier statements as 
context)
 so, let's see.  If we changed d-b to check for build-arch, that'd mean
older d-b would make the package FTBFS, right?
 or maybe not
 no, build: implies build-arch+build-all
 right
 so binary-arch would depend on build-arch instead of build
 yes
 don't they already do that often?
 and the

Re: A great weekend for Debian

2006-01-23 Thread Gustavo Franco

On 1/23/06, Amaya <[EMAIL PROTECTED]> wrote:
> Steinar H. Gunderson wrote:
> > I think you're overly optimistic :-) Most of the simple RC bugs
> > (related to the xlibs-dev transition) have been fixed; there aren't 90
> > more like those.
>
> I got home from work and have second thoughts about the email I
> previously sent. I think I am a bit pissed off by this "simple RC bugs"
> statement. I don't personally care about my own credit, but I think the
> people who worked in this transition deserved the email Joseph Smidt
> sent and an acknowledgement for their work. Some of us have been barely
> doing anything else in our lives than this transition for 14 days.
>
> I am talking about Marc 'HE' Brockschmidt, Thomas Viehmann, Nico Golde,
> Steve Langasek, Victor Seva Lopez and Justin Pryzby, others I might not
> be aware of, and Moritz Muehlenhoff, who provided the script that helps
> find out the new Build-Depends.
>
> (...)

The point is that there are a lot of people in this project that loves
(or not) duelling banjos, cares (or not) about lesbians, uses Debian
and Ubuntu (or not) and keep considering that flamewars are a waste of
time and we still are about a *universal* operating system, that
involves "shut up and hack" sometimes and "be cool" in others.

Thanks Justin, Amaya and all the others involved in any transition or
just for you that keep your packages without RC bugs as much as you
can, or for you that look into the RC bug list and feel that you
should help.

Sometimes, it's really good feel that i'm less than 1/1000 of all this
and while i'm busy helping with something that i think is important
there are others working in others not less interesting tasks.

Etch is coming. :)

Thanks,
Gustavo Franco

Re: Bug#349534: ITP: pyntor -- flexible and componized presentation program

2006-01-23 Thread Florian Ragwitz

On Mon, Jan 23, 2006 at 06:49:58PM +0100, Andreas Tille wrote:
> On Mon, 23 Jan 2006, Florian Ragwitz wrote:
> 
> > Due to the minimal size and maximum configurability, Pyntor is a nice
> > alternative to conventional presentation programs.
> 
> What do you mean by "conventional" presentation programs. IMHO we
> could differentiate into three groups of presentation programs:
> 
>  1. Text based with on syntax and own viewer
>  2. LaTeX based (mostly using PDF export or special DVI viewers)
>  3. GUI-based
> 
> I guess pyntor falls in group 1 and a comparison with members of this
> group might be nice.

'conventional' refers to group 3 I guess. The long description I put in
the ITP is taken from the projects homepage. A better description, that
will be the Description of the package, as soon as it's done, will be
more verbose and also make a comparison with mgp and others.


Regards,
Flo

-- 
BOFH excuse #42:
spaghetti cable cause packet failure


signature.asc
Description: Digital signature

Re: Autobuilding and the build-arch target, again

2006-01-23 Thread Wouter Verhelst

On Mon, Jan 23, 2006 at 06:59:55PM +0100, Michael Banck wrote:
> On Mon, Jan 23, 2006 at 06:36:40PM +0100, Simon Richter wrote:
> > To summarize the proposals so far:
> > 
> >  - "Scan debian/rules, invoke build-arch if present".
> > 
> > Has been tried, does not work.
> 
> AFAIK it is working as long as you assume debian/rules to be a Makefile,

No, that is not true. The code to do it that way had been added to dpkg
1.10.11 (from 2003!), but was pulled in 1.10.15, with the following
changelog:

dpkg (1.10.15) unstable; urgency=low

  * Fix detection of va_copy.
  * Back out debian/rules build-arch detection.  It is *not* possible *at
all* to detect available targets in a rules file.  Period.

 -- Adam Heath <[EMAIL PROTECTED]>  Fri, 19 Sep 2003 20:02:19 -0500

-- 
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/


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

Re: Autobuilding and the build-arch target, again

2006-01-23 Thread Bill Allombert

On Mon, Jan 23, 2006 at 06:45:07PM +0100, Simon Richter wrote:
> There have been various proposals on that matter, and it always boils 
> down to the same chicken-and-egg problem:
> 
>  - policy documents existing practice, which is to invoke "build".
>  - the existing practice cannot be changed because it would break packages
>  - the policy cannot be changed because there needs to be an 
> implementation first.
> 
> To summarize the proposals so far:

You forget my proposal in bug #218893 to add a Build-Options control
field indicating if the build-arch target exist, and the patch in
bug #229357.

So far I am waiting a decision from the dpkg maintainers.

At the time the dpkg maintainers were strongly opposed to requiring
the build-arch target but maybe things have changed.

Cheers,
Bill.

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

Re: Autobuilding and the build-arch target, again

2006-01-23 Thread Frank Lichtenheld

On Mon, Jan 23, 2006 at 06:36:40PM +0100, Simon Richter wrote:
> Questions? Comments? Seconds?

Yet another proposal to solve this problem can be found in #229357

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

Re: Autobuilding and the build-arch target, again

2006-01-23 Thread Michael Banck

On Mon, Jan 23, 2006 at 07:31:08PM +0100, Wouter Verhelst wrote:
> On Mon, Jan 23, 2006 at 06:59:55PM +0100, Michael Banck wrote:
> > On Mon, Jan 23, 2006 at 06:36:40PM +0100, Simon Richter wrote:
> > > To summarize the proposals so far:
> > > 
> > >  - "Scan debian/rules, invoke build-arch if present".
> > > 
> > > Has been tried, does not work.
> > 
> > AFAIK it is working as long as you assume debian/rules to be a Makefile,
> 
> No, that is not true. The code to do it that way had been added to dpkg
> 1.10.11 (from 2003!), but was pulled in 1.10.15, with the following
> changelog:

Yeah, I know (it is quoted in the URL referenced in the IRC log).  In
the same URL however, is the proposal from keybuk to use make -pn
instead of make -qn (the latter got used and later reverted in dpkg).

The difference between the two is that -q checks whether a target is
uptodate and return an appropriate exit code, while -p prints out the
data base (i.e. the rules and variables) that results from reading the
Makefile.  The latter seems more robust to me, so we should reevaluate
the "It is *not* possible *at all* to detect available targets in a
rules file." assertion, IMHO.

Michael

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

Re: Pre-Depends for Xorg 7.0

2006-01-23 Thread Nathanael Nerode

Russ Allbery wrote:
> (Or is
> imake going away completely?)

Yep.

Imake is still being shipped for the benefit of third-party packages, but it 
is not used by anything in Xorg 7.0 IIRC.  Doing a quick check, I think very 
few if any other packages in Debian use imake.

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

Re: Re: Arabic Linguist

2006-01-23 Thread LLA70



 
 
   CHASIB W ALSAEDI    614 Strathmore Ave   Erie, PA  16505    (814)836-2737
 
Employment Objective:  To obtain a full time position as an Arabic Linguist
 
 
 
 
 
 -  EMPLOYMENT HISTORY  -
 
 
 
1999 - 2005  UNITED MISSOURI BANK  -  Kansas City, MO   Job Title:  Lead Mailroom Associate   Duties: Responsible for distributing mail to all areas of the bank, put postage on all outgoing mail, sorted interoffice mail,   logged all incoming courier deliveries, responsible for overseeing 3 other second shift employees.
 
 
 
1997 - 1998  KANSAS CITY AUTO AUCTION  -  Kansas City, MO   Job Title:   Auto Detailer   Duties:  Delivered vehicles to and from the auction to various dealerships throughout Kansas City.  prepared used cars    to be sold at the auction. 
 
 
 
1996 - 1997  GEO-SPACE CENTER  -  Kansas City, MO   Job Title:  Warehouse/Forklift Driver   Duties: Responsible for shipping and receving in the warehouse, drove forklift, loaded and unloaded trucks, some  sorting and assembly.
 
 
 
  -  EDUCATION  -
 
1985    High school diploma in Nassarea, Iraq
 
1997 - 1998  Penn Valley Community College  -  Kansas City, MO   Course:  English as a second language   Grade:  A   -    Received certificate for completion of course.  
 
 
 
 
 
    -   EXPERIENCE  -   Volunteered time while going to school to translate in area hospitals in Kansas City for patients who could not speak English.
 
 
 
References available upon request.

Re: Re: Arabic Linguist

2006-01-23 Thread LLA70



 
 
   CHASIB W ALSAEDI    614 Strathmore Ave   Erie, PA  16505    (814)836-2737
 
Employment Objective:  To obtain a full time position as an Arabic Linguist
 
 
 
 
 
 -  EMPLOYMENT HISTORY  -
 
 
 
1999 - 2005  UNITED MISSOURI BANK  -  Kansas City, MO   Job Title:  Lead Mailroom Associate   Duties: Responsible for distributing mail to all areas of the bank, put postage on all outgoing mail, sorted interoffice mail,   logged all incoming courier deliveries, responsible for overseeing 3 other second shift employees.
 
 
 
1997 - 1998  KANSAS CITY AUTO AUCTION  -  Kansas City, MO   Job Title:   Auto Detailer   Duties:  Delivered vehicles to and from the auction to various dealerships throughout Kansas City.  prepared used cars    to be sold at the auction. 
 
 
 
1996 - 1997  GEO-SPACE CENTER  -  Kansas City, MO   Job Title:  Warehouse/Forklift Driver   Duties: Responsible for shipping and receving in the warehouse, drove forklift, loaded and unloaded trucks, some  sorting and assembly.
 
 
 
  -  EDUCATION  -
 
1985    High school diploma in Nassarea, Iraq
 
1997 - 1998  Penn Valley Community College  -  Kansas City, MO   Course:  English as a second language   Grade:  A   -    Received certificate for completion of course.  
 
 
 
 
 
    -   EXPERIENCE  -   Volunteered time while going to school to translate in area hospitals in Kansas City for patients who could not speak English.
 
 
 
References available upon request.

Re: Pre-Depends for Xorg 7.0

2006-01-23 Thread Russ Allbery

Nathanael Nerode <[EMAIL PROTECTED]> writes:

> Yep.

> Imake is still being shipped for the benefit of third-party packages,
> but it is not used by anything in Xorg 7.0 IIRC.  Doing a quick check, I
> think very few if any other packages in Debian use imake.

I think you should perhaps check a little more thoroughly before jumping
to conclusions.

Here's a list of packages that install binaries into /usr/X11R6/bin and
don't have lintian overrides for it.  In spot checks, about a quarter of
these packages use imake.  And that's just the packages with binaries;
there are a number of other packages that don't install binaries but that
still use imake (I happen to maintain one of them, a font package).

bugsx
buici-clock
ctwm
emelfm
fte-xwindow
fvwm95
gerstensaft
gipsc
gradio
hamsoft
hanterm-classic
hanterm-xf
ibp
isdnutils-xtools
ivtools-bin
ivtools-dev
kdrill
kinput2-canna
kinput2-canna-wnn
kinput2-wnn
kterm
lbxproxy
lm-batmon
lsb-core
lwm
mctools-lite
mgp
olvwm
olwm
oneko
pgaccess
pixmap
plotmtv
ppxp
ppxp-x11
proxymngr
qcam
seyon
skkinput
tkdesk
twlog
twm
videogen
vtwm
wmavgload
wmcpu
wmdate
wmnet
wmscope
xautolock
xbase-clients
xbatt
xbattbar
xcal
xcalendar-i18n
xcb
xclip
xclips
xdkcal
xdm
xdmx
xdu
xengine
xfaces
xfishtank
xfm
xfs
xfwp
xgdipc
xinput
xipmsg
xlbiff
xli
xlockmore
xlockmore-gl
xmeter
xmix
xmon
xnest
xpostit
xrn
xserver-common
xserver-xorg
xsysinfo
xtel
xtoolwait
xtrlock
xutils
xvfb
xview-clients
xviewg
xviewg-dev
xvkbd
xxkb
xzoom
yank

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Autobuilding and the build-arch target, again

2006-01-23 Thread Manoj Srivastava

On Mon, 23 Jan 2006 19:31:08 +0100, Wouter Verhelst <[EMAIL PROTECTED]> said: 

> On Mon, Jan 23, 2006 at 06:59:55PM +0100, Michael Banck wrote:
>> On Mon, Jan 23, 2006 at 06:36:40PM +0100, Simon Richter wrote:
>> > To summarize the proposals so far:
>> > 
>> >  - "Scan debian/rules, invoke build-arch if present".
>> > 
>> > Has been tried, does not work.
>> 
>> AFAIK it is working as long as you assume debian/rules to be a
>> Makefile,

> No, that is not true. The code to do it that way had been added to
> dpkg
> 1.10.11 (from 2003!), but was pulled in 1.10.15, with the following
> changelog:

> dpkg (1.10.15) unstable; urgency=low

>   * Fix detection of va_copy.
>   * Back out debian/rules build-arch detection.  It is *not*
> possible *at all* to detect available targets in a rules file.
> Period.

>  -- Adam Heath <[EMAIL PROTECTED]> Fri, 19 Sep 2003 20:02:19 -0500


Err, don't believe all you read.
==
__> cat notargetfoo.mk 
all:
@echo nothing to see here
__> cat withfoo.mk 
all: foo
@echo something to see here
foo:
@echo doing foo
__> make -n -p -f withfoo.mk | grep foo: >|/dev/null; echo $?
0
__> make -n -p -f notargetfoo.mk | grep foo: >|/dev/null; echo $? 
1
==

Of course, this kinda presupposes that ./debian/rules is a
 makefile -- which is what poicy requires it to be. So we can indeed
 detect if a target foo exists -- just that dpkg folks were trying not
 to depend on the rules file actually being a makefile, as opposed to
 something merely having a similar api to a real make file.

manoj
-- 
The sheep that fly over your head are soon to land.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Autobuilding and the build-arch target, again

2006-01-23 Thread Bill Allombert

On Mon, Jan 23, 2006 at 07:45:10PM +0100, Michael Banck wrote:
> On Mon, Jan 23, 2006 at 07:31:08PM +0100, Wouter Verhelst wrote:
> > On Mon, Jan 23, 2006 at 06:59:55PM +0100, Michael Banck wrote:
> > > On Mon, Jan 23, 2006 at 06:36:40PM +0100, Simon Richter wrote:
> > > > To summarize the proposals so far:
> > > > 
> > > >  - "Scan debian/rules, invoke build-arch if present".
> > > > 
> > > > Has been tried, does not work.
> > > 
> > > AFAIK it is working as long as you assume debian/rules to be a Makefile,
> > 
> > No, that is not true. The code to do it that way had been added to dpkg
> > 1.10.11 (from 2003!), but was pulled in 1.10.15, with the following
> > changelog:
> 
> Yeah, I know (it is quoted in the URL referenced in the IRC log).  In
> the same URL however, is the proposal from keybuk to use make -pn
> instead of make -qn (the latter got used and later reverted in dpkg).
> 
> The difference between the two is that -q checks whether a target is
> uptodate and return an appropriate exit code, while -p prints out the
> data base (i.e. the rules and variables) that results from reading the
> Makefile.  The latter seems more robust to me, so we should reevaluate
> the "It is *not* possible *at all* to detect available targets in a
> rules file." assertion, IMHO.

I would strongly suggest you to consider the "Build-Options: build-arch"
solution I proposed that is going to be much more robust than any
parsing of debian/rules. I am afraid the make -pn attempt will fail
and that will postpone the resolution of this issue even more, like
the -qn did.

Beside that, the "Build-Options: build-arch" has been the product of a
long discussion on debian-policy, does not assume debian/rules is a
makefile and provide a general way to expand the dpkg building interface.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: Autobuilding and the build-arch target, again

2006-01-23 Thread Paul TBBle Hampson

On Mon, Jan 23, 2006 at 07:31:08PM +0100, Wouter Verhelst wrote:
> On Mon, Jan 23, 2006 at 06:59:55PM +0100, Michael Banck wrote:
>> On Mon, Jan 23, 2006 at 06:36:40PM +0100, Simon Richter wrote:
> >> To summarize the proposals so far:
> >> 
> >>  - "Scan debian/rules, invoke build-arch if present".
> >> 
> >> Has been tried, does not work.
>> 
>> AFAIK it is working as long as you assume debian/rules to be a Makefile,

> No, that is not true. The code to do it that way had been added to dpkg
> 1.10.11 (from 2003!), but was pulled in 1.10.15, with the following
> changelog:

> dpkg (1.10.15) unstable; urgency=low

>   * Fix detection of va_copy.
>   * Back out debian/rules build-arch detection.  It is *not* possible *at
> all* to detect available targets in a rules file.  Period.

>  -- Adam Heath <[EMAIL PROTECTED]>  Fri, 19 Sep 2003 20:02:19 -0500

Given that a false-negative would just fallback to build (I hope???
That's surely the only sane option) then this issue must have been due
to false positives...

Can anyone contruct a file of some kind that will give a false-positive
for the various proposed detection routines?

Bonus points if it's a Makefile, since that would be a more powerful
argument for it being impossible...

-- 
---
Paul "TBBle" Hampson, BSc, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

License: http://creativecommons.org/licenses/by/2.1/au/
---


pgpT7U9fsvxYa.pgp
Description: PGP signature

Re: Offline use of apt-cacher

2006-01-23 Thread Eduard Bloch

#include 
* Anuradha Ratnaweera [Mon, Jan 23 2006, 06:24:08PM]:

> - Lazy online: we like apt-cacher to fetch a Packages/Release file
> only if it old as set by a timeout.  So if one runs apt-get update
> many times during a short period, only the first one will need to make
> a HEAD/GET request.  (Lazy online has one tricky case if Packages file
> does get update before timeout, but that can be handled neatly and
> transparently as we are online).

Fine... but don't you describe what is said in the comments in
apt-cacher.conf?

# apt-cacher can use different methods to decide whether package lists need to
# be updated,
# A) looking at the age of the cached files
# B) getting HTTP header from server and comparing that with cached data. This
# method is more reliable and avoids desynchronisation of data and index files
# but needs to transfer few bytes from the server every time somebody requests
# the files ("apt-get update")
# Set the following value to the maximum age (in hours) for method A or to 0
# for method B
expire_hours=0

So you basically want it to detect whether it's online and deliever the
old version if it's offline? That would be a bit uncomfortable in the
code because I would like to know up-front whether the file needs to be
refreshed or not. And how to detect the off-line status quick enough,
and not be confused with a timeout/slow server?

>   This mode is going to be very useful when:
>   - upgrading a large number of machines
>   - running a script which _needs_ to run apt-get update many times
> (and it can't be rewritten to do it otherwise)
> 
> - Offline: apt-cacher is totally offline.  Files (Packages/Release
> files as well as DEBs) are served if available, and returns 503 if not
> available.

As said bvefore, if you activate this mode manually, this should be an
easy feature to add on. How do you want to configure it?

Eduard.

-- 
Major Krantz: What if we take you with us, put you on trial.
Zathras: Zathras not of this time.  You take, Zathras die. You leave, Zathras
die. Either way, it is bad for Zathras.
 -- Quotes from Babylon 5 --


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

Re: What's wrong with update-excuses?

2006-01-23 Thread Frank Küster

Luk Claes <[EMAIL PROTECTED]> wrote:

> Frank Küster wrote:
>> Hi,
>
> Hi
>
>> http://qa.debian.org/developer.php?excuse=tetex-base
>> 
>> says that tetex-base is 0 days old.  However, unstable has 3.0-13 which
>> was uploaded on Jan 18th: 
>> 
>> http://lists.debian.org/debian-devel-changes/2006/01/msg01818.html
>> 
>> Is this just a bug in the qa scripts, or worse?
>
> It's just a matter of britney not been running the last couple of days
> AFAIK (though it has run today... so it will probably be shown as 1 days
> old tomorrow?).

Hm, does that mean that I will have to wait 10 days more for the testing
transition?  Or will the testing script detect the mismatch?

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

GR proposal: GFDL with no Invariant Sections is free

2006-01-23 Thread Fabian Fagerholm

[ Bcc'ed to -project, -devel and -legal, any further discussion and/or
seconds on -vote, please. ]

After reading all the recent posts about the GFDL on debian-vote, I
hereby propose the following General Resolution and ask for seconds.

--8<--
The Debian Project asserts that

Works licensed under the GNU Free Documentation License, version 1.2, as
published by the Free Software Foundation (GNU FDL), are free in
accordance with the Debian Free Software Guidelines (DFSG), if and only
if the work is licensed using the following options of the license:

no Invariant Sections,
no Front-Cover Texts, and
no Back-Cover Texts

If any other options are used, the work is not free in accordance with
the DFSG.

This General Resolution partly reverts an earlier decision by the
Release Management team, taken under delegation in accordance with the
Debian Constitution, to remove all works licensed under the GNU FDL from
the main section of the Debian archive.
--8<--

(The following is not part of the GR proposal text.)

For this to work, an amendment which says the RM decision was correct is
needed. I will second such an amendment given it is not overly broad or
ambiguous.
(That amendment should be simple to write: "Works licensed under the GNU
Free Documentation License are not free in accordance with the Debian
Free Software Guidelines" or something similar.)

Manoj: given this proposal receives enough seconds, will you fast-track
it to appear before the "Why the GNU Free Documentation License is not
suitable for Debian main" GR?

-- 
Fabian Fagerholm <[EMAIL PROTECTED]>
In necessariis unitas, in dubiis libertas, in omnibus caritas.


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

Re: Pre-Depends for Xorg 7.0

2006-01-23 Thread Joey Hess

Matthias Klose wrote:
> Joey Hess writes:
> > Debian GCC Maintainers 
> >gcc-snapshot
> 
> no. must be a false positive.

Yes, didn't anchor the pattern and it matched stuff in
/usr/lib/gcc-snapshot/lib/gcc/i486-linux-gnu/

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Pre-Depends for Xorg 7.0

2006-01-23 Thread Matthias Klose

Joey Hess writes:
> Debian GCC Maintainers 
>gcc-snapshot

no. must be a false positive.

  Matthias


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

Re: Autobuilding and the build-arch target, again

2006-01-23 Thread Wouter Verhelst

On Mon, Jan 23, 2006 at 02:17:36PM -0600, Bill Allombert wrote:
> On Mon, Jan 23, 2006 at 07:45:10PM +0100, Michael Banck wrote:
> > The difference between the two is that -q checks whether a target is
> > uptodate and return an appropriate exit code, while -p prints out the
> > data base (i.e. the rules and variables) that results from reading the
> > Makefile.  The latter seems more robust to me, so we should reevaluate
> > the "It is *not* possible *at all* to detect available targets in a
> > rules file." assertion, IMHO.
> 
> I would strongly suggest you to consider the "Build-Options: build-arch"
> solution I proposed that is going to be much more robust than any
> parsing of debian/rules.

And I would strongly suggest you to consider Simon Richter's proposal,
which sounds a lot cleaner to me: if you have build-depends-indep in
your debian/control file, you must also implement build-arch and/or
build-indep.

Additionally, that has the advantage that most packages probably already
implement it that way.

-- 
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/


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

Re: What's wrong with update-excuses?

2006-01-23 Thread Luk Claes

Frank Küster wrote:
> Luk Claes <[EMAIL PROTECTED]> wrote:
> 
> 
>>Frank Küster wrote:

>>>http://qa.debian.org/developer.php?excuse=tetex-base
>>>
>>>says that tetex-base is 0 days old.  However, unstable has 3.0-13 which
>>>was uploaded on Jan 18th: 
>>>
>>>http://lists.debian.org/debian-devel-changes/2006/01/msg01818.html
>>>
>>>Is this just a bug in the qa scripts, or worse?
>>
>>It's just a matter of britney not been running the last couple of days
>>AFAIK (though it has run today... so it will probably be shown as 1 days
>>old tomorrow?).
> 
> 
> Hm, does that mean that I will have to wait 10 days more for the testing
> transition?  Or will the testing script detect the mismatch?

No, the Release Team can change that, though they won't if not
everything is ready (like more RC bugs in version in unstable than in
the one in testing)...

Cheers

Luk

-- 
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint:   D5AF 25FB 316B 53BB 08E7   F999 E544 DE07 9B7C 328D



signature.asc
Description: OpenPGP digital signature

Re: Pre-Depends for Xorg 7.0

2006-01-23 Thread Nathanael Nerode

Russ Allbery wrote:
> Here's a list of packages that install binaries into /usr/X11R6/bin and
> don't have lintian overrides for it.  In spot checks, about a quarter of
> these packages use imake.  And that's just the packages with binaries;
> there are a number of other packages that don't install binaries but that
> still use imake (I happen to maintain one of them, a font package).
Well, let's see what the scope of imake in the /usr/X11R6/bin issue 
specifically is.  (The fonts issue seems to be more of an issue.)  Actually, 
it seems that there are an even larger percentage than you thought.  So I was 
very wrong.  Sigh.

Imake is considered dead-except-for-routine-maintenance upstream as far as I 
can tell, so best practice would be to migrate away from it.  Unless someone 
plans to adopt it.

Doing some sorting of this list, I find that these originate from
Xorg, so will no longer use Imake:
> lbxproxy
> proxymngr
> twm
> xbase-clients
> xdm
> xdmx
> xfs
> xfwp
> xnest
> xserver-common
> xserver-xorg
> xutils
> xvfb

These don't build-depend on xutils (so either they don't use imake or they 
have a serious missing Build-Depends bug):
> buici-clock
> emelfm
> fte-xwindow
> fvwm95
(fvwm95 is desperately obsolete software which should really be removed 
anyway.)
> gerstensaft
> gipsc
> gradio
> hamsoft
> ibp
> lm-batmon
> lsb-core
> pgaccess
Orphaned, QA.
> ppxp
> ppxp-x11
> qcam
> tkdesk
> twlog
> videogen
> wmcpu
> wmscope
> xclips
> xdkcal
> xgdipc
> xlockmore
> xlockmore-gl
> xvkbd
> yank

This leaves a list of possible Imake users.  I went through these by hand, and 
most of them did use Imake.

Probable non-imake users:
> hanterm-classic
> hanterm-xf
(These two appear to have both Imake and configure/Make build systems, but the 
latter is used.)

Definite imake users:
> bugsx
> ctwm
-- should be straightforward to convert, by copying configury from twm, of
which it is a fork
> isdnutils-xtools
> ivtools-bin
> ivtools-dev
ivtools: severely out of date and busted packages, with a particularly insane 
configuration and build system.
> kdrill
> kinput2-canna (source kinput2)
> kinput2-canna-wnn (source kinput2)
> kinput2-wnn (source kinput2)
> kterm
-- should be trivial to convert, by copying configury from xterm, of which it 
is a fork
> lwm
> olvwm (source xview)
> olwm (source xview)
> mctools-lite
> mgp 
> oneko
-- very simple Imakefile, should be an easy conversion
> pixmap
> plotmtv
> seyon
> skkinput
> vtwm
> wmavgload
> wmdate
> wmnet
> xautolock
> xbatt
> xbattbar
> xcal
> xcalendar-i18n
> xcb
> xclip
> xdu
> xengine
> xfaces
-- has an alternate "noimake" Makefile
> xfishtank
> xfm
> xinput
> xipmsg
> xlbiff
> xli
> xmeter
> xmix
> xmon
> xpostit
> xrn
> xsysinfo
-- orphaned, QA.
> xtel
> xtoolwait
> xtrlock
-- has a 'noimake' Makefile
> xview-clients (source xview)
> xviewg (source xview)
> xviewg-dev (source xview)
> xxkb
> xzoom


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

Re: What's wrong with update-excuses?

On Mon, Jan 23, 2006 at 06:50:12PM +0100, Luk Claes wrote:
> Frank Küster wrote:
> > Hi,

> > http://qa.debian.org/developer.php?excuse=tetex-base
> > 
> > says that tetex-base is 0 days old.  However, unstable has 3.0-13 which
> > was uploaded on Jan 18th: 
> > 
> > http://lists.debian.org/debian-devel-changes/2006/01/msg01818.html
> > 
> > Is this just a bug in the qa scripts, or worse?

> It's just a matter of britney not been running the last couple of days
> AFAIK (though it has run today... so it will probably be shown as 1 days
> old tomorrow?).

It's been running, but not completing.  Yesterday it completed when run by
hand, but the results weren't committed because LCA interfered.  Today it
should complete on its own and be committed normally.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: For those who care about the GR

On Mon, Jan 23, 2006 at 12:40:30PM -0500, Anthony DeRobertis wrote:
> On Sun, Jan 22, 2006 at 03:42:39PM -0800, Steve Langasek wrote:

> > > And what? If someone tries to bring through a GR stating that
> > >  MS office warez can be distributed in main since it meets the DFSG,
> > >  one might rule that as frivolous and a waste of time.

> > I'm not convinced the constitution gives the secretary the power to make
> > such a ruling.  There are no provisions in the constitution for the Project
> > Secretary to dismiss a GR -- *even* a GR stating that the Debian Project
> > holds the value of pi to be 3 -- so long as the GR has the requisite number
> > of seconds.

> I suspect the Secretary could effectively do so by declining to take the
> vote under Section 2.1.1 ("[n]othing in this constitution imposes an
> obligation on anyone to do work for the Project.") It seems then that
> the secretary has no obligation to actually perform 4.2.3 or 7.1.1.

Which would be grounds for removing the secretary from office, if necessary
by appealing to the SPI board under 7.2. of the constitution.

> > In the present case, I understand that the proposed ballot option is
> > ambiguous wrt whether it constitutes an implicit amendment to the foundation
> > docs, and that in the absence of clarification (in the form of a re-worded
> > proposal) on the part of the proposer, it is the project secretary's
> > prerogative to specify a supermajority requirement.

> I think that under 7.1.3, it'd be the Secretary's job/power to determine
> supermajority requirement regardless of what the proposed ballot option
> says.

Correct, it is the secretary's job to determine supermajority requirement in
all cases.  It would also be an abuse of power to establish a supermajority
requirement other than that specified by the constitution.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Autobuilding and the build-arch target, again

2006-01-23 Thread Bill Allombert

On Mon, Jan 23, 2006 at 11:08:00PM +0100, Wouter Verhelst wrote:
> And I would strongly suggest you to consider Simon Richter's proposal,
> which sounds a lot cleaner to me: if you have build-depends-indep in
> your debian/control file, you must also implement build-arch and/or
> build-indep.
> 
> Additionally, that has the advantage that most packages probably already
> implement it that way.

There used to be the issue that the dpkg maintainers were strongly
opposed to that, because that break backward compatibility. 

Cheers,
Bill.


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

Re: Pre-Depends for Xorg 7.0

2006-01-23 Thread Russ Allbery

Nathanael Nerode <[EMAIL PROTECTED]> writes:

> Imake is considered dead-except-for-routine-maintenance upstream as far
> as I can tell, so best practice would be to migrate away from it.
> Unless someone plans to adopt it.

imake the program, and xmkmf, are *probably* not that horribly difficult
to maintain, apart from obnoxious C preprocessor issues.  However, imake
is very, *very* heavily dependent on the exact details of the X
configuration.  If upstream is abandoning imake, my worry on trying to
maintain it would be that the X configuration may drift away from what
imake can deal with.

I've done that sort of X configuration hacking to make imake install
things in appropriate locations and use the right compilers in the past.
It's not fun work; it's painful, tedious, and exceedingly boring, and I
wouldn't recommend it if you can avoid it.

-- 
Russ Allbery ([EMAIL PROTECTED])   

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

Re: Meta pkgs in debian

2006-01-23 Thread Ed Sweetman




On Sun, Jan 22, 2006 at 20:31:53 -0500, Ed Sweetman wrote:
 


Ok, i'm not subscribed here so please cc me any responses directly.

Before I propose my suggestion I want to outline my issues with how meta 
pkgs are done currently. 
   



[...]

 

The problem #2: Meta pkgs in debian are one way.  Removing a meta pkg 
doesn't remove or even check for the pkgs it installed to see if they 
are no longer dependent on anything or ask the user if they want to 
remove them.  Because of problem #1, removing a meta pkg isn't even 
   



Aptitude does this per default.



So does debfoster, but how can aptitude remove the meta package, and
attempt to remove all the pkgs that were installed because of it, when
you removed one of those pkgs yourself before and that caused the pkg
manager to remove the meta pkg.

say you installed mymetapkg.  mymetapkg installs something the 
maintainer thought was really useful to it, but not interdependent with 
the rest of the pkgs.   Now you decide you dont want that nifty pkg that 
got installed when you installed mymetapkg, you remove it.  pkg manager
removes the pkg "mymetapkg" too because it depends on that nifty other 
pkg. Now a while later you decide you dont want mymetapkg because you 
hate it or whatever, now what do you do? Reinstall the mymetapkg pkg to 
remove it? Using the Suggests field instead of Depends ensures this is 
never a problem.  It fixes every issue there is with having meta pkgs 
use dependencies to get the other pkgs installed, without any drawbacks.



aptitude can't do this. so saying this is something aptitude can do is 
completely wrong.   If the pkg isn't installed, aptitude doesn't respond 
with any action when asked to remove it.


It just doesn't make as much sense to use depends than suggests.. 
aptitude already supports installing/retrieving via suggests, removing 
those installed real pkgs wouldn't remove the meta pkg with suggests, 
where as in depends it does.  This makes removal of the meta pkg 
possible (and it's installed pkgs) a much more straightforward and 
logical process later on, no regexps or state juggling or black magic is 
 required.   only the "simple" feature of removing suggested pkgs, 
perhaps via an argument/option similar to the one used to install 
suggested pkgs.


Suggests solves this annoying issue with meta pkgs with extremely minor 
changes to the way the pkgs are made (s/Depends/Suggests) and for 
removal, an argument/option that's selectable to tell aptitude to try 
removing suggested pkgs in the given pkg if they're installed.



Oh, and if i'm missusing Suggests when in fact, aptitude uses Recommends 
to install non-"depends" pkgs, then replace all my usages of Suggests 
with Recommends.



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

Bug#349607: ITP: cl-parenscript -- JavaScript embedded in a Common Lisp host

2006-01-23 Thread Luca Capello

Package: wnpp
Severity: wishlist

* Package name: cl-parenscript
  Version : 1:20060122-1
  Upstream Author : Manuel Odendahl <[EMAIL PROTECTED]>
Edward Marco Baringer <[EMAIL PROTECTED]>
* URL or Web page : http://common-lisp.net/project/ucw/repos/parenscript
* License : BSD
  Description : JavaScript embedded in a Common Lisp host

 Parenscript is a small lispy language that can be compiled to
 JavaScript.
 .
 It also comes with an embedded CSS representation in Common Lisp.
 This simplifies the development of web applications in Common Lisp
 by allowing the Common Lisp programmer to write all the documents
 in Common Lisp syntax.
 .
 HTML pages, CSS files and JavaScript code can be generated with
 the full power of Common Lisp and its macros.

=

This is necessary as dependency for UCW [1].

The package will be sit in the CL-Debian repository [2] and will
follow the "Common Lisp in Debian Manual" [3].  I'm resolving some
minor problems concerning the documentation, so it'll be ready in a
couple of days.

Thx, bye,
Gismo / Luca

[1] http://common-lisp.net/project/ucw/
[2] http://cl-debian.alioth.debian.org/cgi-bin/darcsweb.cgi
[3] http://cl-debian.alioth.debian.org/clid/clid.html/


pgp2gn1qJmKX7.pgp
Description: PGP signature

Re: Autobuilding and the build-arch target, again

2006-01-23 Thread Adeodato Simó

* Wouter Verhelst [Mon, 23 Jan 2006 23:08:00 +0100]:

> And I would strongly suggest you to consider Simon Richter's proposal,
> which sounds a lot cleaner to me: if you have build-depends-indep in
> your debian/control file, you must also implement build-arch and/or
> build-indep.

> Additionally, that has the advantage that most packages probably already
> implement it that way.

  It sounded sensible to me at first, but alas:

 GyrosGeier: oh, but I actually like your proposal as well.
   only, how many  packages would benefit from having buildds
   call 'build-arch' on them, that have _no_ need for B-D-I?

 dato, I think that would be very few
[...]
 dato, these won't benefit from the implementation directly.

 GyrosGeier: right; but if there's a need for it, a solution for all
   would be prefereable, since this would get done probably only once.

 GyrosGeier: (iow, if your proposal is demonstrated to cover 90+% of
   the relevant cases, cool, I think one can consider it; but if
   it doesn't, it'd be better to aim for a solution that did,
   don't you think?)

  So with that proposal you're restricting the number of packages that
  can benefit from it. Now, if one shows that such restriction does not
  have practical impact... (Or that is considerably less bad that the
  "mega-impact" that requiring build-* in every package is, that too.)

  Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
An economist is an expert who will know tomorrow why the things he
predicted yesterday didn't happen today.
--  Laurence J. Peter


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

Re: Pre-Depends for Xorg 7.0

2006-01-23 Thread Anthony Towns

On Sun, Jan 22, 2006 at 09:22:24PM -0500, David Nusinow wrote:
>Because the remainder of the Xorg 7.0 packages will require this change
> to have taken place, they will have to pre-depend upon an appropriate
> version of x11-common. As such, I'm writing to the list in accordance with
> policy.

AIUI, that policy requirement is mostly in place since pre-depends in
the pre-apt days would require users to do an extra [U]npack/[I]nstall
cycle in dpkg. While it's still a good idea to be reluctant to add
Pre-Depends, it's not the big problem it once was, and this seems to
qualify as pretty legit.

Cheers,
aj

signature.asc
Description: Digital signature

Re: Pre-Depends for Xorg 7.0

On Mon, Jan 23, 2006 at 08:55:00AM +, Colin Watson wrote:
> There is some software that contains hardcoded paths to executables in
> /usr/bin/X11; for example, sshd hardcodes the path to
> /usr/bin/X11/xauth. sshd stats whatever it thinks is the location of
> xauth to find out whether it can do X11 forwarding, so it's not entirely
> trivial to unhardcode this path.

Ok, thanks for clarifying that. I wasn't aware of that issue. It also
explains some of the errors I've had with partial upgrades from 6.9 to 7.0.

> Current Ubuntu makes /usr/bin/X11 a symlink to . (i.e. /usr/bin) which
> means that this all continues to work fine after xauth and friends move
> to /usr/bin. David's paragraph above implies something different. David?

Right, I'm sorry. I'd forgotten about that part and had misread the script
before sending the mail. /usr/bin/X11 is still a symlink to . (or rather
../bin), so anything installing to /usr/bin/X11 will actually install to
/usr/bin.

 - David Nusinow

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

Re: Pre-Depends for Xorg 7.0

On Sun, Jan 22, 2006 at 09:54:54PM -0800, Russ Allbery wrote:
> David Nusinow <[EMAIL PROTECTED]> writes:
> > Right. The everything that you'd expect to go in to /usr/bin and
> > /usr/lib will install there, at least as far as Xorg goes. An example of
> > that is that the new xterm package installs to /usr/bin rather than
> > /usr/X11R6/bin.  I haven't finished the packaging of everything, but it
> > seems that some of the header files are put in to differenct dirs of
> > /usr/include. I'll investigate the reasoning for this further. As for
> > /usr/lib/X11, data files like fonts currently go in there.
> 
> I understand why /usr/include/X11 and /usr/lib/X11 would stay; after all,
> those are perfectly reasonable names for what they are currently symlinks
> to.  I don't understand why /usr/bin/X11 wouldn't go away completely, at
> least for the programs that come with X.  Maybe that's the plan and the
> above is just a bit confusing since all three of those directories aren't
> treated quite the same way?

Right. See Colin's mail and my reply for /usr/bin/X11. I'd forgotten that
this one is a symlink to /usr/bin. The others are made in to directories.
/usr/share/X11 is as well.

> Does upstream imake still dump everything into /usr/X11R6 or has it too
> been modified to use a more conventional installation structure?  (Or is
> imake going away completely?)
> 
> I'd love it if imake itself just used a better directory layout, since
> it's going to be a *long* time before everything that currently uses imake
> switches to some other build system (even if that's been in progress for
> years).

Nathanael is right about imake. No one upstream is interested in
maintaining it. I'm planning on packaging it for use in Debian (I'm still
not sure which package it'll be in eventually) but as it's not being used
for X any more I'm not particularly inclined to do much with it myself.

 - David Nusinow


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

Re: Pre-Depends for Xorg 7.0

On Mon, Jan 23, 2006 at 07:32:33AM +0100, Mike Hommey wrote:
> On Mon, Jan 23, 2006 at 12:48:24AM -0500, David Nusinow <[EMAIL PROTECTED]> 
> wrote:
> > Right. The everything that you'd expect to go in to /usr/bin and /usr/lib
> > will install there, at least as far as Xorg goes. An example of that is
> > that the new xterm package installs to /usr/bin rather than /usr/X11R6/bin.
> > I haven't finished the packaging of everything, but it seems that some of
> > the header files are put in to differenct dirs of /usr/include. I'll
> > investigate the reasoning for this further. As for /usr/lib/X11, data files
> > like fonts currently go in there.
> 
> Shouldn't the fonts ans other such files go in /usr/*share*/X11, instead ?

I don't have a good answer for you beyond speculation but I'll try and find
out. Currently very little gets put in to /usr/share/X11 (XErrorDB and
XKeysymDB on my partial install) so I'm not entirely sure what its role is
as of yet. 

 - David Nusinow


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

Re: Pre-Depends for Xorg 7.0

On Mon, Jan 23, 2006 at 02:48:33AM -0500, Joey Hess wrote:
> David Nusinow wrote:
> > Right. The everything that you'd expect to go in to /usr/bin and /usr/lib
> > will install there, at least as far as Xorg goes. An example of that is
> > that the new xterm package installs to /usr/bin rather than /usr/X11R6/bin.
> > I haven't finished the packaging of everything, but it seems that some of
> > the header files are put in to differenct dirs of /usr/include. I'll
> > investigate the reasoning for this further. As for /usr/lib/X11, data files
> > like fonts currently go in there.
> 
> /usr/include/X11 makes some sense, it was mostly /usr/bin/X11 that I
> didn't see the point of. However, even /usr/include/X11 could
> potentially cause a problem, if a third party package currently installs
> headers in /usr/X11R6/include/foo and xorg updates /usr/include/X11 to
> be a directory rather than a symlink, then #include  will stop
> working. Switching any of these directories from symlinks to real
> directories seems likely to require some coordination beyond xorg.

Well, Xorg 7.0 is currently deployed in Gentoo, Ubuntu, and Fedora's
developmental branches, with more to come. So a great many apps are
building and working with it as we speak. I'm sorry I forgot that
/usr/bin/X11 is a symlink to /usr/bin (thanks to Colin again for pointing
that out) so hopefully that'll put at least one issue to rest :-) As for
the include location breaking things, I can imagine it but most build
systems should be looking in /usr/include for headers anyway...

> The fonts directory issue can be fixed in policy easily enough, although
> again if a new version of X looks for fonts in /usr/lib/X11 and some
> third party packages install them in /usr/X11R6/lib, when the former
> directory stops being a symlink, those fonts won't be found.

This is true, but breaking third party packages has never been a huge
concern for Debian (or myself really ;-)
>
> Here's a maintainer-sorted list of packages that install files in
> /usr/X11R6:

Thanks for putting this together!

 - David Nusinow


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

Re: Pre-Depends for Xorg 7.0

On Mon, Jan 23, 2006 at 02:56:09PM -0800, Russ Allbery wrote:
> I've done that sort of X configuration hacking to make imake install
> things in appropriate locations and use the right compilers in the past.
> It's not fun work; it's painful, tedious, and exceedingly boring, and I
> wouldn't recommend it if you can avoid it.

Apparently upstream has made an imake configuration that will basically do
the right thing and install binaries to /usr/bin and so forth. I'll be sure
to enable this in our build. Hopefully that'll take care of this issue.

 - David Nusinow

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

Re: For those who care about their packages in Ubuntu

2006-01-23 Thread Paul Johnson

On Sunday 22 January 2006 03:16, David Weinehall wrote:

> Since all Ubuntu packages are recompiled against a different set of
> libraries, the bug might not even affect the Debian package, even though
> they share the same source.  Hence having Ubuntu developers triage the
> bugs to rule out such issues before they are forwarded to Debian's BTS
> is always a good thing; thus the maintainer field should be changed
> for *binary packages*.  The source is the same, so the field should NOT
> be changed for *source packages*.

Given Ubuntu hopelessly complicates everything, pretends there is cooperation 
where there is none, and merely duplicates the effort of the debian-desktop 
project, and contributes nothing to the community or society, what's stopping 
us from officially discouraging Ubuntu's existence?

-- 
Paul Johnson
Email and IM (XMPP & Google Talk): [EMAIL PROTECTED]
Jabber: Because it's time to move forward  http://ursine.ca/Ursine:Jabber


pgpqOs7lIBNk9.pgp
Description: PGP signature

Re: For those who care about their packages in Ubuntu

2006-01-23 Thread Matthew Palmer

On Mon, Jan 23, 2006 at 05:33:33PM -0800, Paul Johnson wrote:
> On Sunday 22 January 2006 03:16, David Weinehall wrote:
> 
> > Since all Ubuntu packages are recompiled against a different set of
> > libraries, the bug might not even affect the Debian package, even though
> > they share the same source.  Hence having Ubuntu developers triage the
> > bugs to rule out such issues before they are forwarded to Debian's BTS
> > is always a good thing; thus the maintainer field should be changed
> > for *binary packages*.  The source is the same, so the field should NOT
> > be changed for *source packages*.
> 
> Given Ubuntu hopelessly complicates everything, pretends there is cooperation 
> where there is none, and merely duplicates the effort of the debian-desktop 
> project, and contributes nothing to the community or society, what's stopping 
> us from officially discouraging Ubuntu's existence?

I think that way lies madness, for so many reasons.  It's not exactly
encouraging of the principles of Free Software, nor is it particularly
practical.  Would we hold a GR to say "Ubuntu is the Antichrist"?  Some sort
of technical thing to micq our packages against Ubuntu?  I don't really see
the value in it, either -- what's it going to get us?  I seriously doubt
that, even if we *wanted* a PR war, that we could win it.

- Matt


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

Re: For those who care about their packages in Ubuntu

On Mon, Jan 23, 2006 at 05:33:33PM -0800, Paul Johnson wrote:
> On Sunday 22 January 2006 03:16, David Weinehall wrote:

> > Since all Ubuntu packages are recompiled against a different set of
> > libraries, the bug might not even affect the Debian package, even though
> > they share the same source.  Hence having Ubuntu developers triage the
> > bugs to rule out such issues before they are forwarded to Debian's BTS
> > is always a good thing; thus the maintainer field should be changed
> > for *binary packages*.  The source is the same, so the field should NOT
> > be changed for *source packages*.

> Given Ubuntu hopelessly complicates everything, pretends there is cooperation 
> where there is none, and merely duplicates the effort of the debian-desktop 
> project, and contributes nothing to the community or society, what's stopping 
> us from officially discouraging Ubuntu's existence?

That we're here to build a superior operating system, not to engage in
counterproductive wanking out of jealousy over others success?

Oh, wait, you're not a DD, so I guess this is a different "we" you're
talking about having "officially" discourage Ubuntu's existence.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: For those who care about their packages in Ubuntu

2006-01-23 Thread John Hasler

Paul Johnson writes:
> Given Ubuntu hopelessly complicates everything, pretends there is
> cooperation where there is none, and merely duplicates the effort of the
> debian-desktop project, and contributes nothing to the community or
> society...

Do you have evidence to support this, or is it just libel?

> ...what's stopping us from officially discouraging Ubuntu's existence?

The fact that most of us are interested in cooperation or at least peaceful
coexistence.
-- 
John Hasler


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

Re: For those who care about their packages in Ubuntu

On Mon, Jan 23, 2006 at 05:33:33PM -0800, Paul Johnson wrote:
> On Sunday 22 January 2006 03:16, David Weinehall wrote:
> 
> > Since all Ubuntu packages are recompiled against a different set of
> > libraries, the bug might not even affect the Debian package, even though
> > they share the same source.  Hence having Ubuntu developers triage the
> > bugs to rule out such issues before they are forwarded to Debian's BTS
> > is always a good thing; thus the maintainer field should be changed
> > for *binary packages*.  The source is the same, so the field should NOT
> > be changed for *source packages*.
> 
> Given Ubuntu hopelessly complicates everything, pretends there is cooperation 
> where there is none, and merely duplicates the effort of the debian-desktop 
> project, and contributes nothing to the community or society, what's stopping 
> us from officially discouraging Ubuntu's existence?

Wow, just when I thought you couldn't be a bigger tool you write this. I've
had great experiences working with Ubuntu developers (who are, quite
simply, often Debian developers and thus part of our little tribe) and I
look forward to more of the same.  Maybe the next time you start trying to
do some real work for Debian rather than troll -project you'll find this
out for yourself.

 - David Nusinow


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

Re: Offline use of apt-cacher

2006-01-23 Thread Anuradha Ratnaweera

On 1/24/06, Eduard Bloch <[EMAIL PROTECTED]> wrote:
> #include 

Hi again,

> * Anuradha Ratnaweera [Mon, Jan 23 2006, 06:24:08PM]:
>
> > - Lazy online: we like apt-cacher to fetch a Packages/Release file
> > only if it old as set by a timeout.  So if one runs apt-get update
> > many times during a short period, only the first one will need to make
> > a HEAD/GET request.  (Lazy online has one tricky case if Packages file
> > does get update before timeout, but that can be handled neatly and
> > transparently as we are online).
>
> Fine... but don't you describe what is said in the comments in
> apt-cacher.conf?

Oops...  Please forgive my ignorance.  I think I rushed into check the
files in /usr/share/apt-cacher/ without reading the config file...

> So you basically want it to detect whether it's online and deliever the
> old version if it's offline? That would be a bit uncomfortable in the
> code because I would like to know up-front whether the file needs to be
> refreshed or not. And how to detect the off-line status quick enough,
> and not be confused with a timeout/slow server?

This means case 2 is also handled with apt-cacher as is, perfect! :-)

Having a small external program that sets expire_hours automatically
is fine with us.  I created this very crude sudo script which is run
just before Saegiri:

#!/bin/bash

cd /etc/apt-cacher/
cp -f apt-cacher.conf.orig apt-cacher.conf
num_interfaces=$(grep ':' /proc/net/dev | egrep -v 'lo:|:[[:space:]]*0' | wc -l)
[ $num_interfaces -ge 1 ] && \
sed -i 's/^[[:space:]]*expire_hours[[:space:]]*=.*/expire_hours=10/' \
/etc/apt-cacher/apt-cacher.conf

To complete this discussion, we need to clarify a couple of scenarios.
 Let's start with one.  I'll use an example to ease the explaination,
and let's assume expire_hours is set to 12.

- apt-get update is run at 09:00, and Packages/Release/Sources files
are actually fetched; the lists include version 1.0.1 of package x.
- package x is not in the cache.
- package x is upgraded to version 1.0.2 in the repository at 10:00.
- apt-get install x is run at 11:00 which will look for versin 1.0.1
and apt-cacher will get a 404.

Does apt-cacher mark the related Packages/Sources file(s) as `expired'
at that point, so that someone can correct the situation by running
apt-get update next time without waiting until 21:00?

Thanks in advance.

Anuradha
--
http://www.linux.lk/~anuradha/
http://anuradha-ratnaweera.blogspot.com

Re: A great weekend for Debian

On Mon, Jan 23, 2006 at 06:56:56PM +0100, Amaya wrote:
#include 
and thanks for your time to write such a useful note about how you and
others are keeping Debian great!

> 
> It leads me to think Debian accounts should expire in a year of no
> activity and packages be automatically orphaned, but it is just a side
> effect of RC over-dose, and I really need to go back to my own packages
> when this is over. 

I was thinking of an analogy of a car rental store. A company (Debian)
owns a car (a package) and 'hires' a mechanic (maintainer) to look after
it. Folks come in from time to time and rent the car (use the package).
From time to time folks who rent the car notice problems with the car
and tell the mechanic about them. So, when the car is brought back,
night after night, he/she fixes the car. And then folks come in again
and rent the car and notice the improvements. But after sometime, the
car starts to fall apart and then the mechanic is no where to be found. It
seem like the company owners should ask where the mechanic went and the
mechanic should either leave a note (out to lunch, on vacation, on
personal leave) or before leaving, should tell the company to find a
fill-in mechanic, add a mechanic to the mechanic team or if no notice is
given, start looking for a new mechanic who reports back when he/she
will be out. 

It seems various people have sought to address some of the issue of
lack of package maintanership: low threshold NMU policy. This is to
combat the 'fiefdom' idea which is a non-technical issue. And the idea
of a one year term on @debian.org accounts and official maintainer
status for their packages is a techincal solution to the problem of
'fiefdom's. 

Folks are away for legitimate reasons: paid-work, family obligations,
sickness, lack of /bin/sleep ;-). If folks said: "I want to continue to
work on package X but will be away for " where  was not large enought to warrant concern for the package upkeep,
then fine.  Otherwise the person should seek to have someone fill-in for
their time or they could choose to hand it over to someone else. That
could be done with a list for all packages where DD,NM and others could
signup for wanting to work on the package. Otherwise the list could be
used as a way for others to seek a person to address an issue raised by
new upstream, an RC bug or security issue.  

Unfortunatley it does't address all issues for package upkeep when the
maintainer is MIA and no one is to be found to continue the work.

Again,
thanks to all who do great work and contribute much to world
domination^H^H^H^H^Debian!
Kev
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!
  `$' $' 
   $  $  _
 ,d$$$g$  ,d$$$b. $,d$$$b`$' g$b $,d$$b
,$P'  `$ ,$P' `Y$ $$'  `$ $  "'   `$ $$' `$
$$ $ $$g$ $ $ $ ,$P""  $ $$
`$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$
 `Y$$P'$. `YP $$$P"' ,$. `Y$$P'$ $.  ,$.

signature.asc
Description: Digital signature

Re: emacs 21.4, Chinese and utf-8

On Mon, Jan 23, 2006 at 08:28:40PM +0100, Stefan Müller wrote:
> Hi,
> 
> I am a grammar developer and I started to work on Chinese. We use a 
> development system that needs utf-8 input. I managed to set up 
> everything for emacs 21.3. All I had to say was:
> 
> (setq default-input-method \"chinese-py\")
> (set-default-coding-systems 'utf-8)
> 
> And storing the files with Chinese characters in utf-8 and telling emacs 
> about it with the line:
> 
> % -*- coding:utf-8 mode:trale-prolog-*-
> 
> was sufficient.
> 
> I put together a CD rom that is based on Knoppix, which is a debian 
> distribution. Debian uses emacs 21.4 and all I found out does not work 
> any longer:
> 
> I can set the input-method to chinese-py by hand and type chinese 
> characters, but I cannot save them in utf-8. I can set this option for 
> saving the buffer, but if I try to safe the file emacs asks again and 
> utf-8 is not offered as an option.
> 
> Do you have any ideas what I could do about this?
> 
> Thanks and best wishes
> 
> 
>   Stefan
> 
Hi Stefan,
To solve your immediate problem, I'd suggest searching the
lists.debian.org for emacs related mailing lists or possible #debian or
an emacs channel on irc.freenode.net. I have chatted on #debian with
people who use chinese input methods and may also have familiarity with
mule. And additionaly, there maybe hints or bugs in bugs.debian.org
related to mule/emacs.

The reason for my reply follows.

There is currently a debate on the debian-devel mailing list that
relates to the issue that you are experiencing: you are using a
Debian-derivative and then try a similar procedure on Debian expecting a
reproducible behavior and are confused as to why this is. Debian and
Ubuntu, a unique Debian-derivative, are trying to devise a system that
clearly states to Debian-derivative users that difference in application
behavior and/or bugs should be expected. One idea is to change the
attribution of the software package info to reflect who actually changed
the software package as some derivatives leave the info unchanged which 
leads to people:
1. complaining to Debian developers instead of
the derivative maintainers.
2. contributing bug reports to the Debian bug tracking system,
which then the developer is unable to reproduce because of the
differences between a derivative and Debian
3. complaining in #debian when they should be asking on an irc
channel of the derivative (eg. #knoppix)
At some point in the future Debian may have similar discussion with other
derivitavies like Knoppix.
Cheers,
Kevin Mark
ps.
I hope you dont mind me CC the debian-devel list as I think your post is
a data point in the issue being addressed.
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!
  `$' $' 
   $  $  _
 ,d$$$g$  ,d$$$b. $,d$$$b`$' g$b $,d$$b
,$P'  `$ ,$P' `Y$ $$'  `$ $  "'   `$ $$' `$
$$ $ $$g$ $ $ $ ,$P""  $ $$
`$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$
 `Y$$P'$. `YP $$$P"' ,$. `Y$$P'$ $.  ,$.


signature.asc
Description: Digital signature

Re: Offline use of apt-cacher

On Mon, Jan 23, 2006 at 09:23:55PM +0100, Eduard Bloch wrote:
> #include 

> As said bvefore, if you activate this mode manually, this should be an
> easy feature to add on. How do you want to configure it?
> 
> Eduard.
Hi Eduard,
I was just struck by your choice of phrase. It, in a way, expresses one
of the ideas behind Free software. The 'Where do you want to go today?'
phrase came to mind as one phrase that does't quite express Free
software because it says nothing about the user but his/her choice to
use a piece of software. But 'How do you want to configure it?' shows
the idea of the collaborative nature of Free software where user and
developer jointly decide the future and work together on it.
Cheers,
Kev
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!
  `$' $' 
   $  $  _
 ,d$$$g$  ,d$$$b. $,d$$$b`$' g$b $,d$$b
,$P'  `$ ,$P' `Y$ $$'  `$ $  "'   `$ $$' `$
$$ $ $$g$ $ $ $ ,$P""  $ $$
`$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$
 `Y$$P'$. `YP $$$P"' ,$. `Y$$P'$ $.  ,$.


signature.asc
Description: Digital signature

Re: A great weekend for Debian