Bug#369328: ITP: phpmybibli -- Library managment system

[Vincent Danjean]

Package: wnpp
Severity: wishlist
Owner: Vincent Danjean <[EMAIL PROTECTED]>

* Package name: phpmybibli
  Version : 2.1.24
  Upstream Author : [EMAIL PROTECTED]
* URL : http://www.pizz.net/index_logiciel.php
* License : CeCILL
  Programming Lang: php
  Description : Library managment system

PhpMyBibli (PMB) is a php application that allows to manage a library
(list of available books, readers, lent, ...). PMB can be used either
for small personnal collections or even for big libraries. It supports
the UNIMARC norm, the 995 recommandation and it is able to import
notices from BDP (an other library managment system).

Note:
  CeCILL is a french license (ie wrote in french for french laws) whose
aims to be compliant with french laws and with the GPL. More information
can be found here:
http://www.cecill.info/index.en.html

Note (bis):
  Most of the web site and the documentation of phpmybibli are in
french. I would welcome any translators (for the description, the
documentation, ...)

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-rc3-686
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)


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

Re: Bug#369257: remote bug tracking system doesn't look at versions

[Pierre Habouzit]

Le Lun 29 Mai 2006 03:40, Matthias Klose a écrit :

> the only thing that is correct. is the syntax. everything else is
> wrong. the messages should have been generated for gcc-snapshot (if
> at all), but not for 4.1.

debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=356569
is about gcc-4.1, look at it. if it should be about gcc-snapshot, then 
please triage your own bugs the right way.


> > 2) While I can do so, adding administrative prohibitions over
> > something which should be worked out between the GCC maintainers
> > and the btslink maintainers is not something that I'm going to do
> > as an initial step.
>
> that's difficult, emails to to
> [EMAIL PROTECTED] are automatically rejected,
> if you're not subscribed. I really do not intend to subscribe to each
> system / ML, which sends bogus control messages.

that has been fixed, I wanted to do it before, and forgot about it I'm 
sorry. I remind that the first line of bts-link is a link to D-D-A 
where my own debian adress lies.

next mails will be sent with a reply-to on the bts-link-devel@ Mail 
List.


> > What problems with the information in the BTS are you talking
> > about?
>
> the usertags, which are wrongly set and removed.

oh, that's new, since when, usertags of user *BTS-LINK-UPSTREAM*, and 
that have their own semantics, which is clear like I already said to 
you: bts-link-upstream tags are tags that tracks upstream 
STATUS/RESOLUTION. and I'm sorry but http://gcc.gnu.org/PR26757 has:
 * Status REOPENED => usertag status-REOPENED
 * Resolution None => no resolution usertag

> please don't get me wrong; generally the btslink information is
> useful, but I do see the BTS maintainers in charge as well, if the
> system is "misused". we did see this in the past with unreflected
> changes of the forwarded information, now with wrong usertags. what
> comes next?

please don't get me wrong, but even if that was an abuse, BTS 
maintainers have nothing to do with it. I repeat for the third and last 
time, for bug reports/improvements/whishes, please contact me (or 
better [EMAIL PROTECTED]). I'm sorry bts-link is 
not in the BTS, but I should package related tools soon so that there 
will be one, and a place in the BTS to send bugs to.



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


pgpaJSTqaKm9k.pgp
Description: PGP signature

Re: Bug#369257: remote bug tracking system doesn't look at versions

[Pierre Habouzit]

Le Lun 29 Mai 2006 07:50, Thomas Bushnell BSG a écrit :
> Steve Langasek <[EMAIL PROTECTED]> writes:

> > Um... usertags have user-defined semantics.  How can you claim that
> > the usertags being set are wrong?
>
> As I understand it, the complaint is that bts-link is changing user
> tags set by the maintainer.

then if that's true (which is not obviously), he is complaining about me 
changing *my* own usertags. He should use another user for his tags. 
But honnestly, if you want to know what's wrong (AIUI), it's that:

the debian bug is assigned to gcc-4.1, and has been reopened upstream 
for gcc-snapshot or sth similar. and Matthias is wining because I 
didn't understood it ???

I should have a web page written about bts-link, I know, but its 
behaviour is not magical. He sends his updates mails to the 
$(source_package) the bug is assigned to. Sorry for Matthias, but the 
debian bug of which I updated the metadata *IS* a gcc-4.1 bug, and 
there is no behaviour problem in bts-link.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp0PrwnzxJEG.pgp
Description: PGP signature

Bug#369257: marked as done (remote bug tracking system doesn't look at versions)

[Debian Bug Tracking System]

Your message dated Mon, 29 May 2006 09:01:54 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Bug#369257: remote bug tracking system doesn't look at versions
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: bugs.debian.org
Severity: serious

this bug is fixed for 4.1; with these changes you invalidate the
information kept in the Debian BTS. Please fix it, or stop it.

If you do want to do it correct, you have to keep information, which
package is built from which branch.

[EMAIL PROTECTED] writes:
> #
> # bts-link upstream status pull for source package gcc-4.1
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> #
> 
> user [EMAIL PROTECTED]
> 
> # remote status report for #356569
> #  * http://gcc.gnu.org/PR26757
> #  * remote status changed: NEW -> REOPENED
> usertags 356569 - status-NEW
> usertags 356569 + status-REOPENED
> 
> thanks

--- End Message ---
--- Begin Message ---
Le Lun 29 Mai 2006 03:40, Matthias Klose a écrit :

> the only thing that is correct. is the syntax. everything else is
> wrong. the messages should have been generated for gcc-snapshot (if
> at all), but not for 4.1.

debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=356569
is about gcc-4.1, look at it. if it should be about gcc-snapshot, then 
please triage your own bugs the right way.


> > 2) While I can do so, adding administrative prohibitions over
> > something which should be worked out between the GCC maintainers
> > and the btslink maintainers is not something that I'm going to do
> > as an initial step.
>
> that's difficult, emails to to
> [EMAIL PROTECTED] are automatically rejected,
> if you're not subscribed. I really do not intend to subscribe to each
> system / ML, which sends bogus control messages.

that has been fixed, I wanted to do it before, and forgot about it I'm 
sorry. I remind that the first line of bts-link is a link to D-D-A 
where my own debian adress lies.

next mails will be sent with a reply-to on the bts-link-devel@ Mail 
List.


> > What problems with the information in the BTS are you talking
> > about?
>
> the usertags, which are wrongly set and removed.

oh, that's new, since when, usertags of user *BTS-LINK-UPSTREAM*, and 
that have their own semantics, which is clear like I already said to 
you: bts-link-upstream tags are tags that tracks upstream 
STATUS/RESOLUTION. and I'm sorry but http://gcc.gnu.org/PR26757 has:
 * Status REOPENED => usertag status-REOPENED
 * Resolution None => no resolution usertag

> please don't get me wrong; generally the btslink information is
> useful, but I do see the BTS maintainers in charge as well, if the
> system is "misused". we did see this in the past with unreflected
> changes of the forwarded information, now with wrong usertags. what
> comes next?

please don't get me wrong, but even if that was an abuse, BTS 
maintainers have nothing to do with it. I repeat for the third and last 
time, for bug reports/improvements/whishes, please contact me (or 
better [EMAIL PROTECTED]). I'm sorry bts-link is 
not in the BTS, but I should package related tools soon so that there 
will be one, and a place in the BTS to send bugs to.



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


pgpNG2pdliVYv.pgp
Description: PGP signature
--- End Message ---

Re: [Debconf-discuss] list of valid documents for KSPs

[Henning Makholm]

Scripsit Manoj Srivastava <[EMAIL PROTECTED]>

> I see you have never been in a large key signing party.  There
>  is a certain expectation of trust, since no one can actrually detect
>  delibrate forgeries.

If a key-signing method needs any particularly trustworthy behavior
from the people asking to have keys signed, it is broken, plan and
simple. It was broken from day one, and it becomes neither more nor
less broken because anybody in particular does not behave according to
the rule.

The entire _point_ of the web-of-trust is to not take people's claim
about their identity at face value. It is a process rooted in
_distrust_ and if the mechanisms end up with certified trust where
none is warranted, the mechanisms are at fault.

You seem to think that key-signing parties only work if all
participants are honest. That may be so, but if all participants ARE
honest, key-signing in general would be pointless. If the parties do
not work in the presense of dishonest participants they are completely
broken, serve no useless purpose, and might as well be abandoned.

This is true whether or not any precense of dishonest participants
have been speculated or confirmed, and if it is true after Martins
experiment, it was equally true before it.

>  There items I used to check on were the photograph, seplling of the
>  name, expiration date for the document, and, optionally, age.

If you do your checks on a way that assume honesty on the signee's
part, then your checks are broken. When you sign keys you should
_assume_ that the unknown person who wants you to sign a key is
dishonest about who he claims to be, and only sign if you see
something that positively convince you otherwise.

