Re: Uploading amd64 packages

[Ken Bloom]

Steve Langasek wrote:
> On Tue, Nov 22, 2005 at 08:13:23AM -0600, Ken Bloom wrote:
> 
>>Why not accept the AMD64 binaries, then dump the AMD64 binaries because
>>you don't know what to do with them, but accept the arch:all debs from
>>that upload?
> 
> 
> Why would ftp-master want to work on special-casing amd64 for this instead
> of just working on getting amd64 into the archive?

I honestly don't know.

--Ken Bloom

-- 
I usually have a GPG digital signature included as an attachment.
See http://www.gnupg.org/ for info about these digital signatures.


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

Re: dpkg-sig support wanted?

[Matthew Palmer]

On Wed, Nov 23, 2005 at 10:29:32AM +1100, Brian May wrote:
> I would speculate debsigs got a name change to dpkg-sig. Can somebody
> confirm or deny?

As Mark said, it's not a name change.  The FAQ on the dpkg-sig site
(http://dpkg-sig.turmzimmer.net/) has more info.

- Matt


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

Re: dpkg-sig support wanted?

[Marc 'HE' Brockschmidt]

Brian May <[EMAIL PROTECTED]> writes:
>> I've never seen dpkg-sig mentioned before, only debsigs,
>> so I'm not familiar with the tool itself, but the concept
>> is one that needs a lot more exposure.
> I would speculate debsigs got a name change to dpkg-sig. Can somebody
> confirm or deny?

No. dpkg-sig is a completly independent application (though some ideas
were taken from debsigs)

Marc
-- 
Fachbegriffe der Informatik - Einfach erklärt (120: INN 2.x)
   INN 2.x ist wie Fertig-Spaghetti aus der Tüte. Schmeckt lecker und ist im
   Grunde ganz einfach zuzubereiten. Trotzdem muß man ständig umrühren,
   damit's nicht anbrennt. (Andreas M. Kirchwitz)


pgppRAVozxPvv.pgp
Description: PGP signature

Re: dpkg-sig support wanted?

[Marc 'HE' Brockschmidt]

Heya,

After discussing this in IRC, we agreed that I give a short overview
about the important stuff. As I'm quite lazy, I'm quoting James Troup
for the history bits:

 was written for Ubuntu, specifically because they were activating
 data.tar.bz2 support in debs.  as a side effect it also enforced
 certain constraints on the layout of .ars simply becuase of the way the
 code was written.  this was tested on everything in ubuntu and didn't
 trip anything.  the code got ported to Debian shortly before the
 release of sarge 
 at that point, it became apparent it broke dpkg-sig signed debs.
 after various conversations, I disabled the check, because amongst
 other things making changes like that just prior to release probably
 wasn't clever.  however, I didn't sufficently comment WHY the check was
 deactivated in the code, I just said "till sarge is released" or
 similar
 which is my bad, and I apologize.  in any event, sarge has
 obviously been and gone, and the check got re-enabled as part of a
 cleanup of the code on sphor vs. cvs. 

Today, some people ranted in IRC about the fact that packages with
binary signatures were rejected again. As I believed that someone
activated these checks while knowing that they break packages with
binary signatures, I was pretty pissed off. I remembered the comment to
be something like "breaks dpkg-sig, deactivated for now", but the CVS [1]
shows that was wrong. Anyway, I want to apologize for carrying this to
-devel directly.

OK, now to the good parts: Joerg Jaspert planned to provide a better
version of the problematic check anyway (also validating the binary
signatures) and will try to finish them as soon as possible. I'll try to
be useful in respect to that, at least as useful as I can be. And now
we're all happy again. Yay!

Marc

Footnotes: 
[1]  http://cvs.debian.org/dak/jennifer?root=dak&r1=1.56&r2=1.57

-- 
BOFH #139:
UBNC (user brain not connected)


pgpARUHMfjp3A.pgp
Description: PGP signature

Re: dpkg-sig support wanted?

[Brian May]

> "Matthew" == Matthew Palmer <[EMAIL PROTECTED]> writes:

Matthew> I'm keenly interested in per-package signatures for
Matthew> Debian packages -- I think they're a great idea and it's
Matthew> a pity that they haven't received more interest.

Same here.

I would really like to see all packages signed, not just the source
code and not just the archive (if any) they came from.

I see advantages:

* ability to check downloaded binary package even if it no longer
  exists in latest archive.

* ability to trace the source of a binary package in a secure way,
  whether it was built by a maintainer, automatically built by an
  autobuilder (which one?), or built by some 3rd party.

  yes - I realize some people consider automatic signing by an
  autobuilder to be "insecure" - however I think it is more secure
  then not having any signature - when deciding on how much you trust
  it you need to take into account the source. Besides, I believe the
  archive is already signed automatically anyway.

* this can occur without trying to look up the *.changes file
  (assuming it still exists - for packages never uploaded to Debian,
  maybe not).

* others I am too lazy to think of.

Matthew> I've never seen dpkg-sig mentioned before, only debsigs,
Matthew> so I'm not familiar with the tool itself, but the concept
Matthew> is one that needs a lot more exposure.

I would speculate debsigs got a name change to dpkg-sig. Can somebody
confirm or deny?
-- 
Brian May <[EMAIL PROTECTED]>


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

Re: master's mail backlog and upgrade time

[Brian May]

> "Stephen" == Stephen Frost <[EMAIL PROTECTED]> writes:

>> So if I have my system say `250' to a piece of mail, I'm guaranteeing
>> that either I'll bounce it (and get a `250' on the bounce), or that
>> some human (me or someone else I know) will read it.

Stephen> Sure, so say '250' and then bounce it if you want to
Stephen> later.  That's basically the *point* here.  master's
Stephen> forwarding the mail for you, you should accept it and
Stephen> then you can decide to either read it yourself or bounce
Stephen> it.  You do *not* need master to bounce it for you!

Are you saying you should bounce SPAM mail???

Where do you bounce it to? The forged senders email address?

Alternatively, you could redirect the mail to >/dev/null, but then the
poster of a genuine email doesn't know his mail didn't get through.

Yes, in this case the mail would bounce anyway, but I think the
solution is to improve the SPAM checking on master, and not accept the
mail in the first place.

Yes, you could probably make mail from master.debian.org bypass SMTP
level SPAM controls, but taken to the extreme, you would have to also
do this to every server that forwards you email (perhaps even every
mailing list server?).
-- 
Brian May <[EMAIL PROTECTED]>


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

Re: too long to build 2.6.14.2 kernel

[Steinar H. Gunderson]

On Tue, Nov 22, 2005 at 10:54:26AM +, Andreas Orfanos wrote:
> My question is: Is this build time acceptable for the new kernels?
> Is something wrong with the tool chain? Distribution?

My question is: Is it a real problem? How often do you really compile your
kernels yourself with all the modules turned on, such as Debian does?

> I remember kernel builds where ultra fast, couldn't watch on
> screen what it was compiled.

2.4 used to spit out the entire command line while compiling. Try making with
V=1 to get the same effect on 2.6.

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


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

Re: too long to build 2.6.14.2 kernel

[Andreas Orfanos]

Yes! you are right.

I try to produce some statistical data with different kernels. The latest 2.4.32 takes
an average 6 minutes to build (~500 objects). But 2.6.0 takes more than
half an hour for (~3000objects and more). The latest 2.6.14.2 one hour and more,
and again we are talking for thousands of object files. I was using a 2GHz Pentium
for the builds.

Thank for your replies.
Andeas
On 11/22/05, Alexis Sukrieh <[EMAIL PROTECTED]> wrote:
Le mardi 22 novembre 2005 à 10:54 +, Andreas Orfanos a écrit :> The delay was not due to lots of new modules, it was clear that the> incremental list of compiled components on the screen was moving
> up slow. I remember kernel builds where ultra fast, couldn't watch on> screen what it was compiled.Hmmm, sounds like your are mixing 2.4.x and 2.6.x kernels. Since the 2.6branch, the generated output is much less verbose than it was with the
2.4 one.My out-of-topic point: if you want to boost your kernel cooking and youhave a couple of boxes around, give a try at `distcc' ;)--Alexis Sukrieh <[EMAIL PROTECTED]
>

Re: Uploading amd64 packages

[Steve Langasek]

On Tue, Nov 22, 2005 at 08:13:23AM -0600, Ken Bloom wrote:
> Why not accept the AMD64 binaries, then dump the AMD64 binaries because
> you don't know what to do with them, but accept the arch:all debs from
> that upload?

Why would ftp-master want to work on special-casing amd64 for this instead
of just working on getting amd64 into the archive?

-- 
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: How to use lsb init-functions

[Armin Berres]

Benjamin Mesing wrote:

Only a thought that occured to me when reading this: Did you think about
how your approach will work once the proposed parallel boot script
execution is implemented?


If you want to see how it could look like when you have scripts with 
parallel output you could have a look at Initng [1].
The output of the scripts will be buffered and the init system will 
handle the it in some non parallel way.


Regards,
Armin

[1] http://alioth.debian.org/projects/pkg-initng/


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

Re: too long to build 2.6.14.2 kernel

[Alexis Sukrieh]

Le mardi 22 novembre 2005 à 10:54 +, Andreas Orfanos a écrit :

> The delay was not due to lots of new modules, it was clear that the
> incremental list of compiled components on the screen was moving 
> up slow. I remember kernel builds where ultra fast, couldn't watch on
> screen what it was compiled.

Hmmm, sounds like your are mixing 2.4.x and 2.6.x kernels. Since the 2.6
branch, the generated output is much less verbose than it was with the
2.4 one.

My out-of-topic point: if you want to boost your kernel cooking and you
have a couple of boxes around, give a try at `distcc' ;)

-- 
Alexis Sukrieh <[EMAIL PROTECTED]>

Re: dpkg-sig support wanted?

[Matthew Palmer]

On Tue, Nov 22, 2005 at 04:50:02PM +0100, Marc 'HE' Brockschmidt wrote:
> As I'm responsible for most of dpkg-sig's code (and planned to do some
> more work in the next two months) I'd like to know if anyone cares about
> using these binary signatures or if I can invest my time into something
> that's a bit more satisfying (== non-Debian stuff).

I'm keenly interested in per-package signatures for Debian packages -- I
think they're a great idea and it's a pity that they haven't received more
interest.

I've never seen dpkg-sig mentioned before, only debsigs, so I'm not familiar
with the tool itself, but the concept is one that needs a lot more exposure.

- Matt


signature.asc
Description: Digital signature

Re: How to use lsb init-functions

[Henrique de Moraes Holschuh]

On Tue, 22 Nov 2005, Benjamin Mesing wrote:
> Only a thought that occured to me when reading this: Did you think about
> how your approach will work once the proposed parallel boot script
> execution is implemented?

It will be replaced by whatever is in the parallel system. So don't worry
too much about it.

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


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

Re: I am still on the keyring. With my old key.

[Andreas Schuldei]

* Marc Haber <[EMAIL PROTECTED]> [2005-11-21 23:33:48]:
> If the DPL team is actually addressing that issue, it is not doing so
> transparently. 

That was on purpose. we thought that there was something to be
learned from threads on public mailinglists that lead nowhere and
wanted to try private mail threads that lead nowhere, instead.
(c:

> Hence, to the mere mortal DD; nothing has changed since
> Branden's electrion, which is a real disappointment. At least to me.

Well, the process is not over yet, and has not produced the
results we want to see. I too am surprised to see such slow
progress. But as i wrote earlier in this thread i did not give up
hope yet. After all the involved individuals are sensible persons
but busy.  

Of course business is not a valid excuse for everything, even for
volunteers. If you are too busy to do your volunteer stuff you in
fact stopped volunteering some time ago...


signature.asc
Description: Digital signature

Re: I am still on the keyring. With my old key.

[Andreas Schuldei]

* Florian Weimer <[EMAIL PROTECTED]> [2005-11-22 08:52:25]:

> * Andreas Schuldei:
> 
> > i have not given up that hope yet and i invest a considerable
> > amount of time working on this issue as part of my work on the
> > DPL-Team. others there do so, too.
> 
> Is this the "delegation to teams" item on
> ?  A rather cryptic
> reference, IMHO.

yes, that was on purpose. there has been mails to/from the teams
about delegation and things go slow for various reasons.

I updated the above mentioned page to be a *bit* more verbose
about this.


signature.asc
Description: Digital signature

Re: BTS down?

[Don Armstrong]

On Tue, 22 Nov 2005, Bastian Venthur wrote:
> Don Armstrong wrote:
> > On Mon, 21 Nov 2005, Gregor Jasny wrote:
> >> Bastian Venthur schrieb:
> >> > Can somebody confirm that there is a problem with the BTS?
> >> 
> >> I've got the same setup and the same problem. Still no confirmation
> >> from bugs.debian.org.
> > 
> > The BTS is currently receiving mail properly and acting on it
> > properly, as near as I can tell.
> 
> Hmm strange, this was the first time I had any problems with the
> BTS. Is there a dummy-package like "foo" or "test" which exists only
> to test the BTS? If yes could you give me the name of it please?

No, there isn't. The BTS is (in general) working properly; the primary
question is whether or not the mail system between you and the BTS is
working properly. [If you want to just test things in general, feel
free to use the 'test' package on donbugs.donarmstrong.com.]


Don Armstrong

-- 
There is no mechanical problem so difficult that it cannot be solved
by brute strength and ignorance.
 -- William's Law

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


signature.asc
Description: Digital signature

Re: master's mail backlog and upgrade time

[Simon Richter]

Hi,

Darren Salt wrote:


There is a database where ISPs can register the ranges they assign for
dialup users.



Isn't that for dynamic-IP dial-up only?


AFAIK there are two lists, however only few static dialup IPs are 
registered -- after all, the interesting attribute is whether the 
addresses are dynamically assigned, not whether the network connection 
is intermittent (mail servers are supposed to handle that as a temporary 
error, while talking to the wrong server will lead to a 5xx and the mail 
bouncing).


   Simon


signature.asc
Description: OpenPGP digital signature

Re: master's mail backlog and upgrade time

[Darren Salt]

I demand that Simon Richter may or may not have written...

> Rolf Kutz wrote:
>>> emails because of obviously nonexistent envelope addresses, that doesn't
>>> count those systems where we don't accept mail from *at all* because they
>>> are dialup systems. This, however, is a small system with 10 email
>> How do you define dialup systems and tell dialup systems from other
>> systems?

> There is a database where ISPs can register the ranges they assign for
> dialup users.

Isn't that for dynamic-IP dial-up only?

-- 
| Darren Salt   | linux (or ds) at | nr. Ashington,
| sarge,| youmustbejoking  | Northumberland
| RISC OS   | demon co uk  | Toon Army
|   I don't ask for much, just untold riches...

I am Spock of Borg. Resistance is illogical.


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

Re: dpkg-sig support wanted?

[martin f krafft]

also sprach Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> [2005.11.22.1650 +0100]:
> As I'm responsible for most of dpkg-sig's code (and planned to do
> some more work in the next two months) I'd like to know if anyone
> cares about using these binary signatures or if I can invest my
> time into something that's a bit more satisfying (== non-Debian
> stuff). As the ftp-masters and the dpkg maintainers seem to have
> no interest in the whole thing, I'm beginning to doubt that it's
> sensible to work on dpkg-sig.

I fully support dpkg-sig and do not appreciate having to hear that
a decision was made without the giving the collective of developers
a chance to voice their opinions before.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"man soll nicht in kirchen gehn, wenn man reine luft atmen will."
 - friedrich nietzsche


signature.asc
Description: Digital signature (GPG/PGP)

Re: dpkg-sig support wanted?

[John Hasler]

Marc 'HE' Brockschmidt writes:
> I'd like to know if anyone cares about using these binary signatures

I do.
-- 
John Hasler


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

Re: I am still on the keyring. With my old key.

[Jaakko Niemi]

On Tue, 22 Nov 2005, Andreas Schuldei wrote:
> >  Get to next debconf and see him actually work with people.
> >  No need for words. 
> 
> did i beat someone up when i was watched? did it get caught on
> film, even? (c:

 ... where did the evidence go? :)

--j


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

Re: what does Enhances *really* mean?

[Henning Makholm]

Scripsit Peter Samuelson <[EMAIL PROTECTED]>

> I thought that Enhances is merely the converse of Suggests, and that it
> was invented for situations where it is problematic or inconvenient to
> use Suggests directly, as when a main package wishes to suggest a
> non-free package.

*I* thought it was okay for a main package to Suggest a non-free one.
Policy (§2.2.1) only forbids Depends, Recommends, and Build-Depends.

I suppose that Pre-Depends is also out (but just forgotten in the
policy), but the absense of Suggests in the list appears to be
deliberate.

> Since it *is* just a boolean, I'd rather see just a package tag.  If
> one didn't already exist, I would have suggested 'special::useless'.

One does already exist: 'special::auto-inst-parts'.

-- 
Henning Makholm   "We will discuss your youth another time."


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

Re: dpkg-sig support wanted?

[James Vega]

On Tue, Nov 22, 2005 at 05:41:05PM +0100, Petter Reinholdtsen wrote:
> 
> [Marc 'HE' Brockschmidt]
> > I'd like to know if anyone cares about using these binary signatures
> 
> I can not really say if I care or not, as I do not really know what
> these binary signatures are.  Care to send URL to pages explaining the
> topic?

As per 'apt-cache show dpkg-sig':

Website is http://dpkg-sig.turmzimmer.net/

James
-- 
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>


pgpEBswLX1uTA.pgp
Description: PGP signature

Re: I am still on the keyring. With my old key.

[Henning Makholm]

Scripsit Anand Kumria <[EMAIL PROTECTED]>
> On Mon, Nov 21, 2005 at 02:18:02AM +0100, Henning Makholm wrote:

>> If somebody designs and implements (after a suitable architectural
>> review) some software to support distributed keyring maintenance in a
>> secure, auditable way, it is likely that calls for adding more people
>> to the task would be considered more seriously.

> This is an interesting technical position but one that I think is
> incorrect.

On the contrary, you seem to be focusing on the _easy_ part of the
problem (which rules to use when taking the decision). The _hard_
part is to _implement_ the decision in a secure way once the rules
determine that the keyring should be updated.

> As I have indicated above, I do not believe the role of keyring-maint is
> to make *any* decision but to act upon the instructions of other parts
> of Debian (QA, DAM, tech-ctte, DPL(s), DDs via GR).

The core of the problem is not decision-making.

> Ideally the role of keyring-maint can be useful performed by a script

Strong disagreement. A function as sensitive and fundamental as
maintaining the authoritative _master copy_ of the Debian keyring
should not be left entirely to an unattended script. There must be
real people in the loop who can monitor the changes for unusual
patterns.

> but since the set of entities who could instruct the keyring-maint is
> large it would probably make sense to have a number of humans fronting
> that script.

Producing some software that *can* be fronted for by more than one
human without introducing unacceptable security risks is the problem
I'm pointing to.

-- 
Henning Makholm  "*Tak* for de ord. *Nu* vinker nobelprisen forude."


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

Re: dpkg-sig support wanted?

[Petter Reinholdtsen]

[Marc 'HE' Brockschmidt]
> I'd like to know if anyone cares about using these binary signatures

I can not really say if I care or not, as I do not really know what
these binary signatures are.  Care to send URL to pages explaining the
topic?


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

Re: How to use lsb init-functions

[Benjamin Mesing]

Only a thought that occured to me when reading this: Did you think about
how your approach will work once the proposed parallel boot script
execution is implemented?

Best regards Ben
-- 
Please do not sent any email to the [EMAIL PROTECTED] - all email not
originating from the mailing list will be deleted automatically. Use the
reply to address instead.


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

Re: How to use lsb init-functions

[Petter Reinholdtsen]

[Gabor Gombas]
> I'm thinking that it would be very useful to redirect stderr to a
> file (say /var/log/boot/.error). It happens far too often
> that the error message scrolls off the screen, then
> fonty/gdm/etc. starts making scrolling back impossible.

There are ideas to send boot messages to syslog (bootlogd does this,
but not very well), and it might be a better alternative then a
separate file.


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

Re: master's mail backlog and upgrade time

[Wouter Verhelst]

On Tue, Nov 22, 2005 at 10:57:27AM -0500, Stephen Frost wrote:
> * Wouter Verhelst ([EMAIL PROTECTED]) wrote:
> > I don't want to accept any random crap that a forwarding host might send
> > me just because I asked it to forward mail for me; my resources (in the
> > form of bandwidth, processing time, and disk space) are limited, and if
> 
> Then don't run a mail server.

That's not the way things work. My resources are _always_ limited, even
if I'd have a mailserver built out of the latest-and-greatest hardware
(which, granted, is not the case, but still).

It's unconsiderate for _any_ mail system to be sending mail to me of
which it's blindingly obvious that I wouldn't want to have it; and I'll
just reject it if that's the case.

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


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

Re: I am still on the keyring. With my old key.

[Andreas Schuldei]

* Jaakko Niemi <[EMAIL PROTECTED]> [2005-11-22 17:12:00]:

> On Mon, 21 Nov 2005, Thomas Bushnell BSG wrote:
> > Andreas Schuldei <[EMAIL PROTECTED]> writes:
> > > i have not given up that hope yet and i invest a considerable
> > > amount of time working on this issue as part of my work on the
> > > DPL-Team. others there do so, too.
> > 
> > I hope this is true.  I really do.  However, I have no particular
> > evidence that it is true.  Maybe you could explain in more detail?
> 
>  Get to next debconf and see him actually work with people.
>  No need for words. 

did i beat someone up when i was watched? did it get caught on
film, even? (c:


signature.asc
Description: Digital signature

Re: master's mail backlog and upgrade time

[Stephen Frost]

* Wouter Verhelst ([EMAIL PROTECTED]) wrote:
> I don't want to accept any random crap that a forwarding host might send
> me just because I asked it to forward mail for me; my resources (in the
> form of bandwidth, processing time, and disk space) are limited, and if

Then don't run a mail server.

Thanks,

Stephen


signature.asc
Description: Digital signature

dpkg-sig support wanted?

[Marc 'HE' Brockschmidt]

Heya,

Today (or last night, whatever), the dak installation on ftp-master was
changed to not accept packages that include more than 3 parts, which are
usually the binary version and the compressed control and data
tarballs. This means that signed binary packages are rejected.

This is not the first time that this change to the dak scripts was
activated. We had this problem for a few days some months ago, but the
change was reverted. There was no discussion about this issue (and why
signed binary packages need to be rejected) since then. There was no
warning or indication that this check would be activated again in the
last week.

As I'm responsible for most of dpkg-sig's code (and planned to do some
more work in the next two months) I'd like to know if anyone cares about
using these binary signatures or if I can invest my time into something
that's a bit more satisfying (== non-Debian stuff). As the ftp-masters
and the dpkg maintainers seem to have no interest in the whole thing,
I'm beginning to doubt that it's sensible to work on dpkg-sig.

Marc
-- 
Fachbegriffe der Informatik - Einfach erklärt
138: OSPF
   One Single Point of Failure (Pascal Gienger)


pgp3PbiBsGLFY.pgp
Description: PGP signature

Re: Spliting packages between pkg and pkg-data

[Ricardo Mones]

On Tue, 22 Nov 2005 10:11:45 +0100
Goswin von Brederlow <[EMAIL PROTECTED]> wrote:

> Ricardo Mones <[EMAIL PROTECTED]> writes:
> 
> >
> >   IMHO pkg-data package should also include an «Enhances: pkg» in
> > addition to the suggest. Both fields with some partial string
> > matching on the package names could make some frontend realize the
> > kind of relation between the packages.
> >
> >   regards,
> 
> I don't think that is very usefull. Enhances is to see what makes foo
> better. But foo depends on foo-data and there is no getting better by
> installing foo-data. It is required already. I think enhances should
> be left for optional stuff so frontends can present the user with a
> good list of extras without also listing requirements.

  I was thinking more in the opposite, foo doesn't depend on foo-data
(because is optional data, e.g. localization packages) and foo-data
depends on foo, the [*] addition below, which I think summarizes the
possibilities I've understood to avoid circular dependencies while
keeping some relation among packages:

   | foo  | foo-data
  -+--+-
  foo needs foo-data   | Depends: foo-data| Suggests: foo
  -+--+-
  foo may use foo-data | Recommends: foo-data | Depends: foo
  foo-data useless |  | Enhances: foo [*]
  without foo  |  |
  -+--+-
  foo may use foo-data | Recommends: foo-data | Suggests: foo
  foo-data useful  |  | Enhances: foo [*]
  without foo  |  |

  The Enhances would add an extra meaning to explain why foo-data
package is either Depending or Suggesting foo, which in these cases is
not the usual Depend meaning IMHO: the data doesn't really need
anything to work :)

  regards,

P.S.: Don't need to Cc: me, I'm subscribed to the lists where I post.
-- 
  Ricardo Mones 
  ~
  Physics is like sex: sure, it may give some practical results, but 
  that's not why we do it.Richard Feynman

Re: I am still on the keyring. With my old key.

[Jaakko Niemi]

On Mon, 21 Nov 2005, Thomas Bushnell BSG wrote:
> Andreas Schuldei <[EMAIL PROTECTED]> writes:
> > i have not given up that hope yet and i invest a considerable
> > amount of time working on this issue as part of my work on the
> > DPL-Team. others there do so, too.
> 
> I hope this is true.  I really do.  However, I have no particular
> evidence that it is true.  Maybe you could explain in more detail?

 Get to next debconf and see him actually work with people.
 No need for words. 

--j


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

Re: master's mail backlog and upgrade time

[Ian Jackson]

James Troup writes ("Re: master's mail backlog and upgrade time"):
> The change was made roughly less than 24 hours before your first post
> to debian-devel.  There wasn't actually all that much time to contact
> you in.

You (plural) could have _just_ contacted me and I would have fixed it,
as I have now done.  It's not like you don't know how to get hold of
me !  How hard is it to write a short mail ?  `master is having
difficulty talking to chiark; chiark seems to have firewalled master
out.  Please fix it ASAP'.  You would have had it sorted out, with
apology, straight away.

> Err, no you haven't [arranged matters].  In
> <[EMAIL PROTECTED]> posted
> on Sat, 19 Nov 2005 15:39:36 +, you've asked chiark users to
> individually change their config to ensure chiark won't DoS master.
> Until it's confirmed that all those users have done so, it's not fair
> to say master will not have any difficulty talking to chiark.

The problem with chiark becoming upset at master will not recur so
long as a majority of the traffic is to users who have been thus
reconfigured.  This is now the case (and I'm chasing up the few
stragglers).

> And this still relies on per-user config rather than being a global
> change.  Which means the next time a chiark user gets a debian.org
> account but neglects to perform the necessary incantation, master will
> once again be DoSed by chiark.

Doing it this way means that if and when the debian.org hosting
arrangments change (eg, the host that talks to chiark gets a different
reverse DNS name) the configuration will still work and it won't break
again.

It's only old forwarding arrangements that should have the problem -
new chiark users get clear instructions on what to do about mail
forwarding, and I'm sure that new debian.org users do too.

> > I also immediately notified debian-admin of these facts and have not had:
> 
> Err, no you didn't.  You mailed debian-devel, and THREE DAYS LATER
> mailed debian-admin.  That is not immediate.

I replied to Ryan directly, in response to his posting to d-d-a.
There was no other contact address given in his announcement.

> >  * Correction of the broken configuration on master
> 
> [EMAIL PROTECTED]:~$ grep chiark /etc/exim4/exim4.conf
> [EMAIL PROTECTED]:~$

Oh, thanks.

> And it's been like that for several days.

Oh!  Nice of someone to tell me so that I could watch my logs and
check that all was well.  As it turns out it wasn't because I had
underestimated the number of other users and the volume of their spam
flows.

> Speaking of doing better, could you please actually fix chiark?

I should apologise to you for causing trouble, of course.  So yes, I
am sorry that my system didn't like your system.

> Because it's STILL firewalling master

As I say, I've chased up some stragglers this morning about their
configuration and now the vast majority of the spam flow is marked so
that chiark likes getting crap, rather than getting annoyed about it.

This seem to be working as far as I can tell from here.

> > This situation is intolerable and must be rectified forthwith.
> 
> With all due respect, your attitude is intolerable and should be
> rectified forthwith.

I _am_ sorry to be such a pain about this but escalation seemed to be
the only way to get a response !

Ian.


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

Re: master's mail backlog and upgrade time

[Wouter Verhelst]

On Sat, Nov 19, 2005 at 01:56:25PM -0500, Stephen Frost wrote:
> * Ian Jackson ([EMAIL PROTECTED]) wrote:
> > So if I have my system say `250' to a piece of mail, I'm guaranteeing
> > that either I'll bounce it (and get a `250' on the bounce), or that
> > some human (me or someone else I know) will read it.
> 
> Sure, so say '250' and then bounce it if you want to later.  That's
> basically the *point* here.  master's forwarding the mail for you, you
> should accept it

