Bug#299771: ITP: ttf-antp -- Antykwa Poltawskiego font family

[Adam Borowski]

Package: wnpp
Severity: wishlist
Owner: Adam Borowski <[EMAIL PROTECTED]>

* Package name: ttf-antp
  Version : 0.51
  Upstream Author : Bogus³aw Jackowski, Janusz M. Nowacki and Piotr Strzelczyk
* URL : http://www.janusz.nowacki.strefa.pl/poltawski-e.html
* License : GPL
  Description : Antykwa Poltawskiego font family
  Long desc   :
 This font was designed by Adam Poltawski in 1923-28 as a result of his
 research on readability of letter forms.  Even though this typeface is
 pretty dated now, and the readability of screen fonts obeys different
 rules than it does on paper, this font still beats Bitstream-Vera when
 applied to large blocks of text.
  Packages: http://angband.pl/debian/


I'm not sure if a single font family warrants a separate package.  Still, it
would be good to have this one in Debian as generally the readability of
existing free fonts is poor.

Compared to Bitstream Vera (which is currently the default Gnome font),
Antykwa Poltawskiego looks a lot better for larger chunks of text (as in a
web browser, text documents, etc) while being worse when it comes to
rendering random window text (dialogs, menus, etc).

The hinting information differs from upstream, as the upstream hints play
really poorly with freetype.  The hints I included (produced by fontforge
with hardly any manual intervention), on the other hand, fare pretty well,
as does the freetype autohinter.  On the gripping hand, now the win32
renderer hates the hints, but hey, the last time I checked, debian-win32
was dead...


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

Re: Bug#299771: ITP: ttf-antp -- Antykwa Poltawskiego font family

[Adam Borowski]

On Wed, 16 Mar 2005, Frank Küster wrote:
> Miros/law Baran <[EMAIL PROTECTED]> schrieb:
> > The font is included in the tetex-base package, along with other Type1
> > GUST-sponsored fonts (Antykwa Toru?ska etc.) - I think such a package
> > will be redundant.
>
> Well, tetex-base only has the afm and pfb files, along with some
> TeX-specific stuff.  There are no TrueType fonts; having them might be
> worth a package.
Is it even possible to directly use TeX fonts from a high-level
GTK/whatever program without modifying the program in question?  If so,
it's way too unobvious for me...

> Which sources did you use - AFAIK the original format is Metafont?
According to the papers upstream published, it was done using Metafont,
Metapost and Metatype1, and _then_ heavily processed.  The available
formaps are Type1 and TTF, I used the latter.

> Did you submit your new hinting to the upstream authors at gust.or.pl?
Well, you're overestimating my part.  What I did was _removing_ the
existing hinting, as it's worse than no hints at all.

I did attempt improving the upstream hinting, however, I noticed that
simply letting FontForge autohint it gives astonishing results (mostly
for the Regular and Bold variants).  For example, the "e" glyph is a tiny
bit below the line, making the original hints put the lowest part a pixel
lower than it's the case for most other letters.  FontForge can
automatically correct this -- and so does FreeType's autohinter.  It may
be a coincidence that autohinting works so well here, or perhaps simply
Poltawski did a very good job.

GUST provides a number of other fonts, but the only other original one is
Aktykwa Torunska.  It doesn't look as good on the screen, however (but
it's not bad either).  Both fonts share the general resemblance, and the
latter one has much wider charset coverage.  Perhaps it may be a good idea
to provide both in this package...  your call.


Anyway, a scientific poll conducted on three people proved that Antykwa
Poltawskiego looks "much better" that Bitstream Vera for places where 
serif fonts fit.  IMO they're right :p and good fonts are valuable, thus 
this ITP.

1KB
-- 
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)

Re: how to deal with screwed up package

[Adam Borowski]

On Sat, 19 Nov 2005, Bartosz Fenski aka fEnIo wrote:

I'm working on new package for FUSE[1]. Sad to come clean, but I screwed
previous package(s) up. There are plenty of bugs wrt debconf questions and
actions after them. There is also request[2] to simplify or even remove
questions at all.

Now I'm undecided what to do. The idea was to ask user for the group (gid)
that members will be able to use fusermount (sgid).


-rwsr-xr-x 1 root fuse 18360 Oct 14 18:58 /usr/bin/fusermount
Smells suid-ish to me...


If group was absent,
then postinst script was creating it, and put its name in
/etc/default/fuse-utils. But if chosen group existed already, then its name
is also in mentioned file.


As of the current version, fuse-utils will delete the group even if it 
hasn't created it -- this is not what someone would expect.


What about removing all debconf questions, creating/removing the "fuse" 
group unconditionally, and telling the user that chmod is -> over there.
The current code uses /dev/fuse -- if the user can access that device 
within his/her privileges (group/ACLs/what not), you may allow him/her to 
proceed, and deny access otherwise.



The manpage would list two ways to let users use fuse:
* adduser some_user fuse
* [non-udev] chmod :some_group /dev/fuse
  [udev] edit /etc/udev/permissions.rules (owned by the "udev" package,
  and thus out of reach of "fuse-utils" anyway)
As the admin is supposed to read the manpage anyway, educating him in the 
debconf messages is not really needed.


Regards.
--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)


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

Re: Debian Installer team monthly meeting minutes (20051214 meeting)

[Adam Borowski]

On Mon, 19 Dec 2005, Bernd Eckenfels wrote:

In article <[EMAIL PROTECTED]> you wrote:

use nameif.


This has been suggested before but AIUI nameif has problems/limitations
renaming eth0.


Well, you just cant use existing names (this could be fixed, however i am
not sure if this is needed)


It can be trivially worked around by:
nameif blah 00:30:4F:04:C1:61
nameif eth0 00:50:BF:91:28:E5
nameif eth1 00:30:4F:04:C1:61

Too bad, nameif is currently unable to use this workaround on its own,
need to write this by hand.



We could enhance the ifup interfaces file format to use MACs as interface
identifiers and have an additional labeling statement. (i know it can be
done with other means right now but I think it sould be introduced as first
class citizen - AIUI just like suse does):

iface 00:00:C0:A1:E7:CD inet static
name lan0
address 10.0.0.3
network 10.0.0.0
netmask 255.255.255.0
broadcast 10.0.0.255
gateway 10.0.0.1
up route add -net 10.0.0.0 netmask 255.0.0.0 gw 10.0.0.1 || true

We could even "just" change the kernel to asign a name eth, then
most likely no new features are needed.


This is a WONDERFUL idea!  nameif has /etc/mactab which uses a similar 
concept, however:
1. all data about interfaces should be kept together, instead of being 
strewn across 92587239839 files.  Having the ifname<->MAC mapping in the 
same place as ifname<->IP and ifname<->netmask would be the logical thing 
to do.
2. nameif has issues when using /etc/mactab.  I can't remember the exact 
problems as I can't access that machine right now, but I couldn't get 
nameif to work that way.
3. nameif doesn't work unless the interface being renamed is down.  It 
doesn't know that anything that is up can go down for a moment -- but, the 
code which reads /etc/network/interfaces does exactly what we need: it 
puts down all interfaces, reconfigures them and then brings them up again.

Renaming them to what the sysadmin wants is a natural step to do.

Regards.
--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)


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

Re: Debian Installer team monthly meeting minutes (20051214 meeting)

[Adam Borowski]

On Mon, 19 Dec 2005, Marco d'Itri wrote:

On Dec 19, Steve Langasek <[EMAIL PROTECTED]> wrote:


Is there some reason we should be unable to provide a smooth upgrade path
for users of sarge?  Having your network devices scramble themselves on
reboot is a Big Deal, whether or not it's in the release notes.

This often happens anyway when switching between 2.4 and 2.6 kernels, so
it's something users have always needed to be aware about.


Except, you switch from 2.4 to 2.6 only once per server, and this is a big 
change where one _expects_ things to possibly go wrong.


--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)


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

Re: switching to vim-tiny for standard vi?

[Adam Borowski]

On Tue, 20 Dec 2005, Steve Greenland wrote:

On 20-Dec-05, 09:56 (CST), Gabor Gombas <[EMAIL PROTECTED]> wrote:

On Tue, Dec 20, 2005 at 08:57:08AM -0600, Steve Greenland wrote:

[1] Dark blue on black. Need I say more?

The reality is that visibility of color combinations is heavily
dependent on all kinds of things that vim can't determine, from the font
being used and the default background color, to the ambient lighting
of the room and the vision capability of the user (not just color
blindness, but very fine variances in the color sensitivity of the user,
or even how tired the person is, which can affect their ability to
focus.) Color really needs to be tuned to the needs of the individual
user.


The color depends a lot more on the monitor in question, rather than the 
user.  Nearly all of us with full color vision have roughly the same 
sensitivity to all colors -- but, monitors of different manufacturers and 
of different age vary a lot.


But, it's trivial to fix this issue.
On Linux console, PuTTY and a good deal of terminal emulators:
echo -ne '\e]P4ff'
(ESC ] P  )

You can put your palette into /etc/issue, bash prompt or anywhere else.

On real xterms, you can mess with X resources.
On gnome-terminal and konsole, you waddle through the GUI.


If you happen to use CRT monitors that are more than a couple years old, 
improving the color palette is pretty much a must.


--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)


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

Re: switching to vim-tiny for standard vi?

[Adam Borowski]

On Tue, 20 Dec 2005, Henning Makholm wrote:


Scripsit Gabor Gombas <[EMAIL PROTECTED]>

Now, if your terminal pretends to be xterm but does not use the color
scheme of xterm, how should vim know that?


You can't.

real console: TERM='linux'
xterm: TERM='xterm'
gnome-terminal: TERM='xterm'
konsole: TERM='xterm'
PuTTY: TERM='xterm'
rxvt: TERM='rxvt'
aterm: TERM='rxvt'
wterm: TERM='rxvt'



I would suggest that the right solution is that every program that
sets foreground colors should also, as its default behavior, make sure
to set a background color that goes well with the chosen foreground.
The "if you pick one color, pick them all" maxim of web design works
for non-web user interfaces, too.


Good idea.
Just stick \e[40m into the program's color codes and suddenly the scheme 
becomes XXX-on-black.  Use \e[47m and you get XXX-on-white.  And, if 
termcap/terminfo claim the terminal doesn't support \e[4Xm, it's termcap 
which is wrong -- according to my data, Win3.1..ME telnet.exe was the last 
terminal emulator in existence which can't handle these.




Even with a genuine xterm users can and do set their personal color
scheme preferences in X resources. But if you're going to override the
foreground color you might as well also override the background
one. Of course any good program should offer per-user customization of
its color scheme, and offer "default" as an option for background
color, in case the user's preferred background is not among the ones
that can be set with ordinary "setb/setab" strings.


Few fancy terminal emulators obey X resources, but you're right.  While 
the way to set the color palette differs, all of the terminals I named in 
this message provide a way to do so.


However, you're wrong if you believe "setb/setab" are good for anything. 
Since termcap and terminfo are based on the value of "TERM", they assume 
some random settings which are hardly ever valid.
The list I put in the beginning shows that even terminals which use 
completely different code bases and have little coverage of common 
standards tend to claim they're "xterm".  And that's only several 
terminals included in Debian.  If you go outside, things get a lot worse; 
the most spectacular example happens if you log on into a SunOS machine 
using any of three terminals shipped with IRIX (as of ~7 years ago).

The failure mode includes removingallcolorsandallspaces.

It may sound strange, but if you want portability, you can't use termcap, 
terminfo or *curses -- but on the other hand, using lowest-common-
denominator vt100 codes, \e[ foo m and ioctl(TIOCGWINSZ) makes things work 
perfectly everywhere I tested save for the damned telnet.exe.


--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)


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

Re: when and why did python(-minimal) become essential?

[Adam Borowski]

On Tue, 17 Jan 2006, Anthony Towns wrote:

On Mon, Jan 16, 2006 at 09:45:29PM -0500, Eric Cooper wrote:

I saw today that the python-minimal package in unstable is tagged as
Essential (and currently pulls in python2.3).  According to policy,
this is supposed to happen only after discussion on debian-devel and
consensus is reached, but I couldn't find that discussion in the list
archives.


I've changed the override to Priority: standard; I can't say I'm remotely
impressed by how this has been handled.


Could this be stopped, please?  I don't know much about the Debian base 
management, but if I recall correctly, Python used to be kept away 
specifically to stop the base bloat.


A quick comparison of fresh unconfigured i386 chroots:

94420   woody
146140  sarge
160264  etch
185444  sid

a +25MB increase, even though etch is nearly in sync.

With standard/important packages, you simply don't install them; removing 
required/essential ones is not trivial.  Extra bloat doesn't 
noticeably hurt Ubuntu because Ubuntu doesn't try to support memory 
sticks, old hardware, embedded things or farms of tiny virtual machines; 
Debian does.  No one cares about wasting some memory and disk space on a 
modern desktop.


Also, I can't think of any important packages that need Python.  Let's 
check a few of my systems:

* firewall/squid/WWW/samba/mail/DNS server (Sarge, headless)
apt-listchanges, reportbug
* Postgres/MySQL (Sarge, headless)
apt-listchanges
* firewall/squid/DNS cache (Sarge, headless)
apt-listchanges
* router (Sarge, headless)
-
* desktop (Sid)
apt-listchanges, reportbug, btdownloadcurses (IIRC, it's off)

So, it's not a matter of scripts that exist but a matter of possible 
future stuff.  And since the DDs who work on base all have good sets of 
skills at least in Perl ans Bash, keeping Python at standard or less 
won't really hurt anything.


--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)


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

Re: when and why did python(-minimal) become essential?

[Adam Borowski]

On Tue, 17 Jan 2006, Michael Banck wrote:

On Tue, Jan 17, 2006 at 01:28:07PM +0100, Adam Borowski wrote:

On Tue, 17 Jan 2006, Anthony Towns wrote:

I've changed the override to Priority: standard; I can't say I'm remotely
impressed by how this has been handled.


Could this be stopped, please?


I am not sure why you are replying to Anthony, if you read his mail, you
see that he *has* stopped this.


Hey, since when replying to someone implies that you disagree with him? 
It can as well be a case of AOL -- and I provided some arguments to help 
his case in what appeared to be a start of a possible flamewar.



I guess this was a honest mistake from Matthias, he accidently uploaded
a package not stripped of the Ubuntu-specific Essential: yes tags.


I was just whining about:
Obviously, python2.4-minimal is what Ubuntu includes in its essential 
set; so presumably the idea is to move Debian to a similar arrangement.



no reason for the world to end.


You're underestimating the grave consequences of losing 25MB off every 
memory stick and virtual machine.  The increased costs of hardware will 
topple our economy, and the extra power drawn by the equipment will 
accelerate the global warming to a point where Earth will turn into bad-sf 
style land of lava and inferno within our lifetime.  And you'll struggle 
to survive with the knowledge that I warned you.


--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)


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

Re: Amendment to GR on GFDL, and the changes to the Social Contract

[Adam Borowski]

On Thu, 9 Feb 2006, Marco d'Itri wrote:

Well, maybe the people who mislabeled the "everything is software" vote
as an "editorial change" and deceived many other developers should have
tought about this.


There are two different definitions of the word software:
1. something that can be represented as a finite stream of bits
2. a computer program

Definition 1. is precise, definition 2. is not (PostScript, pseudocode, 
programs in scripting languages, examples in documentation, string data,

embedded graphic, icons, Perl pod, etc...), leading to questions like:
"this program outputs 'Hello world', the code is under GPL, the data 
cannot be modified -- does this meet DFSG?"


Another example: the best piece of documentation on vt codes I found is
in /usr/src/linux/drivers/char/vt.c.  For me, it was documentation, for
most of us, it's only code.


Thus, the "editorial change" was simply "changing the wording to something 
disambiguous".  This is clearly just an editorial change _unless_ someone 
mistakenly assumes the other interpretation.  Which seems to be the case 
here.



Suddenly changing the rules to allow non-free documentation would lead to 
significant practical problems.  For example, I once ported a piece of 
software (meaning 2.) to Solaris, IRIX and BSD, raiding the man pages for 
each of these systems, copying snippets directly into my code (#ifdefed 
and autoconfed).  I am allowed to do so.  The glibc version of the 
relevant code predates GFDL, but if I was doing the porting today, I would 
be forced to reinvent the wheel (around two screenfuls of code).  And 
supposedly GNU is all about freedom...


--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)


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

Re: Bug#355488: ITP: bcpp -- C(++) beautifier

[Adam Borowski]

On Mon, 6 Mar 2006, Hendrik Sattler wrote:

Can you explain that?

Either the '{' and '}' are one indentation level down or the same indentation
level.


Hah!  Not in GNU.
The GNU coding standards want you to indent '{' and '}' x/2 spaces, while 
the code inside is indented x.  So, the result is:


if (foo)
{
bar;
baz;
}

Yes, this is bizarre -- but at least GNU folks don't stick the opening
brace in the same line as "if" like certain heretics do.

You can find as many strange coding styles as you can find religions or 
editors.  And all of them have their fanatical believers who are ready to 
stone heathens.


--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)


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

Re: Bug#380388: ITP: toga2 -- computer chess engine, calculates chess moves

[Adam Borowski]

On Sun, Jul 30, 2006 at 01:01:56PM +0200, oliver wrote:
> At Saturday 29 July 2006 22:15 wrote Henning Makholm:
> > Scripsit Oliver Korff <[EMAIL PROTECTED]>
> > >   Description : computer chess engine, calculates chess moves
> > We seem to have several such engines already. Could the description
> > please say something that distinguishes this from the other ones?
> 
> In the short description? Difficult, I could mention a "chess strength" of 
> 2700 ELO, but would have to describe ELO. And I will get a discussion about 
> how I get to this number.

I would say that for any literate enough person, the phrase "chess
strength of 2700 ELO" is self-descriptive.  It includes a number and
an unit of measure -- for those who do not know that unit, it is
named "chess strength".

So, adding anything more would be excess wordage.

-- 
1KB // Q: How do you spot a good inetd?
// A: It build-depends on equivs.


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

Re: release update: freeze, RC Bug count, python, toolchain

[Adam Borowski]

On Tue, Aug 08, 2006 at 11:45:46PM +0200, Andreas Barth wrote:
> Full IPv6 support
> =
> 
> There has been some confusion about the Etch release goal about IPv6. Our
> understanding of that release goal is that all network applications should be
> able to work with both IPv4 and IPv6. Also stateful packet filtering should
> work for both protocols. Please consider all bugs tagged "ipv6" to be
> upgraded to at least important - or even better, fix them.

How invasive ways are welcome/allowed?

For example, I use pound (a reverse proxy/URL redirector/SSL wrapper).
* unstable has 2.0
* I use 2.0.9 with my partial (listen-only) IPv6
* upstream just released 2.1
The maintainer seems to be MIA.  I didn't unload my patches (IPv6, WebDAV)
into the BTS yet as upstream kept saying they'll release "tomorrow" or "in
three days from now" for a few months.  The new stable upstream release got
released on Saturday, but I've been sick so I didn't port my IPv6 patch to
2.1 yet; it should be done and tested soon, though.

So, should I:
a) make a backport to 2.0; or
b) provide patches for the current upstream (2.1) only; or
c) do a complete overhaul, including unrelated issues; giving the maintainer
   a tarball and svn

(Of course, asking the maintainer again is the first thing to do)

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Status of inetd for etch

[Adam Borowski]

