[q] maintainance of xfsprogs and util-linux

[Oleg Verych]

Hallo. I'm new here, let me in, please.

xfsprogs debian's maintainer left SGI and i don't know if he announced
anything about debian. Version in unstable is .11, while in upstream
it's already .16.

util-linux maintaining as in upstream as in debian isn't good, also.
Last one i'll try to update. At least with new RTC support introduced
in linux 2.6.16+. But this package have issues today: depends on very
old tzdata, thus stalled in unstable.

Any comments are appreciated.

--
-o--=O`C  info emacs : not found  /. .\ (is there any reason to live?)
 #oo'L O  info make  : not found  o (   R.I.P)
<___=E M  man gcc: not found.-- (  Debian GNU+Linux  )


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

Re: [q] maintainance of xfsprogs and util-linux

[Oleg Verych]

On 2006-11-18, martin f krafft <[EMAIL PROTECTED]> wrote:
>
> --envbJBWh7q8WU6mo
> Content-Type: text/plain; charset=iso-8859-1
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> also sprach Lo=EFc Minier <[EMAIL PROTECTED]> [2006.11.18.1204 +0100]:
>>  True; but IMO xfsprogs is relatively stable,
>
> Where stability is relative to the filesystem. :)
>
> I actually would like to see the latest xfsprogs in etch simply
> because they contain fixes for the recent XFS kernel bugs, so if
> you've been bitten, you can at least get your data back.

With 2.6.17-stable bug -- corrected file system, so one will not
have unpleasant log messages futher. This is a problem of *testers*,
who was affected by that bug. It was said version .10 corrects fs, but
i saw people, who reported, that it doesn't...



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

bash features (Re: Question about "Depends: bash")

[Oleg Verych]

On 2006-11-21, Ian Jackson wrote:
> Oleg Verych writes ("Re: Question about "Depends: bash""):
>> o `arrays'  bashizm -> tmp=$@ ; set -- $ARRAY ; use_array $@ ; set -- $tmp
>
> This is another piece of bad advice: this approach is buggy if the
> arguments might contain whitespace, which is often the case (eg if
> they're filename arguments).

Who said, that it's without bugs, bugs of my usage or bugs in BaSH, dash?
"NO WARRANTY" message on every login (:?

(BTW, spaces in filenames are problem of those dual-boots, who have non
UTC BIOS time and such.)

IFS doesn't help there. Why?

Quotes can't help against _some_ contents of $ARRAY (in example above).
While i don't know how it should be, please, comment on below experiment,
which i think shows a bug:

,-*- bash -*-
|[EMAIL PROTECTED]:/tmp/b$ touch simple.file
|[EMAIL PROTECTED]:/tmp/b$ echo *
|simple.file
|[EMAIL PROTECTED]:/tmp/b$ echo '*'
|*
|[EMAIL PROTECTED]:/tmp/b$ set -- * ; echo $1
|simple.file
|[EMAIL PROTECTED]:/tmp/b$ set -- '*' ; echo $1
|simple.file
|[EMAIL PROTECTED]:/tmp/b$ set -- '\*' ; echo $1
|\*
|[EMAIL PROTECTED]:/tmp/b$ set -- \* ; echo $1
|simple.file
|[EMAIL PROTECTED]:/tmp/b$ set -- \\* ; echo $1
|\*
|[EMAIL PROTECTED]:/tmp/b$
`-*-

dash does the same way, `-f' option helps there, while its meaning for
`echo' and `set' seems to be different.



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

C-x $ (Re: First draft of review of policy must usage)

[Oleg Verych]

On 2006-10-25, Manoj Srivastava wrote:
[]
> +   
> +For arch dependent packages, binary-arch must
> +exist, since it is used by the build daemons to auto
  +*buld* packages. The binary-indep target should
> +also exist. If one of them has nothing to do (which
> +will always be the case if the source generates only a
> +single binary package, whether architecture-dependent
> +or not), it can be a no-op. In that case, the no-op
> +target should still be present and should still
> +succeed.
> +   

Don't forget to run spell checker (my catch, ispell in jed doesn't work on
this patch).



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

Re: Question about "Depends: bash"

[Oleg Verych]

On 2006-11-22, Tollef Fog Heen wrote:
> * Oleg Verych 
>
>| o `arrays'  bashizm -> tmp=$@ ; set -- $ARRAY ; use_array $@ ; set -- $tmp
>
> This is in no way equivalent (with dash):
>
> [EMAIL PROTECTED]:\w$ set -- "abcd efg" "hij"
> [EMAIL PROTECTED]:\w$ echo $@
> abcd efg hij
> [EMAIL PROTECTED]:\w$ echo $1
> abcd efg
> [EMAIL PROTECTED]:\w$ tmp="$@"
> [EMAIL PROTECTED]:\w$ set -- blah
> [EMAIL PROTECTED]:\w$ set -- $tmp
> [EMAIL PROTECTED]:\w$ echo $1
> abcd
> [EMAIL PROTECTED]:\w$
>
> If you need arrays, use bash or a proper programming language.

Guys. Once more. Spaces is your problem, not my.

In case of spaces in file names, what isn't such a synthetic test
case, i would use temp. file with them, and would read it by lines.

Array means you have some kind of index or iterator, i think, it's ok
with temp. file and ok 2 times if you deal with files.

Real problem is different 'set --' implementations. In bash it honors IFS in
dash it doesn't. Both don't honor quotes for pathname expansions (as
i've mentioned, -f helps). busybox has its own "set --".

As big thread about POSIX shell shows, one must have a real documetation
to implement features. BaSH's man page doesn't have clear line between
"shiny-features" and "a must" for bourne shell. Many bashizms are right
from there.

As all this GFDL ... thing shows who is right, i will work towards
"Debian Viva, GNU R.I.P.", as development and answer to my footer.

--
-o--=O`C  info emacs : not found  /. .\ ( is there any reason to live? )
 #oo'L O  info make  : not found  o (R.I.P. Debian Operating System)
<___=E M  man gcc: not found.-- (  TNX, RMS.   )


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

Re: Question about "Depends: bash"

[Oleg Verych]

On 2006-11-22, Michelle Konzack wrote:
[]
> I am using things like 
>
>   Arrays
>   ${#NAME}

In dash there is one, but i don't know about `*' and `@' there.

>   ${parameter:-word}
>   ${parameter:=word}

Both work.

>   ${parameter:offset}
>   ${parameter:offset:length}

Here you know what and where parameter has. Is it better to split it?

>   disown

This one not needed, unless you are in x-terminal, AFAIK.

> OK, some of thease can be constructed but it takes some time longer.
>
> I have already tested some of my scripts and tried to change it, but
> the it works in one shell but not more in another...
>
> So I stay with BASH.

Yes... Kind of web-programming...

There's some documentation available, so will see. Hope it isn't kind of
"undefined", "implementation defined".



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

Re: Bash /dev/tcp and /dev/udp

[Oleg Verych]

On 2006-11-23, Klaus Ethgen wrote:
>
> Hi all,
>
> from the bash manpage:
>   /dev/tcp/host/port
>  If host is a valid hostname or Internet address, and port
>  is an integer port number or service name, bash  attempts
>  to open a TCP connection to the corresponding socket.
>   /dev/udp/host/port
>  If host is a valid hostname or Internet address, and port
>  is an integer port number or service name, bash  attempts
>  to open a UDP connection to the corresponding socket.
>
> But this feature doesn't work on debian systems (on other distributions
> it works and is not a problem).

Hammer for opening doors, or just keys ? IMHO, that is another useless
stuff, _shell_ mustn't have, and it does in debian (see curl).




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

X and non-X packages (Re: Attempts at security)

[Oleg Verych]

> From: Lars Wirzenius
> Newsgroups: gmane.linux.debian.devel.general
> Subject: Re: Attempts at security
> Date: Sat, 03 Feb 2007 14:05:30 +

Hallo.

> On la, 2007-02-03 at 12:37 +0100, Hendrik Sattler wrote:
>> > > Not being able to change the cause to the better doesn't mean to
>> > > introduce a mess to control the result.  And I really hope that Debian
>> > > never considers installing+enabling selinux by default.
>> >
>> > IIRC, debian/etch already does already install selinux today without you
>> > even noticing it.
>> 
>> It is not enabled by default. That is the other point: you get that selinux 
>> integration if you want or not.
>
> Debian has made similar decisions throughout its history: we generally
> don't provide separate X and non-X versions of the same package, for
> packages where this is a build time option, for example. That is also a
> cost every Debian user pays: increased disk and memory usage, even if
> they don't use X at all.

I'm the one, who don't need X, but emacs21 is linked to some X, even to
(ugly) 3d scollbars, that i hate. Thus, i whould say it's a *very* big
disadvantage.

Also i want to ask, if you don't mind. Thanks.

While there are plenty of possibilities to contribute to Debian as whole,
and in particular, it's very hard for me to even build package with
`apt-get source && debian/rules build`. If there are documents on topic
of configuring self build packages, please point them to me.

But i would really like to have something, like
,-*-
|package-0.1.7: $ ./debian/rules help
`-*-

very brief description how to configure, build package, or to have
maintainer's configuration to play with (if this information isn't
KNOW-HOW ;).

apt-build is debian's version of gentoo-like philosophy, and i would like
to have it fully used by me.

> In order to keep the complexity of the entire Debian system manageable,
> we need to make those choices. If we, as a project, are of the opinion
> that providing SELinux support is a good thing, then everything in
> Debian that needs to be changed for the support to exist needs to be
> changed, even if the individual maintainer thinks SELinux isn't useful.

As there are *-static and non static packages of executable, e2fsck as
example, i think, it's not very hard to have some other differences,
such as *-x -nox, etc.

As for SELinux and other security stuff, as it was mentioned in lkml,
security requires money (big money). But if users of offtopic system
are using Administrator, as they want to have only Word && solitaire,
and time of half-oses, like Win9X, passed, it's their problems with
security and stuff, like having passwords sticking on the screen.
I'm not admin of server fields, but my opinion f.e. on openssh-server's
default config with "rootlogins: on" is bad, also, i've found that to
have numerous configuration for it is very difficult, due to how
/etc/init.d/ssh is written (my laptop and server are with real IPs,
and to have dummy ssh:22 as good idea, also to have 2-3 dummies around
real one on some other port is very good (as logs say) obscurity ;)

As for execsheild, vDSO address space randomization and stuff like this,
software was buggy long before that features were implemented (famous
bind, sendmail etc.), thus i wouldn't rely strongly on it.

Kind regards.
--
-o--=O`C
 #oo'L O
<___=E M


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

Re: X and non-X packages (Re: Attempts at security)

[Oleg Verych]

> From: Hendrik Sattler
> Newsgroups: gmane.linux.debian.devel.general
> Subject: Re: X and non-X packages (Re: Attempts at security)
> Date: Sun, 4 Feb 2007 18:59:01 +0100

Hallo, Hendrik.

> Am Sonntag 04 Februar 2007 15:36 schrieb Oleg Verych:
>> I'm the one, who don't need X, but emacs21 is linked to some X, even to
>> (ugly) 3d scollbars, that i hate. Thus, i whould say it's a *very* big
>> disadvantage.
>
> emacs21-nox exists
> and that's what I use, too. The X interface is plain ugly and has an 
> incredibly bad usability. Using the terminal interface has the advantage of 
> being the same for remote shell access. It's just about copying a sensible 
> configuration file (I doubt that the terminals that the default is for are 
> still widely used).

Really, it is. Somehow i didn't find it in apt-cache before ;D

> HS
>
>

Thanks !



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

use "Sender:", please (Re: Message header fields)

[Oleg Verych]

> From: Miles Bader
> Newsgroups: gmane.linux.debian.devel.general
> Subject: Re: Message header fields
> Date: Mon, 05 Feb 2007 19:08:09 +0900

> Ben Finney <[EMAIL PROTECTED]> writes:
>> Meanwhile, the message header is about the message *as an email
>> message*, and the From field is supposed to be about the individual
>> who sent the message.
>
> ... unless there's a "Sender:" header, in which case _that's_ the person
> who send the email, and the "From:" header names the "true sender" of
> the message.

Yes, and this is stated on various RFCs on E-Mail and E-News...




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

Purging of unneeded localization (cleaL10n)

[Oleg Verych]

Hallo.

If somebody is interested, here is a complete rewrite of `localepurge'
with small `dpkg-deb' implementation to have this done before
unpacking archive on the file system.

Reading docs in `localepurge's directory dated six years back, i fail
to explain to myself, why this is in so horrible state? It seems, more
power was spent to develop ever worthless deb config files, rather
than tool itself.

Anyway, as in the end of the /usr/share/doc/localepurge/README.debian,
here's an one try to solve l10n problems in the "great package
management system". As per TODO.Debian, if anybody knows better
optimization steps and techniques i've proposed, please let me know.

ftp://flower.upol.cz/cleaL10n.tar.bz2

Thanks.
--
-o--=O`C  info emacs : something
 #oo'L O  info make  : not found
<___=E M  man gcc: not found


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

Re: python, then C++, or C++ from the start?

[Oleg Verych]

>> But I am asking you still: can you think of anything to say against
>> such an approach? Please don't flame languages or anything of that
>> sort. The question is just: is it viable for a C++ coder with
>> a Python proficiency to mockup a new application in Python first?
>
> Planning to write the application twice seems to me to presume more
> time and continued enthusiasm than is perhaps realistic, especially
> since your plans seem fairly ambitious---having to slog through the
> last 10% of the application not once but twice seems masochistic.

Configuration of interfaces (hardware or software) is part of OS setup
and proper operation. And this task must be solved on the principle
basis, rather than jet-another-lang-flame. Once you have all
kernel/network-interfaces (ioctl, sysctl, dhcp clients, etc.)
realizations, why not just to start glue them? It's C/shell (or even
C/SLang) ifs-glue thing, as you've wrote in the wiki page and not C++/python.
IMHO it's far too away from ordinary application programming.

[]
> For that matter, figure out what other perl dependencies there are in
> base, rewrite them all in python so that perl could be dropped from
> base (as a way to bolster your argument) and you'll still probably be
> done before you would writing the app twice.

Somebody suggests to get rid of the bloated mammoth, debian so depends
on, interesting. I want to rewrite some base, that is really needed on
shell :)

> Mike.



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

Re: python, then C++, or C++ from the start?

[Oleg Verych]

On Thu, May 31, 2007 at 08:50:11AM +0200, martin f krafft wrote:
[]
> The methods, which are the actual workers doing the configuring will
> most certainly be implemented in shell.

Then call me !

I like shell PITAs. At least it will start to run everywhere by `/bin/sh'
(dash, busybox, bash, zsh, whatever :)



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

Re: python, then C++, or C++ from the start?

[Oleg Verych]

* From: martin f krafft <[EMAIL PROTECTED]>
* Date: Thu, 31 May 2007 10:37:54 +0200
* Organization: Debian GNU/Linux

> also sprach Oleg Verych <[EMAIL PROTECTED]> [2007.05.31.1013 +0200]:
>> Then call me !
>
> Do you have a POSIX-compatible solution to the problem of setting
> variables inside while loops?
>
> See http://blog.madduck.net/geek/2006.05.29-shell-sucks

,---[ blog entry, Mon, 29 May 2006 ]---
|
|Shell sucks
|
|   Shell programming must be the most depressive waste of time out there,
|   and if only because things sometimes just don't work the way you'd
|   expect from a scripting language.

Yes... And main reason is, IMHO, shell is a kernel syscalls (open, read,
write, pipe, fork, etc.) manipulation tool with some helper
functionality, it's not a programming thing.

|   Take the following simple examples in bash (3):
|for i in 1 2 3; do
|  echo $i
|  exit 1
|done
| echo END
|
|==> 1
|
|echo -e "1\n2\n3" | while read i; do
|  echo $i
|   exit 1
|done
|echo END
|
|==> 1
|==> END
| 
|   WTF? The result of the first -- the whole script exits entirely after
|   the first iteration -- is what I expect. After all, I did not call
|   break, but exit. The result of the second is totally unexpected. I
|   understand that for and while each execute their iterations in a
|   subshell, but why don't these behave in the same way?

I'd say, the *fine* reason can be found after reading pipe(7), pipe(2).
Pipe is so frequently mentioned and used in the UNIX environment by
shells, but programmers with their applications use it fairly seldom. 

(in short: syscall pipe(2) can be used only by two processes, i.e fork)

However as noted in some historical notes ever, it was a time, where
all that wasn't that good. Shell implementations ran loops with
redirected I/O (<,>) in subshells also, while this not require
forking[0]. Now it's OK.

[0] UNIX Power Tools <http://www.unix.org.ua/orelly/unix/upt/ch45_23.htm>

|   The fix here is a || exit $? following the done keyword. Urks!

Obviously, it's an another process. Syntax is wired, but hey, it's the
UNIX power!

|
|   Here's another one: the task is simply to output the number of 1's in
|   the output (yeah, I realise grep -c can do this too):
|cnt=0
|echo -e "2\n1\n3\n1" | while read i; do
|case $i in
|  1) cnt=$((cnt + 1));;
|esac
|  done
|echo $cnt
|
| ==> 0
|
|   The reason? The while subshell receives a copy of the caller
|   environment, so when it updates $cnt, it only updates a copy of the
|   actual variable, leaving the original untouched. Similarly, a variable
|   defined inside the subshell won't be available after the while loop is
|   done.