>  -- since good faith expectations were that people were not
>  trying to game the system.

Good faith expectations have absolutely no place in a system that is
based on distrusting people and demanding proof of their claims.

> If people start bringing in forged documents,  no amount of
>  caution on part of laypeople like most software developers is proof
>  against such deception.

Correct. If you think the system depends on people being honest in the
first place, the system has no conceivable useful purpose.

-- 
Henning Makholm "Nemo enim fere saltat sobrius, nisi forte insanit."


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

Uploading packages built against testing? (was: openssl will block bacula into etch?)

[Frank Küster]

Andreas Metzler <[EMAIL PROTECTED]> wrote:

>> Hmm.  But openssl is in testing already, and bacula doesn't build-dep
>> on a newer version.  Why does it matter?
>
> The *binary* packages require a newer version of openssl, they would
> be uninstallable in testing.
>
> http://packages.debian.org/unstable/admin/bacula-sd
> | libssl0.9.8 (>= 0.9.8a-1) [m68k]
> | SSL shared libraries
> | libssl0.9.8 (>= 0.9.8b-1) [not m68k]
> | SSL shared libraries
>
> testing has libssl0.9.8 0.9.8a-8

Would it be acceptable to build bacula (or any other package with that
problem) in an etch environment, or on sid with manually installed
libssl from etch, and upload that to unstable?  After checking that it
works in unstable, of course.

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

Re: not running depmod at boot time

[Eduard Bloch]

#include 
* Jörg Sommer [Sat, May 27 2006, 10:59:39PM]:

> > No, they don't. At least my packages call it only if `uname -r` ==
> > target version. When you drop the depmod run, and someone installs a new
> > kernel together with accompanying module packages and only THEN reboots,
> > the modules.dep* files won't be updated.
> 
> Why the kernel does not run depmod? Either the modules package or the
> kernel package is the last one. Marco had explained in one of his mails
> how to run depmod for a kernel version != `uname -r`. Why this does not
> work for you?
> 
> Good night, Jörg.

Causality?! Because it was an answer to the same message that you quote?!

Eduard.


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

Re: Making init scripts use dash

[Ralf Wildenhues]

Sorry for the late message to this thread.

* Gabor Gombas wrote:
> On Sat, May 20, 2006 at 01:58:14AM +0200, Adam Borowski wrote:
> > Thus, it's bash's start-up which is the slow part, in the terms of
> > actual speed, bash is not that far behind.
> 
> It would be interesting to compare something more complex than
> "configure" scripts. "configure" scripts are huge but primitive.

FWIW, libtool scripts are a bit more complex.  Unrelated though,
Libtool records the shell and its features; if you change /bin/sh
from bash to dash, the installed /usr/bin/libtool will have its
$echo setting wrong, and break occasionally.  dash will be a slight
disadvantage for libtool scripts because it will call an external
echo; but not much.

OTOH in some cases, new bash can really help[1].

Cheers,
Ralf

[1] http://lists.gnu.org/archive/html/libtool-patches/2006-05/msg00016.html


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

Re: Uploading packages built against testing? (was: openssl will block bacula into etch?)

[Marc Haber]

On Mon, 29 May 2006 10:27:45 +0200, Frank Küster <[EMAIL PROTECTED]>
wrote:
>Would it be acceptable to build bacula (or any other package with that
>problem) in an etch environment, or on sid with manually installed
>libssl from etch, and upload that to unstable?

No, that won't fix the problem for the packages built on buildds.

Greetings
Marc

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

Re: Uploading packages built against testing? (was: openssl will block bacula into etch?)

[Mark Brown]

On Mon, May 29, 2006 at 10:27:45AM +0200, Frank K?ster wrote:

> Would it be acceptable to build bacula (or any other package with that
> problem) in an etch environment, or on sid with manually installed
> libssl from etch, and upload that to unstable?  After checking that it
> works in unstable, of course.

That wouldn't help unless you uploaded for all architectures: the
buildds would build against unstable (there are other problems with
doing this too - see the list archives).

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


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

Re: Uploading packages built against testing?

[Florian Weimer]

* Mark Brown:

> On Mon, May 29, 2006 at 10:27:45AM +0200, Frank K?ster wrote:
>
>> Would it be acceptable to build bacula (or any other package with that
>> problem) in an etch environment, or on sid with manually installed
>> libssl from etch, and upload that to unstable?  After checking that it
>> works in unstable, of course.
>
> That wouldn't help unless you uploaded for all architectures: the
> buildds would build against unstable (there are other problems with
> doing this too - see the list archives).

But an upload to testing-proposed-updates (with a suitable version
number) could fix it for the architectures you are interested in.


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

Re: Bug#369257 closed by Pierre Habouzit <[EMAIL PROTECTED]> (Re:Bug#369257: remote bug tracking system doesn't look at versions)

[Pierre HABOUZIT]

On Mon, May 29, 2006 at 12:11:17PM +0200, Matthias Klose wrote:
> Debian Bug Tracking System writes:
> > Le Lun 29 Mai 2006 03:40, Matthias Klose a =E9crit :
> > 
> > > the only thing that is correct. is the syntax. everything else is
> > > wrong. the messages should have been generated for gcc-snapshot (if
> > > at all), but not for 4.1.
> > 
> > debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=356569
> > is about gcc-4.1, look at it. if it should be about gcc-snapshot, then
> > please triage your own bugs the right way.
> 
> please re-read it; you're just wrong. the status changes are about
> trunk, *not* 4.1. You currently assume that each upstream status
> change affects the Debian package as well, which is wrong.

  that's your work to do. bts-link only follows remote bugs status
change. I've no way to know the bug has been reopened because it's a
problem of another branch. If that's the case, the "right" way to do it
is either to reassign the bug, or to clone/close it.

  I use the fact that the debian bug is about gcc-4.1 because it's
*ASSIGNED* to gcc-4.1 in the BTS. if that is not accurate, then fix it.

  I will soon write a web page on http://bts-link.alioth.debian.org/ to
explain what bts-link does and does not. it *do not* triages bugs for
you, it only *synchronize* remote bugs status into the BTS. assigning
bugs to the right package, ensuring that the bug is *really* fixed like
upstream claims it is, ... remains of the responsability of the
maintainer. No automated tool can be trusted for such tasks.

  and again, the bts-link usertags are used as a database of the current
remote states.

 ---

  so a correct summary is that: bts-link sent a status change for a gcc
bug that apply to gcc-snapshot to [EMAIL PROTECTED] instead,
because the debian bug linked to the previous is assigned to gcc-4.1. If
that's correct, then well, sorry, bts-link sadly cannot replace
maintainers. I suppose that what you want is:

  $> bts assign 356569 gcc-snapshot

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


signature.asc
Description: Digital signature

Bug#369257: closed by Pierre Habouzit <[EMAIL PROTECTED]> (Re: Bug#369257: remote bug tracking system doesn't look at versions)

[Matthias Klose]

Debian Bug Tracking System writes:
> Le Lun 29 Mai 2006 03:40, Matthias Klose a =E9crit :
> 
> > the only thing that is correct. is the syntax. everything else is
> > wrong. the messages should have been generated for gcc-snapshot (if
> > at all), but not for 4.1.
> 
> debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D356569
> is about gcc-4.1, look at it. if it should be about gcc-snapshot, then=20
> please triage your own bugs the right way.

please re-read it; you're just wrong. the status changes are about
trunk, *not* 4.1. You currently assume that each upstream status
change affects the Debian package as well, which is wrong.

> please don't get me wrong, but even if that was an abuse, BTS=20
> maintainers have nothing to do with it. I repeat for the third and last=20
> time, for bug reports/improvements/whishes, please contact me (or=20
> better [EMAIL PROTECTED]). I'm sorry bts-link is=20
> not in the BTS, but I should package related tools soon so that there=20
> will be one, and a place in the BTS to send bugs to.

it's certainly easier now that a valid address is set. thanks for
fixing it.

  Matthias


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

Re: [Debconf-discuss] list of valid documents for KSPs

[Wouter Verhelst]

On Sun, May 28, 2006 at 11:12:16PM -0500, Manoj Srivastava wrote:
> So, once someone acts in bad faith, I can't trust anything
>  else they say: How do I know it is not a hoax within a hoax to see
>  how gullible people are, to accept that the papers presented were not
>  faked, or outright forgeries?

Yes, that's a good question: how can you be sure where the truth lies?

Answer: you can't. There is no way to be 100% sure. You have to make a
reasonable guess at whether or not something is correct, but it'll end
about there. Everything beyond a guess will eventually come to that same
conclusion that it is impossible to be 100% sure (as we see right here).
The worst this will ever do to you is that you will try to be more
careful the next time. If this happens too often, you'll end up mad,
because your efforts will be fruitless. That way lies paranoia.