On Thu, Aug 10, 2006 at 10:56:01PM +0100, Roger Leigh wrote:
>   The inetd daemon installed by default:
> etch:   openbsd-inetd | netkit-inetd
> sarge:  netkit-inetd
> woody:  netkit-inetd (netkit-base, split from netbase)
> potato: (in netbase)
> slink:  (in netbase)
>   Users upgrading from woody or sarge to etch will not be switched to
>   openbsd-inetd, whereas new installs will use it by default.

Why, for the love of Cthulhu, does netbase depend on inetd in the first
place?  Let's see:

netbase:
critical network configuration.
It has some ancient cruft like /etc/services (which does more ill
than good), but /etc/init.d/networking is not something one wants to
skip.

inetd:
a way to set up ad-hoc network servers.


Now, let's see what depends on *-inetd:
  Depends:
lukemftpd
wipl-client-java
pawserv
netbase
bitlbee
micro-httpd
wipl-client-inetd
ltsp-server
noffle
  Recommends:
atftpd
  Suggests:
micro-proxy
education-main-server
Throw in a few packages which can optionally use inetd but don't specify the
dependency.


It would be good to get rid of inetd from the basic install at all.  Those
who need it can simply, well, install it -- and packages can use Depends:
on flavour-inetd just like the rest of facilities in Debian.  As an added
bonus, you don't have to bother with drop-in replacements as whatever
depends on an inetd can list the flavours it can use as alternatives in its
Depends: line.


As it stands today, I currently use equivs on all of my boxes.  This can
potentially break dependencies if I install something that happens to
actually need inetd.


Cheers and schtuff,
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Status of inetd for etch

[Adam Borowski]

On Fri, Aug 11, 2006 at 12:29:48AM +0200, Marco d'Itri wrote:
> On Aug 10, Roger Leigh <[EMAIL PROTECTED]> wrote:
> >   - Some inetds automatically listen on v6, whereas others need it
> I call them "broken". I believe that administrators do not expect that
> services are exposed to IPv6 connections unless they are configured this
> way in inetd.conf.

A service can listen:
+on a specific address
  In this case, it won't be exposed to IPv6 anyway.
+on all addresses
  Here, it SHOULD accept IPv6 without any explicit configuration. 
  Otherwise, you'll force the admin to look up the way to enable it,
  something that invariably will be done differently for every single
  service.  And I can assure you that 99.9% folks won't bother.  As a
  result, we won't have IPv6.  Not good.
  "All addresses" means "all addresses, be they IPv4 or IPv6" in my book.


At least, the usual services like apache, apache2, sshd or exim4 work this
way.  Bind9 doesn't, and I'm filing a wishlist on it.


Cheers and schtuff,
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Status of inetd for etch

[Adam Borowski]

On Fri, Aug 11, 2006 at 01:34:39AM +0200, Marco d'Itri wrote:
> On Aug 11, Adam Borowski <[EMAIL PROTECTED]> wrote:
> > Why, for the love of Cthulhu, does netbase depend on inetd in the first
> > place?  Let's see:
> Historical reasons.
> 
> > Now, let's see what depends on *-inetd:
> Under the current rules these packages are buggy, unless they have a
> *specific* reason to depend on a specific inetd.
Right, that's why a generic "inetd" virtual package would be a good idea.

> > It would be good to get rid of inetd from the basic install at all.  Those
> No, it would not. UNIX systems are supposed to have an inetd installed.
Just like they used to be supposed to have telnetd or csh.

But even if it is left as priority:standard, it obviously shouldn't be
depended on by netbase.  I don't have portmap installed anywhere either --
but it at least can be easily ripped away, even though nfs deserves to be on
an Unix system a lot more than inetd does.


-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: dpkg doing wrong math (0.09 = 0.9) ?- [was: dak now supports ~ in version numbers]

[Adam Borowski]

On Fri, Aug 11, 2006 at 08:30:45AM +0100, martin f krafft wrote:
> also sprach Michael Biebl <[EMAIL PROTECTED]> [2006.08.11.0012 +0100]:
> > 1.) Wait for a 0.10 release. I think my users wouldn't be happy ;-)
> 
> Why not continue to current versioning scheme until 0.10 is out to
> avoid the epoch?

Yeah -- and the improvement between 0.09+0.1.svn and 0.1~svn isn't big
enough to warrant an upload anyway.  The former is much nicer than
1:0.1~svn, too.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: dpkg doing wrong math (0.09 = 0.9) ?-

[Adam Borowski]

On Fri, Aug 11, 2006 at 07:17:43AM +0200, Florian Weimer wrote:
> "." is not special as far as version numbers are concerned.  It's not
> a separator, for instance, and "1." is a valid version number (which
> is equal to "1.0").

Uhm, where does the "0" come from?  This is grossly unintuitive, and I would
consider this a bug.  Both strings parse as follows:

"1."  => "", 1, "."
"1.0" => "", 1, ".", 0

Lexicographically, the former is obviously smaller.  In every single version
comparison scheme I saw before, non-numeric and numeric parts get compared
alternatively until a mismatch is found.  It's just dpkg which instead
parses both strings as:

"1."  => ("",1), (".",0)
"1.0" => ("",1), (".",0)

That is, dpkg will make up a 0 at the end.
 
> We need a total ordering of version strings, and any approach is
> arbitrary to some degree because we don't want to use purely
> lexicographic comparison (otherwise, "9.x" would be greater than
> "10.x", which is clearly counterintuitive).  There are upstream
> version number schemes for which the Policy algorithm works perfectly
> well (1.01, 1.02, ..., 1.09, 1.10, ...) and others where it doesn't.

GNU strverscmp() will handle numeric substrings starting with a 0
differently, leading to a switch and possible breakage once "09" turns into
"1" ("09" < "1" < "10", but "19" > "2" < "20".  This what I call unnecesary
complication, and it's obvious why this is bad.

I think the same about inventing a "0" from thin air.

And another bug: "2a.0" is _lesser_ than "2.0"!  This works as documented,
but is totally against lexicography, expectations and common sense.


-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: dpkg doing wrong math (0.09 = 0.9) ?-

[Adam Borowski]

On Fri, Aug 11, 2006 at 09:47:33AM +0100, martin f krafft wrote:
> also sprach Adam Borowski <[EMAIL PROTECTED]> [2006.08.11.0931 +0100]:
> > And another bug: "2a.0" is _lesser_ than "2.0"!  This works as
> > documented, but is totally against lexicography, expectations and
> > common sense.
> 
> I'll shoot anyone who uses such a version number. :)

Then I need to invest in body armour.  This is how I mark a release when
only a minimal change that doesn't warrant to have its version bumped in the
regular manner happens.
Fortunately, in all the cases so far the letter was placed after the last
numeric part, so even with a Debian revision attached the dpkg misdesign
would be mitigated as dpkg special-cases the last hyphen.

An example of such a scheme:
  1.0.6
  1.0.6a (a few hours later, with a brown-paper bug fixed)
  1.0.7

In another case, I have an auto-versioning where releases are tagged
0.20060811 (epoch-guard.date).  If two checkouts happen on the same date,
the makefile target will tag the second one 0.20060811a (or b, c, etc).

Or, in file names:
a proxy I wrote will wrote incoming connections to files named
$date.$time.$format.bz2; if two connections come in the same second (a rare
case), the latter will be named "2006-08-11.14-07-58a.bz2", proceeding with
b, c, aa, ab, zz, aaa and so on.
No one uses dpkg --compare-version to sort file names, but in this case, it
would break.


So, is there anything wrong in any of the three examples I shown above?  I
would call that a pretty natural scheme.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Remove cdrtools

[Adam Borowski]

On Mon, Aug 14, 2006 at 09:52:01PM +0200, Wouter Verhelst wrote:
> On Mon, Aug 14, 2006 at 10:58:13AM -0500, Steve Greenland wrote:
> > On 12-Aug-06, 09:09 (CDT), Jon Dowland <[EMAIL PROTECTED]> wrote: 
> > > At 1155391794 past the epoch, Bernd Schubert wrote:
> > > > Btw, why always the autotools while there's this nice
> > > > cmake? 
> > > 
> > > I've never used cmake myself, so I can't speak for how nice
> > > it is, but autotools (for all its problems) is very
> > > widespread.
> > 
> > So is syphilis. That doesn't make it desirable.
> 
> Syphilis is a disease. Software usually isn't.

For those who disparage automake:
* apt-get source tcng
* say a prayer; using multiple pantheons is a good idea
* take a look at its Makefiles
* have a drink or ten
* for x in `find -iname Makefile`;do dd if=/dev/random ...

For those who disparage autoconf, a look at Schily makesystem will
have a similar effect.

THESE are syphilis or worse.
 
> In the case of autotools, the fact is that usually it's configure.ac or
> Makefile.am being horribly broken, rather than the autotools.

Autotools do require you to do things the way they want, indeed.  And
every single autotool uses a different obscure language.  Some
consistency would be good -- but, I challenge you: write something
that works better.  There's a lot of deficiencies in autotools, but
everything so far is A LOT worse.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Debian ISOs

[Adam Borowski]

On Wed, Aug 23, 2006 at 03:34:34PM -0600, Bruce Sass wrote:
> On Wed August 23 2006 12:32, Blars Blarson wrote:
> > In article <[EMAIL PROTECTED]>
> > [EMAIL PROTECTED] writes:
> > >When a nice bittorrent frontend is installed, the user will only
> > > have to click on the link to start the download. This is true for
> > > Windows and Linux.
> > You left out the reconfigure the firewall(s) step.  Not only is this
> > non-trivial, the user may not have the ability to do so.
> 
> This is a bit of a red herring. Torrents work without re-configuring 
> firewalls, they just don't work as well.

They don't work well if there's NAT[1] involved, you wanted to say.  Do I
need to point out a wonderful opportunity to push in some IPv6 propaganda?

Too bad, most torrent clients seem to be heavily lagging behind the rest of
network software even though it's them who would benefit the most from
peer-to-peer (duh) addressing.  Most but not all, and since you get to
choose both the tracker software and the suggested clients...


The relevant download page can say this.
* if you have only IPv4, you can still use bittorrent.  If you're behind
NAT, your download speed will suffer unless you can reconfigure your
firewall (->discussion).
* if you can't run bittorrent at all, you'll have to fall back to ->http or
->ftp.  This method should work everywhere, although it puts a strain on our
servers.
END

I hope this is dumbed down enough to handle users who would be capable to
reconfigure their firewalls in the first place.  If they have that much
clue, it's a waste to use a bittorrent-specific one-time fix instead of the
Final Solution to the NAT Question.


[1]. In the typical sense of the word, that is.
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Why does Ubuntu have all the ideas?

[Adam Borowski]

On Thu, Aug 24, 2006 at 07:29:22PM +0200, Bastian Venthur wrote:
> John Goerzen wrote:
> > On Thu, Aug 24, 2006 at 06:16:49PM +0200, Bastian Venthur wrote:
> >>> which is definitifly a thing of the Kernel (Linux) which depend
> >>> on the support of the hardware manufacturer.  If you want to
> >>> get better hardware support, please contact the manufacturer.
> >> Because, hardware support seems to be better in Ubutuntu than in Debian?
> >> I've not tested it by myself, but I've heard from many people claiming
> >> that their hardware (especially Laptop hardware) works perfectly out of
> >> the box with Ubuntu but is a PITA to get working on Debian.
> 
> > So it all depends on your perspective.  If you narrow your perspective
> > to "ia32 laptop hardware", perhaps Ubuntu supports more.  If you expand
> > it, I would say Debian supports more.
> 
> I absolutely agree with you, off course Debian supports more hardware
> than Ubuntu. But that was not the point, Michelle claimed that hardware
> support depends entirely on the kernel, which is IMHO only one half of
> the truth. The end user usually understands under "hardware support",
> how well the system recognizes hardware and it's ability to get it
> working with a minimum of user interaction required. And from what I've
> heard Ubuntu seems to be ahead of Debian at this point.

My personal opinion about Ubuntu stable vs Debian stable:
* newer kernels
* nearly completely untested

In other words, Ubuntu _is_ ahead of Debian, both in the positive and
negative sense.  It releases a lot more often, so it obviously features more
recent kernels.  On the other hand, Ubuntu strongly suffers from the
tendency to include all the newest unstable doodads, so the path:

Ubuntu -> experimental -> unstable -> stable

is trodden often these days.  In the term of hardware drivers, people put
very little effort into stabilizing them once they appear to be working, so
for ia32 hardware coverage, Ubuntu does fare better on the average.  This
doesn't excuse them from shipping buggy drivers, which they do.


You can choose between a stable, solid distribution that lacks the newest
trinkets and something on the cutting edges that explodes at touch.  Testing
things takes time, and this is exactly what Debian does.  Is the choice
between Debian and Ubuntu a bad thing?

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Why does Ubuntu have all the ideas?

[Adam Borowski]

On Sat, Aug 26, 2006 at 02:01:21AM -0400, Benjamin Seidenberg wrote:
> Michelle Konzack wrote:
> > Since I have no valid ID-Card (problens with France, since I am origin
> > iranish/turkish witeh illegal german adoptivp arents) I can not enter
> > the NM... nobody can sign legaly my GPG key and more bs.
> >
> > Maybe if I go back to Iran or Turkey it would be possible for me.
> 
> You can always use a Transnational Republic ID card.

I am pretty sure Michelle has at least _some_ sort of ID, even as an
illegal alien.  And with the current anti-Arab scare she would be
already deported were she lacking complete valid papers -- you can
sit in peace if you don't travel anywhere, but by browsing
debian-devel I get the impression Michelle travels around a lot.


And, there is a number of ways to reasonably prove your identity
better than an ID.  And ID can be gotten by talking to an
absent-minded clerk, bribing the said underpaid clerk or even get a
nice blank one from Ivan -- so an ID cannot be deemed a solid proof.

Michelle, you're not a nobody.  Many people know you.  If I walked
with you to a known figure who knew you for a number of years and he
vouched for you, I would be a lot more certain than if I had seen
nothing but a smudged photo on an ID.  You can bribe or sweet-talk the
guy to fool me, but I still would call an university professor or the
like someone more trustworthy than a nameless clerk.  And I'm sure
there's a number of similar people who know you.  What would you say
about the chief of Polish chapter of FFII?  He's a long-time buddy of
mine, even though I haven't seen him for a number of years.  While
not a DD, I don't think his word would have less weight than an ID
you can get for $25.


Also, the name means little.  I don't really care if an upload was
done by a person who claims to be named "Benjamin Seidenberg", I care
that it was done by a person with a history of valid good
contributions whose prior work was checked by many people.  Whether
it was signed by "Benjamin Seidenberg" doesn't matter until I want to
pursue legal action.  I don't need your real name to appreciate your
deeds -- feeling thankful to "astronut" works as well.


It's the ownership of the key what matters, not the name attached to
it.  It's important to know that the key is yours, not that it
belongs to a "Benjamin Seidenberg".


-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: ITP: adun.app -- a Molecular Simulator

[Adam Borowski]

On Wed, Aug 30, 2006 at 10:12:04PM -0400, Daniel Dickinson wrote:
> On Thu, Aug 31, 2006 at 09:24:21PM +1000, Steffen Joeris wrote:
> > > * Package name: adun.app
> > Maybe I miss some essential parts, but I always wonder why some people add 
> > a .app to the software name? Can you please give me a short explanation or 
> > point me to a previous thread?
> 
> IIRC .app is usually used by apps with gnustep support (e.g. WindowMaker
> dockapps). It doesn't normally mean they only work on gnustep though,
> just that they use some features from gnustep, when available.

Just like all the stuff that prepends 'k' or mispells its initial letter as
'k'.


-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Bug#358003: ITP: ttf-dzongkha -- TrueType fonts for Dzongkha language

[Adam Borowski]

On Sun, 26 Mar 2006, Lars Wirzenius wrote:

su, 2006-03-26 kello 04:11 -0600, Peter Samuelson kirjoitti:

OTOH, if you have no idea what language or what country the font
pertains to, why would you want that font?


It is not inconceivable that one could stumble on a document from
Bhutan, and want to install a font to be able to view it. It is a bit
more convenient to be able to find the correct package by only having to
search for "Bhutan", and not have to know that the language is
"Dzongkha".


Why would viewing the document matter if you don't know the language or 
even the script in the first place?



This is not what I would call a common use case, but it exists. I've
been in the situation once searching for a "Russian" font, when I
should've been looking for a "Cyrillic" font, for example. I should've
known better, but sometimes it is difficult to come up with the right
search terms even when you supposedly know the right ones.


This is a bad example, as cyrillic is used by more than 200 languages 
other than Russian; this includes both a number of southern slavic 
languages (Serbian, Bulgarian, etc) and mosts nations that have been 
conquered by Russians at some point in their history.  According to 
your argument, we would have to mention all of these in the description

of every cyrillic font.

Learning a language is quite a time-consuming task, I don't believe that 
anyone can learn even an alphabet without knowing its name.  A bit of 
synergy exists (like, you can perhaps decipher some place names in 
cyrillic if you know both latin and greek scripts), but I believe that 
it's better to keep descriptions short and sweet, as they are useless for 
anyone who don't know the language in the first place.


1KB
--
*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*
Spammers!  Please drop a copy of your junk to [EMAIL PROTECTED], 
or, depending on your collation order, [EMAIL PROTECTED] before 
mailing me.  Thanks.



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

Re: Results for Debian Project Leader 2006 Election Statistics

[Adam Borowski]

On Sat, 8 Apr 2006, [EMAIL PROTECTED] wrote:

Option 3 "Steve McIntyre"
Option 4 "Anthony Towns"


Take a look at these numbers:


Option 3 Reached quorum: 344 > 47.0531614240744
Option 4 Reached quorum: 339 > 47.0531614240744



Option 3 passes Majority.   6.491 (344/53) > 1
Option 4 passes Majority.   4.775 (339/71) > 1



 Option 3 defeats Option 1 by ( 230 -  123) =  107 votes.
 Option 4 defeats Option 1 by ( 230 -  144) =   86 votes.



 Option 3 defeats Option 5 by ( 233 -  124) =  109 votes.
 Option 4 defeats Option 5 by ( 242 -  135) =  107 votes.



 Option 3 defeats Option 7 by ( 278 -   68) =  210 votes.
 Option 4 defeats Option 7 by ( 281 -   99) =  182 votes.



 Option 3 defeats Option 8 by ( 344 -   53) =  291 votes.
 Option 4 defeats Option 8 by ( 339 -   71) =  268 votes.


So, 3 (Steve) clearly wins over 4 (aj) everywhere except:

 Option 4 defeats Option 3 by ( 190 -  184) =6 votes.


Nice close shave...


The Schwartz Set contains:
 Option 4 "Anthony Towns"


Congrats!


--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)


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

Re: System users that receive mail in /var/mail/systemuser?

[Adam Borowski]

On Mon, 10 Apr 2006, Noah Meyerhans wrote:

Really?  I get spam addressed to ftp, cyrus (the Cyrus IMAP system),
postfix, apache, daemon, etc etc all the time.  Those are very common
user names, and (even better for the spammers) their mail is typically
aliased to a group of people.  They're probably in every spammers list
of dictionary words to try.

Still, though, even if I'd never expect legitimate mail to e.g. my
proftpd user, I'd certainly not want to automatically discard it.  I'd
prefer a default configuration that sent it to root, but that could
easily be overridden.


What you really want, is accepting all locally-generated mail to that 
user, and rejecting/discarding everything from the outside.  However, 
there is a problem with what "outside" means.


Usually, that's just everything but localhost, but if smarthosts with no 
local mail are involved, things get messy.


--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)


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

Re: Bug#363598: udev should conflict with ifrename