Aha, you knew that! But it's a kind of confusion. Again, *subshell* is
another process, another process is not necessarily a shell. See also
38.4 in the [0]. Thus same result must be with `` and $().

Funny thing to note is, that this script already bash specific, because
of `echo -e'. Forget it, please, use `printf %b "..."' instead.

|
|   I cannot find a fix that's not bash specific.
|
|   Of course, it works fine when I replace the while loop by a for loop:
|cnt=0
| for i in 2 1 3 1; do
|case $i in
|  1) cnt=$((cnt + 1));;
|esac
|  done
|echo $cnt
|
|==> 2
|
|   Great, isn't it?
|
|   And I am not surprised that zsh gets it right. Why would anyone
|   actually want to use bash?

Maybe zsh is a shell for programmers ;)

==[self, about programmers] I developed one simple way of being useful
for any kind of Linux development, while i had wonderful academia time.

Become a User (not user or luser) of your system first, before you start
to develop and code anything. Unfortunately big and expensive UNIX setups
were not so widely available, and many of use came back there only after
M$ brainwashing, dot com bubbles, HTML, Javascript XML and such
$(

Re: python, then C++, or C++ from the start?

[Oleg Verych]

> On 2007-05-31 08:13, Oleg Verych wrote:
>> I like shell PITAs. At least it will start to run everywhere by
>> `/bin/sh' (dash, busybox, bash, zsh, whatever :)
>
> How do you implement control sockets or listen on the netlink socket
> with shell? Do you want to tail 'ip monitor'? Even if, how do you do
> control sockets which don't block?

I'm not one, who wrote http server in bash or Postscript anyway ;)

Seriously. With meaningful wrappers netlink sockets can be handled.
I'm not sure what control sockets are, any why non blocking is a
problem if I/O is line-oriented (mainly).

Moreover, i didn't know `ip' was upgraded to `monitor' functionality!



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

Re: checklib

[Oleg Verych]

* From: Manoj Srivastava
* Date: Wed, 30 May 2007 12:04:01 -0500
* Organization: The Debian Project

[]
>  (I tend not to optimize before determining whether it is needed).

Even trailing whitespace your editor tend not to remove, before X
time ;)

[]
> If someone wants to port my simple shell scripts into gobs
>  and gobs of python; they can get it from ./debian/common/checklibs
>  files in any of my packages; and they can browse on arch.debian.org for
>  easy access.

I've got it from your kernel-package. And want to `release early' my
non working version, mainly due to finding bugs in the binutils's
readelf and comparing it to elfutils'.

Before that, let me publish testcase for surely buggy `readelf':

,---[tst-readelf.sh]
cd /tmp/
exec 2>/dev/null
e=bin.elfs
o=bin.objs

elf() {
readelf -sDW -- $* | sed -n -e '
/LOCAL/d;/UND/{ s_\([^ \t]*\)$_|\1_;s_[^|]*|__;p;}'
}

elf /bin/* | sort -u >$e

objdump -T -- /bin/* | sed -n -e '
/*UND*/{ s_\([^ \t]*\)$_|\1_;s_[^|]*|__;p;}' | sort -u >$o

__diff() {
>$1 diff -u $e $o
ls -l $1
}

__diff elfs_obj.diff # i have non zero diff here and zero one below

echo note size, but [press enter] ; read f

for i in /bin/*
do elf $i
done | sort -u >bin.elfs

__diff 0

echo so, readelf is buggy "?;)"
---'

ftp://flower.upol.cz/checklibs...

here it is anyway.

Notes about original:
- `basename' doesn't work,
- unlink early, rather than that "trap" bloat,
- "progname" isn't used anyway,
- awk, perl overkill, (there could be `python' easyly ;)
- `objdump' can handle one file at time (and not buggy).
+ i would suggest $PATH compatible EXTRA_ syntax

Anyway it works! My is not yet ;)

Reading this thread, i just don't know what to implement (thus how).
If somebody can summarize, i can more forward a bit faster.



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

shell and sed vs awk perl and python (Re: checklib ;)

[Oleg Verych]

* From: Manoj Srivastava
* Date: Fri, 01 Jun 2007 16:24:20 -0500