The point being that you should not start screaming hell and murder
because someone used an ID card that fails your standards. It simply
does not work that way; and, frankly, I would suggest that that is also
not what matters. When you sign someone's key, what you're saying is not
"I know for a fact that this person is who he claims to be"; You're
really saying "This person has convinced me that he is who he claims to
be".

The fact of the matter is, there are some people of whom I would sign
their key without even looking at their ID card, since I know who they
are and don't need to verify that by looking at their ID card. I know
who my brother is. I know what the name and address of my best friend
is. I have signed 0x2C4928A0 and 0x210E0785 without ever having seen
these people's ID cards, simply because I have known them for years, and
requiring them to show government-issued ID would have been silly. Apart
from that, there are even cases where government-issued ID isn't the
best you can get; I have heard that in some country (I believe it was
Sweden, but I might be mistaken), banks are so careful in handing out ID
cards that they are considered more secure than government-issued ID
cards; in fact, in this country it is possible (and common) to prove
your ID to the government by showing a bank-issued ID card.

When I check someone's ID card for PGP checking, I do not verify whether
the card has expired. I do not verify whether the ID card was issued by
a government.  I will verify whether or not it is something that can be
easily faked (and will refuse to sign if I believe it is), and whether
it matches the name of the person. I will have a close look at the
picture, comparing it to the person in question, and sometimes ask
personal questions about people's names (why they were given this name,
or perhaps things I remember which a person of that name did) because
that is far more effective in assessing whether someone is who he or she
claims to be than having a look at an ID card, whether government-issued
or not.

Manoj, I have seen you doing your SELinux-related talk through the
DebConf webcast, and I now know what you look like. If we were to meet
in person some time from now, and you were to verify that yes,
0xBF24424C is your key and that yes, you are Manoj Srivastava, and there
were other people there who would call you by your name, then I would be
convinced that you are who you claim to be. If you would ask me at that
point, I would not oppose signing your key. I would still prefer seeing
your ID card if possible, but I would not see this as an absolute
requirement; because I would be far more convinced that you are indeed
Manoj Srivastava just by being around you than by seeing any ID card,
government-issued or not.

Because those can be forged. People's memories cannot be.

To get back to your claim where you say that Martin Krafft is a fraud
who was gaming the system, I would say that you are way off base. He
showed everyone at the KSP some ID which did contain his name as he
really is called. You have had the opportunity to see him in the days
before the KSP and to hear him being called by his name. If he would
actually have been a fraud, chances are pretty high that you would
already have known by the beginning of the KSP.

Thus, I don't think you have any reason to believe that Martin is not
who he claims to be. And for OpenPGP keys, that really is all that
matters.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


signature.asc
Description: Digital signature

Debian systems and assumptions about user rights (was: Braindump: Can we get rid of the font-cache-group question?)

[Frank Küster]

Okay, let's take this to -devel; I hope we'll get a bit more of answers
instead of just new questions there...

We are thinking about ways to make TeX font caching safer than it
currently is, without breaking buildd's or unusual setups.  The current
idea is to cache the font data in each user's home directory, and only
if this does not exist or is not writeable, fall back to VARTEXFONTS;
but this variable would no longer point to /var(/cache/fonts), but to
/tmp/texfonts instead.

Florent Rougon <[EMAIL PROTECTED]> wrote:

> BTW, about the /tmp/texfonts directory, won't it be a problem if one
> user creates it (not manually, but as suggested in this thread, by way
> of mktexnam or whatever kpathsea program) and then, *another user* also
> needs it to store fonts? Under normal circumnstances, the second user
> won't have the permissions to write to /tmp/texfonts.
>
> I didn't follow the discussion very closely, so I may say something
> wrong here. If I understood correctly, /tmp/texfonts would be only used
> for a user who has no $HOME and thus cannot write the font data to
> TEXMFVAR. If this is right, the previous paragraph could only happen
> with such users (buildds?), but still, it may happen...

I think we should not rely on current implementations here, but instead
consider which setups should generally be supported, and which need
not.  Therefore I'd like to hear comments from -devel about the
following questions:

- Setups without an existing $HOME directory can exist, and package
  building must work there, correct?

  (one easy way to set this up is copy /etc/passwd to /chroot/etc/passwd
  and su to a user.  Or some users of su/sudo with "pbuilder login"
  which do not unset $HOME)

- /tmp/ will always be available to create a reasonable amount of data?

- If package builds or other automated tasks happen on a system and are
  performed by a local user who has no home directory, can we assume
  that it will always be the same user, and use a system-wide unique
  name for the font cache directory withing /tmp?  

  I fear the current implementation of the font generating scripts does
  not allow to create font cache directories in /tmp which have the
  username in their paths (although with some hazzle it might be
  doable).

This current discussion has started at 
http://thread.gmane.org/gmane.linux.debian.devel.tetex/16065/focus=16065

but the problem is old and has been thought about over and over again in
a multitude of threads, even here on -devel...

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

Re: Debian systems and assumptions about user rights (was: Braindump: Can we get rid of the font-cache-group question?)

[Marco d'Itri]

On May 29, Frank Küster <[EMAIL PROTECTED]> wrote:

> - Setups without an existing $HOME directory can exist, and package
>   building must work there, correct?
I'd say that packages being built should not create files outside of the
build directory. But creating ~ is simple enough that I think it's
reasonable to require that it exists.

> - /tmp/ will always be available to create a reasonable amount of data?
Yes.

> - If package builds or other automated tasks happen on a system and are
>   performed by a local user who has no home directory, can we assume
>   that it will always be the same user, and use a system-wide unique
>   name for the font cache directory withing /tmp?  
I think it's a safe assumption for our buildds.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: [Debconf-discuss] Alternative keysigning procedures

[Wouter Verhelst]

On Mon, May 29, 2006 at 03:49:28PM +1000, Aníbal Monsalve Salazar wrote:
> On Sun, May 28, 2006 at 06:40:28PM -0500, Andrew McMillan wrote:
> >On Sun, 2006-05-28 at 04:54 -0700, Steve Langasek wrote:
> >>On Sat, May 27, 2006 at 04:47:20PM -0500, martin f krafft wrote:
> >>
> >>>I imagine an improved protocol for the keysigning, which is based on
> >>>an idea I overheard after the party (and someone mentioned it in the
> >>>thread): instead of the everyone-signs-everyone approach, it might
> >>>be interesting to investigate forming groups (based on connectivity
> >>>statistics) such that everyone's mean distance in the web of trust
> >>>can be increased by a fair amount in a short amount of time. At the
> >>>same time, such circles could be used for education by those with
> >>>high connectivity (and thus much experience). The problem here is of
> >>>course the somewhat unreliable attendance of people. Comments
> >>>welcome.
> >>
> >>I agree that this is the way to go.  Who has time to work on implementing
> >>the necessary code?
> 
> [Sending to -devel only]
> 
> I just talked to a friend who is an expert in mathematics (Senior
> Lecturer of Deakin University, Melbourne). He said the problem is a
> discrete programming problem

Of course it is.

> and could be represented as a classical problem with a known solution
> algorithm.
> 
> He will futher look into this problem.
> 
> I'll do the coding of the optimization program (with his help).

Err, discrete programming is a rather complex subject matter to
implement in a general-purpose language, while on the other hand there
are specialized programs to already do that. It's quite likely your
friend has that already.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: Please revoke your signatures from Martin Kraff's keys

[Wouter Verhelst]

On Sun, May 28, 2006 at 10:37:39PM -0500, Manoj Srivastava wrote:
> On 27 May 2006, martin f. krafft spake thusly:
> > From within the project, what matters is that everything you do
> > within the project can be attributed to one and the same person: the
> > same person that went through our NM process. The GPG key is one
> > technical measure to allow for this form of identification. Its
> > purpose is not, as Micah Anderson states, a means to confirm the
> > validity of a government-issued ID.
> 
> A GPG key that can not be traced to a real person who has
>  introduced a trojan into Debian and has stolen valuable data
>  (perhaps, just as another "test" to prove how stupid people are to
>  trust Debian), is worth less than a key that can implicate a real
>  person, and perhaps mitigate some damage done by the attack.

You're making fun of yourself.

If someone willingly introduces a trojan into Debian, and they did so by
means of a GPG key bearing their own name, then we have no more or less
problems than when this would happen if done by means of a GPG key
bearing the name of 'Poo', the teletubbie. The fact that my key does
indeed bear my own name does not in any way 'mitigate' anything that I
might perhaps do to harm the Project (not that I in any way intend to do
so). The problem would exist, the damage would be done, and it would be
a real-world problem whether or not we would be able to point fingers.

Then there's the issue of tracing who did an actual upload into the real
world. A name on a GPG key is not, by any means, an effective way to do
that, since it does not contain enough information to get out the black
helicopters. Case in point:



I am not a professional volleybal player who make appearances on TV.
However, this person is, and he bears my name. It is written exactly the
same way. By way of a name on a GPG key _only_, you would be able to
trace anything I might have done to me; but it's just as likely that you
would trace it to this person instead.

What you really need is a way to link a name to an actual person. A GPG
key is not an effective means to do that. If you really want to link a
person's name to a GPG key, then a far more effective way of doing so is
looking at a person's email address (which is globally unique, unlike a
name), contacting the person in charge of the mail server, log the IP
addresses that fetch mail for that person, and contact the owner of the
netblock to find out the snail mail address or phone number of the
person involved.