[Adam Borowski]

On Thu, 20 Apr 2006, Gabor Gombas wrote:

On Thu, Apr 20, 2006 at 11:12:58AM +0200, Marco d'Itri wrote:

Result: programs run after ifrename (like ifupdown...) will get the old
name.


So what? The user deliberately asked for it. Also it seems easy to write
an udev rule to replace persistent-net-generator.rules using ifrename so
udev will be notified about the new name. That's at most a whislist bug
against ifrename.

It's nice that udev can do it all alone but allowing users to continue
to use the tool they are already familiar with is even nicer.


Idea: if /etc/iftab is present on upgrade, you can consume it, producing 
relevant rules in that place (and displaying a message to the admin).


Having a /sbin/ifrename script which internally uses udev but accepts old 
ways of calling it for compatibility could be good, too; however, since 
the /etc/iftab one-shot renaming on boot-up is usually everything that is 
needed, porting the script is probably not worth the effort.


1KB
--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)


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

Re: Possible conflict with XFree 4.5

[Adam Borowski]

On Mon, 24 Apr 2006, Gunnar Wolf wrote:

gustavo halperin dijo [Sun, Apr 16, 2006 at 01:40:42PM +0300]:

I think that we have a problem when the common library between XFree and
/usr/lib are update in /usr/lib.


I assume that you're installing XFree86 4.5 by yourself, since it wasn't
packaged for Debian.  In that case, local installation conflicts are
your problem to sort out.



When you choose a distribution
(like Debian, Ubuntu, Fedora, SuSE or any other), you choose the
carefully crafted work of integration of thousands of packages. Of
course, for most packages you can decide to roll your own and live
with it.


Aren't you supposed to have all files provided by the distribution in 
/{usr,var}/ and all local customizations in /{usr,var}/local/?  At least 
this is what the FHS and the Debian infrastructure expect.  Packages which 
use autotools install to /*/local/ by unless overriden; I would expect 
most other pieces of software follow this convention as well.




- But in the case of X... Well, it's one of the packages in
which most other packages depend, and it's one of the least trivial
ones to get right.


Well, actually it is one of _most_ portable ones.  That is, if you don't 
look at the libraries but on how it works on the wire.  X11 is supposed to 
negotiate the set of extensions supported by the server and the client and 
to degrade gracefully [1].
From my experiences, even in a vastly diverse IRIX/SunOS/PLD/Debian 
environment, X11 is the only piece which continues to work flawlessly even 
where most basic things like curses fail.  All thanks to the separation 
between the X server and X clients -- if you can install XFree4.5 in a way 
that it won't interfere with Debian libraries, I would expect it to work.


[1]. Unless things absolutely require a given extension, that is.  This is 
sometimes the case with xcomposite and some OpenGL stuff.




- So the answer is right, why would you want to use XFree now?

I guess, he has unsupported hardware, ugly proprietary drivers, etc.

1KB
--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)


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

Re: Archiving bugs with version info (Was: Re: Closing a bug vs. tagging wontfix)

[Adam Borowski]

On Tue, 25 Apr 2006, Otavio Salvador wrote:

"Roberto C. Sanchez" <[EMAIL PROTECTED]> writes:

What about oldstable while it is supported?


IMHO, would be good to have a way to check the bugs affecting each
release, so in the current interface we might have a link for:

Filter bugs affecting:
 - current stable
 - previous stable
 - testing
 - unstable


Or even filters for bugs affecting a certain stable point release.



The new BTS versioning is a Good Thing(tm), it just needs people to 
actually use versioned closes instead of leaving tagged bugs lingering.
For example, during the recent BSP I retitled a bug which was titled just 
"package doesn't work" (good move) and tagged it +sarge (bad move, as it 
discourages the maintainer from closing the bug).


(Fenio, I'm CCing this to you even though you're subscribed to d-d, just 
to bring #355827 to your attention.)


1KB
--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)


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

Bug#366482: ITP: dnscruft -- feeds Bind a list of domains as useful as doubleclick.com or less

[Adam Borowski]

Package: wnpp
Severity: wishlist
Owner: Adam Borowski <[EMAIL PROTECTED]>

* Package name : dnscruft
  Version  : 0.20060508-1
* URL  : file://home/kilobyte/dnscruft/
  Initial packages : http://angband.pl/debian/dnscruft/
  Apt  : deb[-src] http://angband.pl/debian unstable main
* License  : GPL
  Description  : feeds Bind a list of domains as useful as doubleclick.com 
or less
 Adverts are an atrocity that plagues "teh Intarweb"; in a typical ISP
 scenario you can expect even up to 1/3 of all http requests to carry
 annoyances instead of useful traffic.  Moreover, such requests are
 usually not-cacheable.
 .
 This package can seed up your DNS server with either prepackaged lists of
 domains or your own selection; it may be used to fight ads/crapware or to
 help enforce your policy against any list of sites you have a database of.
 .
 For the purpose of blocking ads you may want to also look at an alternate
 means like FireFox+Adblock for personal use or Squid+Adzapper for your
 users -- these means grant a more fine-grained control.  On the other
 hand, dnscruft uses far less resources and blocks a much greater range
 of win32 malware, browser hijackers, drive-by-downloads, traffic analysis
 spies or fine products of Russian newest phisheries.
 And, no one says you can't use both dnscruft and URL-based controls.


Annoyed by the amount of crap, I've taken my personal block lists
(gathered over a few years) and combined them with a number of publicly
available ones.  However, the lists I found all contain quite a lot of
false positives -- domains which contain not only cruft but also some
(questionably) redeeming values.  Popular items include for example
rackspace.com (Fanatical Ads(tm)), eads.com (aeronautics),
astalavista.box.sk (a search engine for cracks/serials) or even
myspace.com (THE bane of good taste/reason).  Thus, such existing
lists may be used as-is only on personal/company networks.

To make them useful, I've included only entries I've checked by hand.
As checking >12 hosts would be an inhuman task, I covered only
those with most incidence on the source lists and/or in Squid logs of
two ISPs which are ahead of others in my quest for world domination.
Thus, I believe a good percentage of current scum will be blocked
with very few false positives.

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


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

Re: PDF files and dh_compress

[Adam Borowski]

On Tue, 9 May 2006, Frank Küster wrote:

Martin Wuertele <[EMAIL PROTECTED]> wrote:

How about compressing all generated pdf with eg pdftk instead of gzip?
That would save on space without troubling potential readers.

Most PDF files in Debian are already compressed;  at least those
which are generated on a Debian system, and somehow TeX is involved
are.

[an example of TeX-generated pdf]

So somehow uncompressing-recompressing with pdftk gives a slightly
larger file [...]
To me, this sounds like in general it's not worth to compress compressed
pdf files with gzip; if we'd go for size, we should use bzip2.


An idea:
debhelper:
if (-x '/usr/bin/pdftk'")
{
`pdftk $_ output $tmp uncompress`;
`pdftk $tmp output $recompressed compress`;
compare the sizes of $_ and $recompressed
install the smaller
}
else
{
warn "PDF docs but no pdftk installed\n";
}
lintian:
W: PDF docs but no Build-Depends on pdftk

--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)

Re: multiarch status update

[Adam Borowski]

On Thu, May 11, 2006 at 04:49:26PM -0400, Joe Smith wrote:
> On the other hand, if we continue that thought process we could end up
> with all headers and libraries in /usr/share/, which is absurd.

Why?  This is exactly what's beautiful, especially if EVERYTHING ends up in
/usr/share/ at one day, at which point /share/ will be redundant and the FHS
will change.

> Indeed, the current proposal almost seems to be reversing this.
> >Non-target specific libraries and header files remain in $prefix/lib and 
> >$prefix/include.
> It seems to me that libraries and headers that are not target specific are 
> supposed to go in /usr/share.
> That is because if they are not target specific they are most certainly 
> cross-platform.

I remember a lab that consisted mostly of SGI Indy boxes, a SunOS server,
some O2 and a stray Linux or two.  The common problem was incompatibility of
binaries: things compiled on an Indy worked on the Indies and O2, but things
compiled on O2 were incompatible with Indy.  Exactly the same thing as
i386->i486->i586->i686->amd64.

Now, imagine that /usr/bin is split this way:
/usr/bin (perl, bash)
/usr/bin/indy (binaries)
/usr/bin/o2 (binaries)
/usr/bin/sun (binaries) [1]
Can you see what I mean?  By just having different PATHs, everything would
be completely transparent.  And the multiarch would take care of all
libraries and headers.

> Hm... This entire concept seems messy. It seems that processors that
> support multiple architectures, as well as cross compilition are begining
> to blur the line between /usr and /usr/share.

It's not "messy", it's plain awesome.  And if the line gets blurred into
oblivion, it will be a reason for joy.


[1] Ok, ok.  I'm stretching it a bit, as SunOS was a different beast than
IRIX.  But if all boxes are Debian...

Cheers.
-- 
1KB // Rule #6: If violence wasn't your last resort,
// you failed to resort to enough of it.
//   - The Seven Habits of Highly Effective Pirates


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

Re: using /usr/bin/nologin instead of /bin/false in adduser?

[Adam Borowski]

On Sat, May 13, 2006 at 01:17:02PM -0400, Roberto C. Sanchez wrote:
> Out of curiousity, what happens when someone tries to login and /usr is
> unavailable?  If the shell is set to something in /bin, it will still be
> used.  What is the default action when the user's shell is not available?

foo:x:1002:1002:,,,:/home/foo:/bin/


Debian GNU/Linux testing/unstable umbar tty5

umbar login: foo
Password:
Linux umbar 2.6.16-1-686 #2 Thu May 4 18:22:23 UTC 2006 i686
Cannot execute /bin/: No such file or directory

Debian GNU/Linux testing/unstable umbar tty5

umbar login:


/* Note: the password below is correct every time */
[~]$ ssh -l foo ::1
foo@::1's password:
Permission denied, please try again.
foo@::1's password:
Permission denied, please try again.
foo@::1's password:
Permission denied (publickey,password).
[~]$ scp DEADJOE [EMAIL PROTECTED]::1]:
foo@::1's password:
Permission denied, please try again.
foo@::1's password:
Permission denied, please try again.
foo@::1's password:
Permission denied (publickey,password).
lost connection
[~]$


May 13 19:43:32 umbar sshd[7413]: User foo not allowed because shell /bin/ 
does not exist
May 13 19:43:32 umbar sshd[7413]: Failed none for invalid user foo from ::1 
port 47974 ssh2
May 13 19:43:34 umbar sshd[7413]: (pam_unix) authentication failure; logname= 
uid=0 euid=0 tty=ssh ruser= rhost=ip6-localhost  user=foo
May 13 19:43:36 umbar sshd[7413]: Failed password for invalid user foo from ::1 
port 47974 ssh2
May 13 19:43:44 umbar last message repeated 2 times
May 13 19:43:44 umbar sshd[7413]: (pam_unix) 2 more authentication failures; 
logname= uid=0 euid=0 tty=ssh ruser= rhost=ip6-localhost  user=foo


With /bin/true:

[~]$ scp DEADJOE [EMAIL PROTECTED]::1]:
foo@::1's password:
lost connection
[~]$

May 13 19:50:25 umbar sshd[7465]: Accepted password for foo from ::1 port 53466 
ssh2
May 13 19:50:25 umbar sshd[7467]: (pam_unix) session opened for user foo by 
(uid=0)
May 13 19:50:25 umbar sshd[7467]: (pam_unix) session closed for user foo



-- 
1KB // Rule #6: If violence wasn't your last resort,
// you failed to resort to enough of it.
//   - The Seven Habits of Highly Effective Pirates


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

Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email

[Adam Borowski]

On Tue, May 16, 2006 at 07:58:52PM -0500, Ron Johnson wrote:
> > > On Tue, 2006-05-16 at 19:21 +0200, Henning Makholm wrote:
> > >> The point is that they could if the wanted to. And if they did, it
> > >> would work for _all_ programs, not just particular perl scripts that
> > >> happen to use some obscure perl module to send mails.
> 
> T-bird, Evo, Outlook, etc don't figure it out either.  They ask 
> the user, "What's the name of your ISP's outgoing mail server?"
> 
> Here's the relevant question from "reportbug --config"
> 
> Do you have a "mail transport agent" (MTA) like Exim, Postfix
> or SSMTP configured on this computer? [y|N|q|?]? 

Except, this is _doubling_ a question that was already asked somewhere else,
ie, a bug.  The UNIX way of configuring the mail is setting up a binary that
knows how to deliver it as "/usr/sbin/sendmail"; it doesn't matter whether
that binary will do the work itself, run ssh -T foo sendmail, or toss the
mail to a smarthost.  The Debian way of configuring stuff is asking the
admin the relevant questions only once, and keeping the config in a shared
place.

Having to configure every single program that happens to send out mail adds
more work to the user.  You also are guaranteed that every such program will
ask the questions in a different way, which adds extra confusion.

Cheers and schtuff,
-- 
1KB // Rule #6: If violence wasn't your last resort,
// you failed to resort to enough of it.
//   - The Seven Habits of Highly Effective Pirates


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

Re: Making init scripts use dash

[Adam Borowski]

On Fri, May 19, 2006 at 10:18:46AM +0200, Michal Čihař wrote:
> There are anyway users using dash as /bin/sh right now and broken
> packages are bugged, so switching default should not reveal any new bug

The policy says:
# If a script requires non-POSIX features from the shell interpreter, the
# appropriate shell must be specified in the first line of the script (e.g.,
# `#!/bin/bash')

It's a "must" clause, so the bugs should be RC.

> (however there are some not being fixed for a long time).

Upgrading their severity to a RC one tends to make the bugs getting fixed _a
lot_ faster, and in many cases is the only way to have them fixed at all.
Since the lame-but-guaranteed-to-work fix requires nothing but adding two
letters, I see little reason to leave them unfixed.

Besides, here's an idea:
let's make it karma-mandatory for debian-devel readers to have /bin/sh point
to foosh for sh!="ba".  The more people people use alternate shells, the
faster bugs are exposed.
And, you can't claim that the whole world uses bash.  OpenBSD has pdksh
there, {Free,Net}BSD got [d]ash.

Whee?
-- 
1KB // Rule #6: If violence wasn't your last resort,
// you failed to resort to enough of it.
//   - The Seven Habits of Highly Effective Pirates


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

Re: Making init scripts use dash

[Adam Borowski]

On Thu, May 18, 2006 at 05:27:23PM -0300, Margarita Manterola wrote:
> During some tests I've performed, I've found that making the init
> scripts run with dash as default shell instead of bash makes the boot
> time a 10% faster (6 seconds in a 60 second boot).

This speed-up is not limited to booting.  For example, my tests of
package build speed show around 4% improvement for package builds.

The interesting fact is that, contrary to what I expected, running
"configure" was improved by only about 1% on average.  Thus, it's
bash's start-up which is the slow part, in the terms of actual
speed, bash is not that far behind.  Too bad, make runs every single
command in a separate shell, going through bash's slow start each time.


I checked these results by building four packages (fuse, kbtin, bash
and dash) a number of times; having dash as /bin/sh speeds up the
builds by 3-4% except for building bash itself (just 0.39%).


Conclusion: moving to dash is worth it.


Cheers and schtuff,
-- 
1KB // Rule #6: If violence wasn't your last resort,
// you failed to resort to enough of it.
//   - The Seven Habits of Highly Effective Pirates


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

Re: RFC: Better portability for package maintainers

[Adam Borowski]

On Sat, May 20, 2006 at 12:37:36PM -0300, Gustavo Noronha Silva wrote:
> Our Architecture: field is about the arches that Debian itself supports.
> If the meaning was broad as you describe, would we have to make sure our
> packages build on MS DOS?
> 
> I'll agree with Josselin here: Debian is a GNU operating system, not a
> POSIX OS. If there are porting problems which are specific to Nexenta
> and you want them to be integrated, you can provide patches. Or you can
> port the GNU libc to Nexenta (and, after this happens, you can even
> integrate Nexenta into Debian, why not?).

Still, I would say that Erast has a good point.  The problem is, there
are three different sides:
* Sun
They want people to support their platform.
* upstreams
They just *love* having their software ported everywhere.  And I mean:
* purely commercial upstreams (more customers!)
* purely noncommercial ones (free ego boost)
* anything in-between (bigger user base, more potential patches, etc)
With Nexenta being more similar to Solaris, the ported software will
be more likely to work there as well, giving it more coverage.
* Debian
Easy porting, and keeping porting that way in the future.  Supporting
wildly diverse libcs stands against this goal.

Note that the first two groups would prefer a new project which is not
very likely to have a lot of users soon to use the Sun libc.
Sun: for obvious reasons.
Upstreams: free porting to near-Solaris, hardly any users lost due to
harder porting.

On the other hand, Debian obviously would prefer to have Nexenta be
close -- preferably as an arch.  Without GNU libc, Nexenta can't really
be a part of Debian.

> I do care about Free Software principles, but my time for working on
> Debian is very limited these days, and porting my packages to an
> "unsupported" architecture is not very high in my priorities list.

In other words, Nexenta can choose between:
* GNU libc: easy porting of nearly all of Debian's repository, more
  cooperation from Debian developers
* Sun libc: better interoperability with Solaris

GNU libc would give Nexenta lots of usability fast, Sun libc would make
it a more experimental bridge to Solaris.

I don't really love Sun -- but, if we can give them a reason to relicense
their stuff to something GPL-compatible, it would be a big win.  Without
compatibility with GPL, we'll have more and more wars and crap similar to
the recent Java issue.

Cheers and schtuff,
-- 
1KB // Microsoft corollary to Hanlon's razor:
//Never attribute to stupidity what can be
//adequately explained by malice.


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

Re: Bug#368371: ITP: gp2c -- PARI/GP GP to C compiler

[Adam Borowski]

On Mon, May 22, 2006 at 12:29:42AM +0200, Bill Allombert wrote:
> On Sun, May 21, 2006 at 10:18:19PM +0200, Nacho Barrientos Arias wrote:
> > IMHO, pari-gp-c or pari-gp2c could be better than 'gp2c' to avoid
> > this namespace pollution, at your option.
 
> Good catch, I will consider this option. gp2c is the upstream source
> package name.

Wait, so "gp2c" doesn't stand for "GNU Pascal to C"?

At least that's what I thought before I reread the short desc for the second
time.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Packages violating policy 8.2

[Adam Borowski]

On Tue, May 23, 2006 at 09:42:03PM -0500, Manoj Srivastava wrote:
> On 23 May 2006, Goswin von Brederlow stated:
> > To me it sounds like you are. You provide a shared object file in a
> > public place so other people can link their binaries against
> > it. What else is a shared library? Does it matter if no package in
> > Debian uses it but only other people? I think not. If you intention
> > is to let others link against it then it is a shared library by all
> > means.
> 
> It is a shared library, and you are free to link with it --
>  but as a developer you must realize that your package may break on
>  upgrade, since there is no shared library package, just a single
>  combined setools package.

I'm afraid that Goswin is right.  If it's not a shared library
package, it shouldn't have anything in /usr/lib; anything else
belongs in /usr/lib/*/ or /usr/share/*/.

> > Policy 10.2:
> >
> > | Shared object files (often .so files) that are not public
> > libraries, | that is, they are not meant to be linked to by third
> > party executables | (binaries of other packages), should be
> > installed in subdirectories of | the /usr/lib directory. Such files
> > are exempt from the rules that | govern ordinary shared libraries,
> > except that they must not be | installed executable and should be
> > stripped.
> 
> Err, those a plugins, and one generally dlopens them, or
>  otherwise manipulates the loader.  It certainly does not apply.

