Re: effectiveness of rsync and apt

[Tyler MacDonald]

Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> Bittorrent has a per chunk hash so it can validate each chunk when it
> recieves it instead of waiting for the full file. It won't see if a
> chunk is present at some other position in the file, not even if that
> position is also on chunk boundaries.
> 
> Rsync has a per chunk Alder-32 and md4 checksum. Those chunk checksums
> are compared to a chunk at every byte position in the file. The
> Adler-32 checksum is fairly weak but it can be updated from one
> position to the next with minimal work. Only when it matches does
> rsync compute the expensive md4 checksum for the block.
> 
> 
> The only thing that is simmilar is the "per block" when generating the
> checksum, which is basicaly nothing.

Actually it's quite a bit of similarity... but you're right, they
still are very different. From the article, it sounds like the author is
suggesting storing these checksum values for quick retrieval, which gets
closer to what BitTorrent is doing. If an rsync daemon were to spit out IP's
of clients that were mirroring the exact same thing (which is technically
feasable, given that an rsync client could easily send it's relevant
command-line arguments upstream), then rsync clients could talk to
eachother, which would lower the bandwidth requirements of top-level debian
mirrors significantly.

> MfG

?

Cheers,
Tyler


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

Re: effectiveness of rsync and apt

[Goswin von Brederlow]

Tyler MacDonald <[EMAIL PROTECTED]> writes:

> Brian Eaton <[EMAIL PROTECTED]> wrote:
>> http://rsync.samba.org/rsync-and-debian/rsync-and-debian.html
>> 
>> Has anyone ever done some log file analysis to figure out how much
>> bandwidth would be saved by transferring package deltas instead of
>> entire new packages?

Look at zsync and help develope it far enough so it can look into
debs. Without that the gain is practicaly 0 or less.

>   Slightly off-topic, but I never realised until I read that article,
> how similar rsync and bittorrent are! The whole "storing checksum files on
> an HTTP server" sounds exactly like what BitTorrent is already doing. :-)
>
>   Cheers,
>   Tyler

Not very similar.

Bittorrent has a per chunk hash so it can validate each chunk when it
recieves it instead of waiting for the full file. It won't see if a
chunk is present at some other position in the file, not even if that
position is also on chunk boundaries.

Rsync has a per chunk Alder-32 and md4 checksum. Those chunk checksums
are compared to a chunk at every byte position in the file. The
Adler-32 checksum is fairly weak but it can be updated from one
position to the next with minimal work. Only when it matches does
rsync compute the expensive md4 checksum for the block.


The only thing that is simmilar is the "per block" when generating the
checksum, which is basicaly nothing.

MfG
Goswin


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

Re: python-minimal

[Steve Langasek]

