[q] maintainance of xfsprogs and util-linux

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

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

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 xf

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

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

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

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

Re: Question about "Depends: bash"

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 PROT

Re: Question about "Depends: bash"

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 w

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

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 op

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

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

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

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

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

> 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

Purging of unneeded localization (cleaL10n)

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

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

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

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

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,

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

* 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

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

> 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

Re: checklib

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

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

* 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

checklib... (Re: checklib)

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 >

Re: Dependencies on shared libs, take 2

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

Re: Dependencies on shared libs, take 2

* 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

Re: Dependencies on shared libs, take 2

* 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

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

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 sourc

Re: Wanted: introductory page for all teams

* 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

Re: Why not move Apt to a relational database

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

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

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

Re: Bourne shell assistance needed for Bug #422909

* 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" = "

The Shell: arithmetic comparison with void

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

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

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

coreutils: long stall

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'

* 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

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

* 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

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

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

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

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

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

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

Re: Looking for new FTP assistants

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

Re: Looking for new FTP assistants

> 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

Re: Looking for new FTP assistants

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

Re: Thoughts about the bug tracking system

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

Re: Thoughts about the bug tracking system

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

Re: Thoughts about the bug tracking system

>> [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" Tha

Re: Thoughts about the bug tracking system

* 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

Re: Thoughts about the bug tracking system

* 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

Re: Thoughts about the bug tracking system

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 wa

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

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

Re: Google SoC 2007- KernelConfigProposal

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

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

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

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

* 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. > ;-) > > Embedd

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

* 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

Re: /bin/sh diversions

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

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

* 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

Re: /bin/sh diversions

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 bee

Re: Installation of Recommends by default on October 1st

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

Re: Installation of Recommends by default on October 1st

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

Re: /bin/sh diversions

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

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

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

Re: Considerations for 'xmms' removal from Debian

* 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

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

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

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

* 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. T

Re: Proposal regarding future packaging

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 possi

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

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

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

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 kin

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

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

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

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

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

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

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

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

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

* 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

Re: Proposal regarding future packaging

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

Re: Proposal regarding future packaging

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

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

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 f