FHS 2.3:
# /usr/lib includes object files, libraries, and internal binaries
# that are not intended to be executed directly by users or shell
# scripts.
#
# Applications may use a single subdirectory under /usr/lib. If an
# application uses a subdirectory, all architecture-dependent data
# exclusively used by the application must be placed within that
# subdirectory.

And indeed, most of files I find in /usr/lib/*/ on my system are not
plugins but binary objects of any kind:
* helper programs (most frequent case)
* non-portable data (NetHack levels, etc)
* firmware blobs
* plugins
* private shared libs
  ^^^
* scripts, headers, etc which differ between archs
* object files for compilers

It's non-obvious whether a given .so file is loaded with dlopen or
loaded directly, but for example "devscripts" does the latter.

As another example, I've recently made a program with three executables that
share most of their code; quite an usual thing.  To save space, the common
parts are placed in a shared library (well, well, .dll ...) that resides in
the program's private dir.  On a FHS-compliant system, I can't think of any
place to put such a library other than /usr/lib/$foo/; how is this different
from the case of setools?


I'm not sure if a nobody like me is the right person to correct Manoj,
someone whose name is on the very policy package, but the issue seems to be
pretty clear, at least to me...

Cheers and schtuff,
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Red team attacks vs. cracking

[Adam Borowski]

On Tue, May 30, 2006 at 12:20:14PM -0700, Paul Johnson wrote:
> Even the guy at 7-Eleven has the big book of north american ID cards with 
> pictures and descriptions of what makes a real one for when they encounter an 
> ID that they've never seen before.  Surely Debian can do as well as the guy 
> selling cigarettes and beer at the 7-Eleven when it comes to verification...

How can you check if an ID card is real based only on what is written
on the card, even if it has all the hallmarks mentioned in that book?

See, if you visit a bazaar, I bet a helpful guy with a Russian accent
can sell you a perfectly valid passport for less than $50.  Several
years ago, a friend of mine actually asked someone at the Stadion
10-lecia in Warsaw, and was led to a guy with a number of blank Polish
IDs for ~$25 each...

That's about what checking government-issued IDs is worth.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

[Adam Borowski]

On Mon, May 29, 2006 at 09:29:34PM +0200, Matthias Urlichs wrote:
> * gnulib
>   (easy pickings; need to package new Upstream from CVS, every month or so)
I ported quite a lot of C software between IRIX/SunOS/AIX/Linux, so
I'll take it.

> * tcng
>   (some clean-up required)
I have some idea about bare tc -- two local ISPs run my scripts that
manage traffic shaping according to the customers' databases;
however, I haven't used tcng itself -- it looks interesting, though.
Unless someone else steps up, I can do it.

> * hashalot
>   (easy pickings)
Trivial; I can grab it if no one else does -- but if someone actually
uses it, that person of course has a priority.

Whee?
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Red team attacks vs. cracking

[Adam Borowski]

On Tue, May 30, 2006 at 01:57:18PM -0700, Paul Johnson wrote:
> On Tuesday 30 May 2006 13:02, Adam Borowski wrote:
> > On Tue, May 30, 2006 at 12:20:14PM -0700, Paul Johnson wrote:
> > > Even the guy at 7-Eleven has the big book of north american ID cards with
> > > pictures and descriptions of what makes a real one for when they
> > > encounter an ID that they've never seen before.
> > How can you check if an ID card is real based only on what is written
> > on the card, even if it has all the hallmarks mentioned in that book?
> If you don't trust the ID, you don't sign the key.  But having the book to be 
> able to get a bad feeling about the ID from sure beats the apparent current 
> system of "Sign the key and hope the ID is for real."

What I mean is, it makes no sense to believe that IDs provide any
real security.  I would rather trust some common sense.  A brief
Google search on the person's name where you look at page 6 and pick
something that the person whose key you're signing should know.

For example, my name is pretty popular, but it's still pretty easy to
pick a reference to me.  Taking a few random links yields:

* an ELinks patch for a bug with xterm detection
=> ask me what was wrong

* a translation of a task from the Polish Olympiad in Informatics,
  the task was authored by me
=> ask me to briefly describe a solution for the task

* a Usenet-to-webforum mirror of r.g.r.nethack with a post about
  "termrec", my enhanced implementation of ttyrec
=> you can assume that the upstream of a piece of software will know
   its inner workings pretty well

Generally, you can learn a few things about the person you're trying
to impersonate, but there is no way you can know everything.  And the
real person can describe things in detail...


Thus, given:
A) someone with a government-issued ID, or
B) someone with a random card that bears a photo: a chess club card,
   a Transnational Republic passport, etc
I see hardly any difference between person A and B.  I would trust
common sense, not any passport.


> > See, if you visit a bazaar, I bet a helpful guy with a Russian accent
> > can sell you a perfectly valid passport for less than $50.
> > [...]
> > That's about what checking government-issued IDs is worth.
> Perhaps in that part of the world, yes.

Yes, you're right.  In the US, the ID may set me back perhaps even
$100 or more.  And the point is...?

Cheers and schtuff,
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: LSB init scripts and multiple lines of output

[Adam Borowski]

On Thu, Jun 01, 2006 at 06:51:54PM +0200, martin f krafft wrote:
> In my ideal world, this is what it would look like:
> 
> Starting RAID devices ...
>   /dev/md0 has been started with 3 drives.
>   /dev/md1 has been started with 3 drives.
>   /dev/md2 assembled from 2 drives - need all 3 to start it
>   /dev/md3 assembled from 1 drive - not enough to start the array.
>   /dev/md4 has been started with 3 drives.
> ... done assembling RAID devices: failed.
[...]
> Generally, I would not have a problem doing something like
> 
>   Starting RAID devices ... failed (see log for details).

Really, PLEASE, don't!
Hiding information is _never_ good.  For any reason.  Even if you
expect the user to be non-technical.


Let me go into a longer rant, only partially on the topic.


I witnessed a smart but non-guru user install a certain brand new
Debian-like distribution on her home box today.  That person is a
physicist doing medical research, with no sysadmin experience but
familiar with quite a bunch of Unices.
The machine was known to be good except for the disk, which in turn
was checked on an identical box before.

The trouble she faced consistent of a number of _random_ breakages
with totally no usable error messages:
* In about 1/3 tries, parted failed with whatever the error message
  was hidden by the installer's GUI.  Tell me, how she was supposed
  to figure out what's wrong?  (Skipping the fact that something as
  dangerous as parted should never be allowed to break in a common
  setup [1].)

* At some point during the main installation phase (with nothing but
  a progressbar shown), the installer coughed up and barfed a window
  full of a Python backtrace right in the user's face, then died.  I
  looked at the dialog, but couldn't figure out what went wrong,
  either.  Perhaps taking a look at the logs (HIDDEN FROM THE USER)
  would be insightful, but the friend claimed that if the
  installation is supposed to be graphical, she's not going to let me
  do everything by hand [2].

  Where's the goddamn meaningful error message?  

* Two times, a dialog simply popped up, saying: "The installer has
  crashed".  Just that.  Without a single damn word about the cause,
  or even just a mention of what it was doing at the time.

  The friend muttered something about Ubuntu being as flaky as
  Windows, then rebooted and started the installation anew...

* The GUI network setup tools simply ignore any failures.  After
  choosing a SSID from a list (the list shows that the hardware and
  kernel-side stuff was working ok) then clicking "Activate", the
  dialog simply shows nothing for ~20sec and then acts as if
  everything was in working order.

  What was wrong?  Can you tell me from the provided information? 
  Current vanilla text-mode Debian will give you a message after
  every action.  With Ubuntu, you need to dig deeply to force the
  system to reveal what's going on.

Finally, I had to leave; the friend hasn't succeed yet.

[1]. A 50GB unformatted primary partition, the rest being on
extended: two 50GB unformatted ones, 50+GB ext3 on /home, 1GB swap,
7GB ext3 on /.

[2]. Get a reflex of going into mkfs/debootstrap mode at the smell of
the first installer trouble and people will start spreading evil
rumors about you :p


--End of rant--

Now, let's go into your question:
> Starting RAID devices ...
>   /dev/md0 has been started with 3 drives.
>   /dev/md1 has been started with 3 drives.
>   /dev/md2 assembled from 2 drives - need all 3 to start it
>   /dev/md3 assembled from 1 drive - not enough to start the array.
>   /dev/md4 has been started with 3 drives.
> ... done assembling RAID devices: failed.

An user who has just the basic idea what RAID is will know what's
going on instantly.  When they'll call you, you will be able to help
them right away.

> Starting RAID devices ... failed (see log for details).

Now, you'll have to explain to the user how to get to the log.  And
what if the system is inoperative (with failed RAID, it almost
certainly will be)?


You can't be too verbose, but if you hide the most important parts,
it will be a great disservice to the users.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: LSB init scripts and multiple lines of output

[Adam Borowski]

On Fri, Jun 02, 2006 at 02:36:15AM -0400, Joey Hess wrote:
> Adam Borowski wrote:
> >   The friend muttered something about Ubuntu being as flaky as
> >   Windows, then rebooted and started the installation anew...
> 
> This is not an Ubuntu mailing list. It's pretty annoying to require all
> us d-i developers to get this far down in the mail before we realize
> that the problems you are describing are (probably) not d-i problems.

My sincere apologies.  For my defense, I was ranting about "why
hiding error messages is unacceptable" not about "the installation is
bad", but certainly mentioning just "a certain brand new Debian-like
distribution" wasn't clear enough.


And I still haven't completed the report I once promised on the
behavior of d-i on low-end 486 with various amounts of memory...

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Software Patents

[Adam Borowski]

On Fri, Jun 02, 2006 at 10:24:45PM +0200, Cesare Leonardi wrote:
> One of the terrible effect of software patents is that nobody knows if 
> his program infringe some of them in some country. And, as you said, i 
> think it's impossible to be completely patent-free as things stand now.

However, don't forget that we know that no programs infringe any
patents in some countries.  Thus, it is possible to be completely
patent-free there.

The bad countries are: USA (the "land of the free"), Japan and
perhaps some parts of Europe.  In Europe, after years of fighting,
the current situation is that no common laws on software patents can
be binding on member states -- as far as I know, this leaves only UK
and Germany among the bad guys.
Unfortunately, there is a controversy whether TRIP agreements apply
to software patents as well or not.  If they do, we have to avoid
more than just the four rogue countries.

The good news is, there are countries which are not bound by any
TRIPs.

In other words: let's revive non-US, rename it accordingly
(non-patent-troll, non-non-free?), and have it served only from
machines placed in the free countries.

> Since patents cover concepts not the implementation, if mp3 bases
> itself on several patents, then all codecs are covered by that
> patents. And so ffmpeg, mplayer, xine and vlc are not different in
> that sense.

So, we can have everything that is ok copyright-wise in Debian and
not suffer from patent issues.  We can have LAME, non-castrated
mplayer, and so on.  There is no reason to keep fine DFSG-free
software out of Debian just because it's illegal in some countries. 
Likewise, Debian does distribute encryption software even though it
is illegal in some places.

Also, there is no real reason why a home user shouldn't include the
non-US repositories in her apt/sources just because she happens to
live in the US.  Sure, companies would have troubles doing this, but
the label says it pretty clear: don't touch it if you live in a
non-free country or know the possible consequences.

So: down with the patents, long live non-US!

Cheers,
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Hidden files

[Adam Borowski]

On Wed, Jun 07, 2006 at 12:02:23AM +0100, Roger Leigh wrote:
> Ron Johnson <[EMAIL PROTECTED]> writes:
> > Just as /etc/bashrc is not hidden, whereas ~/.bashrc is, *why*
> > should any *system* files be hidden?
> 
> IMO dotfiles are a historical artifact which we are stuck with.  If we
> were just starting today, I'm sure we would be using ~/etc/bashrc
> rather than ~/.bashrc so the user's files match the standard
> locations.  It's logical, simple, and would make many things easier.

This argument is valid only for configuration.  There are more
reasons to have files which are not displayed unless you ask for
them.  For example:
* .svn
  Storing this metadata somewhere else would mean you have to
  explicitely purge it every time you do something as basic as
  deleting a dir.  Also, you are no longer free to move things around
  by hand, can't move them to another machine without some kind of
  export/import, and so on, so on.
* .xvpics
  It takes a long time to show the thumbnails, so caching them is not
  a bad idea.  However, if this cache was placed anywhere else than
  the dir which contains the images, thumbnails would accumulate
  indefinitely -- with .xvpics, deleting the directory removes the
  relevant cache without any extra effort.

> While historical reasons are acceptable for users' dotfiles, I remain
> to be convinced that there is a logical rationale for them in any
> system location, or even anywhere under $HOME except the root.

Showing dotfiles by default doesn't provide you with any extra
security.  The rootkit can as easily use /var/lib/dpkg/info/ or even
/mnt/win/Windows/System32/hidden\ from\ mom/pr0n/.  Also, unlike Sony's
rootkit, dotfiles are hidden only from tools that explicitely remove them
from the output -- that is, ls, mc or nautilus but not find.

Dotfiles are just a means of hiding visual spam.  The less irrelevant
information is forced into your eyes, the more attention you have left for
real work.  And " -a" is just three keystrokes anyway.


On the other hand, the issue which started this thread _is_ valid IMHO.
/usr/lib/xulrunner/.autoreg is not "metadata you're not going to look for"
but a file that is not really different from, let's say, no_ppp_on_boot.
A marker that is a functional part of xulrunner and that is usually
important to those who bother to take a look at the relevant dir.
Note that I think you're right because of semantics, not because of broken
"security" scanners.

Regards,
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: SUMMARY -- Generic handling of WORD, EXCEL, FILE MANGER ...

[Adam Borowski]

On Thu, Jun 15, 2006 at 12:38:52PM +0200, Eduard Bloch wrote:
> * Jari Aalto+usenet [Thu, Jun 15 2006, 01:31:49PM]:
> > x-word-processor
> > x-spreadsheet
> > x-file-manager
> > x-archiver
> > x-media-player  or "x-video-player"
> > x-media-editor  or "x-media-mastering"
> > x-music-player
> > x-music-editor  think "audacity" etc.
> 
> Allright, why is it called x-spreadsheet but not x-word, x-file,
> x-archive and x-media? Please be consistent about the naming; if you
> mean a spreadsheet processor, call it x-spreadsheet-processor (or
> -calculator).

Eh, what is a "spreadsheet processor"?  The name for this class of
programs was always "spreadsheet" even in the days of Lotus 1-2-3.
And, this name actually makes sense, as opposed to "word processor"
which is a remnant of the historic usage.

Just look up "word processor", "spreadsheet", "file manager" or
"archiver" in Wikipedia.  While not an authoritative source, it would
have a disambiguation from "word" to "word processor" or from "excel"
to "spreadsheet" if using the names of certain Microsoft products had
any wide use in the "industry".

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Regexp to parse "Version:" fields

[Adam Borowski]

On Wed, Jun 21, 2006 at 01:56:21PM +0200, Christoph Haas wrote:
> for mentors.debian.net I would like to find a perfect (TM) regular
> expression to split the "Version:" line of a control file into:
> 
>  - epoch
>  - upstream version
>  - Debian package revision
> 
> My current attempt is:
> 
>^(?:(\d+):)?(\d[\w\.\+-:]*?)(?:-(.+))?$

You don't want to match a hyphen inside the Debian revision.  .+
will match it, [\w.+]+ won't.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: make -j in Debian packages

[Adam Borowski]

On Wed, Jun 28, 2006 at 03:17:27AM +0200, Henning Makholm wrote:
> > If package maintainer wants to build it faster on their own machine, I
> > would imagine that checking for an environment variable (DEB_MAKE_OPTS
> > or something, perhaps?) and using that would be the way to go. By
> > default, build with a single processor.

This would affect every single package, and you can't do that.  While
a vast majority of C code will build correctly, not every package is
SMP-safe. [1]
 
> If I understand the problem correctly, it is not even necessary to
> modify debian/rules to get this behavior. If the interdependencies
> are properly declared,
> 
> $ debian/rules -j42 binary
> 
> should do the trick, as GNU make is smart enough to pass the option
> down to sub-makes that it starts.

Actually, this is a bad idea; debian/rules are specifically the kind
of makefiles that typically rely on the order in which dependencies
are built.  This is a bug as it breaks make -k, but as -k hardly ever
makes sense with regard to debian/rules, this is nearly totally
untested.


On the other hand, making builds significantly faster is not
something that you can shake a stick at.  Typically make -jX is faster
even on uniprocessor, and I don't need to tell you why it's much
faster on SMP.
Too bad, a C++ build where every file takes 1GB memory obviously
should not be parallelized.  Also, no one but the maintainer knows
whether a package is SMP-clean or not.  You cannot guess this in an
automated way.

Thus, my counter-proposal:
Let's allow maintainers to use make -jX according to their common
sense, requiring obeying an env variable to opt out.

Rationale:
Nearly every buildd and nearly every user building the packages on
his own will benefit from -j2 [2], even on non-SMP.  Unless it's a
piece of heavily-templated code, any modern box will have enough
memory to handle it.  The maintainer know whether the code is heavily
templated or not.

Giving the choice to someone who doesn't know the package (upstream
and/or the maintainer) will lead to _random_ FTBFSes.

Having DEB_MAKE_NON_PARALLEL [3] disable this behavior would make
m68k happy, while giving a reasonable default for everyone else.


And yeah, I'm guilty of using unconditional make -j4 in one of my
packages (not in the archive yet), too.




[1] A real-world example:
 [ make_commands ]
#!/bin/sh

rm -f commands.h
rm -f load_commands.h
ARGS="_command(char *arg, struct session *ses)"
while read FUNC
do
if [ -z "$FUNC" ]
then
continue
fi
case $FUNC in
\;*);;
\#*)echo "$FUNC" >>commands.h;echo "$FUNC" >>load_commands.h
;;
\**)FUNC=`echo "$FUNC"|sed 's/^\*//'`
echo "extern struct session *$FUNC$ARGS;" >>commands.h
echo "add_command(c_commands, \"$FUNC\", 
(t_command)${FUNC}_command);" >>load_commands.h
;;
*)  echo "extern void$FUNC$ARGS;" >>commands.h
echo "add_command(commands, \"$FUNC\", ${FUNC}_command);" 
>>load_commands.h
;;
esac
done
==
This script produces two files, commands.h and load_commands.h, both
of which should be regenerated every time the input data changes.

A naive Makefile will just have both of these depend on an
invocation of make_commands.  This will work correctly and be
unnoticed for years until someone gives "-j" to make.

Would you bet that every single of your upstreams knows to avoid such
subtle errors?


[2] I benchmarked this with an old gcc several years ago on an
uniprocessor, and -j4 (!) gave the best results.  Today, with gcc-4.2
-j2 won.


[3] This name sucks.  Give a better one if you care :p

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: make -j in Debian packages

[Adam Borowski]

On Wed, Jun 28, 2006 at 02:06:26AM -0700, Don Armstrong wrote:
> On Wed, 28 Jun 2006, Adam Borowski wrote:
> > Let's allow maintainers to use make -jX according to their common
> > sense, requiring obeying an env variable to opt out.
> 
> Why not just have some ENV variable (CONCURRENCY_LEVEL?) which
> specifies the maximum -j; the package maintainer is free to choose any
> level equal to or below that.
> 
> If CONCURRENCY_LEVEL is not set, the rules file must assume
> CONCURRENCY_LEVEL=1 (or not specify -j?); this will keep what should
> be the current status quo the same, and allow buildd's and other
> builders to set this variable to a reasonable level for their system.