> On Fri, 1 Jun 2007 20:53:10 + (UTC), Oleg Verych
><[EMAIL PROTECTED]> said:  
>
>> Notes about original:
>> - `basename' doesn't work,
>
> Why? It seems to work perfectly fine here.
> __> basename 
> /usr/local/src/arch/packages--debian/kernel-package/kernel-package/debian/common/checklibs
> checklibs

[EMAIL PROTECTED]:/tmp/ck$ bash ./checklibs
checklibs"
[EMAIL PROTECTED]:/tmp/ck$ sh ./checklibs
checklibs"
[EMAIL PROTECTED]:/tmp/ck$ sh ./checklibs...
checklibs...
[EMAIL PROTECTED]:/tmp/ck$ bash ./checklibs...
checklibs...
[EMAIL PROTECTED]:/tmp/ck$

# I use
APPNAME="${0##*/}"
echo $APPNAME

>
>> - unlink early, rather than that "trap" bloat,
>
> You do not seem to understand what trap does.  I unlink temp
>  files the moment I am done with them.  Traps are set to handle
>  exceptions, and to clean up when those occur.

# In this case i meant something like this
#
O=/tmp/chklib_libs_dyn_symbols.sh
echo "# generated by $APPNAME" >$O
exec 4<$O 5>>$O # redirect and unlink early
rm $O; I=4; O=5

# descriptors sometimes aren't flexible, nevertheless this is one of
# the solutions for concurrency, races and unconditional killing

> Please read up on signal handling; your remark seems to indicate
>  you don't know what it is all about.

Ok ;)

>> - "progname" isn't used anyway,
>
> Right. It is standard boilerplate for my scripts; I usually use
>  it in diagnostic messages; of which none seemed to have survived into
>  production. 
>
>> - awk, perl overkill, (there could be `python' easyly ;)
>
> awk and Perl are essential packages; python would mean a
>  dependency.  I also don''t like python, so I am unlikely to add python
>  code to my build system.

Well, at least awk-style field access in the shell you can do like that:

field() {
# $1 field #
# $2 data
#
shift $1 ; echo $1
}

foo=`field 3 $bar`

>> - `objdump' can handle one file at time (and not buggy).
>
> I don't understand that comment.
> ,[  Manual page objdump(1) ]
>| SYNOPSIS
>|objdump [-a|--archive-headers] <>  objfile...
>| DESCRIPTION
>|objdump  displays  information  about  one  or  more object files. 
> `

`readelf' failed, this one is working -- no problem.

But i meant, that to get need libraries and undefined symbols from (not)
one file(s), one run of `objdump' is needed:

2>/dev/null objdump -T --private-headers -- * | sed -n -e '
# Matching needed libraries:
#,-
#|Dynamic Section:
#|NEEDED  libc.so.6
#`-
# Making output like (for further parsing, thus making unique names):
#,-
#|L=$L" libc.so.6";
#`-
/NEEDED/{
s_^[^lib]*\([^.]*\)\(.*\)$_L=$L" \1\2";_;
p;
};

# Matching needed dynamic symbols:
#,-
#|DYNAMIC SYMBOL TABLE:
#|000  DF *UND* 0148  GLIBC_2.2.5 __libc_start_main
#|...
#|000  w   D  *UND*   __gmon_start__
#`-
# Output is:
#,-
#|S=$S" __libc_start_main";
#|S=$S" __gmon_start__";
#`-
/\*UND\*/{   # prefix symbol with "||", add script
s_\([^\t ]*\)$_||S=$S" \1";_
s_[^|]*||__; # remove all up-to and marker
p;
};'

>> + i would suggest $PATH compatible EXTRA_ syntax
>
> I don't understand this comment either.

The way `EXTRA_LIBRARY_PATHS' variable is assignd, isn't it bad idea
to have compatible PATH assigments?

CHLPATH=/lib:/usr/lib:$EXTRA_LIBRARY_PATHS:
CHLPATH=`echo $CHLPATH | sed -e 's_/*:_:_g;s_:_ _g;s_/$__'`
# bad path test case: `echo /lib//:::/usr/lib///:/jj/kk/`

Anyway thanks for your feedback, i've placed chunks of the script here
for reference.




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

checklib... (Re: checklib)

[Oleg Verych]

On Fri, Jun 01, 2007 at 04:24:20PM -0500, Manoj Srivastava wrote:
[]
> > - `objdump' can handle one file at time (and not buggy).
> 
> I don't understand that comment.
> ,[  Manual page objdump(1) ]
> | SYNOPSIS
> |objdump [-a|--archive-headers] <>  objfile...
> | DESCRIPTION
> |objdump  displays  information  about  one  or  more object files. 
> `
 
That also means, that test case for `readelf' in prev. message wasn't
read. Anyway.

"checklibs..."[0] is a script (sh + sed) to find redundant linked
libraries. As example, here's output for "/bin/*":

,-*-
|[EMAIL PROTECTED]:/bin$ time /tmp/ck/checklibs... 2>/tmp/chl_stderr.log
|[/lib/libnsl.so.1]  ? [./cpio ./ksh ./mt ./mt-gnu ./rzsh ./zsh 
./zsh4 ]
|[/lib/libresolv.so.2]   ? [./ip ./ping ./ping6 ]
|[/lib/libcfont.so.0]? [./loadkeys ]
|[/lib/libuuid.so.1] ? [./mount ./umount ]
|
|real0m1.043s
|user0m0.920s
|sys 0m0.144s
|[EMAIL PROTECTED]:/bin$
`-*-

I don't know about false positives, but if you are linking for more fun,
there's more ;)

Results are quite interesting and are subject to testing. Xchat and
XMMS plugins is easy way to start.

Hope, this script will be useful and *interesting*.

[0] 

I was very excited about to implement something as interesting as this
one. My last message with flame-like subject was just a need to reply,
while nothing was ready. But unlike "cleaL10n", "checklibs..." wasn't
downloaded for sport interest. Funny, that i've spent all time for
latter, while started from former. Sorry, for bugs, i'll fix them soon.
While being at "checklibs..." i've found *features* in dash, busybox's
sed (fixed upstream, not in sid), readelf (sid). Also, statement about
prominent bug in the BaSH (#1 in the man page) regarding speed was
conformed. It's 2-3 times slower, than dash.



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

Re: Dependencies on shared libs, take 2

[Oleg Verych]

* From: Steve Langasek
* Date: Tue, 5 Jun 2007 02:56:14 -0700
>
> On Tue, Jun 05, 2007 at 08:56:40AM +0200, Raphael Hertzog wrote:
>> On Mon, 04 Jun 2007, Steve Langasek wrote:
[]
>> > Considering the number of bugs I see because of maintainers who don't 
>> > notice
>> > they need to change package names due to upstream soname changes, or who
>> > routinely fail to bump their shlibs when new symbols are added, I think
>> > there is definitely room here for a recommended solution for maintainers
>> > that aren't watching the subtleties, even without trying to bump
>> > dependencies based on API extensions.
>
>> Would you care to elaborate? (What would you recommend? How do you expect
>> it to improve the situation with those maintainers?)
>
> Maintaining library symbol files with a tool that updates the symbol lists
> with behavior analogous to dh_makeshlibs -V would be a significant
> improvement over either dh_makeshlibs -V (force a shlibs bump for every
> rev), or dh_makeshlibs alone (get too weak shlibs for any API additions).
>
> Throwing a sensible error at build-time if the soname has changed without a
> package name change is also something that needs to be done, as well as
> throwing an error at build-time if symbols listed in the symbols file have
> gone missing; I don't see these features mentioned in your proposal, but I
> think they're part and parcel of a good implementation of what you're
> describing.

If one will take look in the message with subject "checklibs...", one will
see similar items in the wish list on top of the script. But i don't
know much (yet) about build infrastructure to store information
script already (and can easily) generate.

For colleagues with python implemented ELF parsing, i will suggest to
help either elfutils, or binutils with their TODO lists.



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

Re: Dependencies on shared libs, take 2

[Oleg Verych]

* From: Steve Langasek
* Date: Wed, 6 Jun 2007 03:34:59 -0700
[]
> FWIW, in the prototyping I did in the unixodbc package I made the symbol
> version and the symbol name two separate fields separated by whitespace,
> because this made it easier to generate files of this format with objdump -T
> and a little bit of shell.  Dunno if you consider that a relevant advantage,
> but it does seem unnecessary to me to store the symbol names in a different
> format than that returned by objdump (given that you need objdump, not nm,
> to get the version of any undefined symbols referenced by an object).

Just as better alternative IMHO, please consider using `eu-readelf -ds`
from elfutils.



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

Re: Dependencies on shared libs, take 2

[Oleg Verych]

* From: Julien Cristau
> Newsgroups: gmane.linux.debian.devel.general
>
> On Wed, Jun  6, 2007 at 17:50:26 +0000, Oleg Verych wrote:
>
>> Just as better alternative IMHO, please consider using `eu-readelf -ds`
>> from elfutils.
>
> elfutils isn't build-essential. binutils is, and does the job, so "it's
> better IMHO" isn't a particularly compelling reason to make all packages
> build-depend on a new package.

Well, if that set of utils was started, maitained and debianized, that
means, there are goals as from design, as from usage points of view.
Eventually it can become essential, as gcc folks have nothing to worry
about the linker or libc.



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

Cleanup before install (Re: Purging of unneeded ... (cleaL10n))

[Oleg Verych]

It was good to have ability to make simple dpkg-deb wrapper [0] (for
clean locales script). Moving further, it must be noted, that current way
dpkg uses dpkg-deb isn't optimal for any kind of pre-cleanup, such as:

- removing locales, mans;
- striping scripts (comments: they're already in the source package)
- removing anything else, user may wish to remove from a package
  (files, that are useless may be cleaned on the next update, e.g.
  /usr/share/mc/mc.hint*).

Currently, dpkg is requesting two actions form it, from what i've seen:
- untar control information in directory "/var/lib/dpkg/foo";
- give me unziped data tar via stdio;

Latter is very strange. Why just not to move (mv) tree? What important
i couldn't figure out in current logic?

That tree can be untared and cleaned without taring it again, for sole
purpose of feeding it back to dpkg. Even more optimized way, i see, is to
return to dpkg directory of untared data, it can `mv' itself, thus
eliminating second exec of dpkg-deb at all.

So, what about making such option?

--
[0] at least dpkg-deb wrapper script available here




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

Re: Wanted: introductory page for all teams

[Oleg Verych]

* From: David Nusinow <[EMAIL PROTECTED]>
* Date: Tue, 29 May 2007 20:15:08 -0400
>
> On Tue, May 29, 2007 at 08:00:17PM +0200, Josip Rodin wrote:
>> On Sat, May 26, 2007 at 07:53:30PM -0400, David Nusinow wrote:
>> > The only thing I've ever heard about helping out with the website is that
>> > it's a herculean task that no mere mortal should attempt.
>> 
>> Where did you hear this?
>
> Word of mouth, usually in conjunction with promises that the site would be
> updated to not look like it came from the 90's and no visible improvements
> in that area. I'd heard about meetings at debconf/debcamps to work on this,
> and yet the site still looks almost identical to the way it did when I
> first downloaded Debian back in 1999.

Sure it is, and will be for me.

[]
>> What's next in this fine line of reasoning, I wonder? It doesn't have
>> a MS Windows GUI that my granny thinks is trivial, therefore it sucks?
>
> I don't consider my job in Debian to maintain the website. I consider my
> job to help maintain X. I've taken it upon myself to work on the XSF wiki
> pages because it's useful and important, but it's clearly a secondary
> concern to actually working on the software. Given this, anything that
> makes the job easier and more trivial so I can focus on what I consider to
> be important is a very valid reason.

As lynx user to mutt user, i want to say: "Thank you very much!" ;)

> I think that any tool that lets us do this should be considered. Debian
> isn't in the website creating business, we're in the Free Software
> Distribution creating business. If a tool, like a wiki, makes it
> substantially easier for us to go about that business then yes, I think we
> should use it.

I second this.



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

Re: Why not move Apt to a relational database

[Oleg Verych]

* From: Justin Emmanuel
* Date: Sun, 03 Jun 2007 10:55:01 +0100

Hallo, Justin. Hope, you are still here.

> I am brand new to this mailing list, I joined it because I had an idea
> that I would like to have considered. Moving apt to a relational
> database, for several reasons.
>
> Based on a relational database it will run faster,

First reason is "faster". What if i'll say: based on tmpfs and
directory/file structure it will run even faster?

> also there should be some more data stored about the programs to
> facilitate system restoring.

File size in UNIX systems is limited to two things:

- amount of memory (soft limit)
- arch (hard limit, on AMD64 practically it approaches infinity)

> The data should be backed up automatically and regularly,

Periodic job:

(lock-db) && (tar c -C /var/cache/db-tmpfs -f /var/backup/db.$$ .) \
&& (unlock-db) || echo error | mail -s '[db] backup daemon' root

> so that if the database is stored on another computer and first
> computer has a hardware failure, the data from the backup can be used
> to completely restore the computer to its status again.

clients on failed machine: scp, curl, lftp, whatever to transfer a file

> It should be a relational database that contains checksums of the
> compressed and uncompressed state of files that will be installed. So
> that if there is a problem with the computer and something is
> segfaulting, every file on the computer can be checked against this
> information, including freshly downloaded files, so that they can find
> out if any of them are corrupt and need to be replaced. Then apt can
> automatically download the file. I have had to numerous times manually
> edit the text database that apt writes to because something had been
> changed to "." when it should have been ">". In a good relational
> database, the version numbers can be kept separately from the rest of
> the data, this will all go to help avoid corruption and lead to
> scalability both for individual machines and networked enterprise
> machines. The data at every level can be split into different tables
> using normalisation, increasing the speed of the reading and making
> sure that only the files that need to be parsed get parsed.

Can't see more reasons here, only new features.
Problem: is it possible without RDB, with scheme, i've proposed?

> So what do you think? Is this the correct mailing list to send this idea
> to?

I think, we must take FREE version of DB2 Express and take control of
our XML

(composed from sf.net's ads in mailing lists ;)

As i'm new here also, just expressing my stupid (Linux specific)
contr-``idea''.



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

tmpfs (Re: Why not move Apt to a relational database)

[Oleg Verych]

On 2007-06-09, Bastian Blank <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 09, 2007 at 02:52:04AM +0000, Oleg Verych wrote:
>> > Based on a relational database it will run faster,
>> First reason is "faster". What if i'll say: based on tmpfs and
>> directory/file structure it will run even faster?
>
> tmpfs is not faster than a real disk. You need the memory anyway and the
> data on a real disk should be in the cache anyway if possible.

First startup is. But after that, tmpfs will go to swap and unless
swap is as fragmented as hdd, and not all parts of db will be needed
immediately, next startup will be far more faster. Even if swap
version will be not plausible, "untar" can run with "apt-get update",
"apt-get upgrade" (sometimes very slow) *downloads* in _parallel_, thus
db will be ready and in memory, before it will start to further
package processing.

>> > so that if the database is stored on another computer and first
>> > computer has a hardware failure, the data from the backup can be used
>> > to completely restore the computer to its status again.
>> clients on failed machine: scp, curl, lftp, whatever to transfer a file
>
> Most db formats are not transfer formats and are incompatible between
> different versions and architectures. You need to dump them for such
> sort of backup.

I've described tar (ar, cpio,etc.) file as storage, i doubt if it has
version/arch problems.






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

Re: Bourne shell assistance needed for Bug #422909

[Oleg Verych]

* From: Roger Leigh
* Date: Wed, 09 May 2007 22:48:49 +0100
>
> Hi folks,

Hallo.

> # Unmount all filesystem under specified location
> # $1: mount base location
> do_umount_all()
> {
> "$LIBEXEC_DIR/schroot-listmounts" -m "$1" |
> while read mountloc; do
>   if [ "$AUTH_VERBOSITY" = "verbose" ]; then
>   echo "Unmounting $mountloc"
>   fi
>   umount "$mountloc" || exit 1
> done || exit 1
> }
>
> The problem here is that if schroot-listmounts segfaults (the trigger
> in this case) or returns an error,

Two things.

1) Note, that `while' runs in the sub-shell (make sure to understand this)
2) Pipe is cause of wrong assumption. Little stick -- huge impact.

Thus, here it is:

USENET FAQ:


   Here Bourne shell version is most convenient, don't try to
   use/understand POSIX shell version ;)

