Re: Bug#894551: ITP: fascism -- Exhaustive exploration of Fascist theory and practice

[Milan P. Stanic]

On Sun, 2018-04-01 at 14:55, vangelis wrote:
> 
> 
> Στις 01/04/2018 01:03 μμ, ο Enrico Zini έγραψε:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Enrico Zini 
> >
> > * Package name: fascism
> >   Version : 19190323
> >   Upstream Author : Too many forks to list
> > * URL : https://en.wikipedia.org/wiki/Fascism
> > * License : All rights revoked
> >   Section : non-free
> >   Description : Exhaustive exploration of Fascist theory and practice
> >
> > Fascism is a form of radical authoritarian nationalism, characterized by
> > dictatorial power, forcible suppression of opposition and control of
> > industry and commerce, which came to prominence in early 20th-century
> > Europe. The first fascist movements emerged in Italy during World War
> > I before it spread to other European countries.
> I think even as name can't be under Debian's umbrella. Please do not
> accept it.

this is 'April, 1'

Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)

[Milan P. Stanic]

On Wed, 2016-06-08 at 10:53, Christiaan de Die le Clercq wrote:
> 
> On 06/08/2016 10:39 AM, Arturo Borrero Gonzalez wrote:
> > On 8 June 2016 at 10:08, Lars Wirzenius  wrote:
> >> On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote:
> >>> I am also not very keen on using a system with a "open core / enterprise"
> >>> model. For such a crucial service I would really prefer a real open source
> >>> system. But maybe I am alone with that oppinion.
> >> You're not alone. The open core approach of Gitlab worries me greatly.
> >>
> >> (I'm just a random Debian developer. I no particular say in this.)
> > +1
> +1
> Though I am not involved in this discussion and didn't read a lot of
> previous emails about this. I am going to assume it would be hosted on
> Debian's servers and not with Gitlab's hosted services. We use Gogs at
> the office, a (MIT licensed) Gitlab alternative.
> https://github.com/gogits/gogs
> It might be worth checking out.
 
+1

We also tried Gogs and it works very well and looks promising but we
didn't yet moved our repos from gitolite to gogs so I can't tell for
sure would it be good for Debian. IMHO, it is worth some investigation.

Re: Proposal v2: enable stateless persistant network interface names

[Milan P. Stanic]

On Thu, 2015-06-04 at 19:41, Michael Biebl wrote:
 Am 04.06.2015 um 10:10 schrieb Josselin Mouette:
  How about using only the last 3 bytes of the MAC?
  
  The probability of using, on the same system, *two or more* controllers
  from *different brands* with a collision in the last 3 bytes is
  nonexistent in practice.
  
  The clear benefit would be that 3 bytes / 6 hex digits are easy enough
  to remember in the short term memory when you need to type a command. 6
  hex digits are also regularly used as short git references for that same
  reason. 
 
 That's an interesting idea.I don't think though we should change the
 existing mac NamePolicy. After all, this naming policy could already be
 in use. Maybe introduce a new type, say mac-short ?

Maybe I have unusual configuration but look at this:

arya:~# ip link show
1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: lan: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast master br0 
state UP mode DEFAULT group default qlen 1000
link/ether 14:da:e9:ab:a4:e9 brd ff:ff:ff:ff:ff:ff
4: br0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UP mode 
DEFAULT group default
link/ether 14:da:e9:ab:a4:e9 brd ff:ff:ff:ff:ff:ff
10: kvm0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast master 
br0 state UNKNOWN mode DEFAULT group default qlen 500
link/ether 4a:f9:f8:e1:5a:7a brd ff:ff:ff:ff:ff:ff

MAC address for lan and br0 are the same.
lan is physical Ethernet interface and br0 is bridge interface.

When I plug USB Ethernet adapter I have the next:

arya:~# ip link show
1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: lan: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast master br0 
state UP mode DEFAULT group default qlen 1000
link/ether 14:da:e9:ab:a4:e9 brd ff:ff:ff:ff:ff:ff
4: br0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UP mode 
DEFAULT group default
link/ether 00:60:6e:00:48:1a brd ff:ff:ff:ff:ff:ff
10: kvm0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast master 
br0 state UNKNOWN mode DEFAULT group default qlen 500
link/ether 4a:f9:f8:e1:5a:7a brd ff:ff:ff:ff:ff:ff
16: usb: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast master br0 
state UP mode DEFAULT group default qlen 1000
link/ether 00:60:6e:00:48:1a brd ff:ff:ff:ff:ff:ff

Now, USB Ethernet interface (usb) and bridge (br0) have the same MAC.

I know that I made unusual config but anyway I think that the naming
interface by using MAC (or part of it) is not good idea.

Or I still live in the time when the interfaces have had real (i.e.
human readable and easy to remember) names.

-- 
Best regards


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150605085741.ga25...@arvanta.net

Re: Debian 8 Jessie released

[Milan P. Stanic]

On Sun, 2015-04-26 at 10:03, Joachim Breitner wrote:
  Debian 8 Jessie released  pr...@debian.org
 congrats everyone!

And thank you for nearly twenty years of my experience with the best OS


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150426092355.ga10...@arvanta.net

Re: debian github organization ?

[Milan P. Stanic]

On Fri, 2015-04-17 at 16:10, Bernd Zeimetz wrote:
 On 04/16/2015 05:04 PM, Dimitri John Ledkov wrote:
  I'd rather see gitlab.debian.net http://gitlab.debian.net :)
 or gitblit, which would be easier to integrate into ldap/sso/ssh imho.

What about gitolite? It is in Debian, can be used with gitweb and have
access control.

N.B. I'm biased (maybe) because I use gitolite for my company
repositories.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150417154449.ga12...@arvanta.net

Re: internationalized domain name (IDN) in Debian

[Milan P. Stanic]

On Mon, 2014-08-25 at 15:54, Dariusz Dwornikowski wrote:
  Am Sonntag, den 24.08.2014, 20:32 +0200 schrieb Ralf Jung:
https://wiki.debian.org/IDN 
Summary: webbrowser support it in general but email clients still lack
the support of it.
   
   Why do you list Icedove as non-supporting? I just sent a mail to your
   echo service, and got a reply. Is there anything else I should check?
  No, this was a mistake. Just sending/recieving is my first test. This
  could be much more extended (from address with IDN, setup wizard with
  your email account with IDN domain, IDN certificates,...) but first it
  helps to know the software can send IDN emails.
 I have chromium on testing, IDN works but show the domain name as 
 http://www.xn--kthe-5qa.de/ instead of www.köthe.de . I think this is a known 
 chromium issue. 

In my chromium it show it as http://www.köthe.de
chromium  35.0.1916.153-1~deb7u1 amd64

-- 
Kind regards,  Milan


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140825175316.ga9...@arvanta.net

Re: RFH: Re: Bug#752075: daemontools-run: Add systemd support

[Milan P. Stanic]

On Fri, 2014-07-04 at 14:34, Michael Biebl wrote:
 Am 04.07.2014 13:50, schrieb Gerrit Pape:
  I hereby ask for help to add systemd support to these packages.
 
 We (pkg-systemd team) can help you with that.
 
 Let's follow up on the pkg-systemd mailing list.
 
 In most cases adding a .service file is pretty simple.
 If it's only about starting a svscanboot process, that might be as
 simple as installing a file
 /lib/systemd/system/svscanboot.service containing
 
 [Unit]
 Description=daemon tools
 
 [Service]
 ExecStart=/usr/bin/svscanboot
 Restart=always
 
 [Install]
 WantedBy=multi-user.target
 
 
 
 We probably need to tweak the Type= [1] setting depending on what type
 of service svcanboot is.
 
 [1] man systemd.service

And for runit:

cat /etc/systemd/system/runit.service
[Unit]
Description=runit svscan
After=syslog.target

[Service]
ExecStart=/usr/bin/runsvdir -P /etc/service 'log: 
...'

[Install]
WantedBy=networking.service

N.B. WantedBy=networking.service can be changed to something
appropriate.

-- 
Kind regards,  Milan


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140704132224.ga29...@arvanta.net

Re: RFH: Re: Bug#752075: daemontools-run: Add systemd support

[Milan P. Stanic]

On Fri, 2014-07-04 at 15:55, Michael Biebl wrote:
 Am 04.07.2014 15:22, schrieb Milan P. Stanic:
  And for runit:
 Thanks for sharing.
 
  cat /etc/systemd/system/runit.service
  [Unit]
  Description=runit svscan
  After=syslog.target
 
 The After=syslog.target is no longer necessary and not recommended
 anymore. Lintian will actually complain about that.
 Syslog is started via socket activation nowadays making this explicit
 ordering obsolete.

Nice to know. Tnx.

  
  [Service]
  ExecStart=/usr/bin/runsvdir -P /etc/service 'log: 
  ...'
  
  [Install]
  WantedBy=networking.service
 
 Services should be hooked up in targets. So WantedBy=networking.service
 looks wrong.
 
 In the vast majority of cases you want WantedBy=multi-user.target

My point was not to show perfect systemd unit for runit but to show that
it is really easy to write it. It took me one minute to write and test it
and I don't know much about systemd units.

-- 
Kind regards,  Milan


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140704155049.ga32...@arvanta.net

Re: MATE 1.8 has now fully arrived in Debian

[Milan P. Stanic]

On Tue, 2014-07-01 at 13:01, Ondřej Surý wrote:
 On Tue, Jul 1, 2014, at 08:15, Stefano Rivera wrote:
  Hi Matthias (2014.06.26_08:38:09_+0200)
   Of these, roughly 20% have switched to systemd. And they apparently did 
   not
   and do not have any problem with it, otherwise we'd hear about it. Here 
   and
   other places. Quite loudly.
  
  Not necessarily.
  
  My laptop won't boot with systemd, although other machines I have will.
  I haven't filed a bug, because I haven't had the time to sit down and
  learn how to debug systemd booting, and I wouldn't want to file an bug
  until I know what's going on...
 
 Still - this is just anecdotic evidence that doesn't deviate from normal
 modus operandi of Debian packaging (e.g. most software has bugs).
 I think that what Matthias wanted to say is there is no massive breakage
 among users who has switched to systemd (and not that systemd is
 100% bug free).

I switched to systemd on Asus transformer tf101 (ARM 32-bit) about one
year ago without any problem, and that device is not officially
supported by Debian nor it is tested. And I've built hackish 3.1.10
kernel for it and I have a lot of problem with that device but none is
related to systemd.
So, saying that the systemd is problematic does not 'keeping the water'
IMHO. It has bugs for sure but is there any non simple software without
bugs. I suspect.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2014070719.ga9...@arvanta.net

Re: systemd and Linux are *fundamentally incompatible* - and I can prove it

[Milan P. Stanic]

On Tue, 2014-03-25 at 16:15, Jonathan Dowland wrote:
 I was very proud of my fellow colleagues for not feeding the troll a
 full 24 hours later. Thanks for breaking the record :(

I had a hope that the no one will answer OP. :(


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140325173351.ga6...@arvanta.net

Re: systemd effectively mandatory now due to GNOME

[Milan P. Stanic]

On Sat, 2013-12-21 at 19:31, Russ Allbery wrote:
 Vincent Lefevre vinc...@vinc17.net writes:
  On 2013-12-21 18:04:19 -0800, Russ Allbery wrote:
  That said, the display managers in Debian other than kdm and gdm are not
  ready for systemd at the moment.  I had to switch to gdm3 to use systemd
  (by which I mean booting with it) because neither slim nor lightdm worked
  properly.
  I actually had to switch from gdm3 to lightdm because I could no longer
  reboot or power off the machine with the new version... apparently due
  to an issue with systemd:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729576
  Another user at least has the same issue.
 Odd, I don't have any trouble at all with gdm3.  lightdm wouldn't even
 start under systemd, IIRC.  But this was about six months ago and may well
 already be fixed.  (I was guessing some missing integration with logind or
 something; since it wasn't what I was fiddling with at the time, I didn't
 investigate it in detail.)

Really odd. With my testing/unstable installation on amd64 and armhf
(Asus TF101 tablet) systemd and lightdm combo works without any problem
for nearly a year.

-- 
Kind regards,  Milan
--
Arvanta,http://www.arvanta.net
Please do not send me e-mail containing HTML code or documents in
proprietary format (word, excel, pps and so on)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131222134106.ga23...@arvanta.net

Re: [OT] config file formats

[Milan P. Stanic]

On Mon, 2012-12-03 at 15:31, Игорь Пашев wrote:
 Guys, it looks like you are looking for The Silver Bullet.

And, it is called YAML ;-)

-- 
Kind regards,  Milan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121203114303.ga9...@arvanta.net

Re: Canonical pushes upstart into user session - systemd developer complains

[Milan P. Stanic]

On Mon, 2012-11-26 at 07:27, Norbert Preining wrote:
 On So, 25 Nov 2012, Henrique de Moraes Holschuh wrote:
  [crap]
  foo = bar
 ...
  issue, even git uses that crap instead of something better like xml,
 
 
 ??? Sorry, are you realistically proposing a convolutive pile of shit
 like XML for simple config files?
 
 I will send *each*and*every* bug report due to misconfiguration due to
 human incapability of editing XML to you.
 
 No please.
 
 In upstream TeX Live which is distributing over 2G of material for 15
 different arch/os combinations, we threw out XML in 2005, because
 it is a pain in the ass, and nothing nothing else.
 
 Ever heard of 
   grep, sed, awk, 
 all these nice things that make your life happy. Trash them when you
 are doing XML.
 
 
 No please - I don't mind the key = value in group config format, that
 is readable, usefull, easy to edit.
 
 Everything but XML. *EVERYTHING*.

+1

I found YAML as the best compromise for human readability and easy for
automated tool processing.

-- 
Kind regards


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121127112623.ga2...@arvanta.net

Re: RFC on MBF (non-freeness of The Software shall be used for Good, not Evil)

[Milan P. Stanic]

On Thu, 2012-11-08 at 19:13, Holger Levsen wrote:
 On Donnerstag, 8. November 2012, Jakub Wilk wrote:
  As far as I can see Mr Crockford _enjoys_ being asked to change his
  license. So no, please don't feed the troll.
 As much as I think this licence is stupid (from my free software point of 
 view), I don't think he should be called a troll, just because he likes 
 his users to do good - even if only by his own definition.

I agree. Someone who uses software which have that licence, uses it
because it is useful i.e. 'it is good' for him/her.

-- 
Kind regards,  Milan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121108194648.ga12...@arvanta.net

Re: Change default PATH for Jessie / wheezy+1

[Milan P. Stanic]

On Thu, 2012-08-09 at 12:14, Carlos Alberto Lopez Perez wrote:
 On 08/08/12 12:11, Thomas Goirand wrote:
  On 08/08/2012 10:32 AM, Carlos Alberto Lopez Perez wrote:
[...]
 on any *nix. Furthermore the output formatting of ifconfig is more user
 friendly than the one of ip.

It depends of that who is the 'friend'.

-- 
Kind regards,  Milan


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120809110711.gc21...@arvanta.net

Re: Change default PATH for Jessie / wheezy+1

[Milan P. Stanic]

On Wed, 2012-08-08 at 19:08, Harald Jenny wrote:
 On Wed, Aug 08, 2012 at 12:22:50PM +0200, Marco d'Itri wrote:
  (Does anybody want to try removing net-tools and see what breaks?)
 On my debian systems net-tools are removed, had to recompile openvpn
 with ip support and run openswan from experimental without any problems
 since 4 months.

I removed it without recompiling anything from my notebook.

-- 
Kind regards,  Milan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120808200824.ga16...@arvanta.net

Re: Change default PATH for Jessie / wheezy+1

[Milan P. Stanic]

On Wed, 2012-08-08 at 22:18, Harald Jenny wrote:
 On Wed, Aug 08, 2012 at 10:08:24PM +0200, Milan P. Stanic wrote:
  On Wed, 2012-08-08 at 19:08, Harald Jenny wrote:
   On Wed, Aug 08, 2012 at 12:22:50PM +0200, Marco d'Itri wrote:
(Does anybody want to try removing net-tools and see what breaks?)
   On my debian systems net-tools are removed, had to recompile openvpn
   with ip support and run openswan from experimental without any problems
   since 4 months.
  I removed it without recompiling anything from my notebook.
 openvpn still uses the route command from net-tools and in openswan's

I forgot to tell that I don't use openvpn.

 KLIPS helper there was an occurence of the netstat command.

For IPsec I use racoon and ipsec-tools. For wireless I use wicd.

So everything I need for networks on my notebook works without
net-tools.

-- 
Kind regards,  Milan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120808210846.ga18...@arvanta.net

Re: Bug#683934: ITP: publicsuffix -- An accurate, machine-parseable list of domain name suffixes

[Milan P. Stanic]

On Sun, 2012-08-05 at 11:18, Daniel Kahn Gillmor wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Daniel Kahn Gillmor d...@fifthhorseman.net
 
 * Package name: publicsuffix

To me, name is vague, though I see that the upstream site name is the
same.

Something like 'public-dns-suffix-db' (or clearer name) would be better,
IMHO.

   Version : 20120704
   Upstream Author : Public Suffix Maintainers cont...@publicsuffix.org
 * URL : http://publicsuffix.org/
 * License : MPL-2
   Programming Lang: data
   Description : An accurate, machine-readable list of domain name suffixes
 
 This package provides a machine-readable list of domain name suffixes
 that accept public registration.  Each suffix represents the part of a
 domain name which is not under the control of the individual
 registrant, which makes the list useful for grouping cookies, deciding
 same-origin policies, collating spam, and other activities.
 
 
 
 
 Having this list maintained directly in debian will make it easier for
 debian packages to reliably refer to public suffixes; it is similar in
 nature to the tzdata and geoip-database.



-- 
Kind regards,  Milan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120805155038.ga20...@arvanta.net

Re: Making -devel discussions more viable

[Milan P. Stanic]

On Tue, 2012-05-08 at 15:19, Miles Bader wrote:
 Alexander Wirt formo...@debian.org writes:
  I am just speaking for myself as listmaster. But I don't think any
  DD has more right to talk on a mailinglist than anybody else. I
  won't support such a proposal nor want I participate in it. If you
  have a problem with someone on a mailinglist, report it and
  listmasters decide if we should step in.
 
 ... and as a non-DD who's been using Debian for 15 years (and reading
 this list for many of them), and understands at least some of the
 technical issues, I find the suggestion that I be automatically
 considered a negative influence and excluded kind of annoying.

I'm in the same bandwagon.
Sometimes I even package some packages which are not in Debian for some
users. Few years ago I backported selinux to Sarge to Woody (IIRC) and
some people from over the world downloaded it and used or played with
it. These days I maintain Kannel development release (packages are on
the Kannel site) for Debian Testing and people use it.

Do I help Debian? I really don't know but I'm sure that I did help some
Debian users.

This (and some other) Debian list are helpful for me and I sometimes
post some comment, question or even opinion about some subjects which
are interesting me.

If I have to pass some kind of meritocracy to post to this list I'll have
feeling of the 'second class' participant and probably will not post
anything.
That wouldn't be big loss for Debian anyway ;-)

 The issues discussed here often do affect me, because I use Debian.  I
 don't actively participate most of the time but I do read, and every
 once in a while, feel I have something to add.
 
 The problem is not non-DDs, it's jerks and/or the clueless.  Maybe on

Well said.

 this list there's _some_ correlation between non-DDness and those
 things -- but it's far from perfect... (and not, IMHO, enough to
 justify censorship).
 
 -miles