On Sun, Apr 30, 2006 at 02:08:25PM -0700, Tyler MacDonald wrote:
> Steve Langasek <[EMAIL PROTECTED]> wrote:
> > No, that's not what I said.  The python-minimal package is designed to be
> > used *as* an Essential package, not *by* Essential packages.  Nothing,
> > essential or not, should depend on it in Debian, whether or not
> > python-minimal itself gets marked as Essential: yes.  (As long as
> > python-minimal is not essential, you don't depend on it because it shouldn't
> > be installed without python; if python-minimal *is* essential, you don't
> > depend on it because you don't declare dependencies on essential packages.)

>   I'm playing paranoid here, but why don't you want to declare
> dependencies on essential packages? If the package ceases to be Essential at
> some point in the future, some non-essential packages may still need it's
> functionality, but without this relationship being tracked, the package
> could easily disappear. Wouldn't it be better for the package database to
> have as much information as possible on what uses what, essential or not?

Essential is defined as the minimal set of functionality that must be
available and usable on the system even when packages are in an unconfigured
(but unpacked) state.  This is nedeed to avoid unresolvable dependency loops
on upgrade.  If you add unnecessary dependencies on packages in this set,
you increase the chances that there *will* be an unresolvable dependency
loop caused by forcing these Essential packages to be configured first
before they need to be.  It also increases the chances that frontends will
be unable to *calculate* an upgrade path, even if one exists.

Also, it's pretty unlikely that we'll ever remove functionality from
Essential (which is one of many reasons why we should be cautious about
adding to it), but we *have* removed particular packages from Essential in
the past when the functionality has moved to a different package.

So depending on these packages "just in case" they stop being essential does
way more harm than good.

-- 
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: effectiveness of rsync and apt

[Tyler MacDonald]

Brian Eaton <[EMAIL PROTECTED]> wrote:
> http://rsync.samba.org/rsync-and-debian/rsync-and-debian.html
> 
> Has anyone ever done some log file analysis to figure out how much
> bandwidth would be saved by transferring package deltas instead of
> entire new packages?

Slightly off-topic, but I never realised until I read that article,
how similar rsync and bittorrent are! The whole "storing checksum files on
an HTTP server" sounds exactly like what BitTorrent is already doing. :-)

Cheers,
Tyler


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

effectiveness of rsync and apt

[Brian Eaton]

Hello all -

Regarding the ideas discussed here:

http://rsync.samba.org/rsync-and-debian/rsync-and-debian.html

Has anyone ever done some log file analysis to figure out how much
bandwidth would be saved by transferring package deltas instead of
entire new packages?

Assuming someone hasn't done the work already, I'd be interested in
looking at some logs to figure it out.

Regards,
Brian

Bug#365554: ITP: vdrift -- vdrift

[Gonéri Le Bouder]

Package: wnpp
Severity: wishlist
Owner: "Gonéri Le Bouder" <[EMAIL PROTECTED]>


* Package name: vdrift
  Version : 2006.02.21 
  Upstream Author : Joe Venzon 
* URL : http://www.vdrift.net/
* License : GPL
  Programming Lang: C++
  Description : An open source drift racing simulation
 VDrift is a cross-platform, open source driving simulation made with
 drift   racing in mind. It's powered by the excellent Vamos physics engine.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-amd64-k8
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)

Re: python-minimal

[Russ Allbery]

Tyler MacDonald <[EMAIL PROTECTED]> writes:

> I'm playing paranoid here, but why don't you want to declare
> dependencies on essential packages?

The short answer is "because Policy 3.5 says they shouldn't."  I'm not
positive about the exact rationale, though.

> If the package ceases to be Essential at some point in the future, some
> non-essential packages may still need it's functionality, but without
> this relationship being tracked, the package could easily disappear.

It's fairly unlikely that anything currently included in Essential will
ever be dropped from Essential in the future, at least without a lot of
warning and mass bug-filing on the packages that need to add dependencies.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: python-minimal

[Tyler MacDonald]