UNIX Power Tools (47.2.1.4 More Elaborate Combinations)
http://unix.org.ua/orelly/unix/upt/ch47_02.htm

   Compare that to historical perspective.

Thus, without bashizms yet!

--
-o--=O`C
 #oo'L O
<___=E M


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

The Shell: arithmetic comparison with void

[Oleg Verych]

If was time, where string comparisons with void were ... with features.

|-*-
if [ "x$a" = 'x|' ]; then
|-*-

Yet arithmetic ones are still with them:

|-*-   
[EMAIL PROTECTED]:/tmp$ bash -c "test '' -eq 0 ; echo \$?"
bash: line 0: test: : integer expression expected
2
[EMAIL PROTECTED]:/tmp$ dash -c "test '' -eq 0 ; echo \$?"
0
[EMAIL PROTECTED]:/tmp$ busybox sh -c "test '' -eq 0 ; echo \$?"
0
[EMAIL PROTECTED]:/tmp$
|-*-

Ah, bash is clever?

|-*-
[EMAIL PROTECTED]:/tmp$ bash -c -v "test \"printf '\t'\" -eq 0 ; echo \$?"
test "  " -eq 0 ; echo $?
0
[EMAIL PROTECTED]:/tmp$ bash -c -v "test \"printf ' '\" -eq 0 ; echo \$?"
test " " -eq 0 ; echo $?
0
[EMAIL PROTECTED]:/tmp$ bash -c -v "test \"printf 'a'\" -eq 0 ; echo \$?"
test "a" -eq 0 ; echo $?
bash: line 0: test: a: integer expression expected
2
[EMAIL PROTECTED]:/tmp$
|-*-

Nope?

Are there bugs or features?



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

(glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

[Oleg Verych]

* From: Russ Allbery
* Date: Sun, 24 Jun 2007 22:36:21 -0700
* Organization: The Eyrie
>
> Bernd Zeimetz <[EMAIL PROTECTED]> writes:
[]
>
>> there're also the google perftools[1], which are suppsed to work very
>> well and we have libgoogle-perftools in Debian.
>
> Hoard is noticably better for OpenLDAP's load profile than Google
> perftools (although both of them annihilate the glibc allocator).
>
>> [2] is very interesting to read in this case.  I'd be really interested
>> to know why one of those implementations is not the default in glibc,
>> and if hoard or perftools provides the better/faster malloc.
>
>> [1] http://sourceforge.net/projects/goog-perftools/
>> [2] http://bugs.mysql.com/bug.php?id=27063
>
> Well, I don't know if this is a full explanation,

Message-ID: <[EMAIL PROTECTED]>
WWW:



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

coreutils: long stall

[Oleg Verych]

At least experimental package must be updated.

Is it maintainer's problem or it's a normal situation?



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

long arithmetics in dash, dash fix 4`The Shell: arithmetic comparison with void'

[Oleg Verych]

* Date: Mon, 11 Jun 2007 14:24:24 + (UTC)

> Yet arithmetic ones are still with them:
>
>|-*-  
> [EMAIL PROTECTED]:/tmp$ bash -c "test '' -eq 0 ; echo \$?"
> bash: line 0: test: : integer expression expected
> 2
> [EMAIL PROTECTED]:/tmp$ dash -c "test '' -eq 0 ; echo \$?"
> 0
> [EMAIL PROTECTED]:/tmp$ busybox sh -c "test '' -eq 0 ; echo \$?"
> 0
> [EMAIL PROTECTED]:/tmp$
>|-*-

Proposed fixing in the dash: #431320

Maybe somebody interested in making dash use "long int", thus enabling
wider range on 64bit platforms, while still having same on 32bit ones?

Patch for test built-in is ready, now i'm thinking about arithmetics.
Long int is used internally, but then casted to int, that's why
changes are very small indeed.



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

long arithmetics in dash, dash fix 4`The Shell: arithmetic comparison with void'

[Oleg Verych]

* Date: Mon, 11 Jun 2007 14:24:24 + (UTC)

> Yet arithmetic ones are still with them:
>
>|-*-  
> [EMAIL PROTECTED]:/tmp$ bash -c "test '' -eq 0 ; echo \$?"
> bash: line 0: test: : integer expression expected
> 2
> [EMAIL PROTECTED]:/tmp$ dash -c "test '' -eq 0 ; echo \$?"
> 0
> [EMAIL PROTECTED]:/tmp$ busybox sh -c "test '' -eq 0 ; echo \$?"
> 0
> [EMAIL PROTECTED]:/tmp$
>|-*-

Proposed fixing in the dash: #431320

Maybe somebody interested in making dash use "long int", thus enabling
wider range on 64bit platforms, while still having same on 32bit ones?

Patch for test built-in is ready, now i'm thinking about arithmetics.
Long int is used internally, but then casted to int, that's why
changes are very small indeed.



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

upstart (Re: Bug#417118: ntpdate: Start sequence problem for some network setups)

[Oleg Verych]

* Hamish Moffatt (Thu, 5 Jul 2007 17:28:20 +1000)

> On Thu, Jul 05, 2007 at 02:26:43AM +0200, Marco d'Itri wrote:
>> On Jul 05, Brian May <[EMAIL PROTECTED]> wrote:
>> 
>> > Marco> Hope that some day we will switch to upstart.
>> > Ok, so when do we switch to upstart?
>> Probably at the same time when we will switch from exim to postfix.
>
> That's just religion without technical basis.

Unless i will see any kind of implemented proposal, i.e. tar or deb
that i can use/test on base installation, it's a *technical* problem.




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

Re: long arithmetics in dash, dash fix 4`The Shell: arithmetic comparison with void'

[Oleg Verych]

* me (Sun, 1 Jul 2007 20:22:21 +0200)
>
> Maybe somebody interested in making dash use "long int", thus enabling
> wider range on 64bit platforms, while still having same on 32bit ones?

#329025 has a link to the standard, that states:

   Precision and Operations , with the following exceptions:
* Only signed long integer arithmetic is required.
 
> Patch for test built-in is ready, now i'm thinking about arithmetics.
> Long int is used internally, but then casted to int, that's why
> changes are very small indeed.