I would rather have it default to "a reasonable value on an average
uniprocessor box, according to the maintainer's common sense". 
Otherwise, nearly no one will have this variable set and thus the
whole benefit will be lost.  And cutting the build time by half or
more is a GREAT thing to have.

> (or not specify -j?)

no -j => 1

-j with no value => INFINITY
This is certainly not what you want for a package build; unlimited -j
is useful for other uses of make.

-jX (or -j X, the space is BAD for an option with an optional
argument) => X processes
 
> This has the disadvantage of not automatically using -j for every
> package and requiring maintainer buy in to see results... but
> presumably those packages where it actually makes a difference will
> adopt it just so maintainer builds don't take as long.

Why would you restrict this just to maintainer builds?  Speeding up
buildds and user builds would be a worthy goal, too.  An obscure env
var hardly anyone knows about means that hardly anyone will be
affected.
The m68k buildd admins are here, listening, so they can add this
line.


Or, another approach:
if CONCURRENCY_LEVEL is unset, debian/rules can check the amount of
memory present and/or the number of CPUs and make a guess.


-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: make -j in Debian packages

[Adam Borowski]

On Wed, Jun 28, 2006 at 12:38:51PM +0200, Ingo Juergensmann wrote:
> On Wed, Jun 28, 2006 at 10:31:54AM +0200, Adam Borowski wrote:
> > On the other hand, making builds significantly faster is not
> > something that you can shake a stick at.  Typically make -jX is faster
> > even on uniprocessor, and I don't need to tell you why it's much
> > faster on SMP.
> 
> Well, make -jX is not everywhere faster on UPs. It depends on other factors
> as well. If you specify -j2 and the second make is causing lots of swapping,
> you won't gain much if anything at all. 

Exactly, just like I said: it depends on the memory.

The benefits on UP are small (~10%), but except for huge working
sets, non-negative.  And the maintainer knows if the package handles
huge chunks at once or not.
 
> > Nearly every buildd and nearly every user building the packages
> > on his own will benefit from -j2 [2], even on non-SMP.  Unless
> > it's a piece of heavily-templated code, any modern box will have
> > enough memory to handle it.  The maintainers know whether the
> > code is heavily templated or not.
> > 
> > Giving the choice to someone who doesn't know the package
> > (upstream and/or the maintainer) will lead to _random_ FTBFSes.
> 
> Therefore a double opt-in would be nice (machine admin and package
> maintainer saying it's OK). 
> 
> > Having DEB_MAKE_NON_PARALLEL disable this behavior would make
> > m68k happy, while giving a reasonable default for everyone else.
> 
> I don't think it's good to define an opt-out variable (*_NON_PARALLEL).
> Think positive! So, it would be better to define DEB_MAKE_PARALLEL, but even
> better it would be to use something existing: CONCURRENCY_LEVEL as Don
> Amstrong suggests. 
> If this variable exists (e.g. if [ -z CONCURRENCY_LEVEL ]) the maintainer
> can make use of -jX. 

Indeed, using the existing name is better.

But, did you really want to say -z?  It's what I want, and you seem
to argue against me :p

However, it's very unlikely someone would set a random env var unless
the person knows about it.  Defaults are what a vast majority of
users use, so I would go for sensible ones.

> Keep in mind that there are archs that don't have that much resources to
> build in parallel, and I'm not thinking of m68k. M68k has buildds with 512M
> RAM, but for example armeb which has only 32M. 

Good point, but such machines are RARE.  I would rather go for either
have the admin opt out or them, or, have the packages detect low-mem
conditions and optimize their builds accordingly.

> I would like to see a method to allow usage of other compile accelerators as
> well (distcc (for using crosscc, but testing locally), ccache, etc). 

In theory, you would set CC, but not everything obeys it.  I
personally tend to mess with what "gcc" points to.  Usually with more
than one levels of indirection, too -- colorgcc is a nice thing for
when the output goes to a terminal.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: make -j in Debian packages

[Adam Borowski]

On Wed, Jun 28, 2006 at 12:38:51PM +0200, Ingo Juergensmann wrote:
> I don't think it's good to define an opt-out variable (*_NON_PARALLEL).
> Think positive! So, it would be better to define DEB_MAKE_PARALLEL, but even
> better it would be to use something existing: CONCURRENCY_LEVEL as Don
> Amstrong suggests. 
> If this variable exists (e.g. if [ -z CONCURRENCY_LEVEL ]) the maintainer
> can make use of -jX. 
> 
> Keep in mind that there are archs that don't have that much resources to
> build in parallel, and I'm not thinking of m68k. M68k has buildds with 512M
> RAM, but for example armeb which has only 32M. 

Ok, so let's try some actual code.
I've used my usual playground: package "kbtin" on mentors.debian.net

Take a look at the marked ###\\\### box:

If CONCURRENCY_LEVEL is set, it will be used if it looks plausible.
If it's not there, it will be set to 2 if the box has at least 128MB
memory.

If any problem happens, the build continues with make -j 1.


How do you like this, Ingo?


Cheers and schtuff,
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: make -j in Debian packages

[Adam Borowski]

On Wed, Jun 28, 2006 at 03:22:35PM +0200, Ingo Juergensmann wrote:
> On Wed, Jun 28, 2006 at 01:37:37PM +0200, Adam Borowski wrote:
> > The benefits on UP are small (~10%), but except for huge working
> > sets, non-negative.  And the maintainer knows if the package handles
> > huge chunks at once or not.
> Right. The maintainer should know it. But when the benefits are so small,
> one can argue if it's worth the work to change the build system? ;)
> Therefore I think it's best to first go with opt-in before make opt-out the
> default, let's say when etch+2 is out.

What I mean is opt-in for the maintainer, opt-out for the builder.
And the benefits are small only on UP.
   
> > > I would like to see a method to allow usage of other compile accelerators 
> > > as
> > > well (distcc (for using crosscc, but testing locally), ccache, etc). 
> > In theory, you would set CC, but not everything obeys it.  I
> > personally tend to mess with what "gcc" points to.  Usually with more
> > than one levels of indirection, too -- colorgcc is a nice thing for
> > when the output goes to a terminal.
> Of course, but my point is: when we make a decision now about -j flag, we
> can have some thougts about such accelerators as well and implement both in
> one go instead of having two separate changes to the build system. 

"changes to the build system"?  Where?

Note that in my proposal there are exactly no changes to the global
build system, except for a flag that can be set to force a package to
go down to -j 1.  No legislation needed.

And with the guessing code in my debian/rules (package kbtin on
m.d.n, as per the sibling branch of the thread), even that flag is
not needed.  On a small box, the package will go down to -j 1 without
any admin intervention.

I'm not talking about etch+2, I'm talking about something that can go
into the archive right now.  Just opt-in by including in debian/rules
the code of which v0.1 I uploaded to mentors.

Whee?
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: make -j in Debian packages

[Adam Borowski]

On Wed, Jun 28, 2006 at 03:42:07PM +0200, Wouter Verhelst wrote:
> SMP buildd systems currently run multiple instances of buildd at
> the same time, rather than expecting a package to specify make -j
> itself. Having three packages that specify 'make -j 4' on a
> multiprocessor buildd host that _already_ runs six builds in
> parallel is going to be devastating.

I admit, this is news to me.

> While parallel builds can indeed help speed up things even on
> uniprocessor systems, they do this at a price; they require a _lot_
> more RAM than non-parallel builds.

Modular C code can require an order of magnitude less memory than
templated C++.  What I propose is parallelizing only those packages
which are not heavy on RAM, on the maintainer's discretion.

If all packages had a similar memory profile, this would be an
optimization as it would equalize buildd loads somewhat.

> A uniprocessor parallel build will go faster for as long as your
> buffercaches can keep make, the compiler, and the most often used
> header files in memory; as soon as those need to be swapped out,
> your performance will go down dramatically. Since not all machines
> have the same amount of RAM, it is impossible to say in a generic
> way when this point is going to be.

Right, that is why the debian/rules snippet I suggested checks just
the amount of RAM without even looking at how many CPUs are present.

Indeed, it would fail to recognize several instances of buildd
running at once, but this is such a rare case that it can be handled
with an env variable we can agree upon.

> In any case, I have nothing against doing parallel builds by
> default (at least, not as long as it can be properly disabled and
> regulated),

Cool!  This is exactly what this thread is about.

What do you think about going with Don Armstrong's suggestion
($CONCURRENCY_LEVEL), while handling the default (no env var) my
way (decent memory => parallel, little memory => -j 1) instead of
Ingo's (-j 1 unless explicitely set)?

I think that the sample script I uploaded in kbtin would do the job;
if it is not good enough, it can be improved.

> but do not claim that it's a good thing "also for the buildd's",
> because you are sadly mistaken.

Still, my way is already an improvement over gem: gem used
unconditional -j4 and it happens to be a C++ package.

(Well, well.  Because this happened just days after I uploaded a
version with unconditional -j4 to mentors, it's likely it's me who's
the real culprit.  Gem's maintainer could have looked at my package
and copied -j4, the choice of 4 instead of 2 kind of suggests that.)


Another idea is to use -l; it trims concurrency down to 1 whenever system
load exceeds a given value.


Anyway, it's possible to come to an agreement that will make everyone
happy, and I believe we're close.

Meep?
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: make -j in Debian packages

[Adam Borowski]

On Wed, Jun 28, 2006 at 07:50:50PM +0300, Lars Wirzenius wrote:
> ke, 2006-06-28 kello 18:43 +0200, Adam Borowski kirjoitti:
> > What do you think about going with Don Armstrong's suggestion
> > ($CONCURRENCY_LEVEL), while handling the default (no env var) my
> > way (decent memory => parallel, little memory => -j 1) instead of
> > Ingo's (-j 1 unless explicitely set)?
> 
> I'm in favor of Ingo's approach. I don't think it is a good idea to
> hardcode assumptions of what is sufficient memory size into rules files;
> that's the kind of thing that is best done centrally.

Still, the buildd admin has no way to estimate how much a sub-process
of a package is going to use, the maintainer has at least a rough
idea.  Since the maintainer's action is needed anyway, he can as well
provide this estimate.
And then the buildd admin can set CONCURRENCY_LEVEL to 1 to centrally
disable any parallelism of this kind.

> (Also, any rules file snippet should be as simple as possible. Otherwise
> fixing it everywhere when a bug is found is going to be tedious.)

Exactly, or even better, it could be first debugged until it makes
everyone happy, then put into a common repository (debhelper?).  This
way, fixing a bug would require bothering just a single person.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: make -j in Debian packages

[Adam Borowski]

On Fri, Jun 30, 2006 at 03:26:15AM +0200, Goswin von Brederlow wrote:
> Adam Borowski <[EMAIL PROTECTED]> writes:
> > Still, the buildd admin has no way to estimate how much a sub-process
> > of a package is going to use, the maintainer has at least a rough
> > idea.  Since the maintainer's action is needed anyway, he can as well
> > provide this estimate.
> > And then the buildd admin can set CONCURRENCY_LEVEL to 1 to centrally
> > disable any parallelism of this kind.
> 
> One could patch make to use concurency when the ram permits. This
> would involves checking the current ram usage and forking more builds
> if there is enough

Oh, so you mean checking the _free_ RAM instead of the _physical_ RAM?
This would be reasonable -- I didn't use this in the debian/rules
snippet I proposed as the physical memory is a trivially discernable
number while free RAM can be sometimes hard to tell, especially on Xen:

Mem:588472k total,   574028k used,1k free,4k buffers
Swap:  1048568k total,   24k used,  1048544k free,   238984k cached

this is on a box where the only currently accessed process is mutt
(+sshd and $EDITOR).  Who cares if apache's processes which didn't
handle a single request in two months (the real server is elsewhere)
are in the physical memory?  Who cares about idle dovecot?  The box
is for all practical purposes completely idle as of right now.

Of course, when I say that something is tricky, it doesn't mean that
someone with more clue than me can't do it.


> as well as suspending submakes when swapping starts. But i guess
> that would greatly complicate make itself.

Actually, make -l already does something very similar.  It stops -j
from forking any new processes (above 1) once the system load exceeds
a given value.  And while the "system load" is a lousy measure, make
won't ever starve off the build, it will in the worst case behave as
make -j1, which is what Ingo wants.

Cheers and schtuff,
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: make -j in Debian packages

[Adam Borowski]

On Fri, Jun 30, 2006 at 08:41:33AM +0200, Ingo Juergensmann wrote:
> On Fri, Jun 30, 2006 at 03:22:48AM +0200, Goswin von Brederlow wrote:
> > The same can't be said for upstream makefiles though. Many sources
> > don't build with -j option.

Right, that's just what I said :p  It's the upstream and the
maintainer who know whether -j is safe or not -- the end-user or
buildd are not expected to guess this.  What the end-user and buildd
are supposed to have to say about is whether they want a fast or a
low-mem build.

> > I'm not sure if debian/rules should somehow enforce -j1 in those
> > cases

That would be opt-out, and everyone here seems to be against it in
this place.

Just let's not confuse maintainer's opt-foo and the builder's opt-foo.

> > or if only packages that benefit from -jX should add support for
> > some DEB_BUILD_OPTION or CONCURENCY_LEVEL env var. The later
> > would always be the save option. The former would have lots of
> > hidden bugs that prop up suddenly on rebuilds or security fixes.

Hell yeah.

> I'm strictly in favour of being on the safe side. If maintainers
> would start now to add -j4 to their makefiles, we would end in more
> FTBFS bugs,

It's them who are supposed to have a clue whether their packages can
handle -j or not.  If they are wrong, well, unlike typical SMP
issues, this is actually a bug which is pretty likely to pop up in
the first build.  This means before the upload is actually done, or,
for abysmal maintainers, when the faster autobuilders get the package.


> When we want to introduce some sort of concurrency builds, we
> should do it that way that the impact is as small as possible
> (opt-in). Start with some packages that are known to build fine
> with -jX and choose 1-2 buildds on some archs to implement this
> feature for a small test.

Good idea.

That's why I started with a small but not tiny (1MB of sources)
package of very little importance.  It appears to build fine, and
when I built it on a box with 24MB of memory, the machine didn't
croak.

So, here: take either this test package (kbtin), or, even better,
take the snippet between the marked () lines in
debian/rules and apply it to a bigger package.  I claim that it will
handle both small and big machines well by default, and obey
CONCURRENCY_LEVEL if it's set.  

This is not "intelligent design", there is a clear way to prove my
claims false.

> > Maybe someone should do a complete archive rebuild with -j1 and -j4 on
> > a smp system and compare the amount of failures to get an overview how
> > bad it would be.

Ugh, wrong.  A "complete archive rebuild" won't do anything if the
change is done in debian/rules, and it is known to be a bad idea for
any non-SMP-clean package already.

We're talking about allowing the maintainers to enable their packages
to make use of concurrency if they believe that:
1. their packages are SMP-safe
2. the amount of memory taken won't exceed like 128-256MB.

> > > Thus, my counter-proposal:
> > > Let's allow maintainers to use make -jX according to their common
> > > sense, requiring obeying an env variable to opt out.
> > and let the maintainer pass that env variable down a -jX.
> > How about this option:
> > We write a tool "concurency-helper" that gets a set of requirements of
> > the source and outputs a suitable concurency level for current build
> > host. Requirements could include:
> > --package pkg
> >Let the tool know what we build. The tool can have overrides in
> >place for packages in case special rules apply.
> > --max-concurency X || --non-concurent
> >Limit the concurency, possibly to 1, for sources that have problems
> >with it. Although such sources probably just shouldn't support this.
> > --ram-estimate X [Y]
> >Give some indication of ram usage. If the host has too little ram
> >the concurency will be tuned down to prevent swapping. A broad
> >indication +- a factor of 2 is probably sufficient. The [Y] would
> >be to indicate ram usage for 32bit and 64bit archs seperately.
> >Given the pointer size ram usage can vary between them a lot.
> > --more-concurent
> >Indicate that there are lots of small files that greatly benefit
> >from interleaving I/O with cpu time. Try to use more concurency
> >than cpus.
> > The tool would look at those indicators and the hosts resources in
> > both ram and cpus and figure out a suitable concurency level for the
> > package from there.
> > What do you think?
> 
> Of course this is a more complex approach, but I think it's an approach into
> the right direction. I would like to have settings for distcc to get added
> (like --use-distcc and --distcc-hosts)

A good idea.  My proposal was to keep it simple, at the cost of being
too cowardly when distcc is in use.

If the helper is stored in a common place, this would also handle
duplication of code.

> > > Rationale:
> > > Nearly every buildd and nearly every user building the packages on
> > > his own wil

Re: ITP: openwatcom -- C/C++ compiler and IDE that produce efficient, portable code

[Adam Borowski]

On Sun, Jul 02, 2006 at 06:17:20PM -0400, Jason Spiro wrote:
> * Package name: openwatcom
> * License : Sybase Open Watcom Public License 1.0 (it is 
> OSI-approved)

Oops... it looks like OSI smoked something especially bad this time,
I'm afraid.  This license looks like someone took his time to collect
every single problematic clause.

Debian-legal may provide you with a clause-by-clause analysis, but
let me point out just one particular gem:

the moment you use openwatcom to compile any work-related piece of
software (thus not "Personal Use"), you need to make the source of
openwatcom publicly available for 12 months.


Regards,
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: ITP: openwatcom -- C/C++ compiler and IDE that produce efficient, portable code

[Adam Borowski]

On Mon, Jul 03, 2006 at 01:10:34AM +0100, Matthew Garrett wrote:
> Adam Borowski <[EMAIL PROTECTED]> wrote:
> > the moment you use openwatcom to compile any work-related piece of
> > software (thus not "Personal Use"), you need to make the source of
> > openwatcom publicly available for 12 months.
> 
> What? 
> 
> "You must make Source Code of all Your Deployed Modifications publicly
> available under the terms of this License, including the license grants
> set forth in Section 3 below, for as long as you Deploy the Covered Code
> or twelve (12) months from the date of initial Deployment, whichever is
> longer."
> 
> That is, if you modify openwatcom and distribute that modified version
> (even internally), you must provide the source code to the modified
> version to the public. Some people may find that objectionable, but it
> doesn't appear to mean what you claim.

# 1.4 "Deploy" means to use, sublicense or distribute Covered Code
# other than for Your internal research and development (R&D) and/or
# Personal Use, and includes without limitation, any and all internal
# use or distribution of Covered Code within Your business or
# organization except for R&D use and/or Personal Use, as well as
# direct or indirect sublicensing or distribution of Covered Code by
# You to any third party in any form or manner.

"use", like, for example, compile a piece of software.  You don't
need to distribute openwatcom to anyone to fall within this clause.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: ITP: openwatcom -- C/C++ compiler and IDE that produce efficient, portable code

[Adam Borowski]

On Mon, Jul 03, 2006 at 01:36:12AM +0100, Matthew Garrett wrote:
> Adam Borowski <[EMAIL PROTECTED]> wrote:
> > "use", like, for example, compile a piece of software.  You don't
> > need to distribute openwatcom to anyone to fall within this clause.
> 
> Ok, but it still needs to be modified. Are you suggesting that the 
> freedom to produce a binary that can't be recompiled by anyone else is a 
> necessary freedom?

Let's say my modifications to openwatcom consist of changing -O2 to
-Os.  This is still a modification, and as such, it forces me to
distributing it to the entire world for 12 months.  Unless I cope
with this, I'm limited to compiling things only for:
* my "Personal Use"
* "R&D"

As such, this breaches DFSG6.


-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: make -j in Debian packages

[Adam Borowski]

On Sun, Jul 02, 2006 at 11:57:50AM +0200, Wouter Verhelst wrote:
> Additionally, it puzzles me how you think a maintainer will be able to
> accurately predict how much RAM a certain build is going to use. There
> are so many variables, that I think anything but 'this is the fastest
> way to build it on my machine' is going to be unfeasible.

Let's say:
program X consist of a number of C files; it seems like compiling
every file takes around 24MB, with the final link taking much more[1].
I guess this can be called typical, in C you need to store just the
current file and the headers you use.

Now, let's assume we use not the simple snippet I wrote [2] but a
"concurrency-helper" with the interface Goswin described, with some
unknown logic inside.

The maintainer thus declares that package X takes 24MB, and says it's
good to use heavy concurrency:
concurrency-helper --ram-estimate 24 --more-concurrent

The machine is a mid-range user box, with 512MB ram.

Thus, if the helper decides to go with -j4, the safety margin is _5_
times.  I guess you can trust people to be at least within _that_
error range.  And even if they fail, you can always force the build
to use -j1.

If, let's say, the machine is a high-end one with 2GB ram, it runs 4
buildds at once and the admin didn't specify his preferences, using
-j4 won't be any worse than on the user box mentioned above.



[1]. I was once forced to do a kernel compile on a critically memory
starved box.  Going from .c to .o went quite smoothly, but the final
link was an unholy swappeathon that took hours.

[2]. My idea was to simply go with -j1 if the machine has less than X
memory, or with a given constant otherwise.

Cheers,
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Using the SSL snakeoil certificate

[Adam Borowski]

On Tue, Jul 04, 2006 at 02:38:30PM +0200, "Uwe A. P. Würdinger" wrote:
> James Westby schrieb:
> >An estimate of the pacakages that generate a certificate in postinst
> >(lets hope there are none that include them in the package) I tried:
> >
> >$ grep-available -FDepends openssl -sPackage -n | sort
> 
> Well there are a number of packages out there that can use X509 Certs 
> but don't do so now as per default for example lighttpd.

Toss pound into the list as well.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: make -j in Debian packages

[Adam Borowski]

On Wed, Jul 05, 2006 at 08:23:00PM +0200, Wouter Verhelst wrote:
> On Mon, Jul 03, 2006 at 03:04:14PM +0200, Adam Borowski wrote:
> > On Sun, Jul 02, 2006 at 11:57:50AM +0200, Wouter Verhelst wrote:
> > > Additionally, it puzzles me how you think a maintainer will be able to
> > > accurately predict how much RAM a certain build is going to use. There
> > > are so many variables, that I think anything but 'this is the fastest
> > > way to build it on my machine' is going to be unfeasible.
> > 
> > Let's say:
> > program X consist of a number of C files; it seems like compiling
> > every file takes around 24MB,
> 
> Like I said, there's just too many variables. Also, I wouldn't be
> interested in figuring out how much RAM the build takes if I were to
> maintain a package like, say, X or so.

No one forces you to do so.  No one even said a word about making
concurrency mandatory.  It's just a way to make builds faster on
machines that are beefy enough (ie, virtually all).

> You're not convincing me that you can indeed accurately predict for
> every compiled language out there how much RAM you're going to need
> during the build.

So what?  If you're not sure, you simply don't provide your
prediction.  And with a huge safety margin, you would have to be
MALICIOUS to make a mistake.

> Before you've proven that this is indeed possible, I don't think
> there's much point in this whole exercise; otherwise there
> *is* going to be a problem with you overloading build machines, and
> *you will* get bugs filed about that (from me, at the very least).

Here, you got a piece of working code, is that not a good enough
proof?  Tell me how exactly a build using 4 processes using ~24MB
each overloading a build machine which has 512+MB ram.  And builds
which do require 1+GB of memory, well, simply are not going to use
any concurrency.

And note that the system I propose actually _limits_ concurrency in
some cases.  The whole thread started with gem packages choking the
m68k build.  It's a big package, and the maintainer rightfully
thinked that it is completely useless on small arches.  The
optimization he employed was to use -j4 -- something that can't hurt
a machine on arches where the package is usable.  Too bad, the
maintainer's fault was that he didn't protect the -j4 from arches
which can't handle it.  And handling this, exceptionally rare in
normal use, case is what we can fix.

Even you, in the initial post of this thread, proposed a way to
enable concurrency in some cases, so this can't be such a bad idea :p

Regards,
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: cdrtools

[Adam Borowski]

On Fri, Jul 07, 2006 at 08:57:54AM +0200, Daniel Baumann wrote:
> Kevin Bube wrote:
> > What about switching to dvdrtools? I think this project was
> > started to solve the frequently recurring arguments about the
> > licensing and the device adressing scheme cdrtools use.
> 
> dvdrtools are currently in non-free (so not part of Debian at all)
> and therefore not a solution/replacement

I completely fail to see any logic here:
* cdrtools, obviously completely non-free, is in main
* dvdrtools, a fork of the last GPLed version, is in non-free

The only reason why dvdrtools would sit in non-free is a controversy
whether a "clarification" can be retroactive.  If it can be, it is
quite a hit to the GPL in general.

Freeness of dvdrtools is >= freeness of cdrtools, at least.

> The people in charge (CTTE and the maintainers) are working on an
> optimal solution. They will communicate it as soon as they are
> ready.

And of course, this particular case is already in good hands.  What I
am interested in is whether GPL can be withdrawn.  Of course, the
copyright holder can relicense new versions to his heart's content,
but can he take away people's rights from older releases?  The whole
point of the GPL is to prevent _anyone_ from imposing further
restrictions that could limit the freeness of covered software, so I
would say that this would be a bad precedent.

Cheers,
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: These new diffs are great, but...

[Adam Borowski]

On Fri, Jul 07, 2006 at 02:28:49PM +0200, Marc Haber wrote:
> Updating with pdiffs took one minute nine seconds while downloading a
> completely new set of list files took eight seconds.
> 
> Test environment was quite unfair though (an old machine with an 1200
> MHz CPU and a single, slow disk on an 100 MBit link to a rather local
> mirror).

1200MHz is slow these days?  I ran this very test on Wednesday's
night, on a super-duper machine overclocked to whooping 120MHz.

But even though it was only ~10 diffs (installed from Sunday's d-i
daily), I have to concur with your results :p

And the installation isn't complete yet...

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: make -j in Debian packages

[Adam Borowski]

On Fri, Jul 07, 2006 at 03:34:59PM +0200, Wouter Verhelst wrote:
> Err, AIUI, ruby gems are a way to automatically install extras to a
> running ruby environment, much in the same way that the CPAN module is
> used for Perl.
> 
> I fail to see why this would be "completely useless" on smaller
> architectures. If you want to use ruby there, you may want to use gem.

Uhm, gem seems to be a X11 package dealing with graphics rendering
and animation.  "grep -ir ruby" on its source doesn't show anything,
too.  Or am I missing something?

Also:
  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
18425 kilobyte  25   0 20904  15m 5660 R 29.5  3.2   0:01.00 cc1plus
18428 kilobyte  25   0 19880  14m 5552 R 23.6  2.9   0:00.71 cc1plus
18436 kilobyte  25   0 17496  10m 3232 R 10.3  2.0   0:00.31 cc1plus
18259 kilobyte  15   0  4940 1392 1008 S  1.7  0.3   0:00.59 mpc123
18426 kilobyte  23   0  5004 2372 1468 S  1.7  0.5   0:00.06 g++
18434 kilobyte  25   0  5004 2376 1468 S  1.7  0.5   0:00.05 g++
18423 kilobyte  16   0  2264 1152  852 R  0.3  0.2   0:00.02 top

Doesn't sound that deadly...

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: make -j in Debian packages

[Adam Borowski]

On Fri, Jul 07, 2006 at 02:46:15PM +0200, Goswin von Brederlow wrote:
> The point of the helper is to remove the decision from the package
> alone to a central place that is easily configurable for a wide range
> of cases.

Ok, here goes my stab at the helper:
(attached)

Usage:
  $(MAKE) -j`debian/concurrency-helper`

  (note: you'll need to either chmod +x or insert "perl " after the
  first backtick)

Maintainer's manipulation:
  on command line

User's manipulation:
  ENV var

joeyh's manipulation:
  upgrade clause


I see that the rules I used are probably way too cowardly memory-wise
but way too fork-happy where the number of CPUs is concerned.  But oh
well, it's not me who is supposed to set the defaults anyway :p



This time an example isn't really needed, but just in case I've used
kbtin as the test package.  mentors.debian.net seems to be down, so:

deb-src http://angband.pl/debian unstable main
dget http://angband.pl/debian/kbtin/kbtin_1.0.7-1.dsc
(in an uploadeable state, in case you'll want to test it against real
buildds :p)

Cheers,
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.
#!/usr/bin/perl -w
use strict;
use integer;

#Upgrade clause:
my $dh='/usr/bin/dh_concurrency';
exec {$dh} $dh,@ARGV if -x $dh;


=head1 NAME

concurrency-helper - guess a reasonable concurrency level for make

=head1 SYNOPSIS

$(MAKE) -j`B [S>]`

=head1 DESCRIPTION

concurrency-helper is a program that will guess whether running more parallel
I jobs would speed up the build, and write a reasonable argument for I<-j>
on the standard output.

If the environment variable B is set, it will override any
guesses.

=head1 OPTIONS

This is the interface for the package maintainer.

=over 4

=item B<--ram-estimate> I [I]

   Give some indication of ram usage, in megabytes.  If the host has too
   little ram the concurency will be tuned down to prevent swapping.  A
   broad indication +- a factor of 2 is probably sufficient.  The [Y] would
   be to indicate ram usage for 32bit and 64bit archs seperately.  Given the
   pointer size ram usage can vary between them a lot.

=item B<--more-concurrent>

   Indicate that there are lots of small files that greatly benefit from
   interleaving I/O with cpu time.  Try to use more concurency than cpus.

=item B<--max-concurrency> I

   Limit the concurrency to no more than X.  Shouldn't be ever needed, you're
   either SMP-safe or not.

=back

=head1 CAVEATS

This helper can't detect multiple builds running on the same host.  In
that case, just set B appropiately; to 1 if you want
to disable any parallelism altogether.

=head1 SEE ALSO

L

=head1 AUTHOR

Adam Borowski <[EMAIL PROTECTED]>

=cut


#Leaving no output would lead to bare -j, that is, -j INFINITY.
sub die_1($)
{
print "1\n" unless -t STDOUT;
die "concurrenct-helper: $_[0]";
}

if (defined $ENV{'CONCURRENCY_LEVEL'})
{
$ENV{'CONCURRENCY_LEVEL'}=~/^(\d+)$/ && $1>0
or die_1 "E: CONCURRENCY_LEVEL malformed.\n";
print "$1\n";
exit;
}

my ($mem,$cpus); #machine's specs
my ($ram32,$ram64,$limit,$extra); #arguments
my $ram;

open FREE, "free|" or die_1 "W: can't run 'free'.\n";
while()
{
$mem=$1/1024 if /^Mem:\s+(\d+)/;
}
close FREE;
$mem or die_1 "W: can't get the amount of memory.\n";

if (open CPUS, ");
close CPUS;
}
$cpus=1 unless $cpus;

while(@ARGV)
{
$_=shift;
if (/^--max-concur(|r)ency$/)
{
$_=shift
or die_1 "E: --max-concurrency requires an argument.\n";
/^(\d+)$/ && $1>0
or die_1 "E: --max-concurrency expects a positive integer.\n";
$limit=$1;
}
elsif (/^--ram-estimate$/)
{
$_=shift
or die_1 "E: --ram-estimate expects an argument or two.\n";
/^(\d+)$/
or die_1 "E: --ram-estimate: ram32 malformed.\n";
$ram32=$1;

#The second argument is optional.
if (@ARGV && $ARGV[0]=~/^(\d+)$/)
{
$ram64=$1;
shift;
}
else
{
$ram64=$ram32;
}
}
elsif (/^--more-concur(|r)en(cy|t)$/)
{
$extra=1;
}
else
{
die_1 "E: invalid argument \"$_\"\n";
}
}

$ram=(length(pack('l!',0)) <= 4)? $ram32:$ram64;


### Here the fun starts.
# Edit this part to fine-tune the logic.

#Default to 24MB per job.
$ram=24 unless $ram;

#Be a coward, use no more than 1/5 of the memory.
$_=$mem/5/$ram;

#Don't have too many jobs waiting for CPU.
my $cap=$cpus+1;
$cap*=2 if $extra;
$_=$cap if $_>$cap;

#Obey --max-concurrency.
$_=$limit if (defined $limit && $_>$limit);

#But use at least _one_ job.  We want to get the build done, don't we?
$_=1 if $_<1;

print "$_\n";

Re: Long blurbs repeated in many package descriptions considered harmful

[Adam Borowski]

On Sat, Jul 08, 2006 at 02:18:19PM +0200, Enrico Zini wrote:
> For example, the pike blurb could be summarised with something like:
> 
>   Pike is an interpreted, object-oriented, dynamic programming language
>   with a syntax similar to C.  To learn more about pike, see the package
>   pike7.6 or visit http://pike.ida.liu.se/

For pike itself, that's a good description.  For pike-pcap, no way.

> I think it is essential to provide information about acronyms and other
> high-tech names, however they should be essential and they shouldn't
> distort search results mentioning things that are not present in the
> package.  When the pike module for pcap says what is pike, it's ok.  But
> when it mentions image manipulation, database connectivity and XML
> parsers, then it's strongly misleading.

If you want to explain what "pike" is, I think it would be best to
say "pcap is blah blah blah for the pike programming language".
^
This is exactly the amount of explanation that is due.  No less, no
more.  It tells a casual user well enough "what is pike", but doesn't
include anything not related to the library itself.

Just my 2 zorkmids,
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: greylisting on debian.org?

[Adam Borowski]

On Mon, Jul 10, 2006 at 05:57:45PM +0200, Adrian von Bidder wrote:
> On Monday 10 July 2006 02:17, Matthew R. Dempsky wrote:
> > On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote:
> > > Another problem is with hosts that do not accept a message from an MTA
> > > unless that MTA is willing to accept replies.  This is a common spam
> > > prevention measure.
> >
> > It also prevents mail from setups that use different servers for inbound
> > and outbound mail.
> 
> Hmm.  I've not seen this kind of sender verification.  As I know it, the 
> receiving MX connects the regular MX for the sender address to see if 
> *that* is ready to receive mail.  Works beautifully if outbound != inbound.

In fact, broken servers which don't obey MX will _already_ fail:

debian.org  A   192.25.206.10
debian.org  MX  master.debian.org
master.debian.org   A   70.103.162.30

[~]$ telnet 192.25.206.10 25
Trying 192.25.206.10...
Connected to 192.25.206.10.
Escape character is '^]'.
220 gluck.debian.org ESMTP Exim 4.50 Mon, 10 Jul 2006 18:06:29 -0600
helo utumno.angband.pl
250 gluck.debian.org Hello acrc58.neoplus.adsl.tpnet.pl [83.11.4.58]
mail from: [EMAIL PROTECTED]
250 OK
rcpt to: [EMAIL PROTECTED]
550 relay not permitted


MX records have been with us for 20 years, so I don't think a
legitimate mailer can ever disobey one.  Of course, illegitimate
mailers often do.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Bug#377939: ITP: vtgamma -- gamma correction for Linux console

[Adam Borowski]

Package: wnpp
Severity: wishlist
Owner: Adam Borowski <[EMAIL PROTECTED]>

* Package name: vtgamma
  Upstream Author : myself
* URL : http://angband.pl/viewvc/vtgamma/trunk/
* License : Public Domain
  Description : gamma correction for Linux console

 This tool can apply gamma correction to Linux virtual terminals (and
 possibly others).  The correction can use either a single gamma value,
 or separate ones for each color component (R/G/B).
 .
 As CRT monitors rapidly lose low-to-mid-range luminance with age, gamma
 correction can significantly improve the usefulness of old ones.  At the
 very least, light gray is easier to read than dark yellow.
 .
 Of course, no one stops you from adjusting your LCD as well, though.


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


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

Re: cdrtools

[Adam Borowski]

On Wed, Jul 12, 2006 at 12:46:51PM -0700, Erast Benson wrote:
> Joerg clearly stands that:
> 
> 1) Makefiles != scripts or at least it is unclear whether Makefiles may
> be called "scripts":
> 
> """ GPL §3 requires the "scripts for compilation" to be provided but
> as a first note, it is unclear whether Makefiles may be called
> "scripts".

Er, wait.  This is complete nonsense: the very definition of a
makefile is "compilation script".
 
> Makefiles are programs written in a non-scripting language:
> I call this language "make". It is a non-algorithmic language but
> a rule based language (like e.g. CDL2)."""