-- 
Kind regards,  Milan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120508120730.ga16...@arvanta.net

Re: RFC: OpenRC as Init System for Debian

[Milan P. Stanic]

On Thu, 2012-04-26 at 16:05, Matthias Klumpp wrote:
 Hi!
 AFAIK systemd supports startup notifications, even in colour - at
 least it did this last time I tried (a few weeks ago)

Yes, it does but on wide screen it is not so easy to follow it because
status (OK, Failed ...) are on the right end.

It would be better if the status are on the beginning of the line.

 Maybe your systemd version is too old?
 (Quoting Lennart: We now show the progress of fsck at boot on the
 console, again. We also show the much loved colorful [ OK ] status
 messages at boot again, as known from most SysV implementations.)
 Regards,
 Matthias
 
 2012/4/26 Chris Knadle chris.kna...@coredump.us:
  On Wednesday, April 25, 2012 08:52:59, Patrick Lauer wrote:
  Greetings,
 
  in the last months there have been many discussions about init systems,
  especially systemd. The current state seems to make no one really happy
  - the current debian init system is a bit minimal and doesn't even do
  stateful services in an elegant way (e.g. /etc/init.d/apache2 start;
  /etc/init.d/apache2 start).
 
  After testing systemd some, I've now grown a new appreciation for the 
  default
  Debian init system -- because it gives visual notification of what's been
  started, where systemd does not.  I'd like to know where OpenRC is in this
  regard -- if it maintains visual notification at startup, that would be a
  benefit it has that isn't currently mentioned at [1] AFAICT.
 
  I think visual startup notification is significant.  Often enough I find 
  error
  notifications during startup which I can then track down and fix, and if 
  this
  information is hidden then startup errors might not get noticed.  :-/
 
  [I do like that systemd can be loaded and you can choose when to turn it
  on/off via passing 'init=/bin/systemd' to the booting kernel.  That and the
  fast bootup time are nice.  Bootup time is not a significant benefit in my
  case, as I'm using LUKS encryption with several long passwords to enter at
  boot time.  :-P]
 
  ...
  What we offer you is a modern, slim, userfriendly init system with
  minimal dependencies. All you need is a C99 compiler and a posix sh!
  The list of features is long and tedious
  http://wiki.gentoo.org/wiki/OpenRC )
  (Note to the reader: this is the same page as [1].)
 
  Some feedback on the page above: in the first table comparing system startup
  types there are markers for notes, e.g. no[1] concerning Read-Ahead, but 
  the
  expected note details after the table seem to be missing.
 
  Should you decide to switch (or just evaluate if switching is possible /
  makes sense) you'll get full support from us in migrating init scripts
  and figuring out all the nontrivial changes. Just visit us on IRC (
  #openrc on irc.freenode.net), send us a mail ( ope...@gentoo.org ) or
  meet us for a beer or two.
 
  For others looking to evaulate:  at the tail end of [2] I found a link to 
  the
  OpenRC Git repository [3], along with more documentation on OpenRC and how 
  to
  migrate at [4].
 
 
 
  [1] http://wiki.gentoo.org/wiki/OpenRC
 
  [2] https://en.wikipedia.org/wiki/OpenRC
 
  [3] http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git
 
  [4] http://www.gentoo.org/proj/en/base/openrc/
 
   -- Chris
 
  --
  Chris Knadle
  chris.kna...@coredump.us
  GPG Key: 4096R/0x1E759A726A9FDD74
 
 
 --
 To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: 
 http://lists.debian.org/caknhny88jdfepbj0xckw4jx6fyb85i7sf95mhfjlnun2bhz...@mail.gmail.com
 

-- 
Kind regards,  Milan
--
Arvanta,http://www.arvanta.net
Please do not send me e-mail containing HTML code or documents in
proprietary format (word, excel, pps and so on)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120426173751.ga3...@arvanta.net

Re: On init in Debian

[Milan P. Stanic]

On Thu, 2012-03-29 at 13:07, Russ Allbery wrote:
 Mike Hommey m...@glandium.org writes:
  On Thu, Mar 29, 2012 at 10:09:57AM +0200, Vincent Lefevre wrote:
  Well, wicd has its own bugs, such as preventing a laptop from
  suspending.
 Works for me; I've never had any trouble at all suspending my laptop and
 I've been using wicd for years.  (The laptop tracks unstable.)

Also for me, my wife, daughter, nephew and son. :-]