Is it going to be required really? I've contacted upstream with such
question among others (in the way maintainer of dash does) some days ago
but still have no answer.

> 



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

Re: upstart (Re: Bug#417118: ntpdate: Start sequence problem for some network setups)

[Oleg Verych]

* martin f krafft (Fri, 6 Jul 2007 07:57:57 +0200)
>
> also sprach Oleg Verych <[EMAIL PROTECTED]> [2007.07.05.1957 +0200]:
>> Unless i will see any kind of implemented proposal, i.e. tar or deb
>> that i can use/test on base installation, it's a *technical* problem.
>
> So why don't you use your time to help solve the problem

In fact i do use my time now to solve problems. One of those is an
alternative to "dpkg filters", after one or two days to be released to
you here. Another, as you night notice in this ML, is bug shooting in
`dash'.

> instead of harping= on mailing lists?

Oops, i thought message, i was replying to, is one of those. That's why
i did reply in such way actually.

Either way, i don't care.



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

Re: Looking for new FTP assistants

[Oleg Verych]

> Date: Tue, 10 Jul 2007 12:40:27 +0200

> Maybe is it time to adopt some required tags in the mail subjects to filter
> spamming activities? Something already adopted for the RT system indeed.

I also am thinking about something new in anti-spam case.

While i'm newbie, let me express the idea.
Doing bcc to watch dogs, where those are

  separate for mailing lists, bts, whatever else; with special syntax
  of the address (or addresses) in the bcc field, because only they appear
  in a message's envelope-to header

This require some work from sender's side, how is using plain MUA<->ML
interaction. For things like Gmane or reportbug anti-spam rules are
customizable and known at least.

Subject is a content-describing thing, thus is not appropriate for
filtering IMHO. I even wanted to propose to include package/subsystem
name to messages resent to developer's or general (like all bugs) MLs
to have easy way of filtering info i'm not interested.

Finally X-Bug-Title will be also very useful, because i can participate
to topic known to me faster without going to bts via http or other means,
where i can have needed info right here.
--
-o--=O`C
 #oo'L O
<___=E M


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

Re: Looking for new FTP assistants

[Oleg Verych]

> This require some work from sender's side, how is using plain MUA<->ML
> interaction. For things like Gmane or reportbug anti-spam rules are
> customizable and known at least.

While defending against spam is being long enough on user's side [0],
why not to apply this little addition to sender's duty, hm?

[0] The poor user hit by spam in 5 hours after BTS post
<[EMAIL PROTECTED]>



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

Re: Looking for new FTP assistants

[Oleg Verych]

>> This require some work from sender's side, how is using plain MUA<->ML
>> interaction. For things like Gmane or reportbug anti-spam rules are
>> customizable and known at least.
>
> While defending against spam is being long enough on user's side [0],
> why not to apply this little addition to sender's duty, hm?

Another idea is tickets for first message (thread start, opening bug
report {0}) and requirement to have in-reply-to in any other message.
It's already requirement in rfc2822(SHOULD) to have it in replies. What
is ticket, then? When one wants to send message{0}, request is sent to ML
handling service or watch dog (helper service), ack is sent. Then
replying on that message will bring in-reply-to header as a ticket.

Currently some tools (bts) don't make threads in bug report, i.e. do
not include reference on at least last message in bug report, while
producing manipulations. Changing this will have 100% chance to remove
anything non related, unless more intelligent noise maker will appear.



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

Re: Thoughts about the bug tracking system

[Oleg Verych]

20-07-2007,
> When I'm locking at the BTS, I sometimes get the feeling it was either
> designed a long time ago,

Is it good or bad?

> or that it was designed by real hardcore developers. Not that it isn't
> effective, as when you have learned the whole system, you can query it
> pretty fast, but the threshold is pretty steep.

Is it good or bad?

(Try to explain why, using more concrete language, please.)

> I don't know

Than can be ... all you should say.

> if there has been any discussions about some redesign of the system, to
> make it a bit more user friendly, but perhaps it's time to do
> something? (or perhaps you only want "real" bug reports from "real"
> developers, and pass "users" to ubuntu or similar? :)).

(If you don't know, doing something can have nothing in result.)

> The major problem with the current system, is that it requires that
> the reporter has access to a mail server, if they want to use the more
> easier variant by using reportbug script. their other alternative is
> to send an email from their webmail (I assume that they don't have
> access to an smtp server, and are prohibited to use one by them self
> by port 25 blocking) using a complicated syntax to be able to send
> "correct" reports.
>
> Perhaps I'm out on deep water here, but just wanted to give a thought.
> perhaps a web-based solution (with backward compabillity to current
> system) would be the most optimal solution?

You were brain washed, weren't you? The enterprise Visual AJAX WEB 2.0
written in Java(R) using XML technology, is what will save users?

My opinion is not, not at all! Let me explain it from my experience.

First of all i reject any web:HTML,XML means of operation/visual
representation.

* one-WWW-browser support on the planet
* HTMLize, XMLize, Java/VB Scriptize it all
* CSS, CSS2, DOM, other W3C

technical crap is legacy of the pre dot coms era, and this bound to die.
The Flash plug-in is fscking all that crap for Windows(R) WEB users
some years now. Well, any point-click user-friendly software is a crap.
Mixing high technology with high profits from stupid luzers, that what
it is.

OTOH any professional CAD tools are tools for professionals, any means
are allowed, as long as there are money.

The operating system development, and then making software distribution
based on it -- is completely another story. Have you being official
Windows(R) beta tester for example? Can i be one?

Not going too far from the subject -- Bugzilla, tool every user knows,
every developer hates. Just philosophical description, technical problems
you can find in mail archives of most heavy projects (e.g. Linux kernel,
glibc). 

It was created for one particular project by one particular designer
(company). Project was (is) -- the web browser. Guess, what can be
designed by web browser producing company? My answer -- very inflexible,
inefficient but turned to be very famous tool.

> p.s. if this is wrong list, please shoot me...

So, please, don't just talk. Try to make something above average
first. Then try to support it for some time, then go back to your
questions, and know wise answers.

--
-o--=O`C
 #oo'L O
<___=E M


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

Re: Thoughts about the bug tracking system

[Oleg Verych]

>> > p.s. if this is wrong list, please shoot me...
>>=20
>> So, please, don't just talk. Try to make something above average
>> first. Then try to support it for some time, then go back to your
>> questions, and know wise answers.
>
>   Not only you are very harsh and aggressive, but there is definitely
> ways to improve the BTS, and e.g. _also_ allow web forms. (not
> exclusively).

Sure. I would like to and will try to.

>   And if I agree with you on the fact that bugzilla is a huge pile of
> crap, 

(btw i'm amazed by your bts <-> bugzilla bridge :)

> the rest of your mail is OT, and the way you wrote it show you totally
> lack any kind of social skills. Please take your bad mood elsewhere.

Sorry for that. While i didn't "shoot", as it was proposed, i tried to
make some social statements, because that wasn't a reply to technical
stuff.

> --=20
>=C2=B7O=C2=B7  Pierre Habouzit
>=C2=B7=C2=B7O[EMAIL PROTECTED]
> n.org
> OOOhttp://www.madism.org



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

Re: Thoughts about the bug tracking system

[Oleg Verych]

>> [incensed ranting on the topic of web applications]
>
> Oleg, your response doesn't seem to be in response to the message you
> quoted.

A reply to off topic message to the development list. Insulting -- yes. Why?

In dry lanuage:

"post your thoughts in your weblog, come here with patches"

That's a linux-ish style of reaction i've learned from LKML. I think it's
right here also. Such questions while not pure user's for answer,
are more appropriate to debbugs list. Even lack of this shows small or
nearly no homework before posting.

> Instead, you invent a position about complex web technologies and
> attack that.

Well, just words, style of the `quoted message', so to speak.

> Worse, you imply that the person you're replying to holds that position
> because of brainwashing.

I'm sorry if my humor is not funny.

> Please either address the points raised by the message you're replying
> to, or don't.

IMHO that message was a hand waving not deserving reading. Thus i
dissagre, that i didn't addressed its points in my reply.



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

Re: Thoughts about the bug tracking system

[Oleg Verych]

* Don Armstrong

> On Sat, 21 Jul 2007, Oleg Verych wrote:
>> "post your thoughts in your weblog, come here with patches"
>
> This is a list which is used to discuss development related issues.
> The ability of users to report and discover bugs which affect them is
> inextricably linked to development.

Fine, if `thoughts' are `issues'.

> As one of the developers of debbugs, I want to encourage discussion of
> how things can be done better, even from those who aren't in a
> position of having supported their ideas with patches.
>
> I mean, it'd be rather boring holding this discussion otherwise.

IMHO that comes from inflexibility of web based archives at first place,
general ignorance WRT mailing lists as from its purpose as from tools
misusing points of view.

As of our late night conversation you may know my approach to
ML information handling, i.e. Gmane + comprehensive new reader (slrn). 

Some issues with breaking threads in pkg specific MLs and absence of pkg
name in the subject in some messages in -dist MLs, i've tried to address,
are just very beginning of what can be improved in debbugs, among other
things, i try to make working proposal before publishing. And if my
recent (less than 24h) similar reply about URLs in the message bodies was
read in debbugs list, this thread would not be existed.

-*- To the thread:

My anger (50% of the original reply) actually caused by general state of
software industry. I think time has came, where quantity (of user
reports, bug reports, feature requests, number of applications) should
finally turn into efficiency. Yet nothing happens and i in Y2006 after
year of using Sarge on my amd64 with all that fancy X, Mozilla stuff,
have to threw everything away and now nearly for almost year sit in text
terminal with small set of tools like, screen, lynx, slrn, mutt,
emacs-nox. I sick of ever increasing userspace sucking. After seeing how
linux core kernel developers are care for single cache miss, bunch of
byte saved, cpu cycle, i just break down from slowness and stupidness of
X, Mozilla and such.


Finally. I've got a message about being disliked here in list. Guys, my
opinion is, that doing this in private is unfair. If i'm out of order,
tell me in the follow up. I'll go away, i have nothing to loose in this
live, really.

p.s. `for.gmane' account will bounce your messages on SMTP time, because
i don't care about receiving and deleting stuff i easily can read in
ML. I care about network bandwidth, efficiency and other rather
unusual things. I reply to messages being with Cc or mail-followup-to
with regular account. That's my strong policy on `i read MF list'.

Thanks for reading and understanding.



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

Re: Thoughts about the bug tracking system

[Oleg Verych]

* 21-07-2007, Steve Langasek

> The scripts in /usr/share/bug/ are *created by the package maintainers to
> collect information they believe should be present in bug reports about
> their packages*.  Asserting that maintainers "have the option" to ask for
> more info is just stupid; the whole point of having
> /usr/share/bug/$package/script is to save a round trip with the submitter,
> and to save the submitter (who may not be very adept at all) the trouble of
> figuring out how to capture this information to a mail by hand.

That's funny. It is in my TODO list to add dropping tainted(P) reports for
linux-image, after i saw many "tainted -- not supported here". Before that
i'm trying to develop skills i need to do so in the right way. I've
accidently found /u/s/bug while doing current project. I've mentioned
this among other advantages former and current Debian members have
developed WRT bugs, while expressing opinion on how linux kernel
currently (mis)dealing with this.

It seem there some more for current leader to do on social ground. Are
there more deep disagreements hidden somewhere in the BTS, hm?



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

Re: Thoughts about the bug tracking system

[Oleg Verych]

21-07-2007, Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> пишет:
> --=-=-=
>
> Oleg Verych <[EMAIL PROTECTED]> writes:
>>> Please either address the points raised by the message you're replying
>>> to, or don't.
>> IMHO that message was a hand waving not deserving reading. Thus i
>> dissagre, that i didn't addressed its points in my reply.
>
> If you feel there were no points raised you need to comment on, just
> don't send mail in the future. Thanks.

Points that i've shamelessly added there are what i was thinking about
for a while. Eventually it came in. I really would like to have technical
start for any thread here. But it seems users reflect some DDs nowdays
(no offense)...

As about replying, i will better be red quiet about (:

Message-ID: <[EMAIL PROTECTED]>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)



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

Re: Cleanup before install (Re: Purging of unneeded ...)

[Oleg Verych]

Hallo.

Finally i've came up with a new solution, shared in dpkg-general [0].
It's only for those, who cares about having less bloated (yet functional)
rootfs. More ideas (and probably testing) is welcome.

[0] 

Thanks.



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

Re: Google SoC 2007- KernelConfigProposal

[Oleg Verych]

* Amit Kumar Saha:

> Hi all,
>
> Has anyone started working on the "Kernel Config" Google SoC 2007
> proposal listed at
> http://wiki.debian.org/SummerOfCode2007/KernelConfigProposal?

There was some activity in debian-kernel, though i didn't follow that
list for summer.

Here are links on information i know:

<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>

> I would like to have some updates on that as I am interested to work
> on this particular project.
>
> I am really not sure if this is the correct list to ask this. But if
> any one here has any idea about the project, please let me know.

Do something, call for testing. This way you can get anything from busy
developers/maintainers.



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

Re: Cleanup before install (Re: Purging of unneeded ...)

[Oleg Verych]

> The alternative approach is to modify the packages themselves, rather
> than remove files after installation. See Emdebian:
> http://www.emdebian.org/

Well, after download, before installation and using general purpose
archive.

> http://lists.debian.org/debian-embedded/2007/05/msg00025.html
> http://lists.debian.org/debian-embedded/2007/05/msg00031.html
>
> (Note that Emdebian does not retain perl in the rootfs.)

How that can be, without perl? I don't like perl, but it's a must for
Debian.

Also i don't want to have small or minimal rootfs, i want less bloated
one. That means, i have all freedoms to do things i like and OS needs,
yet without static info, that is just re-added on every update.

It would be nice if everybody will collect, sort and order things, that
are to be needed for laptop Foo/power user/user etc. Publishing such
configs will let people have light setups easily.

>> [0] 
>
> Same link:
> http://lists.debian.org/debian-dpkg/2007/07/msg00038.html

Technical stuff does there. (I have message-id on my side and no web
browser, thus i writing such links, where my posting suppose to be).



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

Re: Cleanup before install (Re: Purging of unneeded ...)

[Oleg Verych]

* Neil Williams:
>
> On Tue, 31 Jul 2007 09:08:10 + (UTC)
> Oleg Verych <[EMAIL PROTECTED]> wrote:

>> How that can be, without perl? I don't like perl, but it's a must for
>> Debian.
>
> It ain't necessarily so.
> ;-)
>
> Embedded devices don't need perl or ruby or python or 