The word "script" in computing came from theater, previously meaning
"screenplay", listing the things actors have to do, in a particular
order.
Makefile does exactly that, lists what compiler/linker/etc have to
do, in a given order.


Thus, a makefile is certainly more a script than for example a Perl
module, and if it's not a "compilation script", then I don't know
what is.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Getting the buildds to notice new architectures in a package

[Adam Borowski]

On Sat, Jul 15, 2006 at 10:55:32PM +0200, Ludovic Brenta wrote:
> I will upload ~20 source packages in the next few weeks, adding
> support for more architectures to each package.  So I'm really looking
> for a general solution and not one that only applies to asis.

Why aren't those packages arch:any?  "asis" neither uses any hardware
devices, nor appears to have assembly code anywhere inside.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: ITP: gzrt -- gzip recovery toolkit

[Adam Borowski]

On Sun, Jul 16, 2006 at 10:11:41AM +0200, Thijs Kinkhorst wrote:
> On Sun, 2006-07-16 at 13:14 +0800, Paul Wise wrote:
> > I will drop the version from the description and add cpio to the
> > suggests. 
> > 
> > I added the suggestion to the description because I guess that .tar.gz
> > will be the most common type of file being recovered
> 
> I agree that that is a common type of file to recover, so that would
> make it more appropriate to Recommend cpio rather than Suggest.

"a common type"?  Come on, that's not just "common", it's "a vast
majority of cases".  And, a hard Depend on a small priority=important
package is not a big burden -- what about just having a dependency
without the comment?

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: greylisting on debian.org?

[Adam Borowski]

On Mon, Jul 17, 2006 at 10:42:22PM +0100, Stephen Gran wrote:
> This one time, at band camp, Thomas Bushnell BSG said:
> > And finally, if we don't care about standards conformance, I have said
> > that a good second-best is to document exactly what our requirements
> > are, rather than burying them in apparent secrecy.
> 
> What standards, exactly?  Can you be specific?  I have seen you assert
> this several times, but I see nothing in the RFCs preventing a site from
> saying it has a temporary local problem when it doesn't.

Even worse, there's nothing preventing a site from saying it has a
temporary local problem when it _does_.  Thus, if your mail server
can't handle retrying, it will drop mail every time something is not
in perfect working order.  And hardware or network failures are
something to be expected.

Any legitimate server must support retrying.  For any reason.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Bug#378746: ITP: chameleon-cursor-theme -- a modern but not gaudy X11 mouse theme

[Adam Borowski]

Package: wnpp
Severity: wishlist
Owner: Adam Borowski <[EMAIL PROTECTED]>

* Package name: chameleon-cursor-theme [1]
  Version : 0.5-1
  Upstream Author : Giuseppe Benigno 