[...]

-- 
Kind regards,  Milan
--
Arvanta, IT Securityhttp://www.arvanta.net
Please do not send me e-mail containing HTML code or documents in
proprietary format (word, excel, pps and so on)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120329205644.ga23...@arvanta.net

Re: Unofficial repositories on 'debian' domains

[Milan P. Stanic]

On Mon, 2012-03-05 at 17:56, Thomas Goirand wrote:
 On 03/05/2012 03:40 PM, Stefano Zacchiroli wrote:
  But before getting there, the question is whether the existence of the
  website (and its popularity) poses problem to Debian reputation and/or
  to the activity of official Debian multimedia packaging. I think this is
  a question for the Debian Multimedia Maintainers (as in
  pkg-multimedia-maintain...@lists.alioth.debian.org) to answer. If they
  see a problem with debian-multimedia.org, we should get in touch with
  the website maintainers and solve the issue.
 I do think this website hurts Debian, and its user community.
 Let me explain, it's based on my past *user* experience.

I don't agree with you here.
For me d-m.o was (and still is) valuable resource.
Some codecs missing in Debian packages because of the policy (I don't
blame Debian for that) and in that case d-m.o is best option for me
because I don't want/have time to package it from the source.

[...]

-- 
Kind regards,  Milan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120305105215.gb27...@arvanta.net

Re: Unofficial repositories on 'debian' domains

[Milan P. Stanic]

On Mon, 2012-03-05 at 16:45, Reinhard Tartler wrote:
 On Mon, Mar 5, 2012 at 11:52 AM, Milan P. Stanic m...@arvanta.net wrote:
  For me d-m.o was (and still is) valuable resource.
  Some codecs missing in Debian packages because of the policy (I don't
  blame Debian for that) and in that case d-m.o is best option for me
  because I don't want/have time to package it from the source.
 Out of curiousity, what codecs do you miss in the official debian packages?

It was a long ago when I installed packages from d-m.o so I can't
remember right now. I just put (in apt.sources):
deb http://www.debian-multimedia.org testing main contrib
deb http://www.debian-multimedia.org unstable main contrib

and forgot about it.

When I encounter conflict in apt/itude I know how to resolve it or just
don't care if it isn't important.

So, I appreciate Christian Marrilat effort with d-m.o when Debian was not
unable to package all codecs and apps due to patent and licencing
'issues'. Again, I don't blame Debian for that.

I just want to tell that the d-m.o was and I think it would be useful
just because Debian cannot ship all software/codecs which have
patent/licence problem.

-- 
Kind regards,  Milan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120305170115.ga29...@arvanta.net

Re: Removing web server dependencies from web apps

[Milan P. Stanic]

On Fri, 2012-01-06 at 23:49, Daniel Baumann wrote:
 On 01/06/2012 02:46 PM, Milan P. Stanic wrote:
  live with the idea that Debian must be usable for everyone in the
  world (which is impossible, IMHO) but that's the life.
 
 at least debian is equally bad for everyone/everything, having almost no
 worst cases by itself, already is quite a good thing, isn't it? ;)

No. Debian is the best distribution for me in last fifteen years.
But, I think the trend toward unexperienced users is not where Debian
should go because there are already some distributions positioned well.

Ubuntu, which was intended for desktop already have server variant and I
can't see a reason why Debian couldn't have something like that, i.e.
variant for unexperienced users and another one for servers.

There is Debian-Edu (and some other specific variants) already.

I know that that requires more volunteers and time but I can dream about
it ;-)

-- 
Kind regards,  Milan
--
Arvanta, IT Securityhttp://www.arvanta.net
Please do not send me e-mail containing HTML code or documents in
proprietary format (word, excel, pps and so on)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120110113332.gb10...@arvanta.net

Re: Removing web server dependencies from web apps

[Milan P. Stanic]

On Fri, 2012-01-06 at 20:45, Thomas Goirand wrote:
[...]
 This is why I think the solution of moving apache2 | http as
 a Recommends: is a good compromise.
 
 Never mind, it seems there's more people against my idea
 than some thinking it was a smart one, so I'll hack with equivs
 (which I didn't know) and see how it goes.

You can't be sure ;-)
Maybe we just tired to repeat our arguments against 'Debian dependency
hell', as I call it.

I just do what you do: rebuild application without unneeded dependencies
and live with the idea that Debian must be usable for everyone in the
world (which is impossible, IMHO) but that's the life.

-- 
Kind regards,  Milan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120106134615.gb12...@arvanta.net

Re: from / to /usr/: a summary

[Milan P. Stanic]

On Sun, 2012-01-01 at 14:42, Nick Leverton wrote:
 On Sun, Jan 01, 2012 at 05:14:41PM +0800, Thomas Goirand wrote:
  On 01/01/2012 03:11 PM, Russ Allbery wrote:
   Thomas Goirand tho...@goirand.fr writes:
   The other sane way is to mark files not in /etc as conffiles.  It
   semantically sux a bit, but if we have no choice because of upstream
   decisions (which we don't have enough time to fix), then that might be a
   way...
   That doesn't help unless you expect sysadmins to change them (unchanged
   conffiles are quietly updated just like any other package file), at which
   point it becomes an FHS violation.
  I'd like to know: is it a normal thing to edit these files in
  /usr/lib/udev/rules.d
  (or, any other file that udev will use and which will be stored in /usr)?
  Or should we expect that *never* anyone will touch them (eg: there's never
  a real valid reason to edit them)?
 The latter.  If you wish to override them, place the new file in
 /etc/udev/rules.d and the one in /usr/lib/udev won't be used.
   ^
You mean:
/lib/udev/rules.d

-- 
Kind regards,  Milan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120101172513.gb29...@arvanta.net

Re: Bug#653894: ITP: mediainfo -- MediaInfo supplies information about a video or audio file

[Milan P. Stanic]

On Sun, 2012-01-01 at 16:21, Chow Loong Jin wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Chow Loong Jin hyper...@ubuntu.com
 
 
 * Package name: mediainfo
   Version : 0.7.52
   Upstream Author : i...@mediaarea.net
 * URL : http://mediainfo.sf.net
 * License : LGPL
   Programming Lang: C++
   Description : MediaInfo supplies information about a video or audio file
 
 MediaInfo supplies technical and tag information about a video or audio file
 .
 What information can I get from MediaInfo?
 General: title, author, director, album, track number, date, duration...
 Video: codec, aspect, fps, bitrate...
 Audio: codec, sample rate, channels, language, bitrate...
 Text: language of subtitle
 Chapters: number of chapters, list of chapters
 .
 What format (container) does MediaInfo support?
 Video: MKV, OGM, AVI, DivX, WMV, QuickTime, Real, MPEG-1, MPEG-2,
 MPEG-4, DVD (VOB)...
 (Codecs: DivX, XviD, MSMPEG4, ASP, H.264, AVC...)
 Audio: OGG, MP3, WAV, RA, AC3, DTS, AAC, M4A, AU, AIFF...
 Subtitles: SRT, SSA, ASS, SAMI...
 .
 This package includes the command line interface

Mediainfo is already in Debian multimedia.

-- 
Kind regards,  Milan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120101172017.ga29...@arvanta.net

Re: Two groups of users, one distro in the middle

[Milan P. Stanic]

On Tue, 2011-11-15 at 13:34, Ian Jackson wrote:
 Charles Plessy writes (Re: Two groups of users, one distro in the middle):
  I agree.  One possiblity when packages A and B conflict for a program name
  would be to rename, but in addition to provide a wrapper that executes the
  program from A when only A is installed, from B when only B is installed, 
  and
  that gives an error reporting alternative path names when both A and B are
  installed.  The wrappers for all names could be provided by a third package.
 
 I don't think this ia a good idea.  The result would be that
 installing an additional package could break the operation of
 an unrelated package.
 
 If users desperately want to do this themselves there is no reason why
 they shouldn't symlink /usr/bin/node - nodejs themselves - apart
 from, of course, the reasons why they shouldn't.
 
 But we should absolutely not support it.  I have no sympathy at all
 for nodejs upstream on this matter.

As a user/admin I fully agree with you. Debian policy should be changed
to state something like First come, first served. Principle of least
surprise.

ax25 packages are in Debian for more than ten years, IIRC.

What to do if someone create {some}script language and call it 'cat' and
refuse to rename it because s/he like cats. ;-)

-- 
Kind regards,  Milan
--
Arvanta, IT Securityhttp://www.arvanta.net
Please do not send me e-mail containing HTML code or documents in
proprietary format (word, excel, pps and so on)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201518.ga24...@arvanta.net

Re: Depends: logrotate (forever and ever and ever)

[Milan P. Stanic]

On Sun, 2011-09-18 at 22:45, Russ Allbery wrote:
 Ivan Shmakov i...@gray.siamics.net writes:
  It's therefore my long-standing opinion that the dependency on
  logrotate should be downgraded to Recommends:, unless, of
  course, postinst or prerm do actually use anything provided by
  the logrotate package (which seems to me unlikely.)
 I completely agree and report this bug every time I run into it.  We use a
 different log rotation strategy and program at Stanford that has
 capabilities that logrotate doesn't have, and we want to purge logrotate
 from all our systems so that it doesn't so something unexpected.