Yea, devices don't, software packages do...

> By cross-building the packages for our own repository, we can (and do)
> change the dependency chain to remove things that embedded devices do
> not need, including removing perl from "Essential".

Well, with "pkg perl-base; keep 'really' nothing;" string in config file
you will have empty package installed, but what you say does not solve
problems like this:

- exim4 and cron {1} have dependency on adduser
- adduser is 48k of "unreadable perl mess" and is a wrapper around
  useradd from passwd
- it is used only in postinst scripts to create (once) users/groups
  needed

So, as you can see, on any system where this packages{1} were installed or
one with /etc/passwd set up by user from its backups or by admin
(after fresh install), this 'adduser' content is useless, while
dependency may stay.

>> Also i don't want to have small or minimal rootfs, i want less bloated
>> one. That means, i have all freedoms to do things i like and OS needs,
>> yet without static info, that is just re-added on every update.
>
> As far as /usr/share/locale is concerned, we have similar needs.
> Embedded devices also don't want 250Mb of LC_MESSAGES files where 90%
> are for unsupported locales.
>
> This was an issue at DebConf7 and one solution is dpkg filtering. This
> allows admins to tell dpkg simply not to install certain files. This
> should be able to replace your script with the benefit that you need
> less temporary space to install the packages themselves.

I did it via wrapping dpkg-deb

- it processes deb file only once, thus saving processing time
- resulting tar is saved temporarily between config/content execution
  of the dpkg-deb, but this is small tradeoff one must pay; with tmpfs
  it's lightweight; linux-image savings are more than 50M and this
  would be transfered via pipe to dpkg's secretary with obviously more
  power burned and time consumed.

> I'm not sure if the dpkg maintainers have included this feature yet.

If sh(dash) + sed(GNU)[0] is worse, than C mess in dpkg and obviously
more human-hours needed, then i don't care.

[0] note, debian's not updated busybox's sed currently broken

>> It would be nice if everybody will collect, sort and order things,
>> that are to be needed for laptop Foo/power user/user etc. Publishing
>> such configs will let people have light setups easily.
>
> Use the debian wiki.

I need a feedback from DDs first, because if dpkg solution is being
waited with such hope, then geloiwa is useless.



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

Re: Cleanup before install (Re: Purging of unneeded ...)

[Oleg Verych]

* Neil Williams:

>> Yea, devices don't, software packages do...
>
> Nah, we get around that too.
>
> (cdebconf for one)

I must take a look, thanks. Current debconf (depends on perl, not only
perl-base, sigh) is ..., you know.

> Then use busybox to replace adduser.

Tell it to package maintainers, please; i did my small and flexible
solution for that. Flexible, because if i need something from the
package, i just run update with another PATH (without wrapper being in
the first turn).

>> So, as you can see, on any system where this packages{1} were
>> installed or one with /etc/passwd set up by user from its backups or
>> by admin (after fresh install), this 'adduser' content is useless,
>> while dependency may stay.
>
> Nah. Trust me, perl is not needed for any software to be used in
> Emdebian.

That's cool!

> It is vital to Emdebian that perl is removed from 'essential' for
> embedded devices. It's part of rebuilding the dependency chain - you
> can't do that easily with dpkg wrappers, you need to cross-build.
>
> My iPAQ has no hope of running perl and that is a large device as far
> as Emdebian is concerned so there is no option - perl simply MUST
> disappear.
>
> The irony is that emdebian-tools, apt-cross and dpkg-cross are all
> written in perl.
> ;-)

Then it will not disappear ever, especially when shell scripting have
no support at all. Also, i noted broken busybox already.

>> I need a feedback from DDs first, because if dpkg solution is being
>> waited with such hope, then geloiwa is useless.
>
> I expect dpkg filtering to arrive soon.

I didn't see anything in [EMAIL PROTECTED] Maybe they like to develop
something in dark corners and then bring it to the light? Whatever, i've
shared my ideas and implementation not for embedded things, and that's it.

Thanks.



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

Re: /bin/sh diversions

[Oleg Verych]

* Pierre Habouzit:
>
>> Well, bash is essential, so you have to have that one installed or else y=
> ou
>> have to scan all your packages for uses of bash and convert them.
>
>   Let's make it a release goal !

In my TODO list. The quilt is one of main goals; not only bash->sh but
also awk->no awk. At least i will try.

Now, after i've done my aggressive janitor, it's time to get rid of some
bloat inside scripts also. There's an example[0] of pure size reduction
in tzselect to make it less than 4096 bytes.

[0] ftp://flower.upol.cz/geloiwa/src/usr/local/etc/geloiwa/iwant



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

perl, shell, size of installed packages (Re: Cleanup before install)

[Oleg Verych]

* 31-07-2007, Marc Haber:

> On Tue, 31 Jul 2007 19:09:10 + (UTC), Oleg Verych
>
>>- adduser is 48k of "unreadable perl mess"
>
> As former maintainer of adduser, I take offense here. Adduser has
> improved a lot in readability in the last three years.

This is a funny quote i've get from the `bts' command sources.


* Debian Development List.

Seriously, after reading all that shell and apt threads, i wonder if all
that size thing really matters? Install 4G of Vista++ and be stupidly
happy.

I thought, it's a good thing to have size concerns in the first place.
It's even matter of taste, not only technical problems with
disks/filesystems speed.

In order.