* URL : 
http://www.{gnome,kde,xfce[2]}-look.org/content/show.php?content=38459
* License : GPL
  Description : a modern but not gaudy X11 mouse theme
 Package comes with 15 different mouse themes for X11.
 5 colors (anthracite, sky blue, dark sky blue, white, pearl)
 3 different sizes (small, regular and large)
 .
 Preview: http://www.kde-look.org/content/show.php?content=38459


The default, industrial-cursor-theme, comes in just one size.  The two
other good themes we have, comixcursors and crystalcursors are really
compatible only with desktop themes matching ".*k.*".  xcursor-themes
are only so-so, so adding one more package won't hurt...

Speaking from a more complete point of view, the only themes worth
being packaged left on http://www.foo-look.org are perhaps silver and
yellowdot -- the rest is either redundant or ugly.  Of course, you do
know that my opinion is the highest authority in the realm of
aesthethics.


[1]. Should I stick to *-cursor-theme or *cursors?  Or keep the
upstream name, chameleon Xcursors?

[2]. Alas, they don't seem to support WindowMaker or BlackBox :p


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

Re: Getting rid of circular dependencies, stage 5

[Adam Borowski]

On Wed, Jul 26, 2006 at 04:41:37PM +0200, Goswin von Brederlow wrote:
> Andreas Barth <[EMAIL PROTECTED]> writes:
> > * Ian Jackson ([EMAIL PROTECTED]) [060726 13:18]:
> >> But, for example,  foo <-Depends-> foo-data  is not usually an example
> >> of a silly dependency.
> >
> > Actually, there is no reason why foo-data needs foo configured before
> > being configured, but there might be reason for the other direction.
> > Why not inventing some new "Depends-for-being-useful" from foo-data to
> > foo, and having Depends cycle-free?
> 
> Pre-Depends: Needs to be unpacked and configure before me
> Depends: Needs to be configured before me
> 
> How about adding:
> 
> Post-Depends: Needs to be configured for me to be useable
> 
> The difference between Depends and Post-Depends would be that only the
> former may use the other package in the maintainer scripts.
> 
> 
> To implement this dpkg would need a new state. One between
> unconfigured and installed, say post-config or configured. Packages
> would go from purged to unpacked (unpacking done) to configured
> (maintainer scripts have been run) to installed (Post-Depends have
> been configured).

Adding a new state would break a lot of tools, and require a couple
of releases until it's functional.

What about this:
"Post-Depends:"/"Needs:" don't have to be satisfied for a package to
be configured.  If A "Needs:" B, you can still have A installed
without B, and have a perfectly functional system -- from dpkg's
point of view.
Apt and the frontends which understand the new field will scream at
you, and won't allow such a case to happen (unless forced).

If you have a mixed system where some tools know about the new field
and some which don't, you may end up with left-over cruft like
foo-data installed without foo.  This is not a problem except for
some disk space wasted -- you do have useless files on your
filesystem, but they have otherwise no detrimental effect.


This way, you could have this in for Etch.


Here's how existing tools handle the field:

