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: 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: 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#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]

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

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

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: 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 .
> 
>   This is a symbolic link to  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: 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]

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

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 02:19:32PM +0100, Nico Golde wrote:
> Hello Milan,
> 
> * Milan P. Stanic <[EMAIL PROTECTED]> [2005-01-12 14:16]:
> > 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.
> 
> have a look on the source of an existing apache modules. 

Did that (see above) but I had a hope that there is something like
"libapache-mod Debian policy". Never mind, I'll try to conclude from
examples.

Anyway, thx.


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


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

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 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 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: 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: 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#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: 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: 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: 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\)"  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\)"  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

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

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 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 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: 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: 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: 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: Syslog file paths in 'metalog'? (#423299)

[Milan P. Stanic]

On Sun, Dec 09, 2007 at 01:42:02PM +0100, Christoph Haas wrote:
> On Thu, Dec 06, 2007 at 01:11:32PM -0500, Kris Deugau wrote:
> > Mmmh.  Strictly speaking, sysklogd logs mail to /var/log/mail.log, along 
> > with duplicating (!!) much of the content to (IIRC) /var/log/messages and 
> > /var/log/mail.{err,info,warn}. .0, .1.gz, etc are created by the 
> > non-logrotate widget Debian uses for rotating system logs.
> >
> > In general, I would say as a sysadmin that any syslog daemon that does not 
> > allow me to configure any given log facility and priority to (at least!) an 
> > arbitrary file wherever I want it is inherently broken.

What do you mean by "configure any given log facility and priority to an
arbitrary file"?

Metalog can be configured to log given log facility and priority to an
arbitrary directory, but (yes) not to file.

> I think I agree to that. Thus I will request the removal of the package
> until metalog will one day be more configurable and allow to mimic other
> syslog daemons' file schemes.

I'm using metalog on some of the servers so I would like it to remain in
Debian. I can maintain it if someone want to sponsor me.

Best regards


signature.asc
Description: Digital signature

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#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  /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: 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: 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 
> 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: 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 
> > > 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: 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  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: Bug#575209 closed by Holger Levsen (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: 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: 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

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: 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: 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: 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: 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: 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: 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 :
> > 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: Making -devel discussions more viable

[Milan P. Stanic]

On Tue, 2012-05-08 at 15:19, Miles Bader wrote:
> Alexander Wirt  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: 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 
> 
> * 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 
> * 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: 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: 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: 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: 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  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 
> 
> 
> * 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: 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: 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: 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
> > ) 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  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: On init in Debian

[Milan P. Stanic]

On Thu, 2012-03-29 at 13:07, Russ Allbery wrote:
> Mike Hommey  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: 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: 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: [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: systemd effectively mandatory now due to GNOME

[Milan P. Stanic]

On Sat, 2013-12-21 at 19:31, Russ Allbery wrote:
> Vincent Lefevre  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: 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: Debian rolling: tentative summary

[Milan P. Stanic]

On Tue, 2011-05-03 at 09:47, Martin Wuertele wrote:
> * Cristian Henzel  [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#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: Depends: logrotate (forever and ever and ever)

[Milan P. Stanic]

On Sun, 2011-09-18 at 22:45, Russ Allbery wrote:
> Ivan Shmakov  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: 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  :)
> 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: 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: 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:  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:  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:  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:  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:  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:  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:  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:  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:  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: 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.