I do the same on my machines with metalog (there is no official Debian
package) and logrotate is installed only to waste time and bandwidth and
to annoy me. And logrotate depends on cron which I don't need on some
machines.

 Recommends is more appropriate than Depends for logrotate, since software
 in Debian rarely cares exactly which program is rotating its logs, only
 that some program does.
 
 It's very hard to get a Debian system without logrotate installed without
 explicit and intentional action, so changing Depends to Recommends is
 quite unlikely to introduce a bug where no log rotation program is
 installed at all.

+1

-- 
Kind regards,  Milan
--
Arvanta, IT Securityhttp://www.arvanta.net
Please do not send me e-mail containing HTML code.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110919104009.ga1...@arvanta.net

Re: Bug#630977: ITP: raccoon -- preparation for ligand screening projects

[Milan P. Stanic]

On Sun, 2011-06-19 at 20:28, Paul Wise wrote:
 On Sun, Jun 19, 2011 at 8:02 PM, Steffen Moeller wrote:
 
  * Package name    : raccoon
 
 That is one letter away from racoon, the IPsec IKE keying daemon. I
 wonder if that would be too confusing of a name?

It is, IMHO.

When I saw ITP and version 1.0.0 I was surprised because I follow racoon
mailing list and I know that the latest release of racoon is 0.8.0

Careful look clarified all, but it could be confusing.

-- 
Kind regards,  Milan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110619131743.ga20...@arvanta.net

Re: Debian rolling: tentative summary

[Milan P. Stanic]

On Tue, 2011-05-03 at 09:47, Martin Wuertele wrote:
 * Cristian Henzel cri...@b3r3.info [2011-05-03 08:12]:
  I'm a bit new to Debian but just wanted to add my $0.02 to this discussion,
  since it's something that I personally find very interesting.
  Firstly, I think the question should be, which users would be targeted by a
  rolling release? I don't think there are many people out who have the need 
  for
  *both* really stable and supported *and* up-to-date packages and this might 
  not
  even be possible without a huge team to work on it. IMHO the rolling release
  should be targeted at people who want the latest stuff but don't care that 
  much
  about stability.
  I had a quick talk on this with a couple of people on IRC where I suggested
  starting with a 'clone' of the testing repository, and changing a couple of 
  the
  rules, like not having a freeze for example and maybe increasing the time it
  takes packages to 'promote' from unstable into rolling. This might not make 
  the
  most stable configuration but I think it would be a good compromise between
  having the latest packages and not having any really serious bugs. I for one
  would only dislike bugs that cause a data loss or a non-operable system, and
  from what I know these are pretty rare even in testing.
  If it then would be also possible to decrease the release time of stable to
  something around a year, I think this might make everyone happy, both the
  'stability freaks' and the average Joe.
 
 Er, no. Those of us using Debian in corporate environments desire high
 stability, long-term support and defined, not to short, periods between
 releases. The 2 years with the security support for currently about 4
 years from the release date on is good if even a bit on the short side.

I agree. Debian shouldn't become yet another Ubuntu.

I converted all my servers to Debian stable and workstations to
testing/unstable thirteen years ago and I don't regret.

I don't think that the Debian can beat Ubuntu in popularity on
desktop/laptop field (not yet) and IMHO it should not even try that.

IMHO Debian is for the people who understand computers and are willing
to invest some time to learn and user friendly distributions are for
other more or less laymen people.

-- 
Kind regards,  Milan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110503083301.ga13...@arvanta.net

Re: Bug#575209 closed by Holger Levsen hol...@layer-acht.org (Re: Bug#575209: general: Error resolving hostname [resent])

[Milan P. Stanic]

On Thu, 2010-03-25 at 13:15, Ben Hutchings wrote:
 On Thu, 2010-03-25 at 11:21 +0100, Fabian Greffrath wrote:
  - The advice in the cited RFC is already ignored. Domain names that 
  start with a digit, e.g. 12345.foo.bar, can be resolved, whereas the 
  RFC tells us They [labels] must start with a letter, end with a 
  letter or digit [...].
 [...]
 It is not ignored; the standard was updated by RFC 1123 (STD 3).

Yes. I forgot to mention that in original post. Sorry.

-- 
Kind regards,  Milan


signature.asc
Description: Digital signature

Re: Bug#575209: general: Error resolving hostname [resent]

[Milan P. Stanic]

On Wed, 2010-03-24 at 10:50, Fabian Greffrath wrote:
 [Resent, because reportbug somehow ate my line breaks, sorry!]
 
 Dear all,
 
 I've found something that is most propbably a bug in Linux's resolv
 system, when trying to open a specific page with Epiphany (but any
 other browser will fail as well, please try out yourself).
 
 To reproduce, please visit http://www.deviantart.com/ and search
 for SNES. On the first results page a picture called SNES World
 HD should appear. Try to click this picture. Your browser will fail
 to resolv the hostname and even ping won't be able to:
 
   $ ping KeR-.deviantart.com
   ping: unknown host KeR-.deviantart.com
 
 However, nslookup returns the right IP address and this page even
 loads under both Windows XP and Mac OS X:
 
   $ nslookup KeR-.deviantart.com
   Server: 134.147.57.130
   Address: 134.147.57.130#53
 
   Non-authoritative answer:
   KeR-.deviantart.com   canonical name = www.deviantart.com.
   Name: www.deviantart.com
   Address: 8.10.77.140

Labels must end and begin only with a letter or digit.

RFC 1035 says:

The labels must follow the rules for ARPANET host names.  They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen.  There are also some
restrictions on the length.  Labels must be 63 characters or less.

 I believe this bug is caused by the dash character in the domain
 name, but I don't have any further knowledge of Linux's resolv
 system. As you are the experts, please point me to where I can help
 to trace this bug.
 

-- 
Kind regards,  Milan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100324102204.ga8...@arvanta.net

Re: Is Paul Dwerryhouse MIA?

[Milan P. Stanic]