In other words, I will not object to signing someone's GPG key if it
only contains a nickname rather than an official name (though I might
have second thoughts), but I will _not_ sign _any_ uid on a key of which
I have not personally verified that the person reading the email address
has access to the key.

> > In my eyes, this is exactly what a keysigning is and should be all
> > about: a statement of familiarity with a person, nothing more and
> > nothing less. And as a project, we should either accept that, or
> > find a better way to identify our developers.
> 
> This is also silly --- what is the trust path he has to the
>  crackers identity?  Say, some person walks up to a LUG or linuxtag or
>  debconf and says, "Hi, I am Donal Duck".  He proceeds to talk about
>  free software, goes out for drinks, and tells a fine tale.  He does
>  so again a year later, again calling himself Donal Duck.

This scenario seems highly unlikely.

I expect that anyone willing to work a whole year on building up trust
with people he intends to defraud would be just as willing to pay the
amount of money required to acquire counterfeited, but real-looking, ID
cards.

You are not the CIA, and even they are unable to say with 100% certainty
that people are who they claim to be. I suggest you let it go.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Debian Mini-distro: how to recompile base-system and remove Java?

[Chris Boot]

Hi all,

I'm starting work again on a thinned-down version of Debian I call PicoDebian. 
The idea of this new version is to replace glibc with uClibc, and generally slim 
down various packages to fit nicely in confined environments.


I've managed to build several of the base-system packages already, mostly 
forcing dependencies to be ignored as a start, but there are some that I'm not 
entirely sure how to get around.


For example, a huge number of packages depend on gettext. While I've installed a 
local version from vanilla upstream source, this isn't good enough! The gettext 
source package itself would be better, but requires Java related tools to build. 
I'd rather keep Java and other such less-used stuff out of my distro, which also 
means thinning down GCC so it no longer requires quite so much to build, and no 
longer building Java.


Can anybody give me a helping hand in building a basic base-system that I can 
use to recompile other packages? How about removing all the Java dependencies 
from gcc-3.3, gettext, et al?


Many thanks,
Chris

--
Chris Boot
[EMAIL PROTECTED]
http://www.bootc.net/


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

Re: Debian systems and assumptions about user rights

[Frank Küster]

[EMAIL PROTECTED] (Marco d'Itri) wrote:

> On May 29, Frank Küster <[EMAIL PROTECTED]> wrote:
>
>> - Setups without an existing $HOME directory can exist, and package
>>   building must work there, correct?
> I'd say that packages being built should not create files outside of the
> build directory. But creating ~ is simple enough that I think it's
> reasonable to require that it exists.

But generating cache data in the current directory (or subdirectories
thereof) does not make sense, so requiring it for the special case of
buildds doesn't sound very sensible.  Anyway, I think many packages
create files in /var during operation, that's all this hierarchy is
meant for.  I don't see how we could generally restrict package build
processes to the build directory, especially since there's no sane way
to detect when we are "building a package".

Regards, Frank


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

Re: [Debconf-discuss] Re: Please revoke your signatures from Martin Kraff's keys

[Jacob S]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, 27 May 2006 16:21:22 -0700
Paul Johnson <[EMAIL PROTECTED]> wrote:

> On Saturday 27 May 2006 16:12, Ron Johnson wrote:
> > Paul Johnson wrote:
> > > On Saturday 27 May 2006 14:12, Steinar H. Gunderson wrote:
> > >> On Sat, May 27, 2006 at 01:54:03PM -0700, Paul Johnson wrote:
> > > Oregon abolished the voting booth in 2000
> > 
> >  Oh, so they get better counts and less fraud by doing away
> >  with ballot secrecy. How wonderful.
> > >>>
> > >>> No, that's not how it works, your ballot is still secret.
> > >>> Think about it for a minute.  You sign the mailing envelope,
> > >>> your ballot goes in a secrecy envelope.  Elections compares
> > >>> signatures, opens the mailing envelope and saves it for the
> > >>> voter rolls, sends the secrecy envelope down the line off to
> > >>> the counting machines to be opened separately in some other
> > >>> room.
> > >>
> > >> That is secrecy only to the government; not in general. For
> > >> instance, someone can easily pressure you into voting for party
> > >> or candidate X, _since they can verify it_ (just watch as you
> > >> put the ballot in the envelope, and make sure you post it). With
> > >> a voting booth, nobody can effectively pressure you, as your
> > >> vote is secret from everybody.
> > >
> > > Nobody can effectively pressure you, except everyone else in line,
> > > campaigners trolling the polling place, and the inability to get
> > > the day off to vote because polling places are only open 4-6
> > > hours on election day.  If you want to ignore that vote by mail
> > > is more secure than the voting booth, that's fine.  Don't move to
> > > Oregon.
> >
> > With vote-by-mail from the privacy (and seclusion) of your home,
> > who's to stop a political operative or angry husband from saying
> > "vote Democrat, or else!"?
> 
> The fact you can go to the police, and you can vote wherever you
> please.  If you're really that concerned about it, you can go down to
> county elections, say your ballot got lost in the mail or tell them
> that someone else coerced you (which voids the original ballot's
> mailing envelope, and if that mailing envelope gets cast, they void
> the ballot it contains) and they'll give you a fresh ballot and
> envelopes.  You're welcome to vote at the elections office, but if
> you want privacy you're going to have to lock yourself in a restroom.
> 
> Penalties for screwing with other people's votes here are severe.

That sounds like the same reason there's no more cases of battered and
abused women. For some reason I'm not convinced.

Jacob
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEew/akpJ43hY3cTURAmXRAKCBQgiP7tIPNhZT9rRD8zgs75jQIgCguEW+
R5t3Hq2eiQs3YKTQH3HEcP0=
=ZBlX
-END PGP SIGNATURE-

Re:

[debian-news-request]

General info

Subscription/unsubscription/info requests should always be sent to
the -request address of a mailing list.

If a mailing list is called for example "[EMAIL PROTECTED]", then
the -request address can be inferred from this to be:
"[EMAIL PROTECTED]".

To subscribe to a mailing list, simply send a message with the word "subscribe"
in the Subject: field to the -request address of that list.

To unsubscribe from a mailing list, simply send a message with the word (you
guessed it :-) "unsubscribe" in the Subject: field to the -request address of
that list.

In the event of an address change, it would probably be the wisest to first
send an unsubscribe for the old address (this can be done from the new
address), and then a new subscribe to the new address (the order is important).

Most (un)subscription requests are processed automatically without human
intervention.

Do not send multiple (un)subscription or info requests in one mail.
Only one will be processed per mail.

NOTE: The -request server usually does quite a good job in discriminating
  between (un)subscribe requests and messages intended for the maintainer.
  If you'd like to make sure a human reads your message, make it look
  like a reply (i.e. the first word in the Subject: field should be "Re:",
  without the quotes of course); the -request server does not react to
  replies.


The archive server
--
Every submission sent to this list is archived.  The size of the archive
depends on the limits set by the list maintainer (it is very well possible
that only, say, the last two mails sent to the list are still archived, the
rest might have expired).

You can look at the header of every mail coming from this list to see
under what name it has been archived.  The X-Mailing-List: field contains
the mailaddress of the list and the file in which this submission was
archived.

If you want to access this archive, you have to send mails to the -request
address with the word "archive" as the first word of your Subject:.
To get you started try sending a mail to the -request address with
the following:
Subject: archive help


  The listmaster
  --
To reach a human being answering your mail you may contact the address
[EMAIL PROTECTED]  We will process your request as soon as
we can.

Mail sent to this address is pre-parsed, a little mail robot will
automatically answer all mails sent with the following Subject lines:

  help  sends this help

  lists sends information on how to get a list of mailing lists


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

Re:

[debian-user-request]

General info

Subscription/unsubscription/info requests should always be sent to
the -request address of a mailing list.

If a mailing list is called for example "[EMAIL PROTECTED]", then
the -request address can be inferred from this to be:
"[EMAIL PROTECTED]".

To subscribe to a mailing list, simply send a message with the word "subscribe"
in the Subject: field to the -request address of that list.

To unsubscribe from a mailing list, simply send a message with the word (you
guessed it :-) "unsubscribe" in the Subject: field to the -request address of
that list.

In the event of an address change, it would probably be the wisest to first
send an unsubscribe for the old address (this can be done from the new
address), and then a new subscribe to the new address (the order is important).

Most (un)subscription requests are processed automatically without human
intervention.

Do not send multiple (un)subscription or info requests in one mail.
Only one will be processed per mail.

NOTE: The -request server usually does quite a good job in discriminating
  between (un)subscribe requests and messages intended for the maintainer.
  If you'd like to make sure a human reads your message, make it look
  like a reply (i.e. the first word in the Subject: field should be "Re:",
  without the quotes of course); the -request server does not react to
  replies.


The archive server
--
Every submission sent to this list is archived.  The size of the archive
depends on the limits set by the list maintainer (it is very well possible
that only, say, the last two mails sent to the list are still archived, the
rest might have expired).

You can look at the header of every mail coming from this list to see
under what name it has been archived.  The X-Mailing-List: field contains
the mailaddress of the list and the file in which this submission was
archived.

If you want to access this archive, you have to send mails to the -request
address with the word "archive" as the first word of your Subject:.
To get you started try sending a mail to the -request address with
the following:
Subject: archive help


  The listmaster
  --
To reach a human being answering your mail you may contact the address
[EMAIL PROTECTED]  We will process your request as soon as
we can.

Mail sent to this address is pre-parsed, a little mail robot will
automatically answer all mails sent with the following Subject lines:

  help  sends this help

  lists sends information on how to get a list of mailing lists


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

Re: Please revoke your signatures from Martin Kraff's keys

[Gunnar Wolf]

Javier Fernández-Sanguino Peña dijo [Sun, May 28, 2006 at 11:40:46PM +0200]:
> > > For me, yes, some questions asked, some delays involved, but no
> > > detailed background checks. I'm sure neither the FBI or the CIA (or,
> > > as for Mexican authorities, CISEN or PGR) were involved.
> > 
> > Then some government organizations do not take as stringent a
> >  set of precautions as others do. That, by itself, is an unsurprising
> >  statement. 
> 
> In Spain, you are *required* to have a national ID card (if you are
> over 18 years old), that means the Police will provide you with one
> regardless of what background checks they might want to run. That is, they
> *have* to provide you with a national ID card. Same happens with the passport
> BTW. Unless they want to remove you of it (because you are being prosecuted
> and they fear you might ran away), they *have* to provide you with a
> passport. Not because it is a requirement, but because you have the *right*
> to travel abroad (at least it is in Spain)

