headers
Miles Bader | 1 Aug 01:29
Picon
Gravatar

Re: ITP: ttf-atarismall -- Very small 4 x 8 font

Peter Samuelson <peter <at> p12n.org> writes:
>> If anyone knows how to limit the fontsize to 8 only for a otf/ttf
>> font, please contact me. (The original font is in bdf format)
>
> If this font is intended to be used at one fixed size, why bother with
> ttf/otf at all?  Just ship it as bdf.

Aren't the former formats more generally usable these days (e.g. by
various apps that do their own font blathering, not necessarily for
display)?

-miles

--

-- 
`Life is a boundless sea of bitterness'
Permalink | Reply | 0 comments |
headers
Daniel Burrows | 1 Aug 04:22
Picon
Favicon

Re: Non-security updates between stable releases?

On Tue, Jul 31, 2007 at 12:07:44PM +0200, Adam Borowski <kilobyte <at> angband.pl> was heard to say:
> stable (pinned at 500):  foo=1.0 [Depends: bar>=1.0], bar=1.0
> testing (pinned at 200): foo=1.2 [Depends: bar>=1.2], bar=1.2
> 
> If the user says: apt-get install foo=1.2, apt won't be smart enough to find
> out it needs to upgrade bar as well.  Same for aptitude or any other
> front-end, making pulling packages from testing or experimental a pain.

  That's actually not true in aptitude.

  Daniel
Permalink | Reply | 0 comments |
headers
Antonio Diaz Diaz | 1 Aug 04:01
Picon

Re: Bug#434206: ITP: moe -- powerful text editor for ISO-8859 andASCII character encodings

> I don't think we should be adding more programs to the archive that
> can't handle multibyte encodings.  I believe the default character
> encoding for new installations is UTF-8.

GNU Moe is a console text editor written to be stable, compact and 
powerful. It is the middle point between GNU Ed and GNU Emacs, and it 
deliberately doesn't support multibyte encodings.

When editing configuration files or source code written in ASCII many 
people want something like Moe, not another buggy and/or bloated editor 
of multibyte encodings.

So perhaps it is not so bad the idea of adding GNU Moe to the archive.

Regards,
Antonio.
Permalink | Reply | 835 comments |
headers
Ben Finney | 1 Aug 05:41
Picon

Re: Bug#434206: ITP: moe -- powerful text editor for ISO-8859 andASCII character encodings

Antonio Diaz Diaz <ant_diaz <at> teleline.es> writes:

> When editing configuration files or source code written in ASCII
> many people want something like Moe

Even a humble configuration file can have comments and text strings
with non-ASCII characters; e.g. names of people or organisations.

This is even more true for source code, which frequently have these in
the copyright notices as a simple example.

I don't see how adding an editor to Debian that can't handle at least
the default encoding of the operating system -- UTF-8 -- is in any way
a service to the users.

> , not another buggy and/or bloated editor of multibyte encodings.

If such programs are bloated and/or buggy, this is an entirely
separate issue from whether the program supports UTF-8. Filing bug
reports is always a correct response in such cases.

--

-- 
 \          "Time's fun when you're having flies."  -- Kermit the Frog |
  `\                                                                   |
_o__)                                                                  |
Ben Finney
Permalink | Reply | 0 comments |
headers
Alok G. Singh | 1 Aug 06:26
Picon
Favicon

Re: emacs21 removal?

On 28 Jul 2007, tats <at> vega.ocn.ne.jp wrote:

> I'm starting to submit wishlist bug reports.  If emacs21 is
> removed, I'll submit bug reports to all of the following packages
> with `Severity: serious' or so.

> Ramakrishnan Muthukrishnan <rkrishnan <at> debian.org>
> quack-el

Ramki had stopped maintaining this package sometime ago and I had
adopted it from him. I am not too clear what my next step would be,
but I will read up and do something about it by this weekend.

--

-- 
Alok

Whistler's Law:
	You never know who is right, but you always know who is in charge.
Permalink | Reply | 0 comments |
headers
Alberto Broggi | 1 Aug 07:37
Picon

Re: Thanks!


	Your message was filtered by my personal ANTISPAM filter
	and was classified as SPAM, and therefore DIRECTLY TRASHED.
	If you think this was done by mistake, please resend your
	message, specifying "thru spam" as subject.
	Messages with zip files attached are classified as SPAM.

	Il tuo messaggio e` stato filtrato dal mio filtro personale
	ANTISPAM ed e` stato classificato SPAM, e quindi DIRETTAMENTE
	CESTINATO. Se pensi che sia stato fatto per errore, rimanda il
	messaggio specificando "thru spam" nel soggetto.
	Messaggi con allegati in formato zip sono classificati come SPAM.

	Thanks for writing to me,
	Alberto Broggi

--

-- 
  Prof. Alberto Broggi, PhD
    Dip. di Ingegneria dell'Informazione, Universita` di Parma
    Parco Area delle Scienze, 181/A  -  I-43100  PARMA,  Italy
    E-Mail: broggi <at> CE.UniPR.IT  -  Web: www.ce.unipr.it/broggi
    Phone: +39 (0521) 905707 (GMT+1)  - Fax: +39 (0521) 905723

    Editor-in-Chief, 
      IEEE Transactions on Intelligent Transportation Systems