No, that's not what you should do.

I don't want to accept any random crap that a forwarding host might send
me just because I asked it to forward mail for me; my resources (in the
form of bandwidth, processing time, and disk space) are limited, and if
a mail is more than obviously not legitimate (i.e., because the envelope
from doesn't even exist), then *I* don't want to spend more CPU time,
disk space, or bandwidth handling the message; I'll just say "thanks,
but no thanks". If that creates problems for master, and there are ways
to avoid those problems (other than by creating more problems for my
systems) then I'll happily implement those; but you won't force me to
accept any random crap you might send me just because your policies
aren't strict enough.

To push your example to the limit, you're suggesting that I should
accept whatever master sends me -- even if that would result in it
sending a constant stream of data to my home server of, say, 100Kbit/s.
To accomodate for such an amount of data, however, I'd need to upgrade
my mail server's disk, processor, and my home Internet connection --
which I'm not willing to do.

Granted, the above example is over the top; but it doesn't even have to
be that extreme. I'm currently nearly out of disk space on my main mail
server; the extra amount of mail that dropping SMTP-time checks would
result in would probably make my mailserver's disk overflow--and I don't
want to buy another hard disk just yet.

> and then you can decide to either read it yourself or
> bounce it.  You do *not* need master to bounce it for you!

If master accepts a mail, it should be prepared to bounce it if the mail
wasn't legitimate after all. If it isn't prepared to do so, it shouldn't
have accepted it in the first place!

> > The only practical solution to this problem in the modern environment
> > is to never accept mail that you don't want.  Unfortunately master's
> > policies make it impossible for me to arrange to do that.  I can do
> > what I can, though, and try to push the problem closer to the place
> > where it can be solved.
> 
> Blacklisting obviously has its own problems.

There are many more ways to rejecting mail at SMTP time than to start
blacklisting; additionally, provided one uses a serious blacklist,
blacklisting isn't likely to result in blocking one's own forwarding
host.

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


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

Re: How to use lsb init-functions

[Gabor Gombas]

On Tue, Nov 22, 2005 at 12:21:37PM +0100, Thomas Hood wrote:

> But the problem is that foo may produce output and this will break up the nice
> single-line format.  I don't mind deverting stdout to /dev/null, but I am
> reluctant to divert stderr to /dev/null and error messages will also break up
> formatting:

I'm thinking that it would be very useful to redirect stderr to a file
(say /var/log/boot/.error). It happens far too often that the
error message scrolls off the screen, then fonty/gdm/etc. starts making
scrolling back impossible.

Gabor

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


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

Re: Spliting packages between pkg and pkg-data

[Bill Allombert]

On Tue, Nov 22, 2005 at 03:15:50PM +0100, Gabor Gombas wrote:
> On Tue, Nov 22, 2005 at 09:48:53AM +0100, Goswin von Brederlow wrote:
> 
> > Aparently yes. Menu seems to be smart enough for that, see other
> > mails. Bad example, sorry. But manpages certainly aren't.
> 
> Well, being able to read the documentation (including the man page) of a
> binary without requiring the binary to be installed is a good thing
> IMHO. Especially for big and complex software that is likely to be
> split to pkg and pkg-data...

I would agree, but the statistical evidence are that most splitted
packages in fact are games containing a single executables and a single
manpage and tons of data.

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: Uploading amd64 packages

[Ken Bloom]

Goswin von Brederlow wrote:
> "=?iso-8859-15?Q?J=E9r=F4me_Marant?=" <[EMAIL PROTECTED]> writes:
> 
> 
>>I meantioned one solution. There is another possible one: source uploads.
>>And no, I don't think it would cause more breakages than nowdays because
>>uploading sources only doesn't meant packages have not been build on
>>our systems.
>>
>>-- 
>>Jérôme Marant
> 
> 
> There are some implementation details that someone would have to fix
> first:
> 
> 1. DAK refuses source uploads
> 
> 2. sources without debs get removed so a source only upload would
> remove itself potentialy before buildds supply debs
> 
> 3. source uploads would not build architecture all package. None of
> the buildds will and then they are missing.
> 
> 4. architecture all uploads are not possible so one would have to
> upload for e.g. i386 with just arch:all debs. But then the DAK would
> see that the source stoped building certain binaries (all arch: i386
> debs) wrongfully and create problems.
> 
> 
> So while theoretically source only uploads would be great practically
> there are problems. I sure hope patches would be welcome though.

Why not accept the AMD64 binaries, then dump the AMD64 binaries because
you don't know what to do with them, but accept the arch:all debs from
that upload?

--Ken Bloom

-- 
I usually have a GPG digital signature included as an attachment.
See http://www.gnupg.org/ for info about these digital signatures.


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

Re: Spliting packages between pkg and pkg-data

[Gabor Gombas]

On Tue, Nov 22, 2005 at 09:48:53AM +0100, Goswin von Brederlow wrote:

> Aparently yes. Menu seems to be smart enough for that, see other
> mails. Bad example, sorry. But manpages certainly aren't.

Well, being able to read the documentation (including the man page) of a
binary without requiring the binary to be installed is a good thing
IMHO. Especially for big and complex software that is likely to be
split to pkg and pkg-data...

Gabor

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


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

Re: what does Enhances *really* mean?

[Enrico Zini]

On Tue, Nov 22, 2005 at 01:07:25PM +0100, Andreas Barth wrote:
> * Peter Samuelson ([EMAIL PROTECTED]) [051122 12:58]:
> > I thought that Enhances is merely the converse of Suggests, and that it
> > was invented for situations where it is problematic or inconvenient to
> > use Suggests directly, as when a main package wishes to suggest a
> > non-free package.
> > In which case, of course, if "foo Depends: foo-data", then "foo-data
> > Enhances: foo" is already implied.
> Agreed.

What I suggest was not this case, but more like the case when a package
is something like a plugin of another (libapache2-mod-* and
phpgroupware-* are trivial examples, but there's more like gkrellm-*,
where the gkrellm "plugins" don't depend on gkrellm at all, or guessnet,
that could be used stand-alone but it make sense to group it as
something gravitating around the world of ifupdown).


Ciao,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: krb5: ABI Issue--confirm your packages work against 1.4.3 in experimental

[Tomas Pospisek]

On Sat, 19 Nov 2005, Sam Hartman wrote:


I'd appreciate it if you would take the time to see if your package
works against the new Kerberos library.  The easiest way to do this is
to build your package or at least the kerberos using parts of your
package against the new libkrb5-dev package and confirm there are no
warnings about missing prototypes and that your package can
successfully link to libkrb5.


Mailsync at least links fine against the new libkrb5. Since I don't have 
access to a kerberos environment I however can't test if it also does

fine at runtime.

Thanks,
*t

--

  Tomas Pospisek
  http://sourcepole.com -  Linux & Open Source Solutions



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

Re: too long to build 2.6.14.2 kernel

[Peter Samuelson]

[Andreas Orfanos]
> I hope I post this to the right list.

debian-user is probably the right list, actually.

> The delay was not due to lots of new modules, it was clear that the
> incremental list of compiled components on the screen was moving up
> slow. I remember kernel builds where ultra fast, couldn't watch on
> screen what it was compiled.

My guess is that you used a different compiler last time.
Specifically, gcc-2.95 is much faster than any newer gcc version,
although I understand the 4.x series promises to regain some of that
lost efficiency.


signature.asc
Description: Digital signature

Re: what does Enhances *really* mean?

[Andreas Barth]

* Peter Samuelson ([EMAIL PROTECTED]) [051122 12:58]:
> I thought that Enhances is merely the converse of Suggests, and that it
> was invented for situations where it is problematic or inconvenient to
> use Suggests directly, as when a main package wishes to suggest a
> non-free package.
> 
> In which case, of course, if "foo Depends: foo-data", then "foo-data
> Enhances: foo" is already implied.

Agreed.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

what does Enhances *really* mean?

[Peter Samuelson]

[Enrico Zini]
> My hope is that if more people start to use it, then package managers
> can start building features with it.

I thought that Enhances is merely the converse of Suggests, and that it
was invented for situations where it is problematic or inconvenient to
use Suggests directly, as when a main package wishes to suggest a
non-free package.

In which case, of course, if "foo Depends: foo-data", then "foo-data
Enhances: foo" is already implied.

What you're suggesting is that Enhances take on a new meaning: "package
has no functionality, so should only be installed as a dependency".
But that meaning is really boolean, it does not require a target
package.  The dependency graph already knows the target package.

Since it *is* just a boolean, I'd rather see just a package tag.  If
one didn't already exist, I would have suggested 'special::useless'.


signature.asc
Description: Digital signature

too long to build 2.6.14.2 kernel

[Andreas Orfanos]

Hi,



I hope I post this to the right list.



Last night I tried to build the latest version of Linux kernel 2.6.14-2, 

on my Debian 3.1. It took me around one hour to build.  I did the 

build on a system with a Pentium M at 2GHz. I tried also on another

machine (3GHz) and it was a few minutes quicker.



However, my last build on 2.6.x versions was one year ago 

was significantly faster. I was using SuSe 9.2 at that time.



My question is: Is this build time acceptable for the new kernels?

Is something wrong with the tool chain? Distribution?



The delay was not due to lots of new modules, it was clear that the

incremental list of compiled components on the screen was moving 

up slow. I remember kernel builds where ultra fast, couldn't watch on

screen what it was compiled.



Thanks

Andreas

Not delete symlinks to directories in /var/run/ ?

[Thomas Hood]

[Please forgive the duplicate, but I first sent this with a useless
Subject line.]

debian-devel readers: There is a proposal (#272066) that bootclean.sh's
cleanrun function not delete symlinks under /var/run/ whose targets are
directories.  The function already refrains from deleting directories.
Any objections?  Please reply to [EMAIL PROTECTED], not to the list.

Cameron Hutchison wrote to #272066:
> This should do it. It uses the -xtype find(1) predicate. I'm not sure if
> that's GNU only and if so, whether it is allowed in an initscript.
> 
> --- /etc/init.d/bootclean.sh  2005-01-05 10:27:40.0 +1100
> +++ /tmp/bootclean.sh 2005-11-22 09:27:46.105703939 +1100
> @@ -90,7 +90,7 @@
>  
>   [ "$VERBOSE" != no ] && echo -n " /var/run"
>   ( cd /var/run && \
> - find . ! -type d ! -name utmp ! -name innd.pid \
> + find . ! -type d ! -xtype d ! -name utmp ! -name innd.pid \
>   -exec rm -f -- {} \; )
>   rm -f /var/run/.clean
>   set -o noclobber


"! -type d" matches everything (including symbolic links) except directories.
"! -xtype d" in the absence of "-L" matches everything except directories
and symbolic links to directories.  Thus IIUC the latter eliminates the need
for the former.

I am cc:ing this to debian-devel in order to solicit opinions.
Please reply to [EMAIL PROTECTED], not to the list.
-- 
Thomas Hood


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

How to use lsb init-functions

[Thomas Hood]

In trying to convert the initscripts in the "initscripts" package to use
the logging functions in /lib/lsb/init-functions I have run into some
problems.

Currently there are two sets of functions intended to implement the several
kinds of messages normally output by Debian and Ubuntu initscripts.  The
first is for reporting the starting and stopping of services:

log_daemon_msg "Foo" "bar" ; log_progress_msg "baz" ; log_end_msg 0

Debian: Foo: bar baz.

Ubuntu: * Foo bar  [ ok ]

The second is for reporting actions to be taken:

log_action_msg "Foo"

Debian: Foo.

Ubuntu: * Foo

The third is for reporting actions to be taken and their completion:

log_action_begin_msg "Foo" ; log_action_cont_msg "bar" ; log_action_end_msg 0

Debian: Foo...bar...done.

Ubuntu: * Foo...
* bar...   [ ok ]

In addition there is a function for reporting success:

log_success_msg "Foo"

Debian:Foo

Ubuntu:* Foo

one for reporting failure:

log_failure_msg "Foo"

Debian:* Foo   [asterisk is red]

Ubuntu:* Foo   [asterisk is red]

and a function for warning:

log_warning_msg "Foo"

Debian:* Foo   [asterisk is amber]

Ubuntu:* Foo   [asterisk is amber]

Finally there is a log_begin_msg which seems to be obsolete.

Now my question.  Suppose I have a script that does something and I want to do
the following:

* Report that foo will be done
* Do foo
* Report that foo has now been done

I am supposed to do:

log_action_begin_msg "Will do foo"
foo
log_action_end_msg $?

But the problem is that foo may produce output and this will break up the nice
single-line format.  I don't mind deverting stdout to /dev/null, but I am
reluctant to divert stderr to /dev/null and error messages will also break up
formatting:

Debian:Foo...ERROR
   failed.   [in red]

Ubuntu:* Foo...
   ERROR
  [fail][in red]

It seems that in many cases we will have to adopt the following schema:

log_action_msg "Will do foo"
if foo ; then log_success_msg "Done foo." ; else log_failure_msg "Foo 
failed." ; fi

Is this what I should do, or is there another solution I am overlooking; or
do we need more functions; or does the whole system need to be reworked?
-- 
Thomas Hood


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

Re: Bug#272066: Patch?

[Thomas Hood]

debian-devel readers: There is a proposal (#272066) that bootclean.sh's
cleanrun function not delete symlinks under /var/run/ whose targets are
directories.  The function already refrains from deleting directories.
Any objections?  Please reply to [EMAIL PROTECTED], not to the list.

Cameron Hutchison wrote to #272066:
> This should do it. It uses the -xtype find(1) predicate. I'm not sure if
> that's GNU only and if so, whether it is allowed in an initscript.
> 
> --- /etc/init.d/bootclean.sh  2005-01-05 10:27:40.0 +1100
> +++ /tmp/bootclean.sh 2005-11-22 09:27:46.105703939 +1100
> @@ -90,7 +90,7 @@
>  
>   [ "$VERBOSE" != no ] && echo -n " /var/run"
>   ( cd /var/run && \
> - find . ! -type d ! -name utmp ! -name innd.pid \
> + find . ! -type d ! -xtype d ! -name utmp ! -name innd.pid \
>   -exec rm -f -- {} \; )
>   rm -f /var/run/.clean
>   set -o noclobber


"! -type d" matches everything (including symbolic links) except directories.
"! -xtype d" in the absence of "-L" matches everything except directories
and symbolic links to directories.  Thus IIUC the latter eliminates the need
for the former.

I am cc:ing this to debian-devel in order to solicit opinions.
Please reply to [EMAIL PROTECTED], not to the list.
-- 
Thomas Hood


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

Re: removal syncing among "official" and amd64 archive

[Goswin von Brederlow]

Stefano Zacchiroli <[EMAIL PROTECTED]> writes:

> On Sat, Nov 19, 2005 at 06:42:15PM +0100, Goswin von Brederlow wrote:
>> [EMAIL PROTECTED]:/org/amd64.debian.net$ madison editex
>> editex |0.0.5-6 |stable | source
>> editex |0.0.5-6 |  unstable | source
>> 
>> As you can see editex is already removed from etch since Heidi syncs
>> are instantaneous.
>
> Ok, so there is some out-of-syncing somewhere else:
>
>   
> http://packages.debian.org/cgi-bin/search_packages.pl?keywords=editex&searchon=names&subword=1&version=all&release=all
>
> editex is listed as available on unstable only for the amd64
> architecture.

Yes, unstable syncs the override files and removals need some
ftp-master interaction. Afaik the DAK sends a mail about possible
removal commands and the ftp-master has to cut&paste them if they are
corret.

Testing syncs on the other hand are done via Heidi. The amd64
'britney' just clones the source versions Debian has in testing and
moves the same versions into testing for amd64 (or out of it on
removal).

So you should never ever see a difference in testing while unstable
should only have short term differences.

The amd64 ftp-masters have been prodded about it so hopefully it
resolves itself anytime soon[tm].

MfG
Goswin


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

Re: Spliting packages between pkg and pkg-data

[Goswin von Brederlow]

Ricardo Mones <[EMAIL PROTECTED]> writes:

>
>   IMHO pkg-data package should also include an «Enhances: pkg» in
> addition to the suggest. Both fields with some partial string matching
> on the package names could make some frontend realize the kind
> of relation between the packages.
>
>   regards,

I don't think that is very usefull. Enhances is to see what makes foo
better. But foo depends on foo-data and there is no getting better by
installing foo-data. It is required already. I think enhances should
be left for optional stuff so frontends can present the user with a
good list of extras without also listing requirements.

MfG
Goswin


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

Re: Spliting packages between pkg and pkg-data

[Goswin von Brederlow]

Thijs Kinkhorst <[EMAIL PROTECTED]> writes:

> On Mon, 2005-11-21 at 16:26 +0100, Goswin von Brederlow wrote:
>> foo depends on foo-data. But foo-data does NOT depend on foo.
>> 
>> So an "apt-get install foo-data", while being useless, is consistent
>> for dpkg. After that you would end up with a menu entry for foo but no
>> foo binary.
>
> If package foo-data is useless when foo is not installed, foo-data
> should depend on package foo. This follows from policy manual 7.2: "The
> Depends field should be used if the depended-on package is required for
> the depending package to provide a significant amount of
> functionality.". Or am I missing something here?
>
> Thijs

What functionality does the foo-data package loose if you purge foo?
Does "less /usr/share/foo/textfile" or "qiv /usr/share/foo/image"
suddenly stop working?

On the other hand, what functionality does foo loose if foo-data is
missing?

You can't have both depending on the other without causing a depends
loop, which is bad and easily causes install/purge failures. Think
about which dependency ensures a working binary to the user and which
only means the installation makes sense.

MfG
Goswin


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

Re: Spliting packages between pkg and pkg-data

[Goswin von Brederlow]

Daniel Burrows <[EMAIL PROTECTED]> writes:

> On Mon, Nov 21, 2005 at 04:26:34PM +0100, Goswin von Brederlow <[EMAIL 
> PROTECTED]> was heard to say:
>> Nicolas Boullis <[EMAIL PROTECTED]> writes:
>> 
>> > On Sun, Nov 20, 2005 at 12:13:48PM +0100, Bill Allombert wrote:
>> >> Hello Debian developers,
>> >> 
>> >> When doing research about circular-deps, I looked at a lot of packages
>> >> that are split between a binary package and a data package. This is a
>> >> good thing since this reduce the total siez of the archive, however
>> >> there are simple rules that should be followed:
>> >> 
>> >> 3) Keep the files that 'signal' executables in the same package than the
>> >>executable (e.g. menu file, program manpage).
>> >
>> > Why? I agree that it menu files and manpages are generally not that 
>> > large, but what would it break to have them in pkg-data?
>> > (I would consider it strange to have such files out of the main pkg 
>> > package, but it looks policy-compliant as far as I can see...)
>> >
>> >
>> > Nicolas
>> 
>> foo depends on foo-data. But foo-data does NOT depend on foo.
>> 
>> So an "apt-get install foo-data", while being useless, is consistent
>> for dpkg. After that you would end up with a menu entry for foo but no
>> foo binary.
>
>   Shouldn't menu refuse to create menu entries for "foo" if the foo package
> is not installed?  At least, I thought that's what
>
> ?package(foo): ...
>
>   meant.
>
>   Daniel

Aparently yes. Menu seems to be smart enough for that, see other
mails. Bad example, sorry. But manpages certainly aren't.

MfG
Goswin


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

Re: BTS down?

[Bastian Venthur]

Don Armstrong wrote:

> On Mon, 21 Nov 2005, Gregor Jasny wrote:
>> Bastian Venthur schrieb:
>> > Can somebody confirm that there is a problem with the BTS?
>> 
>> I've got the same setup and the same problem. Still no confirmation
>> from bugs.debian.org.
> 
> The BTS is currently receiving mail properly and acting on it
> properly, as near as I can tell.

Hmm strange, this was the first time I had any problems with the BTS. Is
there a dummy-package like "foo" or "test" which exists only to test the
BTS? If yes could you give me the name of it please?


> 
>> Is there another possibility to report bugs (i.e. a web page) than
>> reportbug? Is my bugreport lost?
> 
> Just use reportbug; if necessary, point it directly at
> bugs.debian.org.

This is exactly what I did, but it did not work.

>   
> If you give me the precise message ID and the time of your message, I
> may be able to track it down if it ever actually reached spohr.

Sorry, don't have it anymore.


Regards,

Bastian


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