There is a catch - And that catch forced me to do the military
service. No, it's not a military service as you know it, it's more a
joke than anything else (going every Saturday morning to do some
social labor - planting trees, cleaning streets, etc. And taking a
very small part in a parade). But anyway...

Our constitution grants any person in Mexico the right to travel, to
exit the country at will. Ok, perfect. But now, what happens if the
government does not want to issue you a passport? Simple: You can
travel anywhere you want - as long as the destination country accepts
you to enter. And, of course, no country (or, closer to the truth,
very few countries) will allow you to enter without a passport.

If a Mexican is outside Mexico, he must be granted the right to go
back there - and that can only be achieved by having a valid
passport. Thus, I have at least three passports valid only for six
months IIRC, from the time I lived in Israel. But yes, once back in
Mexico, and once my passport expired, I had to go through the military
service to get a new one.

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


signature.asc
Description: Digital signature

Re: Shouldn't we have more ftp masters ?

[Benjamin Seidenberg]

Stefano Zacchiroli wrote:
> On Sun, May 28, 2006 at 11:42:16PM +0200, Bartosz Fenski aka fEnIo wrote:
>   
>> I think it's debconf time and everything is slower, but will be as
>> usual when it's end and everyone came back to his/her normal work.
>> 
>
> The point of the first mail was exactly about that. NEW queue can't stay
> unprocessed just because 1 or 2 ftp masters/assistants are attending
> debconf or on vacation. They have all rights of doing so, of course! But
> we need someone else able to take over their duties in this respect.
>
> I do think that NEW processing is rather important for package
> maintenance and that it can hinder development.
>
> Cheers.
>
>   
FYI:
12:33 < Ganneff> and for all those impatient waiting for NEW: i will
clear that
 in my jetlag time, in those nights i cant sleep (ie 1st
-> 2nd
 june, 2-> 3) :)

12:37 < Ganneff> maybe i can do a bit of NEW later today, but im going
to look
 around in mx city in a few minutes, only doing urgent
stuff
 online atm)




signature.asc
Description: OpenPGP digital signature

Re: [Debconf-discuss] Re: Please revoke your signatures from Martin Kraff's keys

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Sun, May 28, 2006 at 08:57:55PM -0700, Thomas Bushnell BSG wrote:
>
>> > If I were to crack a key signing party, using Bubba's travel
>> >  documents, I too would swear up and down the street that he indeed
>> >  correctly and diligently verified all kinds of _other_ government
>> >  ID's when practising his art.
>
>> How is it "cracking" to use Bubba's documents?  People who do not know
>> and trust Bubba should not accept the ID, period.
>
> Heh, I think you missed the subtext of Manoj's hypothetical, which is that
> Bubba sells fake IDs to underage students.

So, if the ID says on it, "Bubba's Fake ID Shop", I'm not sure I see
the problem.  In other words, Bubba sells forgeries, but the
Transnational Republic does not.

Thomas


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

Re: {SPAM} Debian Mini-distro: how to recompile base-system and remove Java?

[Daniel Ruoso]

Em Seg, 2006-05-29 às 13:49 +0100, Chris Boot escreveu:
> I'm starting work again on a thinned-down version of Debian I call 
> PicoDebian. 
> The idea of this new version is to replace glibc with uClibc, and generally 
> slim 
> down various packages to fit nicely in confined environments.

This need is starting to become more and more evident... I'm working on
this also, using SLIND as toolchain and initial bootstrap (which,
actually, is saving the day).

> Can anybody give me a helping hand in building a basic base-system that I can 
> use to recompile other packages? How about removing all the Java dependencies 
> from gcc-3.3, gettext, et al?

The challange is to compile the other packages that compose the
build-essential package list. With that, in theory, you can setup a
buildd.

I'm working locally on this (my bandwidth is poor, so it's hard to me to
upload partial progress). The uclibc-i386 packages missing to me are:
* gcc
* libgdbm3
* libdb4.2 (I'm very near on finishing this one)
* perl (which depends on the two libs above)

I'm working with sarge, as it's easier to deal with a frozen target, but
after that 4 packages, we have the way to setup a buildd and start
natively building packages.

daniel


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

HOWTO rebuild the archive

[Bastian Venthur]

Hi all,

I want to rebuild the whole archive on my box but I don't really know
where to start. I don't want to keep the resulting packages, I just want
to seek FTBFSes.

I've installed sbuild (do I really need it? Does pbuilder/cowbuilder
suffice?) and followed the instructions of the manpage to setup a build
environment. What would be the next step? How to I manage to get the
whole archive (testing) build? Is there a script or something?


Best regards,

Bastian

-- 
Bastian Venthur
http://venthur.de


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

Re: Uploading packages built against testing? (was: openssl will block bacula into etch?)

[Hendrik Sattler]

Am Montag, 29. Mai 2006 10:27 schrieb Frank Küster:
> Would it be acceptable to build bacula (or any other package with that
> problem) in an etch environment, or on sid with manually installed
> libssl from etch, and upload that to unstable?  After checking that it
> works in unstable, of course.

No, but you could manually set all stuff in Depends to the needed versions. 
That would also work for the buildds, I guess.

HS

PS: I bravely accept some flames for this suggestion...


pgpBdAMTEqsyO.pgp
Description: PGP signature

Renaming a package

[Andreas Fester]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi everyone,

this has already been discusses some times, but
since this is a new situation for me I want to be
sure that it is still true and that I handle it properly :-)

Problem:

Upstream application (non-library) has changed its name.
I want to reflect this new name in the debian
package name while ensuring that apt-get dist-upgrade
works seamless and pulls in the new package.


Solution:

I create a new package with the new name which will
get uploaded to the NEW queue. This package replaces the
old package and conflicts with the old package:
Replaces: oldPackage
Conflicts: oldPackage (<< firstVersionOfNewPackage)

Once the package has moved from the NEW queue to unstable,
I create a new revision of the old package which
serves as dummy package. It does not install any files
(except the mandatory ones in /usr/share/doc) and
depends on the new package.

Finally, after etch has been released end of this year,
I file a bug asking ftpmaster to remove the old, dummy package.

Is this the correct approach? Anything I missed?

Thanks & Best Regards,

Andreas

- --
Andreas Fester
mailto:[EMAIL PROTECTED]
WWW: http://www.littletux.net
ICQ: 326674288
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEe0gyZ3bQVzeW+rsRAh1QAJ9Gu6KQN8+GTkn2dHr49nTUhqiTvwCgzYn+
CHfLgUwOFsXUxQSwfZHGAX8=
=l/Uh
-END PGP SIGNATURE-


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