On Tue, 2010-01-19 at 08:05, Charles Plessy wrote:
 Le Mon, Jan 18, 2010 at 12:05:52AM +0100, Milan P. Stanic a écrit :
  On Sun, 2010-01-17 at 22:57, Jonas Smedegaard wrote:
   I am worried if perhaps Paul Dwerryhouse p...@dwerryhouse.com.au
   is Missing In Action.
   
   He is maintainer of kannel which I have a special interest in.  For
   some time now I have had to use an unofficial packaging of a newer
   release due to the package in Debian being quite outdated (see
   bug#563661).  I recently packaged the kannel-sqlbox addon and plan
   to package mbuni - but find it silly to work on a fork of the
   (un?)maintained kannel.
  Few months ago I tried to contact him for same reason (outdated kannel
  package) but didn't received any answer.
  In the meantime I stopped to use kannel extensively so I didn't tried
  again but just created bare-bone packages from upstream for use on one
  server.
 Dear Jonas,
 
 If others like Milan did not manage to contact the package's maintainer, maybe

I tried just once because I don't like to bother people over Net.

 you can go ahead an take over the package now ? By the way, Ubuntu has already
 upgraded to the latest upstream version since almost a year now, and there are
 no bugs related to this upgrade, so despite the freeze is soon it may be safe
 to upgrade the Debian package as well.

I actually used patches from Ubuntu to build kannel for myself. I just
skipped database support because I don't need it.

And it is quite stable, it works six months for now without restart and
without any problem.

-- 
Kind regards,  Milan
--
Arvanta, IT Securityhttp://www.arvanta.net
Please do not send me e-mail containing HTML code.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Is Paul Dwerryhouse MIA?

[Milan P. Stanic]

On Sun, 2010-01-17 at 22:57, Jonas Smedegaard wrote:
 I am worried if perhaps Paul Dwerryhouse p...@dwerryhouse.com.au
 is Missing In Action.
 
 He is maintainer of kannel which I have a special interest in.  For
 some time now I have had to use an unofficial packaging of a newer
 release due to the package in Debian being quite outdated (see
 bug#563661).  I recently packaged the kannel-sqlbox addon and plan
 to package mbuni - but find it silly to work on a fork of the
 (un?)maintained kannel.

Few months ago I tried to contact him for same reason (outdated kannel
package) but didn't received any answer.
In the meantime I stopped to use kannel extensively so I didn't tried
again but just created bare-bone packages from upstream for use on one
server.

It would be nice if you take maintenance over kannel to have it in
Debian repository. I'm ready to help as much as I can and have time.

 I now checked 
 http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=paul%40dwerryhouse.com.au
 - the packages are not in particularly bad state but only one of the
 bugreports listed there has ever had a single response - back in
 2007 - from Paul Dwerryhouse.
 
 What is the procedure for MIAs?  I seem to recall that db.debian.org
 have a last-seen hint but that is only for account holders in Debian
 which Paul Dwerryhouse seem not to be.
 
 It seems that Paul maintains only the packages kannel and jwhois.
 
 If it comes to that, I can offer to take over maintainance of kannel
 but would be happy to here from others interested in co-maintaining
 it (I would want to use Git and CDBS - so you are warned ahead if
 you have special preferences for or against those tools).  I have no
 interest in jwhois.
 
 
 Please cc me on responses to this mail: I am not subscribed to -devel.

-- 
Kind regards,  Milan


signature.asc
Description: Digital signature

Re: where is /etc/hosts supposed to come from?

[Milan P. Stanic]

On Mon, 2009-12-28 at 20:56, Steve Langasek wrote:
 On Tue, Dec 29, 2009 at 01:47:40AM +0100, Vincent Lefevre wrote:
   As for mail, we already appear to have an /etc/mailname file for MTAs and 
   MUAs to use for finding out the 'canonical' name of the host for message-
   IDs and the like.
  /etc/mailname doesn't seem to be specified by POSIX
 Nope, it's specified in Debian policy (11.6).
  , so that I doubt that all mail software uses it in practice (Mutt doesn't
  seem to use it...
 That would be a bug, then.

Mutt in testing/unstable use /etc/mailname.

-- 
Kind regards,  Milan
--
Arvanta, IT Securityhttp://www.arvanta.net
Please do not send me e-mail containing HTML code.


signature.asc
Description: Digital signature

Re: Bug#559134: ITP: shc -- a generic shell script compiler

[Milan P. Stanic]

On Wed, 2009-12-02 at 15:58, Karl Goetz wrote:
 On Wed, 02 Dec 2009 05:58:17 +0100
 Dario Minnucci \(midget\) deb...@midworld.net wrote:
  * Package name: shc
 
   shc's main purpose is to protect your shell scripts from
   modification or inspection. You can use it if you wish to
   distribute your scripts but don't want them to be easily
   readable by other people.
 Does this mean its a tool to make software no longer DFSG compatible?
 seems a bit odd to include in Debian.

Then gcc (and other compilers) are at the odd with DFSG because they
produce unreadable code for most people. (some can read machine code)

-- 
Kind regards,  Milan


signature.asc
Description: Digital signature

Re: Bug#559134: ITP: shc -- a generic shell script compiler

[Milan P. Stanic]

On Wed, 2009-12-02 at 08:48, Manoj Srivastava wrote:
 On Wed, Dec 02 2009, Milan P. Stanic wrote:
 
  On Wed, 2009-12-02 at 15:58, Karl Goetz wrote:
  On Wed, 02 Dec 2009 05:58:17 +0100
  Dario Minnucci \(midget\) deb...@midworld.net wrote:
   * Package name: shc
  
shc's main purpose is to protect your shell scripts from
modification or inspection. You can use it if you wish to
distribute your scripts but don't want them to be easily
readable by other people.
  Does this mean its a tool to make software no longer DFSG compatible?
  seems a bit odd to include in Debian.
 
  Then gcc (and other compilers) are at the odd with DFSG because they
  produce unreadable code for most people. (some can read machine code)
 
 What this argument is missing is the point that the primary (and
  stated) goal of gcc and the ilk is not obfuscation.
 
  And the goal of obfuscation is not preventing tampering (since
  one may still modify obfuscated code, just not as easily (access
  control mechanisms do the non tampering bit)).
 
 The goal of obfuscation seems to be to prevent people from
  gaining knowledge; and obfuscation is pointless when the sources are
  available, so it is facile to argue that the issues are orthogonal. So
  there is some merit to the argument that this package is against the
  spirit free software.

I absolutely agree with you here, but if some user of Debian want to use
such tools (libfilter-perl is in repos for long time, I think) and some
maintainer is ready to maintain it, I can't see any valid argument
against it.
Debian does not segregate usage of its packages by any means, IIRC.

 Having said that, I am not advocating blocking this package (nor
  am I advocating accepting it), I am just commenting on the arguments
  being presented here.

I also don't want to advocate for this package because it is
uninteresting for me.

-- 
Kind regards,  Milan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Want to work with a Linux Group

[Milan P. Stanic]

[ Sorry for _little_ OT comment ]

On Tue, 2009-04-14 at 10:32, Roger Preston wrote:

 I am interested what you guys are doing with this new operating system.
^^^
Yes, besides the fact that it began in 1993 it is always new. :)

 I am keen to work for/with a Linux development group, though am not sure where
 to start.

 I would describe myself as a competent C++ programmer, though perhaps not
 quite at your levels yet.

 I would really appreciate it though if you could point me in the direction of
 some Linux groups seeking development assistance.

Good starting points are:
http://www.debian.org/intro/help
http://www.debian.org/devel/

-- 
Kind regards,  Milan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bug#522142: ITP: Qoreutils -- Coreutils reimplemented using Qt libraries

[Milan P. Stanic]

On Wed, 2009-04-01 at 09:09, Mike Bird wrote:
 On Wed April 1 2009 00:03:10 Sune Vuorela wrote:
  Qoreutils is a reimplementation of the classic tools from coreutils,
  such as ls, mkdir and cp
 Thanks but this won't be necessary.  We just uploaded a GCC patch
 that converts coreutils to use Qt.  No source changes are needed.

Sorry for my ignorance, but what does that mean? We will have to install
libqt always?
 
-- 
Kind regards,  Milan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Override changes standard - optional

[Milan P. Stanic]

On Wed, 2008-12-31 at 15:18, Stefano Zacchiroli wrote:
 On Tue, Dec 30, 2008 at 01:34:35PM +0100, Joerg Jaspert wrote:
  In case you see a good reason why the above is wrong, feel free to reply
  stating it. We currently can't see any of the packages living up to the
  policy definition of standard.
 I would welcome the following packages to remain Standard:
  strace
 Rationale: every day sysadm local debugging tool, at least IME.

I agree.
 
  mtr-tiny
 Rationale: every day sysadm network debugging tool *and* also user
 debugging tool to understand what is not working in the connection
 to their own remote server/website.
 
 As a user, I'd be very annoyed to login on a machine which is missing
 both traceroute and mtr.

Again, I agree 

I'd like to mention tcsh. More than ten years I administer Debian
machines and tcsh was always there.

-- 
Kind regards,  Milan


signature.asc
Description: Digital signature

Re: RFC: preventing accidental deletion of system directories

[Milan P. Stanic]

On Sun, Mar 23, 2008 at 04:55:52PM +, Lesley Binks wrote:
 In *nix based systems rm has always meant rm - deleting files does just that.
 The KDE Desktop provides the option to keep this functionality or have
 temporary trash can on the desktop.  However, you don't get the option
 of a trashcan on the command line - unless you want to write your own
 script for it.

There were some libraries which can be activated with LD_PRELOAD.
Two of them:
http://homepage.esoterica.pt/~nx0yew/delsafe/
http://hpux.connect.org.uk/hppd/hpux/Development/Libraries/libtrash-0.2/readme.html


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

Re: BitTorrent and ISP interference

[Milan P. Stanic]

On Thu, Mar 20, 2008 at 11:03:47AM -0500, Ron Johnson wrote:
 On 03/20/08 10:46, brian m. carlson wrote:
  I think it's a good idea.  I'm not a DD, but I don't appreciate getting
  dupe messages from the list.  procmail is not set up to handle them, and
  I read the vast majority of the lists I post to.  I only wish non-Debian
  lists had the same policy.
 
 Following that rule would be much easier if Tbird and gmail had
 Reply To List.

Don't know for gmail but there is add-on for thunderbird/icedove at:
http://alumnit.ca/wiki/index.php?page=ReplyToListThunderbirdExtension



signature.asc
Description: Digital signature

Re: Bug#466669: ITP: squirrelmail-gpg -- GnuPG plugin for SquirrelMail

[Milan P. Stanic]

On Wed, Feb 20, 2008 at 10:32:01AM +0100, Jan Hauke Rahm wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Jan Hauke Rahm [EMAIL PROTECTED]
 
 * Package name: squirrelmail-gpg
   Version : 2.1
   Upstream Author : Brian G. Peterson [EMAIL PROTECTED]
 * URL : http://www.squirrelmail.org/plugin_view.php?id=153
 * License : GPL
   Programming Lang: PHP
   Description : GnuPG plugin for SquirrelMail
 
  This is a general purpose encryption, decryption, and digital signature 
 plugin
  for SquirrelMail that implements the OpenPGP standard using GPG.

Private key is on the webmail server? And this should be secure?
I think that warnings should be written somewhere in description about
risks with such plugin.


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

Re: Request for comment: a new software to manage linux networking features

[Milan P. Stanic]

On Sun, Feb 17, 2008 at 11:20:48PM +0700, namnd wrote:
 * The configuration file is in XML so netupdown can handle sophisticated  
 configuration. Editing the XML the configuration by hand or by software  
 will be easy and comfortable.

Editing XML by hand easy and comfortable?!?

In which world?

Best regards


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

Re: Bug#461104: RFP: label -- Set or change label to partition disk

[Milan P. Stanic]

On Thu, Jan 17, 2008 at 02:32:16PM -0600, Ron Johnson wrote:
 On 01/17/08 13:19, Steve Greenland wrote:
  On 16-Jan-08, 10:00 (CST), Rafael [EMAIL PROTECTED] wrote: 
 Package name: label
  Version: 
  Upstream Author: [David Villa Alises [EMAIL PROTECTED]]
  URL: [http://crysol.inf-cr.uclm.es/node/482]
  License: [GPL]
  Description: [Set or change label to partition disk]
  I realize this is just an RFP, but the proposed package name is way too
  generic. Something like 'partlabel' or 'disklabel' would be better.
  It also seems a rather trivial script for its own package...
 Aren't there already ways to do this?  For example,
 # tune2fs -L some_label /dev/[sh]d[a-z][1-15]

Or: e2label device [ new-label ]


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

Re: Syslog file paths in 'metalog'? (#423299)

[Milan P. Stanic]

On Mon, Dec 10, 2007 at 09:37:17AM +0100, Christoph Haas wrote:
 The problem is not that I'm too lazy to maintain the package. It is just
 not a useful replacement for other syslog daemons because the file names
 that metalog writes to are not configurable.

Yes, sometimes that can be a big problem. Log analyzers comes to mind.

 Imagine you used the sysklogd and now replace it by metalog. Then
 you will get a mess in /var/log/* because metalog can't write mail
 log entries to e.g. /var/log/mail.log.

System administrators should know the differences.

 I have contacted the upstream about it but didn't get a reply so far.

It seems that the original author lost interest in metalog. Last answer
from him I have is two (or more) years old.

 I don't intend to say that metalog is not a good piece  of software.
 But it doesn't fulfil the role of a linux-kernel-log-daemon (virtual
 package).

Risking to be boring and repeating over I must say it can be a good
linux-kernel-log-daemon if sysadm knows what are the limitations and
advantages (log files sizes are predictable).
 
 Perhaps in the future metalog will be better configurable. Let me know
 if you get somewhere with the upstream.

I thought to take it (or creating a new project based on it) but I'm not
sure how it can be useful to wider audience and don't want to waste
time on project from which one person have benefit (me).
But anyway, I'm working on patch which adds pid logging (original
metalog doesn't log pids).

Best regards


signature.asc
Description: Digital signature

Re: Bug#453680: ITP: djbdns -- Replacement for BIND, written by Dan Bernstein

[Milan P. Stanic]

On Fri, Nov 30, 2007 at 10:24:48AM -0500, Robert Edmonds wrote:
 Package: wnpp
 Owner: Robert S. Edmonds [EMAIL PROTECTED]
 Severity: wishlist
 
 * Package name: djbdns
   Version : 1.05
   Upstream Author : Daniel J. Bernstein
 * URL : http://cr.yp.to/djbdns.html
 * License : public domain
   Programming Lang: C
   Description : Replacement for BIND, written by Dan Bernstein
[...]
 Supposedly DJB has released all of his code into the public domain.  If
 this is really the case and passes DFSG, I plan to package djbdns
 assuming Adam McKenna (maintainer of djbdns-installer) doesn't want to.

Are you sure that the complete package is in the public domain?
Some files are, but not all of them, AFAIK.



signature.asc
Description: Digital signature

Re: How to track down the data of package installations

[Milan P. Stanic]

On Fri, Nov 02, 2007 at 08:05:51AM +0100, Andreas Tille wrote:
 I update my laptop to recent testing more or less onm each working day
 because I can easily sync a testing mirror.  The first time I observed
 the problem which is described below occured last Friday, so I would see
 a connection to the packages that were installed from about 24. to 26.
 of October.  I observed that X stops accepting any inputs via keyboard
 and I can move the mouse but no application is reacting on any click
 event once I startet audacious under xfce4.  I tried to verify

I noticed that behavior few weeks (or it can be a month or even two) ago
but I thought that is problem with kernel (built from vanilla source with
few patches).

I seldom run any sound player and it occured few minutes ago again and
I'm sure that no audacious (nor xmms which is purged from machine) were
running.

Best regards


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

Re: racoon and bug 372665

[Milan P. Stanic]

On Mon, Mar 26, 2007 at 05:05:53PM +, Jörg Sommer wrote:
 Milan P. Stanic [EMAIL PROTECTED] wrote:
  README says that in the /etc/rcS.d/ should go scripts which are
  executed once during boot. In debian policy manual rcS.d is
  mentioned only once in section 9.3.4, but from short description it is
  not clear could the daemons be started from scripts in that directory.
 
 I like to add that starting a daemon in /etc/rcS.d/ causes troubles when
 switching later to runlevel 1 (e.g. for maintenance) and coming back to
 the real runlevel (e.g. 2). The script /etc/init.d/killprocs started as
 /etc/rc1.d/S30killprocs kills these daemons started in runlevel S. They
 are never started again and you may get a broken system, when you came
 back to your default runlevel. I had/have this problem with devfsd very
 often.

The decision to start daemons from /etc/rcS.d/ is made by presumptions
that the sysvinit is the *only* init subsystem in Debian. Ganesan didn't
take to account that this will break running racoon under runit which is
packaged in Debian as alternative init subsystem. I understand why he
wants to start racoon so early in boot process but (IMO) that shouldn't
lead to breakage of the another init subsystem.

The reason could be because policy is vague in that case.

Would it work under upstart I don't know because I don't have enough
time to test it excessively but it looks like it works without problem.
[ I'm just playing with upstart ]


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

Re: racoon and bug 372665

[Milan P. Stanic]

On Wed, Mar 07, 2007 at 07:17:00AM +0530, Ganesan Rajagopal wrote:
  Milan == Milan P Stanic [EMAIL PROTECTED] writes:
  I don't think so (except maybe udev, but servers can happily work without
  udev). What is the reason to start nfs from one time initialization
  subsystem? Portmap and nfs can be started in runlevel 2 to 5.
 
 That's debatable. However current Debian policy as per /etc/rcS.d/README is 
 
 =
 The following sequence points are defined at this time:
 
 * After the S40 scripts have executed, all local file systems are mounted
   and networking is available. All device drivers have been initialized.
 
 * After the S60 scripts have executed, the system clock has been set, NFS
   filesystems have been mounted (unless the system depends on the automounter,
   which is started later) and the filesystems have been cleaned.
 =

Yes, it is true. But is also says that:
=
The scripts in this directory whose names begin with an 'S' are executed
once when booting the system, even when booting directly into single
user mode.
=

Look at are executed once. Daemons could be executed once when booting
the system but also could be stopped, started and restarted during normal
server (or workstation) operation.

 Besides NFS, if your entire access to the network requires IPsec, you cannot
 even ssh outside the box unless racoon sets up a tunnel. It's really a
 critical service in that sense.

So could be other VPN subsystems (OpenVPN, VPNC, SSH etc).

I would think that mountnfs.sh should be moved somewhere else
(/etc/rc{2-5}.d/) where portmap have symlinks already. If we mount
remote filesystems so early why samba is not started from /etc/rcS.d/ ?

Policy is ambiguous (at least) here, IMO.


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

Re: racoon and bug 372665

[Milan P. Stanic]

On Tue, Mar 06, 2007 at 11:02:35AM +0530, Ganesan Rajagopal wrote:
  Milan == Milan P Stanic [EMAIL PROTECTED] writes:
 Some daemons _need_ to be started from /etc/rcS.d (udev for
 example). Another good example is portmap for nfs. If you're mounting nfs
 volumes over IPsec then, racoon needs to start to setup the IPsec tunnel.

I don't think so (except maybe udev, but servers can happily work without
udev). What is the reason to start nfs from one time initialization
subsystem? Portmap and nfs can be started in runlevel 2 to 5.

What if someone mount nfs over ppp tunneled through ssh? Should we than
stard sshd from /etc/rcS.d/? What's with other VPN daemons like OpenVPN,
VPNC, TINC ...?

  My mistake. I should say boot process. Sorry for inconvenience.
 
 I understood that. I am still not clear why it would interfere with the boot
 process. 

I'll try to reproduce it under UML at the weekend.

  That was with racoon patched to work under runit (or other supervisor
  software like daemontools). When I reinstalled racoon from testing
  it doesn't block booting process. But that gives mi a hint. If some
  daemon process could not be started (for whatever reason) it should
  not block the booting.
 
 racoon should come up just fine even if it fails to negotiate any
 tunnels. Any way, the default policy does not even setup any tunnels.

As I said in previous post it was my mistake. racoon comes up fine.
The problem is in that if it is started from /etc/rcS.d/ when runit
tries to start racoon it fails because racoon is running already.

 Let me know if you're still stuck; I can try your patches in a test
 setup with runit when I find some time.

I'll post patch to ipsec-devel list (you are subscribed, IIRC) in a few
days (I want to test it a little) but if you want tell me and I will
send ti to you in private mail.


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

Re: racoon and bug 372665

[Milan P. Stanic]

On Sun, Mar 04, 2007 at 06:36:34PM +0530, Ganesan Rajagopal wrote:
  Milan P Stanic [EMAIL PROTECTED] writes:
 
  I'd like to discuss problem with regards to bug #372665.
  Why the racoon should be started in the rcS when even ssh is not?
 
 The reasons should be fairly obvious from the bug. IPsec is at a much lower
 level than ssh. racoon needs to come up before other network dependent
 services get started.

README says that in the /etc/rcS.d/ should go scripts which are
executed once during boot. In debian policy manual rcS.d is
mentioned only once in section 9.3.4, but from short description it is
not clear could the daemons be started from scripts in that directory.

  Yesterday I installed racoon but not configured it and on the next
  reboot it blocked start-up process. I had to manually remove
  /etc/rcS.d/S40racoon to boot machine.
 
 This should not happen. What do you mean blocked the start-up process?

My mistake. I should say boot process. Sorry for inconvenience.

That was with racoon patched to work under runit (or other supervisor
software like daemontools). When I reinstalled racoon from testing
it doesn't block booting process. But that gives mi a hint. If some
daemon process could not be started (for whatever reason) it should
not block the booting.


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

racoon and bug 372665

[Milan P. Stanic]

I'd like to discuss problem with regards to bug #372665.
Why the racoon should be started in the rcS when even ssh is not?

Yesterday I installed racoon but not configured it and on the next
reboot it blocked start-up process. I had to manually remove
/etc/rcS.d/S40racoon to boot machine.

I didn't posted bug report because of above mentioned bug (which
introduced this bad behavior, IMO) before someone who understand boot
process, shed a little more light on that problem.

I'm using runit instead of sysvinit as init process but I think that
doesn't invalidate my complaint.


signature.asc
Description: Digital signature

Re: Will IceWeasel be based on a fork or on vanilla FireFox?

[Milan P. Stanic]

[ Off-Topic, sorry ]
On Mon, Oct 16, 2006 at 11:43:51AM +1000, Ben Finney wrote:
 If it's not renamed, we can't legally ship it. What, IYO, should be
 done to ship the existing program currently known as Firefox?

FoxFire or FoxInFire, maybe ;)


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

Re: Request for virtual package ircd

[Milan P. Stanic]

On Wed, Oct 11, 2006 at 06:34:41PM -0500, Ron Johnson wrote:
 It's also possible to run multiple FTP servers, each listening on a
 different port, but all the packaged ftp daemons Conflicts:
 ftp-server.

That is bad, IMO. (and chance to raise my opinion about virtual
packages ;) )

Conflicts tag is used overmuch. Sometimes I want to have more than one
ftp-server or mail-transport-agent installed but Conflicts tag does not
allow that. I know that inexperienced user or admin have benefit from
Conflicts (and some other tags) and virtual packages but experienced
ones have problem with them.

Regards


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

Status of iproute package for Etch

[Milan P. Stanic]

Hi,

[ I thought to post that message to Alexander Wirt but I don't like
  to send private mail to people before previous agreement ]

Default kernel in Etch will be 2.6.17 but the iproute package for now
is 20051007 version.

For new kernels there are new upstream releases at:
http://developer.osdl.org/dev/iproute2/download/ and they are named as
iproute2-kernel.version-releasedate

I made deb package of iproute2-2.6.15-060110 with some patches which
Stex (aka Stefano Melchior [EMAIL PROTECTED] ) made for
some older version of iproute2. It works but I'm not sure if it is
lintian clean. I'm ready to help as much as I can to move on.

What should be done to got new version of iproute in Etch?
Alexander?



signature.asc
Description: Digital signature

Re: Status of iproute package for Etch

[Milan P. Stanic]

On Wed, Jul 26, 2006 at 10:05:57PM +0200, Florian Weimer wrote:
 Do the newer versions include documentation of the semantics of the ip
 commands (and not just the syntax)?

I'm not sure if I understand you, but there are some documents which
describes ip command and some other programs (which comes with iproute
like ss and nstat) in package.

And there is nice howto about iproute and policy routing at
http://www.policyrouting.org/iproute2.doc.html which is not included
in iproute package but I hope it could.

Of course, there is also a famous LARTC HOWTO at http://lartc.org/howto/


signature.asc
Description: Digital signature

Re: Using the SSL snakeoil certificate

[Milan P. Stanic]

On Sun, Jul 23, 2006 at 08:37:50PM +0200, Martin Schulze wrote:
 Milan P. Stanic wrote:
  Sorry if I misunderstand something, but is it okay to call it snakeoil
  if it is real certificate? I like to say that the symbolic links for
  per-service certificate shouldn't point to something called snake-oil.
 
 Nah, if you replace the snakeoil certificate by a real one, it's not
 snake-oil anymore, of course.

But then you must change all symlinks to that new real certificate.


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

Re: Using the SSL snakeoil certificate

[Milan P. Stanic]

On Mon, Jul 24, 2006 at 12:43:16PM +0200, Peter Palfrader wrote:
 On Mon, 24 Jul 2006, Milan P. Stanic wrote:
  But then you must change all symlinks to that new real certificate.
 
 That's why on my systems all the service names symlink to
 thishost.{pem,key} and that is itself a symlink to the current
 certificate.  Only one symlink to update when you rotate certs.

That is what I'm thinking about. All service certificates should be
symlink to one generic name (as Martin proposed) but that name
shouldn't be snake-oil because the meaning of the word snake oil, IMO.
thishost.{pem,key,crt,p12} looks better.

Another idea is to make that decision to user/admin during installation
through debconf or something similar, but don't ask me for patch
because I don't know how to make it. :)


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

Re: Using the SSL snakeoil certificate

[Milan P. Stanic]

On Thu, Jul 20, 2006 at 11:24:34AM +0200, Martin Schulze wrote:
 For example:
 
   Dovecot uses /etc/ssl/certs/dovecot.pem.
 
   This is a symbolic link to /etc/ssl/certs/ssl-cert-snakeoil.pem if
   the above file or link does not exist during configuration of
   dovecot.
 
 That way, the admin can easily replace the symlink with a real
 certificate if they want per-service certificates.
 
 If, however, they want to have one real certificate for everything,
 they can replace the snakeoil certificate like Martin Pitt proposed.
 
Sorry if I misunderstand something, but is it okay to call it snakeoil
if it is real certificate? I like to say that the symbolic links for
per-service certificate shouldn't point to something called snake-oil.

Just my opinion.


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

[Milan P. Stanic]

On Sun, May 14, 2006 at 01:20:20PM +0200, Krzysztof Krzyzaniak (eloy) wrote:
  Email::Send provides a very simple, very clean, very specific interface
  to multiple Email mailers. The goal if this software is to be small
   ^
  and simple, easy to use, and easy to extend.

Isn't the term Email mailers vague a little?


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

Re: Bug#366359: ITP: libnet-smtpauth-perl -- Simple Mail Transfer Protocol client with AUTHentication

[Milan P. Stanic]

On Mon, May 08, 2006 at 12:15:44AM +0200, Nacho Barrientos Arias wrote:
 * Package name: libnet-smtpauth-perl
   Version : 0.08
   Upstream Author : Alex Pleiner [EMAIL PROTECTED]
 * URL : http://search.cpan.org/dist/Net-SMTP_auth/
 * License : Perl
   Programming Lang: Perl
   Description : Simple Mail Transfer Protocol client with AUTHentication
 
  This module implements a client interface to the SMTP and ESMTP protocol
  AUTH service extension, enabling a perl5 application to talk to and
  authenticate against SMTP servers.
  .
  Homepage: http://search.cpan.org/dist/Net-SMTP_auth/

Net::SMTP already supports AUTH service extension (RFC2554), IIRC.

Is it wise to have two Perl modules for the same task with a different
syntax?


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

debian-devel@lists.debian.org

[Milan P. Stanic]

Hi!

I could try to arrange donation of one UltraSparc machine to Debian
project. I think that the transport would be to complicated from
Serbia to anywhere (because of our laws) but I can connect it to the
Net for DD's to use it.

Machine CPU is: (whatever it means)

[EMAIL PROTECTED]:~# cat /proc/cpuinfo
cpu : TI UltraSparc I   (SpitFire)
fpu : UltraSparc I integrated FPU
promlib : Version 3 Revision 1
prom: 3.1.1
type: sun4u
ncpus probed: 1
ncpus active: 1
Cpu0Bogo: 285.08
Cpu0ClkTck  : 088601c0
MMU Type: Spitfire

It has 64Mb RAM, two 2GB scsi HD's, one CD drive, two RS232, one
paralell port, tape drive.

Could that machine be useful for Debian?

[ It worked fine under Potato/Woody for more than 5 years. ]


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

Re: what to do with iputils (ping, etc)

[Milan P. Stanic]

On Fri, Oct 21, 2005 at 04:41:48PM -0400, Stephen Frost wrote:
 It seems like the 'sensible' thing to do might be to provide both.
 Typically I would think the standard 'ping' would be, well, pretty
 standard, and would work across multiple kernels/OSes/etc.  We could
 also have an 'lping' or some such which supported all the
 latest-greatest linux-based stuff.
 
It seems 'sensible' thing is to do like it is now.

If one likes standard ping s/he can install netkit-ping else
iputils-ping.

Re: dhcp-client package in sarge

[Milan P. Stanic]

On Sun, Jun 12, 2005 at 10:19:03PM +1000, Andrew Pollock wrote:
 FWIW, I've recently become a co-maintainer, and now the Sarge has released,
 I'm planning on bringing dhcp3 up to date with the latest upstream and
 having a good bash at all the bugs.

Would you consider to incorporate LDAP patch to dhcp server?


signature.asc
Description: Digital signature

Re: Bug#295122: RFA: iproute -- Professional tools to control the networking in Linux kernels

[Milan P. Stanic]

Hi Andi,

On Sun, Feb 13, 2005 at 09:39:15PM +0100, Andreas Barth wrote:
 Package: wnpp
 anyone who wants to work on iproute is greatly welcome, perhaps also as
 co-maintainer (and I'm also willing to sponsor people). The reason I 
 intend to give the package away is that I'm not really the great
 networking guy, but I'll try to give the package a warm home till I can
 pass it over to someone else -- and as iproute is quite vital for
 some purposes, I'll do some checks before giving the package away. It is
 _not_ orphaned, I'm only looking for somebody else for maintaining.

I raise my hand. I'm not DD so your sponsorship will be appreciated.
I'm subscribed to linux-net (but not netdev) for years so I follow
changes in package.


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

How to build libapache-mod

[Milan P. Stanic]

Hi!

Anyone can give a pointer for doc's how to build apache modules
for Debian? I already looked at some examples but that didn't
helped much.

Sorry if this question answered already or the location of doc's
(policy) is easy to find.

TIA


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

Re: How to build libapache-mod

[Milan P. Stanic]

On Wed, Jan 12, 2005 at 03:44:45PM +0100, Michael Ablassmeier wrote:
 On 2005-01-12, Milan P. Stanic [EMAIL PROTECTED] wrote:
  Sorry if this question answered already or the location of doc's
  (policy) is easy to find.
 
 apache-dev includes `/usr/share/doc/apache-dev/README.modules' which
 contains a set of simple guidelines on how to integrate external Apache
 modules into Debian. Looking at existing libapache-mod-* package-sources
 should also help, though.

I thought such file is in the apache-dev and my first search was
there but without luck. After your answer I think that must be for
the testing/unstable, but not for stable.
And I have only stable/woody.

But, now I know where to search.

Thanks


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

Re: How to build libapache-mod

[Milan P. Stanic]

On Wed, Jan 12, 2005 at 09:25:12PM +0100, Tollef Fog Heen wrote:
 You really don't want to develop new packages for apache 1 and
 certainly not for the apache in woody.  Woody's apache is broken in
 so many and interesting ways it's beyond funny and into the scary
 territory.  Apache 1 is going away when sarge is released, so if you
 can, please package the module for apache 2 rather than apache 1.

I don't have much experience with apache2. Only tried once and stop
using it. With apache1 I work about eight or more years now.

BTW, module which I'm trying to package is psldap and there is in
source doc's which says it can be built with both apache version, so
I hope if I manage to build it with apache1 it should be easy with
apache2 :-)


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

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

[Milan P. Stanic]

On Thu, Dec 02, 2004 at 05:01:57PM +0100, Michelle Konzack wrote:
 Some of the islamic countries like Turkey, Jordania and Morocco

Turkey isn't islamic country but secular one, AFAIK.

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

[Milan P. Stanic]

On Wed, Dec 01, 2004 at 05:34:34PM +0100, Michelle Konzack wrote:
 I do not like to go to prison in Iran or may be killed
 because I have such application on one of my Desktops. 

If you can be killed because you have such application (picture) then
you are in big trouble, anyway.
I like to have such application (picture) not because I actully like
this sorts of pictures, but because I like to be free to choose what
I want to have.

If someone take this one from me today, I might have not a photo of
my daughter without the veil over her face tomorrow.

Freedom is taken out piece by piece, history tell us.

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

[Milan P. Stanic]

On Tue, Nov 30, 2004 at 06:17:37PM -0600, Ron Johnson wrote:
 However, I'd be *highly* agitated if someone gave my daughter a 
 CD-ROM with *any* nudy cartoons.

I'd rather live with this risk than with less freedom.

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor

[Milan P. Stanic]

On Wed, Dec 01, 2004 at 09:10:30PM +, Andrew Suffield wrote:
 The only genuinely neutral content is the output of /dev/random; all
 else is subjective.

What if /dev/random produce picture of hot-babe :-)
[ It is possible, in theory at last. ]

Re: more current iproute

[Milan P. Stanic]

On Wed, Nov 10, 2004 at 11:18:46AM +0100, Andreas Barth wrote:
 I uploaded the current version of iproute (that also works with current
 2.6-kernels) to experimental. As this is a major change, any test
 reports are appreciated. Also, a review of the source whether I managed
 to keep all security patches might be a good idea (I'm quite confident
 that I did, but - a independent look might be a good thing).

Finally. Thanks!
It is worth backport to woody. I'm doing that right now.

 Please note that I'm aware that the package documentation is not in the
 best state, but as this was a NMU, I didn't do the changes that I would
 have done with a normal maintainer upload.

Why version is iproute_20041019 while the upstream is
iproute2-2.6.9-041019? Upstream version is 2.6.9 actually. Date is
appended to serve as timestamp, I think.

Re: ITO several packages

[Milan P. Stanic]

On Thu, Nov 13, 2003 at 11:20:06PM +1100, Martin Michlmayr wrote:
  cvs-conf
  cwwm
  jpegoptim
  libfork-perl
  metalog
  pip
 
 These packages still don't have a new maintainer.  Sebastien, which
 packages are obsolete today?  I'll get those removes and properly
 orphan the rest.

If someone want to sponsor me (I'm not DD) I'd like to take metalog.

Re: stack protection

[Milan P. Stanic]

On Mon, Aug 25, 2003 at 04:14:12PM +1000, Russell Coker wrote:
 On Mon, 25 Aug 2003 07:48, Milan P. Stanic wrote:
   Also I don't expect DJB to write replacements for dhcpd, dhclient, ftpd,
   cron,
 
  Maybe someone else should do that, I hope at least.
 
 What should be done for the few years that we probably have to wait for such 
 programs to be written?

There are some of them: vsftpd, pure-ftpd, udhcp, uschedule ... to note
just some. They are not 100% secure, but they are more secure than
software written by ISC.

[ I don't like to offend  Paul Vixie or ISC programmers. They do good
job in the beginnings of the Internet and probably in these days they
didn't anticipate how hostile will become network for collaboration,
sharing ideas and knowledge, extending freedom ... ]

[ BTW, a good measure for security is: don't use ISC software! :-) ]

[...]
  If attacker can poison DNS cache or fake DHCP server to do something
  nasty then the problem with SE Linux is just mitigated, not solved.
 
 Mitigating a problem so that it only allows DOS attacks or attacks of limited 
 means (such as making a DNS or DHCP server return bogus data) rather than 
 having it allow full administrative access is more than a little mitigation!

I don't like to argue, but that is mitigation and not solution. With
SE Linux problem can be mitigated a lot I agree, and I really like we
have it now in Debian (due to Your effort), but this isn't solution.

[ OK, I'm going to think that we never will have secure system because
absolute security is against nature. ]

[...]
  I'm not against choice, I just don't like idea that that stack
  protection and similar code could become mainstream one day.
 
 Why?  I've used OpenWall and PaX and not found any programs that fail to work 
 correctly with them.

I'm sure You know how easy to write one. If I and You don't know for
such program, that doesn't mean that there isn't some in the wild.

Re: stack protection

[Milan P. Stanic]

On Mon, Aug 25, 2003 at 10:56:38AM -0700, Don Armstrong wrote:
 I'm personally only really familiar with ISC's dhcpd3-server, but have
 you even read the code written by Ted Lemon? Just randomly slandering
 programmers when you are not intimately familiar with their code isn't
 something that should be done lightly.

In my original post you could read: (You quote it, see bellow)
-
[ I don't like to offend  Paul Vixie or ISC programmers. They do good
job in the beginnings of the Internet and probably in these days they
didn't anticipate how hostile will become network for collaboration,
sharing ideas and knowledge, extending freedom ... ]
-
So, I think I'm not slandering them or at least that isn't my
intention. I apologize if I did.

 As far as I can remember, the last exploit in dhcpd3-server happened
 well over 2 years ago. While I've never heard of an exploit in udhcp,
 I'm relatively sure it's not as widely scrutinized as dhcpd3-server.
 
Do you follow DSA?
--
Debian Security Advisory DSA 231-1 [EMAIL PROTECTED]
http://www.debian.org/security/ Martin Schulze
January 17th, 2003  http://www.debian.org/security/faq

Debian Security Advisory DSA 245-1 [EMAIL PROTECTED]
http://www.debian.org/security/ Martin Schulze
January 28th, 2003  http://www.debian.org/security/faq
--

  [ I don't like to offend Paul Vixie or ISC programmers. They do good
  job in the beginnings of the Internet and probably in these days they
  didn't anticipate how hostile will become network for collaboration,
  sharing ideas and knowledge, extending freedom ... ]
 
 Many of ISC's programs (bind, dhcp) current versions have been
 completely rewritten from scratch, or nearly from scratch. The people
 who wrote them are quite well aware of the current state of hostile
 networks.

AFAIK only bind is rewritten, but Dan J. Bernstein explained how they
rewrote it. Some of the bugs were the same in version 8 (old code) and 9
(new rewritten code). ;-) Document could be found somewhere on DJB
site: http://cr.yp.to/
[ I don't like to refer to DJB, but can't remember anything better ]
 
  [ BTW, a good measure for security is: don't use ISC software! :-) ]
 
 In many cases, there isn't an alternative for ISC's software. I have
 yet to find a dhcp server that is as featureful and robust as ISC's
 dhcp server. If you're serving a network of 5 computers, udhcpd might
 work for you, but some people use debian to run dhcpd for networks of
 thousands of nodes with hundreds of subnets.

I'm using ISC's dhcp to. But this doesn't mean I must praise it and 
I can't see bugs.

Re: stack protection

[Milan P. Stanic]

On Sun, Aug 24, 2003 at 01:40:28PM +1000, Russell Coker wrote:
[...]
  I agree, but writing secure (not perfectly secure) software may be
  nearly possible.
  I don't like to start flame war, but must mention djbdns and qmail.
 
 Yes, however they have less functionality than the alternatives that most 
 people want to use.
 
Someone could say that for Linux comparing it with WinXX. 

 Also I don't expect DJB to write replacements for dhcpd, dhclient, ftpd, 
 cron, 
Maybe someone else should do that, I hope at least.

[...]
  That couldn't be solved by SE Linux (or similar code) but just
  mitigated a little.
 
 No, it means that a badly written daemon running as UID 0 can not trash your 
 system.  So a sound server that has a bug can at worst play sounds and record 
 sounds in a malicious manner, and refuse to do what it is supposed to do.  
 Much better than allowing it to write to /etc/shadow!
 
If attacker can poison DNS cache or fake DHCP server to do something
nasty then the problem with SE Linux is just mitigated, not solved.

  I'm not against SE Linux, RSBAC GRSec, LIDS etc. I'm using some them
  on servers and playing with all of them. I just like to say that putting
  limits in the (our loved (Debian)/Linux) is not good thing, IMO.
 
 Why is it a limit? We are not talking about making any of these
 mandatory for Debian users. We want to give them a choice of all of
 the above.

I'm not against choice, I just don't like idea that that stack
protection and similar code could become mainstream one day.

P.S.
I appreciate you contribution to Linux (and Debian) security a lot,
and I play with *your* SE Linux host when I have time.

Re: stack protection

[Milan P. Stanic]

On Sat, Aug 23, 2003 at 03:13:25PM +1000, Russell Coker wrote:
 On Sat, 23 Aug 2003 07:02, Milan P. Stanic wrote:
  On Thu, Aug 21, 2003 at 09:39:53AM +0200, Xavier Roche wrote:
   Note that some options are sometimes incompatible with some packages:
   restrictions on kmem ('Deny writing to /dev/kmem, /dev/mem, and
   /dev/port') prevent lm_sensors from working properly with my server. But
 
  cat /dev/zero  /dev/mem is a feature and not a bug, but today
  more and more people disagree.
 
 Allowing the system administrator to write to /dev/mem as part of debugging 
 the kernel is a feature.

UID 0 must have rights to do everything. root can format filesystem,
by mistake or by intention.

 Allowing the dhcp server to write to /dev/mem because it's UID 0 and Unix 
 security sucks is a bug.

The problem isn't with UID 0, but with bugs in software.

I think that the problem cannot be solved in wrong place. It isn't
possible to have secure DHCP server by fixing kernel, but by writing
secure (OK, with less bugs) DHCP server.

Re: stack protection

[Milan P. Stanic]

On Sun, Aug 24, 2003 at 01:19:38AM +1000, Russell Coker wrote:
 On Sat, 23 Aug 2003 19:36, Milan P. Stanic wrote:
   Allowing the system administrator to write to /dev/mem as part of
   debugging the kernel is a feature.
 
  UID 0 must have rights to do everything. root can format filesystem,
  by mistake or by intention.
 
 UID does not have to be the only method of determining access rights.  In SE 
 Linux you have the Identity (based on the login name for interactive sessions 
 and cron jobs, or system_u otherwise) which determines which roles are 
 permitted.  You have the Role which determines which domains are permitted, 
 for an Identity that is permitted to use multiple roles there are methods of 
 changing roles during a session or of determining which Role to use when 
 logging in.  Then you have the Domain which determines the access rights.
 
 When you login to do administrative work by default you will have the context 
 root:sysadm_r:sysadm_t as the Identity:Role:Domain.  This will deny you 
 access to block devices, when you run mount or mkfs they run in different 
 domains which have the access needed to do their job.

Complexity and security doesn't mix well.
 
[...]
 Writing perfect software is impossible.

I agree, but writing secure (not perfectly secure) software may be
nearly possible.
I don't like to start flame war, but must mention djbdns and qmail.
 
 For a good defence you want to have multiple levels.  Medieval castles never 
 had a single level of defence, they were built on a hill, they were 
 surrounded by a moat, they had outer walls and then a fortified keep inside 
 so that even filling in the moat and smashing the outer walls would not let 
 an attacker win.

Denial of Service was the most successful method to defeat it. :-)
 
[...]
 Writing quality software is good.  Having stack protection is good too (the 
 original topic of this thread).  But it still doesn't provide as much 
 protection as you will really want, SE Linux is still necessary even if you 
 run top quality software.

Having capability to execute code in any place is flexibility of the
OS. If the kernel forbids execution code on the stack, such kernel
forbids using legitimate programming method and I think if it goes this
way we will have OS (kernel) which puts limits and bounds.
 
 Most Unix daemons are not of the highest quality, consider that they added a 
 -b switch to start-stop-daemon.  Think about the quality of coding that 
 goes into a daemon that doesn't even call the daemon(0,0) library call or 
 have equivalent code!

That couldn't be solved by SE Linux (or similar code) but just
mitigated a little.

 PS  The ptrace exploit code that was released did not work on SE Linux 
 systems.  The reason was that the socket access necessary to trigger the 
 module load in the exploit code was denied to the user_t domain because it 
 was not needed (everything that is not needed is denied by default).  It 
 might have been possible to write an exploit to work on SE Linux, but no-one 
 did so.

SE Linux (and Linux kernel) is the program. Programs have bugs. Some
of the bugs can be used as security exploit. If there isn't known
exploit now (I don't know but what knows NSA or black hat community?)
doesn't mean it will not emerge tomorrow.

I'm not against SE Linux, RSBAC GRSec, LIDS etc. I'm using some them
on servers and playing with all of them. I just like to say that putting
limits in the (our loved (Debian)/Linux) is not good thing, IMO.

Re: stack protection

[Milan P. Stanic]

On Thu, Aug 21, 2003 at 09:39:53AM +0200, Xavier Roche wrote:
 Note that some options are sometimes incompatible with some packages:
 restrictions on kmem ('Deny writing to /dev/kmem, /dev/mem, and
 /dev/port') prevent lm_sensors from working properly with my server. But

cat /dev/zero  /dev/mem is a feature and not a bug, but today
more and more people disagree.

cite Doug Gwin
UNIX was not designed to stop you from doing stupid things,
because that would also stop you from doing clever things.
/cite

Re: Should MUA only Recommend mail-transfer-agent?

[Milan P. Stanic]

On Tue, Aug 05, 2003 at 08:00:03PM +0200, Bernd Eckenfels wrote:
 There are enough SMTP/POP3 MUAs which do not need any MTA infrastructure on
 the local host, whatsoever. Mutt can fetch by pop-3, but I think it has no
 smtp support build in, or?

I just (actually few hours ago) find patch which adds smtp support to
mutt. 
http://www.deez.info/sengelha/projects/mutt/libesmtp/patch-1.5.3.sde.libesmtp.3

It depends on libesmtp.

I personally always liked MUAs with smtp and my main objection to mutt
was lack of it. Now, I have it for my (loved) MUA. :-)

-- 
Milan

Re: Kernel 2.5

[Milan P. Stanic]

On Sun, Apr 27, 2003 at 09:37:06PM +0100, Mark Shuttleworth wrote:
 When booting, grub seems to find it, uncompress it, then it says 'OK, 
 booting the kernel' and nothing more. It just hangs. I don't see the 
 line announcing the kernel version or compiler etc.

CONFIG_VGA_CONSOLE=y


Milan

Re: Kernel 2.5

[Milan P. Stanic]

On Sun, Apr 27, 2003 at 06:45:42PM -0400, Bart Trojanowski wrote:
 * Mark Shuttleworth [EMAIL PROTECTED] [030427 16:59]:
  I've configured and built the kernel, using gcc-2.95, make bzImage and 
  modules, installed modules under /lib/modules/2.5.68. Everything goes 
  fine except for a bunch of depmod errors during the 'make 
  modules_install' which I'm guessing is because the new modules don't 
  match the running kernel.
 
 I believe that you can still build with gcc-2.95.  To the best of my
 recollection I did do that at least once... although I've been using 3.2
 for the most recent builds.

Right. I compiled it with gcc-2.95.4 (woody).
It works on my workstation but crashes on the armada notebook.

 The new modules (*.ko) do not work with the old module utils.  It may be
 that you just have to rebuild the kernel with the presence of these new
 utilities.
 
 $ apt-cache show module-init-tools

Yes. You are right again. This must be installed.
I downloaded it from unstable and compiled on woody. It works.

Milan

Re: Kernel 2.5

[Milan P. Stanic]

On Mon, Apr 28, 2003 at 12:40:28AM +0200, Milan P. Stanic wrote:
 On Sun, Apr 27, 2003 at 09:37:06PM +0100, Mark Shuttleworth wrote:
  When booting, grub seems to find it, uncompress it, then it says 'OK, 
  booting the kernel' and nothing more. It just hangs. I don't see the 
  line announcing the kernel version or compiler etc.
 
 CONFIG_VGA_CONSOLE=y

Sorry. I made a mistake. It should be:
CONFIG_VT_CONSOLE=y

Milan

Re: If Debian decides that the Gnu Free Doc License is not free...

[Milan P. Stanic]

On Thu, Apr 24, 2003 at 09:50:35PM +0400, Hans Reiser wrote:
 There is screensaver that displays random fortunes (executes fortune(6)).
 Create fortune's database consisting of credits information and you are 
 done.
[...]
 Would debian be willing to do this as the default screensaver?  I think 
 it would be great if it did.

Can I propose name Super-Ego for this screensaver if it doesn't have
one already? ;) 
 
Milan