dpkg-gencontrol: warning: unknown information field `C Needs' in
input data in general section of control info file
(and the field gets weeded out of the .deb)

dpkg -- no problems -- ignores it but stores

apt -- no problems (ignores it)

So, even backports would be covered with an acceptable failure mode.


> Post-Depends cycles could be broken by allowing: A package can go from
> configured to installed when all its Post-Depends are configured or
> installed. Or Post-Depends cycles are just required to be transitioned
> as one, no splitting by apt-get into multiple calls allowed.
In my proposal, apt wouldn't require to pass this to dpkg in any
special way.  It would just install B whenever A is selected for
installing, and remove A if you ask for removing B, without dpkg
knowing why this is done.

Cheers and schtuff,
-- 
1KB // Q: How do you spot a good inetd?
// A: It build-depends on equivs.


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

Re: RFC: ssl-cert2 design

[Adam Borowski]

On Fri, Jul 28, 2006 at 10:03:13AM +0300, Lars Wirzenius wrote:
> pe, 2006-07-28 kello 00:03 +0100, James Westby kirjoitti:
> >   * Make it easier for package maintainers
> > - One extra dh_ call and maybe one more file in debian/
> 
> How badly is this tied to debhelper? Any chance of designing it so that
> it doesn't require debhelper?

The dh_ file can be shipped with ssl-cert2, preferably under a name
that doesn't invade debhelper's namespace.  As the packages are going
to depend on ssl-cert2, making them build-depend on it is not a real
burden.

-- 
1KB // Q: How do you spot a good inetd?
// A: It build-depends on equivs.


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

Re: console mode(probally off)

[Adam Borowski]

On Mon, 2 Jun 2003, Sean 'Shaleh' Perry wrote:
> On Monday 02 June 2003 04:09, Luiz Rafael Culik Guimaraes wrote:
> > How to start debian  direct on console mode,
> Eh?  I thought Debian always started in console mode unless you both 
> installed 
> xdm (or the gnome/kde equivalent) and enabled it.
Unfortunately, all of these three ({x,g,k}dm) automatically start X when 
the system starts if they are installed, and AFAIK neither of them 
provides a way to disable them other than uninstalling them or editing 
/etc/{rc*.d,init.d}/whatever by hand.

The things are even worse: a vast majority of novice users use tasksel 
when installing Debian, and the two most often selected tasks ("X window 
system" and "desktop environment") include xdm variants.  Thus, questions 
like "How to start debian direct on console mode" have a lot of merit.
It might be just me, but my eyes hurt more after a few hours of doing 
things in graphics mode than after a 48h straight programming run on a 
text console.



As a completely unrelated note, I wonder what is the reason to use fbdev 
instead of real text console/svgatextmode in the default kernel.  I was
setting up a server on an old Pentium MMX 210Mhz machine yesterday, and 
switching between consoles took more than a second.  Considering that even 
on a 1300Mhz machine with GForce2 at home fbdev scrolling is noticeably 
sluggish, I'm afraid to even think about what would happen on a 386.

What about reverting the installation kernels back to the good old real
text console, which has been enjoyed full hardware acceleration since 
the times of MDA cards?

1KB
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)

Bug#198158: architecture i386 isn't i386 anymore

[Adam Borowski]

On Fri, 20 Jun 2003, Bill Allombert wrote:
> On Fri, Jun 20, 2003 at 09:51:07AM +0200, Matthias Klose wrote:
> > - drop the i386 support
> What we have not yet decided is whether we drop i386 support for C++
> packages or for all packages. If we choose the former, the mini-i386
> will just need to contain the important C++ packages. If we choose
> the later, developers can start to activate i486 optimisation in
> random packages.
Hmm... I'm not sure about this as the last time I used assembler was 
in the times of real mode DOS, but there is a yet another option:
we can patch the kernel so when an invalid opcode occurs, whatever 
instruction was at CS:EIP gets emulated in software, similar to the
way i387 emulation is done.
(arch/i386/kernel/entry.S)
Of course, this would further slow down the speed demon known as 80386,
but since (AFAIK) the 486-specific opcodes get used pretty rarely in 
non-kernel code, the performance hit wouldn't be crippling.  And, there
is no performance hit at all for >386 machines, as no legitimate process
ever triggers the invalid opcode fault.

> In any case we need to make clear if we allow 486 optimisation that
> are not i386 compatible or not.
What about perusing the INT 6 idea, and going all the way up to i686?
As i686 is already like ten(?) years old, I would say 99.9% [1] machines 
that run sarge are 686 and higher -- thus, moving to i686-specific 
optimizations would be good for the vast majority of users (this comes 
from someone who set up two servers on P MMX two weeks ago :p)

If speed on archaic machines is an issue, you can always use the
wonderful piece of software called apt-build.
 
Regards,
 1KB

[1] 90% of statistics are made up on the spot.

/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)

Bug#198158: architecture i386 isn't i386 anymore

[Adam Borowski]

On Fri, 20 Jun 2003, Stephen Stafford wrote:
> On Fri, Jun 20, 2003 at 02:25:52PM +0200, Adam Borowski wrote:
> > What about perusing the INT 6 idea, and going all the way up to i686?
> While I support the removal of 386 support, I absolutely and strenuously
> object to going to 686.  686 isn't all that old at all (1997 IIRC), and I
> use a nunber of 4/586 machines still (I have one 486 which I use for
> embedded development and 3 P100 boxen which are used for various things like
> CVS server, gateway/firewall, testing various things).
Note that my idea was about patching the kernel that so the newer opcodes 
would be emulated in software.  Everything would still work even on a 386, 
just slower -- and the speed decrease can be removed by running apt-build.

1KB
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)

Bug#198158: architecture i386 isn't i386 anymore

[Adam Borowski]

On Sat, 21 Jun 2003, John Goerzen wrote:
> On Fri, Jun 20, 2003 at 03:28:02PM +0200, Adam Borowski wrote:
> > Note that my idea was about patching the kernel that so the newer opcodes 
> > would be emulated in software.  Everything would still work even on a 386, 
> > just slower -- and the speed decrease can be removed by running apt-build.
> I don't see how that suggestion can possibly be taken seriously.  Very few
> i386 machines have the requisite disk space, memory, and swap space to build
> large applications in Debian today.
You do have a Pentium 17 10^38Mhz machine nearby, don't you?  Apt-build
doesn't even give the option of avoiding creation of .debs, and the bigger
machine is one scp (or two mcopys in an extreme case) away.

-- 1KB

Bug#198158: architecture i386 isn't i386 anymore

[Adam Borowski]

On Wed, 25 Jun 2003, Branden Robinson wrote:
> > Hmm... I'm not sure about this as the last time I used assembler was 
> > in the times of real mode DOS, but there is a yet another option:
> > we can patch the kernel so when an invalid opcode occurs, whatever 
> > instruction was at CS:EIP gets emulated in software, similar to the
> > way i387 emulation is done.
> > (arch/i386/kernel/entry.S)
> > Of course, this would further slow down the speed demon known as 80386,
> > but since (AFAIK) the 486-specific opcodes get used pretty rarely in 
> > non-kernel code, the performance hit wouldn't be crippling.  And, there
> > is no performance hit at all for >386 machines, as no legitimate process
> > ever triggers the invalid opcode fault.
> 
> If this indeed feasible, then this is the solution that appeals most to
> me personally.
> 
> * It seems the least intrusive.  80386 users are probably going to want
>   and use an 80386-specific kernel, if they don't already *have* to.
> * Our hand is forced by the fact that the rest of the Linux distributors
>   in the world, and apparently the GCC folks, don't care about C++ ABI
>   portability to 80386 processors.
> * This doesn't require recompiling anything except the kernel.
> 
> The drawbacks:
> * Someone actually has to write this kernel patch.
As the person who originally submitted this idea, I'm probably the one
who is morally obliged to write it, even though:
* I'm not a kernel hacker,
* I was once good at _8086_ assembly, but the times of real mode are
  long gone, and I have no recent assembler experience,
* I'm moving home later this week, and won't be able to write this
  while my desktop machine is in transit (all the other boxes I got
  root access to are production servers),
* my skills are probably no match for most of you.

The pros and cons for the idea:
Pro:
  this kernel patch would make the 486 ABI transition flawless for all
  80386 users who have it applied, and (optionally) it can be used to
  make other software built for i486, i586 and i686 work on lesser CPUs.
Con:
  those on 80386 who don't have this patch applied will be screwed


I've made some proof-of-concept patches, and I'm ready for actually
emulating the opcodes.  However, you would need to answer the following
questions:
* what opcodes need to be emulated?
* just those needed for C++ ABI
* all 386->486 opcodes (there's just a few of them, right?)
* most 386->586 opcodes (it's impossible to emulate at least RDTSC,
  but the majority of code doesn't use it)
* 386->686?
* do you need SMP on 80386?  Is there even such thing as 80386 SMP
  machines?  Not requiring SMP support would make the ABI change 
  trivial...
* would you want some other emulation, like 486->586, 586->686?  MMX?
  Once the infrastructure for emulation is done, adding new opcodes
  is a simple task.


And, some patches for you to play with:
1. just reporting the invalid opcodes encountered
--- arch/i386/kernel/traps.c.0  2003-06-25 11:19:53.0 +0200
+++ arch/i386/kernel/traps.c2003-06-25 12:09:16.0 +0200
@@ -388,7 +388,6 @@
 DO_VM86_ERROR( 3, SIGTRAP, "int3", int3)
 DO_VM86_ERROR( 4, SIGSEGV, "overflow", overflow)
 DO_VM86_ERROR( 5, SIGSEGV, "bounds", bounds)
-DO_ERROR_INFO( 6, SIGILL,  "invalid operand", invalid_op, ILL_ILLOPN, 
regs->eip)
 DO_VM86_ERROR( 7, SIGSEGV, "device not available", device_not_available)
 DO_ERROR( 8, SIGSEGV, "double fault", double_fault)
 DO_ERROR( 9, SIGFPE,  "coprocessor segment overrun", 
coprocessor_segment_overrun)
@@ -397,6 +396,32 @@
 DO_ERROR(12, SIGBUS,  "stack segment", stack_segment)
 DO_ERROR_INFO(17, SIGBUS, "alignment check", alignment_check, BUS_ADRALN, 
get_cr2())
 
+
+asmlinkage void do_invalid_op(struct pt_regs * regs, long error_code)
+{
+   siginfo_t info;
+   int i;
+   
+   printk("Invalid opcode: ");
+   for(i=0;i<20;i++)
+   {
+   unsigned char c;
+   if(__get_user(c, &((unsigned char*)regs->eip)[i]))
+   {
+   printk(" Bad EIP value.");
+   break;
+   }
+   printk("%02x ", c);
+   }
+   printk("\n");
+   
+   info.si_signo = SIGILL;
+   info.si_errno = 0;
+   info.si_code = ILL_ILLOPN;
+   info.si_addr = regs->eip;
+   do_trap(6, SIGILL, "invalid operand", 1, regs, error_code, &info);
+}
+
 asmlinkage void do_general_protection(struct pt_regs * regs, long error_code)
 {
if (regs->eflags & VM_MASK)





2. an ugly hack that proves that the emulation can be done.  I took some
   random opcode that just happened to be not present on my machine (you
   would probably need to choose something else), and "emulated" it by
   a token operation: swapping eax and ebx.  I didn't even bother with
   making it nice, readable or anything -- it's just a test code.
--- arch/i386/kernel/traps.c.0  2003-06-25 11:19:53.0 +0200
+++ arch/i386/kernel/traps.c2003-06-25 13:09:5

Re: Application files in $HOME

[Adam Borowski]

On Wed, 2 Jul 2003, Colin Watson wrote:
> On Tue, Jul 01, 2003 at 12:49:10PM +0100, Esteban Manchado Vel?zquez wrote:
> > On Mon, Jun 30, 2003 at 10:57:40PM +0200, Matthias Urlichs wrote:
> >Now, if one removes or purges, say, KDE to install an unofficial
> > version... would (s)he loose all his icons and configuration?
> > 
> >It would be nice, perhaps, having a tool to do it "by hand", but I
> > don't think everybody wants it to be done automatically when removing
> > packages.
> 
> Indeed, it's definitely an incredibly bad idea to try to remove things
> in users' home directories by hand. Consider people who keep their home
> directories in sync (whether it be version control, NFS, unison, or
> whatever) across multiple systems. Those people definitely don't want
> purging a package on just one system to mess about with their shared
> home directory.
No one expects the sysadmin to remove their own files... in fact, people 
do believe their home directories are private, and are going to 
(rightfully) see the sysadmin even _reading_ them as an invasion of 
privacy.  Backing up or moving the entire dir to another physical disk 
during an upgrade is ok, as long as the admin doesn't meddle with the 
contents of the dir.

How I understand Daniel Ruoso's idea, is making:
1. a repository for keeping track of the names used for their $HOME/ files
   by packages that had been installed somewhen in the system's history.
   Example:
   wmaker: ("GNUstep/")
   joe:(".joerc",".jstarrc",".editorrc",".jmacsrc",".jpicorc",
".rjoerc")
   mc: (".cedit/",".mc/")
   links:  ("./links")
   
   This repository could optionally hold some information whether the file
   in question is installed by that package by default or has to be copied
   by the user.  If the former applies, it might even give some way to 
   tell if that config is likely to have been modified by the user or not.
2. a browser which, when invoked by the user, produces a nice list similar 
   to:

   File  SizePackageStatus
   GNUstep/  150MB   wmaker purged
   .jstarrc  2KB joeinstalled
   .cedit/   40KBmc removed
   .mc/  6KB mc removed
   
   (the original idea involved listing just purged packages, but an user 
   over the quota (no one else ever takes any time to clean up their dirs 
   :p) is pretty likely to consider getting rid of unneeded dotfiles even
   if the package in question is still installed).
   The user would then be able to either mark the files for removal is 
   some nifty ncurses-based browser akin to dselect, or type something
   like "userconfpurge delete --status=purged".

Whipping up some nice browser and it's command-line backend is not a 
problem.

Making the repository is.

Regards,
  1KB
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)

Re: surfraw ultimatum

[Adam Borowski]

On Tue, 22 Jul 2003, Thomas Smith wrote:
> On Tuesday, July 15, 2003, at 05:53 PM, I wrote:
> > I strongly believe that this is an overreaction.  Christian is willing 
> > to work with us to bring the package up to date, so there is no reason 
> > not to accept this.  I suggest that someone (I could do it) sets up an 
> > Alioth project for surfraw, so that the non-DD's who are interested 
> > can more easily contribute (using cvs or subversion).


Just don't *dare* to let anyone remove /usr/bin/google or I'll kill you, 
your dog and your friend's uncle's son's ex-roommate's girlfriend's aunt's 
pet hamster.


"surfraw --search-engine-to-use=google" is not an option in my book,
even though it can be aliased.


The Alioth project is a great idea, it would (aside from the main point, 
organizing bugfixes) prevent such heretical moves like the one 
above.  Surfraw provides a great convenient command-line interface to a 
zillion of search engines, however most of these engines tend to be not
used by anyone but a bunch of users.  On the other hand, damn everyone
uses google (or perhaps altavista or similar).  What about leaving 
interfaces to the few widely used search engines in /usr/bin/, and
moving aside (to /usr/share/surfraw/) the rest?  I might agree that
commands like "W", "rhyme" or "ask" are non-obvious and can cause
conflicts (name pollution), but come on, I can't think of any command
named "google" or "altavista" that would do anything else than to 
do a Google/AltaVista search.

While any seasoned admin or programmer is supposed to know where to look
for documentation, an average user is not likely to look in
/usr/share/doc/some-name-not-related-to-the-command/some-file.  If the 
command "google" you got used to suddenly stopped working, you won't know 
that a workaround can be found in /usr/share/doc/surfraw/README.Debian.

Surfraw's core functionality is just a tiny (but really convenient) alias.
There is no real difference between adding to your .bash_profile:
export PATH="$PATH:/usr/share/surfraw/"
to your .bash_profile, and adding something like:
alias surfraw='${BROWSER:-links} "http://www.google.com/search?"; `echo 
$*|sed s/foo/bar/`'
Thus, for both novice and expert users, axing /usr/bin/google is not a lot 
different from removing the surfraw package completely.




You do know how to look for documentation, people don't.  I had seen a 
friend (MSc in marketing) stumped by the task of creating an account on a 
free e-mail service, and a guy with PhD in computer science (not an Unix 
person, though) who asked for help with compiling an automake-style 
package (untar, configure, make).  Check out the "Installing from sources" 
section on http://kbtin.sf.net/ -- are these instructions enough?  
Considering from the number of e-mails I get, seems they're not.

Let's not throw hurdles at users who want to just use surfraw like it was 
intended to be used.


> So if anyone would like to start work and 
> send me surfraw patches I will be happy to quickly review them and 
> upload them, but I don't think I can fix any bugs myself for a few days.
Whee!
Considering the number of people interested in surfraw, you most likely 
already received a complete set of patches.
Unless anyone says the patches are done, I can do them.

All the bugs are either trivial or already have patches, except:
#134498: surfraw: component for searching Debian mailing lists
 -- request for a new elvi
#192869: surfraw: surprized you added so many commands to /usr/bin
 -- an evil conspiracy
#201175: surfraw conflicts with the 'rhyme' package
 -- so rename the command, in either of the packages

Regards,
 1KB

/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)

Re: [Fwd: False Representation at Google.com]

[Adam Borowski]

On Sat, 6 Sep 2003, Richard Braakman wrote:

> On Fri, Sep 05, 2003 at 05:12:35PM -0500, Adam Heath wrote:
> > On Fri, 5 Sep 2003, Ava Driscoll wrote:
> > > I do not appreciate the following showing up:
> > > http://lists.debian.org/debian-devel/2003/debian-devel-200306/msg01662.html
> > 
> > That email was sent by a virus.  This virus is really nasty.
> 
> Are you sure?  Looks like ordinary spam to me.  And this cease & desist
> was sent to [EMAIL PROTECTED] and then forwarded to us -- by the
> person who sent it?!?  Some very broken mail agents are involved here.
> Anyway, I don't think we're being addressed at all.

However, pulling that message from the list archives may be a good idea.
It's what Ava Driscoll asked for, and the big HTML links sure don't look
good on the Debian pages.

1KB
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)

Re: Debian should not modify the kernels!

[Adam Borowski]

On Sat, 27 Sep 2003, George Danchev wrote:
> > Why not? It's a package. We modify it as we need to in order to provide
> > functionality and satisfy the needs of our users. I'm perfectly willing
> > to bet that more of our users are interested in a functional ipsec stack
> > than are interested in the grsecurity patch.
> 
> I think this is not a gamble story to make a bet. I as an debian user am 
> sorry 
> to hear that from you. This is simply unfair. Do in mind that there is no 
> sane way to understand if users prefer ipsec or grsec to be included by 
> default in kernel-source-. Both ipsec (freeswan) and grsec kernel 
> patches are not security fixes, they do not fix existing security holes, they 
> are security enhancements. They both deserve to be included as 
> kernel-patch- packages...
Well... as 2.6 is coming out really soon, ipsec is in a lot better 
position than grsec.  Also, you will _have_ to port grsec to 2.6 (or 
abandon it), and 2.6 will have ipsec in the upstream sources.  The only 
difference lies in needing to do the porting work a bit sooner.

1KB

/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)

Bug#213361: ITP: kbtin -- A text-based MUD client

[Adam Borowski]

Package: wnpp
Severity: wishlist

* Package name: kbtin
  Version : 1.0.5
  Upstream Author : Adam Borowski <[EMAIL PROTECTED]>
* URL : http://kbtin.sourceforge.net
* License : GPL
  Sponsor : Wanted
  Package : http://kbtin.sf.net/debian/
  Description : A text-based MUD client

KBtin is a fullscreen console MUD client based on the once-popular tintin++.
It is not limited for mudding, and can be used for running line-based local
programs like adventure, wumpus or mysqlclient.

Re: Debian based GNU/Solaris: pilot program

[Adam Borowski]

On Thu, 3 Nov 2005, Erast Benson wrote:

Let me enlighten you in regards of CDDL benefits. The great thing about
CDDL is that it is file based. So, all files which are licensed under
CDDL-terms works exactly as GPL does. i.e. any change made by anybody
(including propriatery distributors) *must* be contributed back to the
community.


This only means that they can add any hooks within the CDDL code to their 
leisure.  All the juice can be kept within the proprietary file, and thus 
be not open in any way.



That is why OpenSolaris CDDL'd kernel allowes HW vendors to hide their
IP in their own proprietery files but at the same time forces HW vendors
to contribute their changes to CDDL-licensed files back to the
OpenSolaris community. This fact is a killer for Linux kernel. IMHO.


And it is exactly the reasons why Linux kernel is as good as it is.  Have 
you used the proprietary nVidia drivers from around two years ago?  They 
used to cause kernel oopses around twice per day (within my usage 
patterns), often causing complete lock-up and even (in the very last oops) 
a massive filesystem corruption.


Armed with a backtrace, even with my meager kernel hacking skills, I would 
have a good chance at fixing the crasher had I access to the code.  And 
even if I didn't succeed, Debian developers and users include a multitude 
of people who can recite kernel code in their sleep.  Such a bug would be 
gone in no time.  Even if you disregard the ideologic reasons, being able 
to make code usable is an important freedom.


Since recently, I dare to use a newer version of the nVidia driver.  And 
yet, although that crasher bug is either gone or doesn't apply to the 
hardware I am using, the very first time X is started after a boot, it 
somehow assumes the console is only 80x25 big, making me unable to 
reasonably switch back to text mode which I prefer.  As a workaround, I 
need to start X, kill it, run SVGATextMode then start X again.  And, can I 
fix this annoyance myself?  No way.  I can either beg nVidia, use the 
crippled driver or suck it up.



HW vendors will *never* open their IP in
drivers. Some HW vendors will never give NDAs for their user guides. So,
GPL kernels will always suffer as the result it forces Linux community
to reverse engineer binary drivers.


Uhm, who's left?  nVidia (an only for the 3D part), ATI, some wireless 
network adapters, and that's basically it.



The idea behind Nexenta OS is to bring GNU software to the level, when
end-user will not suffer from GPL kernel *limitations*.


Or, *freedoms*.  If a hardware vendor wants to profit from Linux users, 
they need to lift the limitations on the access to knowledge about their 
wares.


Regards,
--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)


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

Re: Debian based GNU/Solaris: pilot program

[Adam Borowski]

On Thu, 3 Nov 2005, Matthew Garrett wrote:

Debian scales fine on non-glibc ports. It doesn't do so well on non-GPL
compatible ports. These are very much not the same thing.


In fact, Debian and GPL software in general work just fine on non-GPL 
compatible platforms.  I use and distribute (even commercially) a number 
of GPLed programs compiled for the most closed, evil and proprietary libc 
in existence (msvc), and I have a full right to do so.  In fact, a good
deal of Debian packages compile and run using both CygWin and Microsoft 
libraries -- libraries that are shipped with the OS.


The only restriction is that I can't distribute GPLed things and MS 
Windows _together_.  This is purely intentional, and it was devised as a 
way to fight proprietary operating systems.  The OS exception is there to 
make the likes of Microsoft or Sun compelled to give us a set of 
well-defined freedoms.  That is, the licensing problems you have are not
a side issue that should be worked around, they arise from one of key 
goals of the GPL.


Regards,
--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)


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

Re: per-user temp directories by default?

[Adam Borowski]

On Fri, 4 Nov 2005, Lars Wirzenius wrote:

I don't think the suggestion was to make TMP=~/tmp, but TMP=/tmp/$USER,
where /tmp/$USER is owned by the user in question and is inaccessible to
others.


It would be a lot better to use TMP=/tmp/users/$USER, as user names are 
pretty likely to clash with files already in /tmp.  You can't pre-create 
all user dirs at boot as well -- there may be hundreds of thousands of 
users, new users can be created on the fly, or perhaps an authenthication 
mechanism doesn't even support providing you with the list of users.


Having a non-world-writable directory that can be written to only by a pam 
module which then chowns the individual dirs it creates would prevent such 
clashes.


Regards,
--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)


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

Re: debconf best practices: how to ask for a password?

[Adam Borowski]

On Tue, Jan 29, 2008 at 08:38:53PM +1100, Brian May wrote:
> > "Joey" == Joey Hess <[EMAIL PROTECTED]> writes:
> Joey> Francois Marier wrote:
> >> Now the problem (see bug #462658) is that if you ever put a non-empty
> >> password there, then, you can no longer get rid of it after
> >> dpkg-reconfiguring the package.  debconf seems to be ignoring empty 
> password
> >> fields and still returns the previous value.
> 
> Joey> This is a deficiency in debconf's UIs for prompting for password. 
> Since
> Joey> there's generally no sane way to display the old password as the 
> default
> Joey> and allow users to change it or delete the password entirely, 
> debconf
> Joey> instead displays no password, and if the user enters nothing, 
> assumes
> Joey> they meant to enter the old password unchanged.
> 
> This is really confusing UI. To me, as a user, it would appear there
> is no way of reusing the old password, and it would appear that
> pushing enter will result in the password being truncated. In fact
> this is what probably would happen if the system has forgotten the
> password entered for some reason (maybe it was never entered via
> debconf before).

What about this:
if there's a non-empty password, present the user with a magic value (8
stars, one star, "[old password]", etc).  If the debconf dialog returns the
magic value, keep the password unchanged.  If it's anything else (including
an empty value), use whatever is provided.

As long as no one tries to set the password to the magic value, this should
do the trick.


In an unrelated note, I have several users who haven't changed their
passwords after I set it to "Leave it empty".  Hey, it was them who said it
should be that way in the first place :p

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Wrong Architecture for openhackware

[Adam Borowski]

On Wed, Jan 30, 2008 at 09:48:45AM +0200, Guillem Jover wrote:
> On Sat, 2008-01-12 at 18:47:53 +0100, Roland Stigge wrote:
> > Again, I don't agree here (backed by p2): The package is wrong if it
> > asserts that it's "Architecture: all". It contains powerpc specific
> > stuff and can only be built on (i.e. for) that architecture. Therefore,
> > it should be "Architecture: powerpc".
> 
> Yes, ideally, to be pedantically correct, we would either have
> powerpc (or other) cross-toolchains on the archive,

At the first [1] glance, it appears that all of these packages are happy
with nothing but gcc/binutils, so bare-bones crosschains wouldn't take too
much space.

> or we'd have
> Multiarch support and the package could be arch:powerpc and would be
> possible to install on other arches. But this is not possible right
> now, so consider this wontfix.

Also, it would be great if we had packaged kernels (even minimal) for all
arches.  Without them, tools like qemubuilder take a long session of hunting
for docs and files to set up.

A static kernel without useless drivers takes 1-2MB, that's a low price for
the convenience.

[1]. A _brief_ glance, so don't shoot me if I missed something big.
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Automatic mirror selection

[Adam Borowski]

On Fri, Feb 01, 2008 at 02:38:04AM +0100, Leo costela Antunes wrote:
> Hey there,
> 
> As an incredibly late follow-up to this [0] small thread, I created a
> small script to act as backend for pdns and return a mirror for the
> user's country.
> It's a simple DNS based geographic mirror selection idea.

Hell yeah.  Finally.

We got plenty of packages which pull debs from their author's country:
ftp.pl.debian.org, ftp.uk.debian.org.  It would be helluva better to have
them use geoip by default.

I once gave this a though, but never went any farther than checking which
mirrors work.  The status page is still online:
http://angband.pl/deb/mirrors
although it doesn't even update the mirror list.  There are better such
status pages elsewhere, too, except none checks IPv4 and IPv6 separately.

> It works by:
> - using logic based on D-I to select a mirror from a copy of
> Mirrors.masterlist[1], making it behave like a user that selects his own
> country during installation.

Since the packaged version of geoip gives you just the country, my idea
would be to simply give a cname for ftp.XX.debian.org.  On MaxMind's page,
you can also get a "geoip-city-lite" database which appears to be dfsg free
once you purge nondistributable parts about ISPs (city and ISP data is
intermingled in a single file).  That could perhaps provide some better
resolution than just country.

> - filtering by country and arch, with a fallback host if the country
> isn't found or no mirrors provide the needed arch.

Uhm, and how exactly do you get the arch?  At DNS time you don't have
anything but the requester's or his ISP's IP.

> I'd like to put this to use for Debian, but I face two small problems:
> - I currently don't have access to any server in which I could host this.

Would a vserver, one IP and a NS delegation for a test subdomain be enough
for your tests?  No fallover or anything, though.

> - our d.net domains apparently[2] can't contain NS records, which means
> I couldn't have anything more "integrated" without DSA's approval, even
> if I had a machine.

What about this:
  ftptest.debian.net CNAME debian.XXX
  debian.XXX NS your_vserver.XXX
(where XXX is any domain you can control without bothering the DSA for every
change)

> So, which friendly soul could I ask about getting this running on a
> Debian server with a d.net domain, assuming there's some interest in it
> aside from my own? The DSA through a ticket?

This would be a great addition to the official infrastructure.  If this goes
official, it would need some reliable hosting, but for tests, you can use
any machine, even one of mine.

> Please fire away if you have any comments on the idea, but keep in mind
> it's not intended to supplant anything we currently have and it's
> obviously not intended for every scenario.

To the contrary, with the name "ftp.debian.org" being deprecated, I can
think of a perfect case you can supplant once you go official :p


Great work, carry on!

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Automatic mirror selection

[Adam Borowski]

On Fri, Feb 01, 2008 at 09:09:24PM +0100, Leo costela Antunes wrote:
> Adam Borowski wrote:
> > Uhm, and how exactly do you get the arch?  At DNS time you don't have
> > anything but the requester's or his ISP's IP.
> 
> This would have to be placed inside sources.list at some point, then I
> figure the automatic or manual process responsible should stick
> "dpkg-architecture -qDEB_BUILD_ARCH" somewhere in there, so you just
> have to query ".geomirror.d.net", for instance, to get the best
> mirror for your country which contains your arch.
> It could be during D-I, if the D-I people like the idea and no big
> problems arise from a testing period.

Ah, right.  Yet at least in some cases, it could be tricky to have the arch,
so I think you would need a generic mirror anyway.

> > Would a vserver, one IP and a NS delegation for a test subdomain be enough
> > for your tests?  No fallover or anything, though.
> 
> Yes, certainly. Do you have one available?

(Details sent privately).  Too bad, I just learned it can possibly go down
somewhere in the near future...

> > What about this:
> >   ftptest.debian.net CNAME debian.XXX
> >   debian.XXX NS your_vserver.XXX
> > (where XXX is any domain you can control without bothering the DSA for every
> > change)
> 
> I don't think that'll work. Since the Debian nameserver won't find a
> break in the SOA line (introduced with a NS entry), it'll try to find
> YYY.ftptest.d.net directly. A CNAME entry on an upper-level domain won't
> be enough to "redirect" the lower-level domains.

Aargh, it appears you're right.  Does someone have another idea?

If not, we can always do a brief test on a random subdomain, and then toss a
working config to the DSA guys.


Cheers, and so on...
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: How to cope with patches sanely

[Adam Borowski]

On Tue, Feb 05, 2008 at 12:34:08AM -0600, Manoj Srivastava wrote:
> >> On Thu, 2008-01-31 at 10:54:11 +0100, Pierre Habouzit wrote:
> >> >   Of course, that would mean that the few debian/rules (hi Manoj)
> >> > in Debian not being makefiles [...]
> What do you mean, still? I have never used anything but make in
>  my rules files; indeed, I was the one who has (over the objections of a
>  few people) maintained that the policy of requiring Make files make
>  sense.
> 
> I do have Perl maintainer scripts, though.

Hmm... I think that maybe Joey Hess uses such scripts, too.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: [update] Automatic mirror selection - feedback appreciated

[Adam Borowski]

On Wed, Feb 06, 2008 at 08:57:52AM +0900, Michal Čihař wrote:
   ^
> Dne Tue, 05 Feb 2008 22:13:48 +0100
> "Leo \"costela\" Antunes" <[EMAIL PROTECTED]> napsal(a):
> 
> > The -geomirror.d.n addresses are manually added CNAMEs to a
> > PowerDNS server that manages the zone geomirror.angband.pl (helpfully
> > loaned by Adam Borowski). This server is running pdns-backend-pipe,
> > which simply runs a script to determine the best mirror based on the
> > contents of Mirrors.masterlist[0], the IP that originated the request
> > and the requested architecture.
> 
> Hmm, looks like mine server IP address is not detected correctly - first
> resolution ended up with Japan mirror, second one with UK and finally
> the third used correct Czech ;-). Not using any proxy DNS.

geoip is not perfect, but a glance at your mail headers suggest that there
may be some confusion from another source.

Received: from mort.cihar.com (mort.cihar.com [82.208.50.189])
by liszt.debian.org
Tue,  5 Feb 2008 23:58:07 + (UTC)
Received: from p1185-ipbfp704tokaisakaetozai.aichi.ocn.ne.jp ([125.207.87.185] 
helo=raptor.cic)
by mort.cihar.com
Wed, 06 Feb 2008 00:58:05 +0100
Received: from localhost ([127.0.0.1] helo=raptor.cic ident=nijel)
by raptor.cic
Wed, 06 Feb 2008 08:57:57 +0900

IPs, rev names and time zones seem to match.  The machine you sent the mail
from seems to be definitely in Japan, and geoip says so as well.  The mail
server, mort.cihar.com, looks Czechish (per its time zone and your name) --
again, geoip confirms that.

Assuming all machines use a nearby DNS, could you check again, using
"nslookup" or similar to avoid http proxies?  Travelling/sshing to the other
side of the world means you may use a resolver all the way at home. 
Accidentally mistaking a remote ssh session for a local one could be another
explanation.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: dash bug which is affecting release goal

[Adam Borowski]

On Mon, Feb 11, 2008 at 01:33:54AM -0800, Mike Bird wrote:
> On Sun, 10 Feb 2008 21:40:14 Raphael Geissert wrote:
> > I've already changed my /bin/sh and I've found very very few
> > broken/missbehaving scripts.
> > And as a great pro my boot time is more than 50% faster now, not to mention
> > that the overall /bin/sh scripts run faster now.
> 
> On *production* Debian systems, saving 30 seconds in a boot
> which may occur once a year for a kernel security update is
> not worth a single broken script, nor a single failed backup,
> nor a single lost data bit.

And what about Debian desktops, booted up once per day?  What about home
machines?

What about every single shell script?  A glance at /usr/bin:

shell   171
perl182
python   15
ELF 658

That's a sizeable percentage.  Depending on your workload, you can get a
noticeable speedup.  This won't matter for number crunching, but for e.g.
compilation, you'll often see speedups of over 10% -- mostly due to
configure and make.  That's not something to shake a stick at.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Idea of Debian mascot

[Adam Borowski]

On Mon, Feb 25, 2008 at 04:25:06PM +0100, Romain Beauxis wrote:
> Humm
> 
> 
> 
> And why not a marmot ??

Screw marmots.  What about a human?
I would suggest this one:
http://people.debian.org/~amaya/wallpapers/dsc01074.jpg

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Dual-boot setup, incorrect time in Debian's side

[Adam Borowski]

On Tue, Feb 26, 2008 at 02:53:31PM +0100, Ismael Valladolid Torres wrote:
> I am running a dual boot system with Windows XP and Debian just
> upgraded to unstable installed.
> 
> As usual Windows sets the hardware clock to local time. To compensate
> for this I have UTC=no in /etc/default/rcS as specified.

Trying to have hardware clock in local time is bound to lose very fast. 
It's inherently incompatible with having more than one operating system
installed, or even virtual machines and such...

Instead of attempting to work around the related bugs, why won't you instead
use the undocumented way to fix Windows:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal
= (DWORD)1

You'll also need to shutdown and disable "Windows Time Service" if it's
running.  It's there on certain versions of Windows.


I wonder if it would be a good idea to let d-i fix dual-booted systems this
way...

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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