Re: [Debconf-discuss] Please revoke your signatures from Martin Kraff's keys

[Mauro Parra]

Hello, On 5/26/06, David Moreno Garza <[EMAIL PROTECTED]> wrote:
You _usually_ don't get your passport stamped? Really? In recent flights?I have never entered Mexico back without the Immigration seal.Yeah, depends on the mood of the one attending you. 
True! And even by plane! Which I found extremely suspicious when gramtold me he only used his Texas ID card to travel from there to Benito
Juárez airport.Americans need practically nothing to get into Mx. Just a "proof" of being americans (birth cert and so).  
> you were to that country. I have seen this both in Cuba and in> Israel.That's interesting.In the case of Cuba, they don't want to fuck your relations with US, since there is a fine for people buying cuban products (if you are american, of course; in my case, i can get some issues in my reentry to US if they see a cuban sell on my passport). 
 Regards,M-- Mauro Parrawww.mechulk.com

Re: Uploading packages built against testing?

[Thomas Viehmann]

Hendrik Sattler wrote:
> Am Montag, 29. Mai 2006 10:27 schrieb Frank Küster:
>> Would it be acceptable to build bacula (or any other package with that
>> problem) in an etch environment, or on sid with manually installed
>> libssl from etch, and upload that to unstable?  After checking that it
>> works in unstable, of course.
How about waiting for openssl? As has been pointed out, openssl is
frozen for technical reasons and the new version will enter testing all
right[1].

> No, but you could manually set all stuff in Depends to the needed versions. 
> That would also work for the buildds, I guess.
And break at the next opportunity (binNMU, recompile, update in a
hurry...). Such hacks are almost certainly a bad idea, in fact John had
a complaint of similar type about the bacula packaging from before he
took over.

> PS: I bravely accept some flames for this suggestion...
Oh, if you insist: To be frank, maintainers having such ideas are bad
enough, but you'd better have a good excuse for handing them out as advice.

Kind regards

T.

1. http://bjorn.haxx.se/debian/testing.pl?package=openssl
-- 
Thomas Viehmann, http://thomas.viehmann.net/


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

Re: Renaming a package

[Thomas Viehmann]

Andreas Fester wrote:
> Is this the correct approach? Anything I missed?

I think the usual way is to provide the dummy binary package immediately
from the new source package and file a bug for removal of the old source
package.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


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

Re: Renaming a package

[martin f krafft]

also sprach Andreas Fester <[EMAIL PROTECTED]> [2006.05.29.2114 +0200]:
> Replaces: oldPackage
> Conflicts: oldPackage (<< firstVersionOfNewPackage)

Also: Provides: oldPackage, so that it can still satisfy
(non-versioned) dependencies.

But yeah, seems like the right way to do things.

-- 
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
 
"one should never do anything that
 one cannot talk about after dinner."
-- oscar wilde


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

Re: Renaming a package

[martin f krafft]

also sprach Thomas Viehmann <[EMAIL PROTECTED]> [2006.05.29.2122 +0200]:
> I think the usual way is to provide the dummy binary package
> immediately from the new source package and file a bug for removal
> of the old source package.

Sounds like a clean approach, but is there a clean transition?
I doubt you can upload a source package that generates the same
binary package as another source package.

-- 
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
 
"here i was all convinced that if i sleep all day, bug counts go
 down, and if I work all day, they go up, so much for that theory."
   -- lars wirzenius


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

Re: Please revoke your signatures from Martin Kraff's keys

[Lionel Elie Mamane]

On Sun, May 28, 2006 at 11:40:46PM +0200, Javier Fernández-Sanguino Peña wrote:

> (...) they *have* to provide you with a passport. Not because it is
> a requirement, but because you have the *right* to travel abroad (at
> least it is in Spain)

That's a human right, as defined by the Universal Declaration of Human
Rights (article 13).

-- 
Lionel


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

Re: Renaming a package

[Adeodato Simó]

* martin f krafft [Mon, 29 May 2006 21:26:41 +0200]:

> I doubt you can upload a source package that generates the same
> binary package as another source package.

You definitely can, and TTBOMK it does not even need NEW if the source
package that starts shipping it already existed.

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
   Listening to: Maximilian Hecker - Daze Of Nothing


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

Re: Renaming a package

[Mike Hommey]

On Mon, May 29, 2006 at 09:26:41PM +0200, martin f krafft <[EMAIL PROTECTED]> 
wrote:
> also sprach Thomas Viehmann <[EMAIL PROTECTED]> [2006.05.29.2122 +0200]:
> > I think the usual way is to provide the dummy binary package
> > immediately from the new source package and file a bug for removal
> > of the old source package.
> 
> Sounds like a clean approach, but is there a clean transition?
> I doubt you can upload a source package that generates the same
> binary package as another source package.

You can.

Mike


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

Re: Uploading packages built against testing? (was: openssl will block bacula into etch?)

[Steve Langasek]

On Mon, May 29, 2006 at 08:58:19PM +0200, Hendrik Sattler wrote:
> Am Montag, 29. Mai 2006 10:27 schrieb Frank Küster:
> > Would it be acceptable to build bacula (or any other package with that
> > problem) in an etch environment, or on sid with manually installed
> > libssl from etch, and upload that to unstable?  After checking that it
> > works in unstable, of course.

> No, but you could manually set all stuff in Depends to the needed versions. 
> That would also work for the buildds, I guess.

No.  If you're overriding the Depends generated by the build environment,
your packages are fucked, either now or later.

-- 
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: Renaming a package

[Marc 'HE' Brockschmidt]

martin f krafft <[EMAIL PROTECTED]> writes:
> also sprach Thomas Viehmann <[EMAIL PROTECTED]> [2006.05.29.2122 +0200]:
>> I think the usual way is to provide the dummy binary package
>> immediately from the new source package and file a bug for removal
>> of the old source package.
> Sounds like a clean approach, but is there a clean transition?
> I doubt you can upload a source package that generates the same
> binary package as another source package.

You are free to doubt that, it's still possible.

Marc
-- 
Fachbegriffe der Informatik - Einfach erklärt
91: Emacs
   Eight Megabytes And Continously Swapping


pgpJc1N9U8S5j.pgp
Description: PGP signature

Re: [Debconf-discuss] list of valid documents for KSPs (was: Please revoke your signatures from Martin Kraff's keys)

[David Moreno Garza]

Javier Fernández-Sanguino Peña wrote:
> Regardless of this, I think it would be nice to have a document (wikipedia
> article?) listing official documents of countries all over the world. KSP
> attendants need not base their decissions on this, but could be useful
> as background information.
> 
> If someone opens up a Wikipedia article on this, maybe extending
> http://en.wikipedia.org/wiki/Identity_document (which only describes
> *national* cards) I would gladly contribute to it.

But again, should I trust someone else while checking the identity of
the holder of a weird (for me) passport?

-- 
David Moreno Garza <[EMAIL PROTECTED]>   |  http://www.damog.net/
   <[EMAIL PROTECTED]>  |  GPG: C671257D
 ¿Quién lo viera orinando en un cajero?


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

Re: Renaming a package

[Andreas Fester]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

martin f krafft wrote:
> also sprach Andreas Fester <[EMAIL PROTECTED]> [2006.05.29.2114 +0200]:
>> Replaces: oldPackage
>> Conflicts: oldPackage (<< firstVersionOfNewPackage)
> 
> Also: Provides: oldPackage, so that it can still satisfy
> (non-versioned) dependencies.

I thought this only applies to virtual packages, but your
explanation makes sense :-)

> But yeah, seems like the right way to do things.

Ok, thanks for the review.

Best Regards,

Andreas

- --
Andreas Fester
mailto:[EMAIL PROTECTED]
WWW: http://www.littletux.net
ICQ: 326674288
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEe05nZ3bQVzeW+rsRAnDGAKChk2sy1++DSr9/n0JA8fNt1d/jYwCgt0GV
dGS/eXyfVOYfQ+9E6Gc8oo4=
=lfLL
-END PGP SIGNATURE-


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

Re: Uploading packages built against testing? (was: openssl will block bacula into etch?)

[Adeodato Simó]

* Hendrik Sattler [Mon, 29 May 2006 20:58:19 +0200]:

> PS: I bravely accept some flames for this suggestion...

Sure, here, have some:

  - http://lists.debian.org/debian-devel/2006/05/msg01393.html
  - http://lists.debian.org/debian-devel/2006/05/msg00752.html
  - http://lists.debian.org/debian-legal/2006/03/msg00098.html

You have three days now to read the threads/flames whose initial messages
are those mentioned above, and on Jun 2nd, you'll be required to take an
exam to show your knowledge on the matters there discussed, for example:

  In which message (please give a Message-ID) does Penny Leach confess
  her real name to be Penelope?