* adduser is the 48k wrapper around passwd (hope you've read that earlier);
  man page says, low level `user*' command should not be used. WTF? To
  remove or add ordinary user _once_ in first installation, i must carry
  this crap all along? Sorry, guys. I'd better try to fix install scripts
  of cron, mutt, exim-daemon-light, openssh-*. I'm sure nothing extra
  ordinary happens there.

* same song in bash's man page: no clear line between its features and
  Bourne Shell requirements. The long standing bug -- size and speed
  has kind place in that man page. And after all that, everybody write
  `#!/bin/sh' and hope it's a good shell scripting, while it turns to
  a very bash specific script, that will run 2-3 times slower.

* apt-get's man page states, that apt-get is the command line tool and
  is a "back-end". If quoted word there is humor, then remove it or
  leave default behavior as is.

Very disappointing things, that can really be offensive. Because you
think it's good an optimized process of being better and better, but
nope. There are agendas (tiding to GNU bash), laziness (try lightweight
useradd/userdel in once-run branch in install scripts first) and other
non technical problems.

I don't know (yet) all policies on how to package, but one thing i see:

there's no way to supply options to install scripts, so admin/user can
just blindly run installation/upgrade.

Debconf is another sort of design/size issues, i have.
--
-o--=O`C
 #oo'L O
<___=E M


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

Re: /bin/sh diversions

[Oleg Verych]

02-08-2007, Peter Samuelson:
>
> [Pierre Habouzit]
>>   the 3 biggest problems I've seen are:
>>=20
>>   * [[ for test, trivial: add it as a test alias, and also check for ]]
>> termination in the test.c builtin.
>
> Ummm, [[ is not the same as [.  (If they were the same, there would
> have been no need to invent [[.)  They behave quite differently with
> regard to argument quoting.  Try this in bash:
>
>   unset foo
>   [ -n $foo ] && echo foo is non-empty
>   [[ -n $foo ]] && echo foo is non-empty
>
> As you can see, only the second one works.

Not quoting possible empty argument is a script writing bug. It's like
dereferencing NULL pointer and must be shot away also. Supporting
buggy scripting by inventing new tools is struggling with consequences
not cause and is a very bad idea.

BTW, i've provided patch in the BTS for dash's test built-in to have
arithmetic checking of an empty argument and zero right. This was nearly
a month ago, yet nothing happened. (Flaming about dash is easy,
maintaining is not :)



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

Re: Installation of Recommends by default on October 1st

[Oleg Verych]

02-08-2007, LoОc Minier:
> On Thu, Aug 02, 2007, Pierre Habouzit wrote:
>>   *WTF* ? I mean why should I have every possible xserver video driver
>
>  You also have all possible kernel drivers built by the kernel image
>  installed; that's quite consistent with "any hardware you plugin will
>  work".  The dep allows to pick one or more drivers if you so wish
>  though.

There was a laptop mentioned, btw: no pci hotplug, infiniband, isdn, scsi
and A lot more.

Problem is solved, if you didn't noticed already.  All that bunch of
modules can be easily removed before installation. My laptop and all
devices i have or suppose to have let me clean up nearly 58M of
linux-image.



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

Re: Installation of Recommends by default on October 1st

[Oleg Verych]

02-08-2007, Mike Hommey:
> On Thu, Aug 02, 2007 at 10:01:22AM +0200, Pierre Habouzit <[EMAIL PROTECTED]> 
> wrote:
>>   PS: I'm very fond of the apache (to be removed) Recommends. really.
>>   especially on a notebook, it helps understanding how broken the
>>   recommends chain is right now.
>
> I don't know for your case, but there are packages in debian that can use
> apache as a file sharing backend. And it's particularly useful on laptops.

_file_ sharing; another web-like crap?

The FTP, despite of not being able to follow symlinks, what is the
problem? That is easily solved by making /home/ftp a symlink to your
big-file storage.

I use pure-ftp for sharing. mc, any-web-browser or lftp are OK as
clients.



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

Re: /bin/sh diversions

[Oleg Verych]

>>   unset foo
>>   [ -n $foo ] && echo foo is non-empty
>>   [[ -n $foo ]] && echo foo is non-empty
>>
>> As you can see, only the second one works.
[]
> BTW, i've provided patch in the BTS for dash's test built-in to have
> arithmetic checking of an empty argument and zero right. This was nearly
> a month ago, yet nothing happened.

Also, let me share a hint for speed-optimized scripting.

`-n' and `-z' test cases are completely bogus w.r.t. speed and bugs
mentioned. I would suggest to use ${#foo} and compare size
arithmetically. Because if $foo is big, you are passing it to another
program, built-in or not, doesn't matter. And ${#foo} is always
non-empty expansion, thus one may omit quoiting.

That's why i have patches for arithmetics and asked this list about
using long (as it stated in POSIX) for better usage on 64bit platforms.

The dash's upstream is on vocation or something similar, because same
question aren't answered also. I would like to contribute more, but
lack of feedback is a bad thing. I wonder how all that SoC actually
goes in this period :-/



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

(size savings +) Re: proposed release goal: DEBIAN/md5sums for all packages

[Oleg Verych]

* Pierre Habouzit
* Date: Fri, 17 Aug 2007 15:22:05 +0200
>
[]
>> Yes, that sounds like a good idea. It might also be interesting to not
>> put those into the control.tar.gz, but directly into the deb, so that it
>> can easily be extracted.
>
>   OTOH that sucks because it would mean that we have to rebuild the
> whole archive that uses currently dh_md5sums, whereas we could just be
> backward compatible.
>

After playing with size reduction, i came up with stripping configs and
regenerating md5sums (if any). Yes, some packages aren't have them,
but after removing much of the stuff all must be regenerated anyway.

# dpkg-deb wrapper for geloiwa:

cd "$WDIR" # here WDIR=WDIR/data
GACONF=`du -s "$CFGDIR"`
md5sum `find . -type f | sort` > "$CFGDIR/md5sums" < /dev/null

cd "$CFGDIR"
cleanup_debconf
cleanup_scripts
GAdtCONF=$((`ff $GACONF` - `ff $(du -s)`))

cd "$WDIR/../"
printf "_ $PKG\t\t$GAdtSTAT+$GAdtCONF\t$GASTAT+$GACONF" >>stats
tar c -C data -f "$DATAFILE" .
# shend

How much size was reduced in each case is stored in shell-syntax
stats file for ease of totals generation.


Another design problem in this dpkg-deb<->dpkg dance is this re-taring of
data for dpkg. After another package database format, hopefully more
faster, this is issue to solve.



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

Re: Considerations for 'xmms' removal from Debian

[Oleg Verych]

* 07-08-2007, Andrei Popescu:
[]
> Did you even try adding a directory? It might even work ;)
>
>> xmms2... Well, when we have a decent client, then can are an option.
>> Now, isn't it.
>
> Same as with mpd :-/

Server is `(mu-)mplayer` (seek isn't working in ogg), client is `dd`,
playlist is small `sh` script: ftp://flower.upol.cz/mu-player/

> Regards,
> Andrei
> --=20
> If you can't explain it simply, you don't understand it well enough.
> (Albert Einstein)

--
  Hard to disagree :)


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

Re: RFC: changes to default password strength checks in pam_unix

[Oleg Verych]

04-09-2007, John Kelly:
> On Sep 3, Lars Wirzenius wrote:
>
>>ti, 2007-09-04 kello 10:17 +0900, Miles Bader kirjoitti:
>
>>> If the system is excessively anal about what passwords it will let you
>>> use, people will just start writing them down...
>
>>That is arguably better than having passwords which can be guessed by
>>doing brute-force attackes over ssh.
>
> I stop brute force attacks by sending auth log messages to a FIFO which I 
> read with a perl script. After 10 login failures, your IP is firewalled for 
> 24 hours.

What about having more secure Debian's sshd_config by default?
"
PermitRootLogin no
DenyUsers   *
"
to start with.

Also i would really love to have sshd rc script being able to load
different configs easily. I have dummy sshd on 22 port and one actual
door on another. Having more dummy services else where, is more "security
by obscurity". Not 100% protection, but something.



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

Re: speed of COW directory copying: XFS 20x slower than ext3

[Oleg Verych]

* Sun, 16 Sep 2007 04:26:05 +0200

> Hi,

Hallo.

> it turned out the problem is in the XFS filesystem, that is 20x slower,
> than the ext3 filesystem. I know that XFS is bad at handling small
> files, but 20x times?

Try to play with parameters mentioned in laptop-mode.txt in the Linux
sources.

Then, try to have XFS log area on separate device. This can boost
performance, because log data will be accessed and/or written in
parallel (by hardware) to actual file system operation.

I think very vivid data is: http://oss.oracle.com/~mason/seekwatcher

I have my speed test nearly a year ago. Ext3 have big speed, until it
starts writing caches from RAM to actual device.

--
-o--=O`C
 #oo'L O
<___=E M


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

Re: Proposal regarding future packaging

[Oleg Verych]

23-09-2007, Manoj Srivastava:
[]
>>> It doesn't catch files created by Maintainer scripts?
>
>> This is the design flaw in those scripts (even in whole package
>> management).
>
> I am not sure you have made your case here.
>
> Currently, using maintainer scripts, it is indeed possible to
>  create a configuration file that is referred to by many packages, but
>  is owned by none -- so the file survives even though the package that
>  created it went away.
>
> Why is this a design flaw?

Where to find information about those files easily?

Negative search on `dpkg -L *' ?:)

What i mean is absolute freedom in maintainer scripts. Bad freedom, where
scripts can do anything they like. No comprehensive logging/tracing
infrastructure at all, everything is ad hoc.

Also RC scripting. But this is another story, though.



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

Re: Bug#443370: ITP: asmutils -- coreutils replacement written in i386 assembler

[Oleg Verych]

22-09-2007, Steinar H. Gunderson:
> On Fri, Sep 21, 2007 at 09:44:04AM +1245, Andreas Fleckl wrote:
>> It features the smallest possible size and memory requirements, the fastest
>> speed, and offers fairly good functionality.
>
> Size and memory aside, I sort of doubt asmutils' sort is faster than
> coreutils' sort just because it's written in assembly.
>
> /* Steinar */

I second this.

Also. Those programmers are inventing wheels again, fsck. Why they don't
want to make (at least) C (at least gcc or tcc) compiler more efficient:
fast but with good optimization?

And this is not saying about portability of that userspace tools (see
klibc), usability, maintenance. Sigh.



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

Text mode forever (or why all is so boring?)

[Oleg Verych]

I like text mode. Not because X and vga (adapters) sux, but because i
have no art vision at all. I amazed by any trivial paining and drawing,
required in art/architecture courses (not by official art, though).

I happened to see some ascii art occasionally, never thought, that
there was/is some kind of society around that. Saw `bb` (aalib demo), as
well as text rendering engine for GTK2 3 years ago.

Now i have time and internet to see and do some stuff. I also have
shell/sed skills upgrade, so imagination works in many ways on that, how
user interface in ttys, text processing of any kind (e.g sources, data)
can be improved to be more productive, efficient and interesting.

How boring and ugly thing, like console messaging, shell command
line, make menuconfig (in linux), emacs UI are, even, when you got
used to it.

Used `linuxlogo` on my prev. machine. The Debian Logo there, is the
ugliest thing i ever saw. Not only look, but also unimplemented
background coloring are things, that i don't like. I did some editing to
original swirl. I think, new one looks much better. After applying of some
coloring, i happened to do trivial color-filling animation.



Then i started to think, why there are no suck things every where. Like
in install, package update, boot (see, pa, no `splash' and kernel
patching needed) and all other sorts of boring processes most people
doing in a tty.

After another wave of aa mood, i happened to see text mode demos, like

   (win32 exe)
 (screenshots)

This invitation demo to tmdc8 is just awesome. I still am listening just
music track from it.

Happened to read stuff, like this:


(yes, stupid boot process for millions of luzerz, booting everyday)

Most funny thing is, that GFX for awesome demo above is written by non
other, than DPL Sam. Oh well...
--
-o--=O`C
 #oo'L O
<___=E M


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

Teaching assembly (Re: Bug#443370: ITP: asmutils -- coreutils replacement written in i386 assembler)

[Oleg Verych]

23-09-2007, Bernd Zeimetz:
>

Some more context for compilers:


>> I can confirm that it is not faster since I tested it once, I think 'wc' it 
>> was. And it is definitely not portable to other platforms either :-) 
>> Nevertheless the package brings with it some spirit that is good to have: 
>> love to assembly as a language. Maybe there are applications of this package 
>> in the embedded world or for some "UNIX on a floppy disk"-kind of 
>> distributions. I do not care for the moment. The educational aspect of this 
>> package is what makes me want it for our distribution.
>
> For the educational aspect it would now nice to have this package at
> least in mips assembly, too, which is at least at my university used to
> teach assembly. It would also allow to compare the same implementation
> for different architectures.

What problems are with 

`gcc -S --verbose-asm`
`objdump -S`?

Even more interesting would be (i guess), to see actual output of various
optimizations stages in gcc. And this is more interesting work for
students. Analyzing, what is done -- is part of any scientific
publication and academic work. Education (for me) is developed skill of
analyzing with comprehensive knowledge of history of the subject.
That's how one can deal with data coming right now.

So, why waste time with obsolete plain asm programming??? The term "asm
programming" means "teaching asm in *vacuum*". And this is wrong.

Problem is (from what i've seen), that GCC developers don't like to waste
much time looking in asm. Asm is a text output of GCC for them[0]. Kernel
developers like only C, and not many of them like to spend time looking
in actual asm, because they think, that -O2 good, -Os is better for
Embedded hype[1][2].

[0] http://article.gmane.org/gmane.comp.gcc.devel/91370
[1] http://mid.gmane.org/[EMAIL PROTECTED]
[2] http://mid.gmane.org/[EMAIL PROTECTED]
(care to look a little more in threads)
_


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

sshd defaults (Re: RFC: changes to default password strength checks in pam_unix)

[Oleg Verych (Gmane)]

05-09-2007, Gabor Gombas:
> On Tue, Sep 04, 2007 at 08:26:41PM +0000, Oleg Verych: gmane reading wrote:
>
>> I.e *i don't care* about entering passwords on middle ground, without
>> knowing, WTF this installer may do with them, not having comfortable
>> environment for that _important_ action.
>> 
>> Thus i have silly, empty passwords after installation. Then, i get my
>> imagination and compose really super-druper passwords for root and users
>> (that i create myself by script with, IDs i want/have on filesystems, not
>> by installation process).
>
> Well, if you give public network access to any machine before the
> initial configuration is complete, that's _your_ problem. The UNIX way
> was always "if the admin wants to shot himself in the foot, let him".

Oh, sure! I did network friendly install by downloading only vmlinuz
and netinstall initramfs, and i've "shot myself in the foot", nice!

Give me more of that prehistoric crap, please!

Or maybe i just want to test Sid like that. Again i need running OS after
reboot, but nothing else, like password management. Test means creating
rootfs and all other things, so don't propose me useing some ready fs.

I didn't traced issue, but Sid have problem with filesystems, like XFS,
which support sparse files. I've gigs of /var/log/lastlog and faillog
in every Sid install tests!!!



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

Efficiency, Flexibility, Future, what are those? (Re: [CMake] Producing deb package with 'ar')

[Oleg Verych (Gmane)]

06-08-2007, Antti-Juhani Kaijanaho:
[]
> Also note that packages intended for installation in a Debian system
> should follow Debian policy.  This may be nontrivial to achieve using an
> automated system like (I assume) cmake.
>   See http://www.debian.org/doc/debian-policy/

What about 
+2 followups and zero replies by crew?



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

ML improvement proposition (Re: SMTP 550 on replies to bugs)

[Oleg Verych (Gmane)]

(-devel was added in case if somebody is interested)

06-09-2007, Don Armstrong:
> On Thu, 06 Sep 2007, Oleg Verych (Gmane) wrote:
>> Should i reopen/post/close? Or additional info just not needed for
>> "thousands of users and indexing search engines"?
>
> If there's a valid reason to add more information to the bug, or if
> the bug hasn't actually been fixed, then unarchive it.

When i want simply to help, i get 550, when stupid spam wants to get to
the list it gets there. Something is wrong, unless spam isn't stupid.

>> On related topic. Is implementing in-reply-to/references checks,
>> i've mentioned some time ago is no-go for BTS technically?
>
> Checks for what?
>
> If you're talking about threading in the bugreport.cgi display, that's
> something I'd like to do, but it's quite a ways down the todo list.
>
> If you're talking about munging the messages sent to the bts itself,
> no, that's not something I'm planning on implementing.

No, that's in the past. You don't want message to be threaded, whatever.

I was talking about nice technical solution for e-mail sending/spam
handling. In short:

* Allow messages, that have "In-reply-to" and "References" with valid
  message-id's (SHOULD in rfc2822) to pass to bts/ml freely.

* Opening new threads in MLs requires a ticket.

  - ticket is a message (can be in the 550 error text, btw)
that shows what must be put in "In-reply-to" to have thread opened,

  - ordinary spam filtering may be applied to the first message even
with valid ticket,

  - in case of `smart' spam, i.e. real spam with valid "In-reply-to" and
stuff, blacklist smart spammers.

* In case of slowness of validating message ids due to huge amount of
  them, limit archive time of threads to 3 or 4 months. Error message
  in 550 this time must be "open new thread, please". OTOH, Gmane
  operates the load, that's times bigger, that any debian's ML or even
  whole lists. And this is only one `inn`, if i understand this correctly.

* It brings threading to mails in BTS automatically. If people
  don't reply to messages, that already are there, it's spam or misuse
  of e-mail.

* All spam i ever saw in here (MLs) and in my inbox, is stupid spam.
  I.e. it has stupid ms outlook headers or non at all.

You've said, that you don't want to write yet another mailing list
software. So be it, with lot of CPU power burned in spamassasin, lots of
stupid spam in the mailing list(s). Requesting more humans to operate
mailing lists isn't that i expect in dealing with reality of the XXI
century.

--
-o--=O`C
 #oo'L O
<___=E M


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

Re: ML improvement proposition (Re: SMTP 550 on replies to bugs)

[Oleg Verych (Gmane)]

* 18-09-2007, Bernd Zeimetz
* User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.4) 
Gecko/20070828 Thunderbird/2.0.0.4 Mnenhy/0.7.5.0
>
>> * Allow messages, that have "In-reply-to" and "References" with valid
>>   message-id's (SHOULD in rfc2822) to pass to bts/ml freely.
>
> Why? This can be faked easily, getting them together with a destination
> email address should be pretty easy for spammers.

[^]
>>   - in case of `smart' spam, i.e. real spam with valid "In-reply-to" and
>> stuff, blacklist smart spammers.
>
> LOL. Do you REALLY think that those spammers are so stupid that they
> wouldn't start to grab message IDs as soon as they see that this
> blocking function is integrated?

I accept, that all idea can fall apart, iff smart spammers really exist.
This is matter of scientific experimentation, rather than hand-waving,
right? Even if i'll enforce sub-subject matching, i.e. things like

/Re: \1/
/[^(]*(was \1)/

is it imaginable, that such kind of very comprehensive spam will emerge?
If smart-spammers will be so clever (and nice :) to implement that, then
OK, blacklist is a good reward for that.

>> * Opening new threads in MLs requires a ticket.
>> 
>>   - ticket is a message (can be in the 550 error text, btw)
>> that shows what must be put in "In-reply-to" to have thread opened,
>
> which is not understood by users or just thrown away because it's
> annoying, or users just don't read it because they think that the BTS is
> broken and stop taking care of the bugreport.

Well, i'd said developers in first place. Spam in debbugs, bts (for
existing bugIDs) is just isn't handled on some week days at all.

For users, i don't know, what is better:

* 550 with bounced message with "Read FAQ, use google/archive, get a ticket"
* Another quick and silly question.

>>   - ordinary spam filtering may be applied to the first message even
>> with valid ticket,
>
> why use tickets at all then?
...

>> * In case of slowness of validating message ids due to huge amount of
>>   them, limit archive time of threads to 3 or 4 months. Error message
>>   in 550 this time must be "open new thread, please". OTOH, Gmane
>>   operates the load, that's times bigger, that any debian's ML or even
>>   whole lists. And this is only one `inn`, if i understand this correctly.
>
> So you don't want to allow people to reply to old threads?

...in case of performance penalties. Was i unclear in that paragraph?

>> * It brings threading to mails in BTS automatically. If people
>>   don't reply to messages, that already are there, it's spam or misuse
>>   of e-mail.
>
> not really. Ever used the 'bts'-tool? Or cat to write your mails because
> you're on some shell on a re mote server and don't want to setup mutt?
> Validating to every message is just pain to do, and probably you can't
> even reply to them because all you have is a remote shell on a (due to a
> bug) broken machine.

Well, i have text only environment set up no problems with scripting, os
hacking. In any case, all you've wrote from your Mozilla is just
additional `echo "Message-Id: $1"` to SMTP posting script, everyone might
already wrote for such cases.

> If you don't want to have mails at all, use some kind of validation
> before you receive a mail. Your theories may work for your personal
> inbox, but neither for MLs nor for the BTS.

I was addressing issues with low man power in help for listmasters and
spam waves in development lists i (and many others) read. CPU power
wastes by extensive technologies, like current spam filtering.

> YMMV.
> -- 

MMA, BTW is about a year, so far nothing really huge happened in my
inbox. Even though debian's lists and bts have plain text archives.

> Bernd Zeimetz
> <[EMAIL PROTECTED]> 
_


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

Re: Proposal regarding future packaging

[Oleg Verych (Gmane)]

19-09-2007, Bruce Sass:
[]
>> > I like this too. Finding what a package has just installed is one
>> > of the biggest holes in Debian right now, IMO. I have to use dpkg
>> > -L to figure this out, and that's just too crude to be a real
>> > solution.
>>
>> Too crude?  That's a simple command, easily found in a relevant
>> manpage.  In true Unix fashion, its output can be easily piped to
>> other commands.  What's crude about it?
>
> It doesn't catch files created by Maintainer scripts?

This is the design flaw in those scripts (even in whole package
management).

> I'm hoping the dpkg "triggers" functionality Ian Jackson has been 
> working on will help solve that wart though.

How exactly?



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

Re: Proposal regarding future packaging

[Oleg Verych (Gmane)]

21-09-2007, Bruce Sass:
> On Thu September 20 2007 09:25:23 pm Oleg Verych (Gmane) wrote:
>> 19-09-2007, Bruce Sass:
>> > I'm hoping the dpkg "triggers" functionality Ian Jackson has been
>> > working on will help solve that wart though.
>>
>> How exactly?
>
> Exactly? I don't know. I haven't followed what is happening close 
> enough.
>
> Basically, it allows a package to toss up a flag saying, `I'm here and 
> needs to be done.' It may require some convention and a 
> little more infrastructure, but that is close to letting a package say, 
> `add these paths to the list of paths which I control.'

Sure. But i thought, we are talking about finding/listing of generated
files.



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

Re: RFC: changes to default password strength checks in pam_unix

[Oleg Verych: gmane reading]

04-09-2007, Adam D. Barratt:

> On Tue, 2007-09-04 at 07:53 +0000, Oleg Verych wrote:
> [...]
>> What about having more secure Debian's sshd_config by default?
>> "
>> PermitRootLogin no
>
> You'll have to convince the openssh package maintainers first - see
> #105571, #298138 and #431627 for their opinions on whether that change
> is "more secure".

Thanks for references!

But in public i want to say following.

While making new installation all i care is rebooting to working
operating system.

I.e *i don't care* about entering passwords on middle ground, without
knowing, WTF this installer may do with them, not having comfortable
environment for that _important_ action.

Thus i have silly, empty passwords after installation. Then, i get my
imagination and compose really super-druper passwords for root and users
(that i create myself by script with, IDs i want/have on filesystems, not
by installation process).

Having ssh defaults is just debian's asking -- here i'm, take me, wise
man!

--
-o--=O`C
 #oo'L O
<___=E M


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