Permalink | Reply | 0 comments |
headers
Mgr. Peter Tuharsky | 1 Aug 08:05
Picon

Re: Non-security updates between stable releases?

Tim, I couldn't write it better.

3 months ago, there has been a thread with similar topics: Debian 
desktop -situation...

Peter

Tim Hull  wrote / napísal(a):
> Just to follow up, I do appreciate that Debian wishes to cover so many 
> architectures - I even installed Debian on quite possibly the most 
> obscure architecture in the past, m68k (an old Quadra 700).  Would have 
> been funny to attempt a full-blown X install.  Honestly, only NetBSD 
> rivals Debian in that department. However, I will agree that it seems a 
> bit absurd to hold up security fixes for a browser for all architectures 
> based on breakage on a few obscure ones. 
>  
> Getting back to my original question, it still seems like there is a 
> problem (at least for end users on the desktop) with the current release 
> cycle.  Lenny is not slated for release until September 2008, yet Etch 
> will be spectacularly outdated before then (for some, it already is - 
> just ask Gnome users, who are two releases behind *now*).  Testing is 
> not a viable desktop choice (observe the aforementioned security 
> issues), and unstable is really OK only if you are a Linux expert.  It 
> seems to me that something has to be done - whether this be some 
> official backports (especially of popular components like KDE, Gnome, 
> the kernel, etc) or a faster release cycle.  Personally, I prefer the 
> former idea - I don't see a need to update my glibc and gcc every 6 
> months and like the stable Debian base, though I do like to have the 
> latest Gnome.  I think many users are in the same boat.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mgr. Peter Tuharsky | 1 Aug 08:15
Picon

Re: Non-security updates between stable releases?


>         I am not advocating being hostile to novice users; I am saying
>  that we should not cater solely to that segment of our user base;
>  especially at the expense experienced users who have been long using
>  Debian as the basis of productive work.

Some considerations and improvements seem at first glance as "for novice 
users", but they often make sense for proffesionals too.

For example, if Debian Linux makes some choice without bothering the end 
user, and if he does it in logical manner, then not only novice user is 
glad he shouldn't make some cryptic geeky choice that scares him, but 
also the professional often appreciates that he is not wasting his time 
and can concentrate at real work.

Similar if something improves end user comfort somehow, etc.

Sysadmins are slow to explore such improvements and to appreciate them. 
BFU's are much more flexible in this manner :-) However at the end, the 
admins are able to absorb it too.

So, I think the wisdom is in those improvements, that bless BROAD end 
user base.

What is good for BFU is not neccessarily bad for admin!

Peter
Permalink | Reply | 0 comments |
headers
Ron Johnson | 1 Aug 08:51
Picon

Re: Bug#434206: ITP: moe -- powerful text editor for ISO-8859 andASCII character encodings


On 07/31/07 21:01, Antonio Diaz Diaz wrote:
[snip]
> 
> When editing configuration files or source code written in ASCII many
> people want something like Moe, not another buggy and/or bloated editor
> of multibyte encodings.
> 
> So perhaps it is not so bad the idea of adding GNU Moe to the archive.

If the justification is "small, simple text editor", nano is already
in the archives.

--
Ron Johnson, Jr.
Jefferson LA  USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!
Permalink | Reply | 0 comments |
headers
Andreas Tille | 1 Aug 09:08
Picon
Favicon

Re: Prevent pdebuild from removing temporary build dir

On Tue, 31 Jul 2007, Pierre Habouzit wrote:

>> How about using pbuilder hooks?  Something like $hookdir/C01_shell:
>>
>> --- 8< ---
>> #!/bin/sh
>>
>> cd /tmp/buildd/*/debian/..
>> /bin/sh < /dev/tty > /dev/tty
>> --- 8< ---
>
>  you may even want to have some usable env, and enhance it that way:
>
>    [artemis] cat .pbuilder/C10_launch_shell
>    #!/bin/sh
>    # invoke shell if build fails.
>
>    echo "I: installing necessary tools to work in the damn chroot"
>    apt-get install -y --force-yes vim zsh &>/dev/null
>    dpkg --purge nvi
>
>    cd /tmp/buildd/*/debian/..
>
>    /bin/zsh < /dev/tty > /dev/tty

Sounds like what I'm looking for but I have problems to implement this
hint.  I tried pdebuild --hookdir $HOME/.pbuilder and also added
HOOKDIR=/home/myhome/.pbuilder to my .pbuilderrc but there is no visible
effect.  Did I missed something?
(Continue reading)

Permalink | Reply | 7 comments |

Gmane