Have fun,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
   Listening to: Maximilian Hecker - Daze Of Nothing


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

Real Life hits: need to give up packages for adoption

[bounce-debian-devel=archive=mail-archive . com]

Hi,

My inability to find enough time to focus on package maintainance
has been *way* too persistent. I therefore need to give up my packages
for adoption, for the time being.

I am sorry (and not happy with myself) that I've been procrastinating
about this for too long. This decision has not been easy. However,
I need to focus more on (a) work that actually feeds my kids, and
(b) time that is *not* spent hacking.

Before filing Orphan bugs, I'd like to ask whether anybody wants to
tackle these packages. The Easy Pickings stuff would be ideal start-up
work for new maintainers / mentorship; some of the others do need some
work.

* gnutls, gcrypt, libtasn1, libksba
  (security-critical, some work required, having a team for these
  packages would be ideal)
* festival, speech-tools
  (some clean-up work, new major upstream release pending)
* NTP server
  (some work required; currently, not-really-maintained by the Debian
  NTP Team, which consists of zero active members)
* libdigest-hmac-perl, libdigest-sha1-perl, libdigest-md2-perl,
  libdigest-perl, libio-interface-perl, libio-socket-multicast-perl,
  libnet-xwhois-perl, libvideo-capture-v4l-perl
  (easy pickings; check for new Upstream)
* python-docutils
  (easy pickings)
* python-imaging
  (easy pickings)
* gnulib
  (easy pickings; need to package new Upstream from CVS, every month or so)
* gnupg2
  (some clean-up work)
* hashalot
  (easy pickings)
* kforth
  (new Upstream)
* tcng
  (some clean-up required)
* ufraw
  (need to package new Upstream; easy)
* videogen
  (easy pickings)
  
-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Incorrigible punster -- Do not incorrige.


signature.asc
Description: Digital signature

Re: HOWTO rebuild the archive

[Goswin von Brederlow]

Bastian Venthur <[EMAIL PROTECTED]> writes:

> Hi all,
>
> I want to rebuild the whole archive on my box but I don't really know
> where to start. I don't want to keep the resulting packages, I just want
> to seek FTBFSes.
>
> I've installed sbuild (do I really need it? Does pbuilder/cowbuilder
> suffice?) and followed the instructions of the manpage to setup a build
> environment. What would be the next step? How to I manage to get the
> whole archive (testing) build? Is there a script or something?
>
>
> Best regards,
>
> Bastian

You have to setup wanna-build so the buildd can ask for things to
build.

Or just dump all packages into the buildds queue file (as
package_version, one per line) and start it.

MfG
Goswin


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

Re: Uploading packages built against testing?

[Goswin von Brederlow]

Hendrik Sattler <[EMAIL PROTECTED]> writes:

> Am Montag, 29. Mai 2006 10:27 schrieb Frank Küster:
>> Would it be acceptable to build bacula (or any other package with that
>> problem) in an etch environment, or on sid with manually installed
>> libssl from etch, and upload that to unstable?  After checking that it
>> works in unstable, of course.
>
> No, but you could manually set all stuff in Depends to the needed versions. 
> That would also work for the buildds, I guess.

No, that would produce binaries that install with the wrong libs and
then just fail to start or segfault. If you do that you will get an RC
bug just on principal even if it does work out of sheer luck.

> HS
>
> PS: I bravely accept some flames for this suggestion...

MfG
Goswin


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

Re: Renaming a package

[Goswin von Brederlow]

martin f krafft <[EMAIL PROTECTED]> writes:

> also sprach Thomas Viehmann <[EMAIL PROTECTED]> [2006.05.29.2122 +0200]:
>> I think the usual way is to provide the dummy binary package
>> immediately from the new source package and file a bug for removal
>> of the old source package.
>
> Sounds like a clean approach, but is there a clean transition?
> I doubt you can upload a source package that generates the same
> binary package as another source package.

You can as long as the version is higher.

Overrides need adjusting but you are in the NEW queue anyway.

MfG
Goswin


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

Re: Renaming a package

[Frank Küster]

martin f krafft <[EMAIL PROTECTED]> wrote:

> also sprach Thomas Viehmann <[EMAIL PROTECTED]> [2006.05.29.2122 +0200]:
>> I think the usual way is to provide the dummy binary package
>> immediately from the new source package and file a bug for removal
>> of the old source package.
>
> Sounds like a clean approach, but is there a clean transition?
> I doubt you can upload a source package that generates the same
> binary package as another source package.

Oh, you can.  Until a couple of months ago, it would also have saved you
the NEW processing; the package would have just slipped in...


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

Re: Real Life hits: need to give up packages for adoption

[martin f krafft]

also sprach  <> [2006.05.29.2129 +0200]:
> * python-docutils
>   (easy pickings)

I'd like to take that on. I am already co-maintainer. Other
co-maintainers welcome.

-- 
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
 
windoze nt crashed.
i am the blue screen of death.
no one hears your screams.


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

Re: Real Life hits: need to give up packages for adoption

[Franz Pletz]

On Mon, May 29, 2006 at 09:29:34PM +0200,  wrote:
> * festival, speech-tools
>   (some clean-up work, new major upstream release pending)
[..]
> * gnupg2
>   (some clean-up work)

I'd be interested in taking these three, especially gnupg2 as I'm using
it on a daily basis.

Thanks,
Franz

-- 
Franz Pletz   \  Lots of the basis of the open source movement
www: http://franz-pletz.org/   \  come from procrastinating students.
email: [EMAIL PROTECTED]   \  -- Andrew Tridgell


signature.asc
Description: Digital signature

Re: Real Life hits: need to give up packages for adoption

[Eric Dorland]

*  () wrote:
> Hi,
> 
> My inability to find enough time to focus on package maintainance
> has been *way* too persistent. I therefore need to give up my packages
> for adoption, for the time being.
> 
> I am sorry (and not happy with myself) that I've been procrastinating
> about this for too long. This decision has not been easy. However,
> I need to focus more on (a) work that actually feeds my kids, and
> (b) time that is *not* spent hacking.
> 
> Before filing Orphan bugs, I'd like to ask whether anybody wants to
> tackle these packages. The Easy Pickings stuff would be ideal start-up
> work for new maintainers / mentorship; some of the others do need some
> work.

> * gnupg2
>   (some clean-up work)

I'd like to take this, as it ties into some of my work packaging
OpenSC quite nicely. 

-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

Re: Debian Mini-distro: how to recompile base-system and remove Java?

[Chris Boot]

On 29 May 2006, at 18:32, Daniel Ruoso wrote:


Em Seg, 2006-05-29 às 13:49 +0100, Chris Boot escreveu:
I'm starting work again on a thinned-down version of Debian I call  
PicoDebian.
The idea of this new version is to replace glibc with uClibc, and  
generally slim

down various packages to fit nicely in confined environments.


This need is starting to become more and more evident... I'm  
working on

this also, using SLIND as toolchain and initial bootstrap (which,
actually, is saving the day).


It's good to find someone in the same boat!

SLIND sounds interesting indeed, I've been using a buildroot-built  
system for mine so it was difficult getting dpkg built in the first  
place, but I've got it mostly all going. All the arch-independent  
packages help a lot too.


Can anybody give me a helping hand in building a basic base-system  
that I can
use to recompile other packages? How about removing all the Java  
dependencies

from gcc-3.3, gettext, et al?


The challange is to compile the other packages that compose the
build-essential package list. With that, in theory, you can setup a
buildd.


That's what I'm aiming for as well, but unfortunately there's a hell  
of a lot of dependencies in all that lot!


I'm working locally on this (my bandwidth is poor, so it's hard to  
me to

upload partial progress). The uclibc-i386 packages missing to me are:
* gcc


There seem to be ways to build a minimal gcc built into the build  
scripts, but I can't seem to be able to trigger these to successfully  
build a compiler. It keeps dying with:


stage1/xgcc -Bstage1/ -B/usr/i486-linux/bin/   -g -O2 -DIN_GCC   -W - 
Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes - 
Wtraditional -pedantic -Wno-long-long   -DHAVE_CONFIG_H - 
DGENERATOR_FILE  -o gengenrtl \

gengenrtl.o ../libiberty/libiberty.a
./gengenrtl -h > tmp-genrtl.h
/bin/sh: line 1: ./gengenrtl: No such file or directory


* libgdbm3
* libdb4.2 (I'm very near on finishing this one)
* perl (which depends on the two libs above)


I've built perl without having either of the two prerequisites  
installed, works for most things and satisfies lots of dependencies! :-)


I'm working with sarge, as it's easier to deal with a frozen  
target, but

after that 4 packages, we have the way to setup a buildd and start
natively building packages.


Yup, same here, Sarge base with a few patched packages.

Maybe we could join forces to speed things along?

Many thanks,
Chris

--
Chris Boot
[EMAIL PROTECTED]
http://www.bootc.net/