Steve Langasek <[EMAIL PROTECTED]> wrote:
> No, that's not what I said.  The python-minimal package is designed to be
> used *as* an Essential package, not *by* Essential packages.  Nothing,
> essential or not, should depend on it in Debian, whether or not
> python-minimal itself gets marked as Essential: yes.  (As long as
> python-minimal is not essential, you don't depend on it because it shouldn't
> be installed without python; if python-minimal *is* essential, you don't
> depend on it because you don't declare dependencies on essential packages.)

I'm playing paranoid here, but why don't you want to declare
dependencies on essential packages? If the package ceases to be Essential at
some point in the future, some non-essential packages may still need it's
functionality, but without this relationship being tracked, the package
could easily disappear. Wouldn't it be better for the package database to
have as much information as possible on what uses what, essential or not?

Thanks,
Tyler



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

Re: python-minimal

[Steve Langasek]

On Sun, Apr 30, 2006 at 04:25:18PM -0400, Joe Smith wrote:

> "Steve Langasek" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
> >On Sat, Apr 29, 2006 at 09:32:52PM -0700, Russ Allbery wrote:
> >>Steve Langasek <[EMAIL PROTECTED]> writes:

> >>> Seems to me that this should be at least a bug report on alsa-utils.
> >>> I'm surprised that there would be a need for a lintian check for it, 
> >>> but
> >>> I guess it's better than letting such bugs go unnoticed.

> >>I can add one; it's not a lot of overhead given that lintian already has 
> >>a
> >>framework for checking for bad dependencies.  It's basically just another
> >>branch in an if statement.

> >>What's the precise check?  Any package depending on python-minimal should
> >>receive an error (or a warning?)

> Based on Vorlon's message:

> If (package depends on python-minimal) and (package is not essential) then 
> ERROR.

No, that's not what I said.  The python-minimal package is designed to be
used *as* an Essential package, not *by* Essential packages.  Nothing,
essential or not, should depend on it in Debian, whether or not
python-minimal itself gets marked as Essential: yes.  (As long as
python-minimal is not essential, you don't depend on it because it shouldn't
be installed without python; if python-minimal *is* essential, you don't
depend on it because you don't declare dependencies on essential packages.)

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


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

Re: Using defoma for building package ?

[Marcus Better]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Josselin Mouette wrote:
> How about using fontconfig ? Even without using the API you can use it
> to look for a font:
> $ fc-match --verbose sans | awk '$1=="file:"'
> file: "/var/lib/defoma/fontconfig.d/D/DejaVu-Sans.ttf"(s)

Is there a way to use fc-match to locate a Type1 font (pfb) and also its
associated font metrics (the afm file)?

Marcus

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

iD8DBQFEVSFhXjXn6TzcAQkRAt1DAKCVI2yEibbdFoNp/pzK7YkbC1ApZACfZtrC
uRwegAoBJyh80IdKeosTrHk=
=CIAw
-END PGP SIGNATURE-


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

Re: python-minimal

[Joe Smith]

"Steve Langasek" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Sat, Apr 29, 2006 at 09:00:53PM -0700, Thomas Bushnell BSG wrote:

The alsa-utils package depends on python-minimal.
As a result, I must now have two versions of python installed.  That's
a bug.
alsa-utils should depend on "python | python-minimal", or perhaps the
python packages should Provide python-minimal.
Does this seem right?


Er... alsa-utils should be depending on python, *not* on python-minimal at
all.  The previous discussion of this package was that python-minimal 
exists

only for the possibility of use as an Essential: yes package, should never
be installed without python, and should not be used as a dependency by 
other

packages.


To clarify, AIUI Python-minimal should never be installed without python, 
unless install of only python-minimal is explicitly requested by the user. 
This is to avoid having to include full python on an embeded Debian, while 
minimizing cases where a user is surprised by missing python libraries. 




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

Re: python-minimal

[Joe Smith]

"Steve Langasek" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Sat, Apr 29, 2006 at 09:32:52PM -0700, Russ Allbery wrote:

Steve Langasek <[EMAIL PROTECTED]> writes:



> Seems to me that this should be at least a bug report on alsa-utils.
> I'm surprised that there would be a need for a lintian check for it, 
> but

> I guess it's better than letting such bugs go unnoticed.


I can add one; it's not a lot of overhead given that lintian already has 
a

framework for checking for bad dependencies.  It's basically just another
branch in an if statement.



What's the precise check?  Any package depending on python-minimal should
receive an error (or a warning?)


Based on Vorlon's message:

If (package depends on python-minimal) and (package is not essential) then 
ERROR.



It's pretty definitely a bug, so AIUI should be marked as an error.


with roughly the text of Steve's previous message?


Short message: "Non-essential package depends on python-minimal."

Long Message: Something along the lines of Steve's meassage.


Uh... sure :)

--
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/






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

Re: irc.debian.org

[Benjamin Seidenberg]

Benjamin Seidenberg wrote:
> Petter Reinholdtsen wrote:
>   
>> [Steve McIntyre]
>>   
>> 
>>> I can see that more and more of my own Debian IRC discussions are on
>>> oftc, to the extent that I'm (currently) not on any freenode
>>> channels at all.
>>> 
>>>   
>> For me it is the other way around.  I am currently on one channel on
>> OFTC, while I am on 7 channels on Freenode, 4 of them related to
>> Debian.
>>
>>
>>   
>> 
> I agree with Steve. While I agree that freenode has many flaws (the
> biggest being NOIDPRIVMSG), I find that while I am in Debian channels on
> both networks, many more open source projects are on freenode, and that
> makes things much more convenient. Even if all Debian development moved
> to OFTC, I'd still stay on freenode for fluxbox, all of the various kde
> components I use, postfix, etc, etc etc. I think it might be better for
> us to try to use our influence as a huge source of users to try to
> better freenode than to just move.
>
>   
Sorry, accidentally sent this to wrong list, should be on -project.



signature.asc
Description: OpenPGP digital signature

Bug#365532: ITP: xfce4-xfapplet-plugin -- Gnome applets plugin for Xfce panel

[Yves-Alexis Perez]

Package: wnpp
Severity: wishlist
Owner: Debian Xfce Maintainers <[EMAIL PROTECTED]>


* Package name: xfce4-xfapplet-plugin
  Version : 0.1.0
  Upstream Author : Adriano Winter Bess <[EMAIL PROTECTED]>
* URL : http://xfce-goodies.berlios.de
* License : GPL
  Programming Lang: C
  Description : Gnome applets plugin for Xfce panel

 XfApplet is a plugin for the Xfce 4 panel. The plugin itself has no
 special functionality, its only purpose is to enable one to use Gnome applets
 inside the Xfce 4 panel just as they are used inside the Gnome panel.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-rc2
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: irc.debian.org

[Benjamin Seidenberg]

Petter Reinholdtsen wrote:
> [Steve McIntyre]
>   
>> I can see that more and more of my own Debian IRC discussions are on
>> oftc, to the extent that I'm (currently) not on any freenode
>> channels at all.
>> 
>
> For me it is the other way around.  I am currently on one channel on
> OFTC, while I am on 7 channels on Freenode, 4 of them related to
> Debian.
>
>
>   
I agree with Steve. While I agree that freenode has many flaws (the
biggest being NOIDPRIVMSG), I find that while I am in Debian channels on
both networks, many more open source projects are on freenode, and that
makes things much more convenient. Even if all Debian development moved
to OFTC, I'd still stay on freenode for fluxbox, all of the various kde
components I use, postfix, etc, etc etc. I think it might be better for
us to try to use our influence as a huge source of users to try to
better freenode than to just move.



signature.asc
Description: OpenPGP digital signature

Bug#365519: ITP: xfce4-screenshooter-plugin -- Screenshots plugin for Xfce panel

[Yves-Alexis Perez]

Package: wnpp
Severity: wishlist
Owner: "Yves-Alexis Perez" <[EMAIL PROTECTED]>


* Package name: xfce4-screenshooter-plugin
  Version : 1.0.0
  Upstream Author : Daniel Bobadilla Leal <[EMAIL PROTECTED]>
* URL : http://xfce-goodies.berlios.de
* License : GPL
  Programming Lang: C
  Description : Screenshots plugin for Xfce panel

Screenshooter is a plugin for Xfce panel usable to takes screenshots of your 
desktop.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-rc2
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Bug#365509: ITP: xfce4-messenger-plugin -- dbus messages plugin for xfce4-panel

[Yves-Alexis Perez]

Package: wnpp
Severity: wishlist
Owner: Debian Xfce Maintainers <[EMAIL PROTECTED]>


* Package name: xfce4-messenger-plugin
  Version : 0.1.0
  Upstream Author : Pasi Orovuo <[EMAIL PROTECTED]>
* URL : http://xfce-goodies.berlios.de/
* License : GPL
  Programming Lang: C
  Description : dbus messages plugin for xfce4-panel

 Xfce4 Messenger Plugin for Xfce4 Panel is a plugin that listens DBus
 messages and displays received messages in panel and/or popup
 window, and maintains a log of received messages.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-rc2
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Bug#365499: ITP: probcons -- PROBabilistic CONSistency-based multiple sequence alignment

[Charles Plessy]

Package: wnpp
Severity: wishlist
Owner: Charles Plessy <[EMAIL PROTECTED]>

  Package name: probcons
  Version : 1.10
  Upstream Author : Chuong B. Do <[EMAIL PROTECTED]>
  URL : http://probcons.stanford.edu/download.html
  License : Public Domain
  Description : PROBabilistic CONSistency-based multiple sequence alignment

 PROBCONS is a tool for generating multiple alignments of protein
 sequences. Using a combination of probabilistic modeling and
 consistency-based alignment techniques, PROBCONS has achieved the
 highest accuracies of all alignment methods to date. On the BAliBASE
 benchmark alignment database, alignments produced by PROBCONS show
 statistically significant improvement over current programs, containing
 an average of 7% more correctly aligned columns than those of T-Coffee,
 11% more correctly aligned columns than those of CLUSTAL W, and 14%
 more correctly aligned columns than those of DIALIGN. Probcons is
 published in  Do, C.B., Mahabhashyam, M.S.P., Brudno, M., and
 Batzoglou, S. 2005.  Genome Research 15: 330-340.
 .
 Homepage: http://probcons.stanford.edu/
 
-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: powerpc (ppc64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16farm
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]

Bug#365501: ITP: xchat-guile -- Guile scripting plugin for XChat

[Lionel Elie Mamane]

Package: wnpp
Severity: wishlist
Owner: Lionel Elie Mamane <[EMAIL PROTECTED]>

* Package name: xchat-guile
  Version : 0.2
  Upstream Author : Zeeshan Ali Khattak <[EMAIL PROTECTED]>
* URL : http://piipiip.net/~zeenix/xchat-guile/
* License : GPLv2 or later
  Programming Lang: C, Guile Scheme
  Description : Guile scripting plugin for XChat

 Plug-in adding Guile scripting support to XChat.
 .
 Guile is the GNU Scheme implementation, and the official GNU
 scripting language. Scheme is a minimalistic, clean Lisp dialect,
 that is a dynamically typed functional impure programming language
 with reflection.
 .
 XChat is a featureful IRC client with a GTK+2-based graphical user
 interface.



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

Re: Possible conflict with XFree 4.5

[Daniel Stone]

On Sun, Apr 30, 2006 at 09:03:19AM -0500, Gunnar Wolf wrote:
> There is no xorg 7.0 backport yet, and I fear it will not be easy to
> add one (as the Debian xorg 7.0 introduced _major_ packaging changes,
> if somebody puts up a backport it will probably be completely made
> from scratch to behave as close as xfree 4.3 as possible).

That would be basically the worst-case scenario, and completely tank all
upgrades, given the huge number of versioned conflicts et al needed to
ensure even a vaguely smooth upgrade.


signature.asc
Description: Digital signature

Re: Possible conflict with XFree 4.5

[Gunnar Wolf]

gustavo halperin dijo [Sat, Apr 29, 2006 at 09:46:09PM +0300]:
> I don't understand your question: "why would you want to use XFree now?",
>what do you mean.
>Do you mean why not use X.org ??.
>Any way the current XFree version in Debian stable is 4.3, this version is
>to old for me. I have a
>Toshiba laptop Portege R100 with trident Cyber Blade XP , with XFree 4.3 I
>can use only vesa,
>I really need to update X-server. Even now I'm thinking to update from
>Xfree 4.5 to X.org last
>revision ([1]X11R7.0) that looks like have fully support for my driver,
>see [2]link.
> Do you have any recommendation how to do it in the best way for my Debian
>system ??

I suggest you to search for a backports repository - You can find some
here:

http://www1.apt-get.org/search.php?query=xorg&submit=Submit+Query&arch%5B%5D=i386&arch%5B%5D=all

There is no xorg 7.0 backport yet, and I fear it will not be easy to
add one (as the Debian xorg 7.0 introduced _major_ packaging changes,
if somebody puts up a backport it will probably be completely made
from scratch to behave as close as xfree 4.3 as possible).

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


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

Soliciting keys for the debconf6 keysigning party in Oaxtepec

[Aníbal Monsalve Salazar]

Hello,

This is the last call for keys for the debconf6 keysigning party
in Oaxtepec.

This coming Saturday is the last date to send your key(s).

If you intend to participate in the debconf6 keysigning party in
Oaxtepec, please send your ascii armored public key as explained at
[0] or, alternatively at [2] by Saturday, 6th of May, 2006.

If you sent your key(s) and haven't received an acknowledment yet,
please look up your name at [1] or [3]. If your name is listed,
send me an email to resend you the acknowledment. If your name is
not listed, please resend your key(s).

[0] http://debconf.org/ksp/ksp-dc6.html
[1] http://debconf.org/ksp/ksp-dc6-names.html
[2] http://people.debian.org/~anibal/ksp-dc6/ksp-dc6.html
[3] http://people.debian.org/~anibal/ksp-dc6/ksp-dc6-names.html

Best Regards,

Aníbal Monsalve Salazar
-- 
http://v7w.com/anibal


signature.asc
Description: Digital signature

Re: fonts prbl in sid

[Michael Meskes]

On Mon, Apr 24, 2006 at 11:38:43AM +0300, Daniel Stone wrote:
> > almost unusable ; including 'emacs-snapshot-gtk' 'display' 'xmms'
> > ('xmms' is missing fonts for the menus but not for the main display);

Not sure if this is related but for display see 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363371

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

Re: gpg

[Martijn van Oosterhout]

On 4/29/06, Tamas SZERB <[EMAIL PROTECTED]> wrote:

all replies tries to tell me that I'm intend to crack the GPG. Believe
me, If I could do it, I would not use it anymore since it's not safe
enough.


Err, the password is not an unchangable part of the key. You are in
the perfect condition to attempt to crack it since you have some idea
of what the password was. If the cracking works, change the password
to something you can remember.


Anyway, at least, I resolved the upgrade from 1024 to more bits, but I
loose my signatures unfortunately. :(


If you can find the password again, you can change it without losing
the signitures...
--
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/

Re: Bug#365425: ITP: haxe -- Web programming languge generating Flash SWF

[Remi Vanicat]

Jens Peter Secher <[EMAIL PROTECTED]> writes:

> Package: wnpp
> Severity: wishlist
>
> * Package name: haxe
>   Version : 0.b5
>   Upstream Author : Nicolas Cannasse
> * URL or Web page : http://haxe.org
> * License : GPL
>   Description : Web programming languge generating Flash SWF
>
> haXe is a programming language similar to JavaScript, but with
> full-featured type system and generics.  The compiler can generate Flash
> SWF files for client-side use, and Neko bytecode for server-side use on
> Apache.
>

The upstream site tell me that it can also "generate Javascript code
using Browser DHTML API, so you can create AJAX web applications"

This should be added to the description.

By the way, I've only read quickly trough upstream site, but it seem
it can be used to make a pure AJAX application, if so, it should be
noted in the long and short description (because there are people who
prefer to note use Flash, but are OK with AJAX).
-- 
Rémi Vanicat


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

Re: Bug#365203: rootskel: Please support the ppc64 architecture

[Andreas Jochens]

On 06-Apr-29 20:51, Frans Pop wrote:
> tags 365203 - pending
> tags 365203 + wontfix
> tags 365345 + wontfix
> tags 339716 + wontfix
> tags 354947 + wontfix
> thanks
> 
> I'm very sorry, but after discussing this during the d-i development 
> meeting and consulting with Release Management, we feel that the ppc64 
> port ever reaching the archives is currently too uncertain to add support 
> for it in D-I packages.
> 
> Please try to get consensus on the future of the port first.

Hello Frans,

thank you for looking at the ppc64 patches and for discussing ppc64 
on the d-i meeting.

I know that there is no consensus about the future of the ppc64 port.

There have been some discussions that the native ppc64 port might be 
useful to provide multiarch support for powerpc/ppc64 in the same way
as for i386/amd64. The ppc64 port is currently the only way to get
a reasonably complete set of 64-bit libraries for ppc64 machines.
But again, there is no consensus about this and there is certainly
no plan to add the ppc64 port to the official archive in the
near future.

Despite of this, I would like to ask the d-i team and all 
other developers to help the ppc64 port by continuing to apply
simple ppc64 patches, which in most cases just add 'ppc64' to the 
architecture line in debian/control and similar places.

Even if the ppc64 port will never be part of an official release,
this should not do any harm. 

Most packages in the archive have already added ppc64 support 
(most notably gcc, glibc and dpkg). The ppc64 archive has about 98% 
of the source packages from the unstable distribution compiled.
Even some d-i packages (netcfg and yaboot-installer) added explicit
ppc64 support some time ago.

Please do not tag wishlist requests for the addition of 'ppc64' 
to the architecture line in debian/control as 'wontfix'.

Regards
Andreas Jochens


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

Re: python-minimal

[Marco d'Itri]

On Apr 30, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:

> The alsa-utils package depends on python-minimal.
Yes, it's very annoying that a dependency on another scripting language
was added because of a trivial script.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: python-minimal

[Steve Langasek]

On Sat, Apr 29, 2006 at 09:32:52PM -0700, Russ Allbery wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:

> > Seems to me that this should be at least a bug report on alsa-utils.
> > I'm surprised that there would be a need for a lintian check for it, but
> > I guess it's better than letting such bugs go unnoticed.

> I can add one; it's not a lot of overhead given that lintian already has a
> framework for checking for bad dependencies.  It's basically just another
> branch in an if statement.

> What's the precise check?  Any package depending on python-minimal should
> receive an error (or a warning?)

It's pretty definitely a bug, so AIUI should be marked as an error.

> with roughly the text of Steve's previous message?

Uh... sure :)

-- 
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/


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