Re: Uploading packages built against testing?

[Hendrik Sattler]

Am Montag, 29. Mai 2006 21:16 schrieb Thomas Viehmann:
> Hendrik Sattler wrote:
> > No, but you could manually set all stuff in Depends to the needed
> > versions. That would also work for the buildds, I guess.
>
> And break at the next opportunity (binNMU, recompile, update in a
> hurry...).

If he knows that his application is satisfied by openssl-0.9.8_0.9.8a-1, why 
would it break? No app in testing breaks because the newer openssl enter 
testing.
The automated shared lib dependency calculation surely works but does not 
always give optiomal results, e.g. it will pin to a specific libc (building 
packages of non-free apps is sometimes better done with setting the depends 
manually).
Update in a hurry: problem of the maintainer.
binNMU & recompilation: won't break if the app really works with this older 
version and the lib must be ABI-compatible anyway.

Automatism is good but not the only way to do stuff.

HS


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

Re: HOWTO rebuild the archive

[Wouter Verhelst]

On Mon, May 29, 2006 at 09:47:53PM +0200, Goswin von Brederlow wrote:
> Or just dump all packages into the buildds queue file (as

That would be ~buildd/build/REDO

> package_version, one per line) and start it.

That would be

package_version distribution

instead, as in

nbd_1:2.8.4-2 unstable

Whether doing it this way is a good idea, though, I don't know. Buildd
surely wasn't designed for this.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: Debian Mini-distro: how to recompile base-system and remove Java?

[Daniel Ruoso]

Em Seg, 2006-05-29 às 22:08 +0100, Chris Boot escreveu:
> SLIND sounds interesting indeed, I've been using a buildroot-built  
> system for mine so it was difficult getting dpkg built in the first  
> place, but I've got it mostly all going. All the arch-independent  
> packages help a lot too.

In fact, I want it to work as a native debian system. This way,
buildroot causes a lot of problems (I think that's the motivation behind
SLIND). And they already have a binary base system which is a hell lot
of work already done... Mixing this with dpkg-cross, well... it's
perfect :) 

> > The challange is to compile the other packages that compose the
> > build-essential package list. With that, in theory, you can setup a
> > buildd.
> That's what I'm aiming for as well, but unfortunately there's a hell  
> of a lot of dependencies in all that lot!

That's where SLIND helps more... the base system is already built.

> There seem to be ways to build a minimal gcc built into the build  
> scripts, but I can't seem to be able to trigger these to successfully  
> build a compiler. It keeps dying with:

I think it's possible to just use dpkg-buildpackage -auclibc-i386 and
get a functional package (after some changes, probably)... I'm trying to
stay as close as I can from the stock debian packages.

> > * libgdbm3
> > * libdb4.2 (I'm very near on finishing this one)
> > * perl (which depends on the two libs above)
> I've built perl without having either of the two prerequisites  
> installed, works for most things and satisfies lots of dependencies! :-)

As I said, I aim to have a standard debian machine, so I do want to deal
with the dependencies correctly to have a real package.

> Maybe we could join forces to speed things along?

Sure... Actually, I think we should both join forces to emdebian, which
is doing a great job...

What I do think it would be really nice is to have a "contrib-builds"
SLIND repository (like backports do). This would make things easier for
sharing this effort.

daniel


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

Re: Debian Mini-distro: how to recompile base-system and remove Java?

[Steve Kemp]

On Mon, May 29, 2006 at 07:53:02PM -0300, Daniel Ruoso wrote:

> In fact, I want it to work as a native debian system. This way,
> buildroot causes a lot of problems 

  Isn't this what 'apt-build' can be used for?

http://julien.danjou.info/article-apt-build.html

  That allows you to rebuild the whole system, via 'apt-build world',
 and I guess you could go from there to building other packages
 easily enough.

  (Ignore the optimisations, obviously.)

Steve
-- 
Debian GNU/Linux System Administration
http://www.debian-administration.org/


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

Re: {SPAM} Re: Debian Mini-distro: how to recompile base-system and remove Java?

[Daniel Ruoso]

Em Seg, 2006-05-29 às 23:59 +0100, Steve Kemp escreveu:
> On Mon, May 29, 2006 at 07:53:02PM -0300, Daniel Ruoso wrote:
> > In fact, I want it to work as a native debian system. This way,
> > buildroot causes a lot of problems 
> Isn't this what 'apt-build' can be used for?
> That allows you to rebuild the whole system, via 'apt-build world',
> and I guess you could go from there to building other packages
> easily enough.

Hmmm... I may be entirely wrong, but from what I understand, you need a
bootstrapped debian system with native toolchain to use it, isn't it? It
will probably be usefull once we have a base+build-essential uclibc-i386
debian system up and running...

daniel


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

Re: Real Life hits: need to give up packages for adoption

[James Westby]

On (29/05/06 21:29), [EMAIL PROTECTED] wrote:
> Hi,
> 
> My inability to find enough time to focus on package maintainance
> has been *way* too persistent. I therefore need to give up my packages
> for adoption, for the time being.

That's a shame.

> * gnutls, gcrypt, libtasn1, libksba
>   (security-critical, some work required, having a team for these
>   packages would be ideal)

I would like to be part of the team for these packages.

James


-- 
  James Westby
  [EMAIL PROTECTED]
  http://jameswestby.net/


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

Do you dream about retiring early?

[windows]

internet marketers,
 
Do you dream about retiring early?
 
We have the leads, business, automated systems, and product to help you do it.
We charge nothing to send you more information.
Our team has over 8 years of proven success; we will share all.
 
Get more now::
http://windows.topincome-superstars.net/[EMAIL PROTECTED]  
 
Pro Systems   
[EMAIL PROTECTED] 

Already Toured? Re-Tour By Clicking Here:  
http://windows.topincome-superstars.net/[EMAIL PROTECTED]&u=3 
 
 
 






You are receiving this message because you have either signed up
to receive information from us or opted-in to a third-party. 
To be removed from this users list or notify us that this is
Unsolicited, please see the link below.

Pro Systems
Pro Systems Inc
1399 Green Valley Parkway
Henderson, NV 89052

http://windows.topincome-superstars.net/imout/[EMAIL PROTECTED]


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

Re: Real Life hits: need to give up packages for adoption

[Matthias Klose]

> * python-imaging
>   (easy pickings)

as former maintainer of this package and having used that as an
example package, I'd like to maintain this one again.

  Matthias


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

Re: sending debian-private postings to gmail

[Anthony DeRobertis]

Kevin B. McCarty wrote:


Come to think of it, [pgp encrypting each message] isn't a bad idea.  Is it 
feasible for this to
be done transparently?  Mailing list admins, any comments?


I suspect that the end result of this would be more people keeping their 
GPG keys unencrypted on Internet-accessible machines.



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

Re: Please revoke your signatures from Martin Kraff's keys

[Anthony DeRobertis]

Tyler MacDonald wrote:
WTF?  In Oregon, if you have a driver's license, you cannot get an ID card.  
If you have an ID card, you have to surrender it to get a driver's license.  
You're only legally allowed one ID.



	Weird! 


Not really, same rules apply in Virginia, AFAIK.


You can still keep your birth certificate and social security
card though, right?
  


Neither of those are photo IDs.


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

Re: Uploading packages built against testing?

[Thomas Viehmann]

Hendrik Sattler wrote:
> Am Montag, 29. Mai 2006 21:16 schrieb Thomas Viehmann:
>> Hendrik Sattler wrote:
>>> No, but you could manually set all stuff in Depends to the needed
>>> versions. That would also work for the buildds, I guess.
>> And break at the next opportunity (binNMU, recompile, update in a
>> hurry...).

>  he automated shared lib dependency calculation surely works but does not 
> always give optiomal results, e.g. it will pin to a specific libc (building 
> packages of non-free apps is sometimes better done with setting the depends 
> manually).
>From a Debian point of view, correct and minimal dependencies is a
(very) global problem, with correctness being a hard condition and
minimal not. In particular, local optimization towards minimal that
raise the probability of incorrect over package life time, are not a way
to go.
Experience shows automatism is asked for because the problem rate is far
lower. It doesn't any harm, either, does it?
Don't take my word for it, but do trust Steve's expert opinion. Debian
is large enough to predict "there will be N errors" in every "the
maintainer will have to be careful here", so your arguments are void...

> binNMU & recompilation: won't break if the app really works with this older 
> version and the lib must be ABI-compatible anyway.
... and this one is plainly wrong. binNMUs for rebuild against
dependency libs which have changed ABI are not only possible but
routinely done. Transition NMUs would be hard to get correct as well.

> Automatism is good but not the only way to do stuff.
For Debian packages taking clever shortcuts that are almost certain to
fire back is inacceptable. We all do the "create a Debian package using
ar" thing once, but we all agree that this isn't the way to do it.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


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