Re: Handling of (inactive) Debian Accounts

[Ben Gertzfield]

Hi Joerg,

I know I've gone MIA for quite a long time (graduated from university
and got a full-time job).  I don't know if I've gotten the WaT email
yet, but I'd be glad to keep my email forwarding as an emeritus
account.

Anyway, thanks for taking the time to clean up all the accounts, and
my apologies for not contributing to the project in some time.

Ben

On 2/9/07, Joerg Jaspert <[EMAIL PROTECTED]> wrote:

Hi

as Debian gets more and more accounts it is only natural that we have
more and more unused accounts. People get MIA, find different interests
or simply lost interest in Debian but did not follow the normal
procedure of retiring.[1]

To reduce the security risk an unused open account has, and also to get
the number of Developers to reflect the reality, we, the Debian Account
Managers, decided to do regular "WaT"[2] runs.


Selection of the people included in those runs will be done in a way
that we avoid sending out such mails to active people. As a good start
we will take the upcoming DPL vote as an input source, everyone who doesn't
vote this year will be included in the first run.

 * Please note that you can vote without expressing an opinion! *

Later on there should be more such runs, on a regular base. Input of
affected accounts can be (apart from future DPL election non-voters) the
great work from the MIA-team, but details for that need to be worked
out.


We currently have 4 states for any given account in LDAP:

 o [default]
 o Emeritus
 o Disabled
 o Memorial


[default] is obviously what the majority of accounts has. No need to
explain it.

Memorial is a special state used for accounts that are disabled
but which we don't want reused to avoid confusion (at best), e.g. with
developers who've passed away.


Now, for the handling of the WaT runs, Emeritus and Disabled are the two
important states here:


To get into the Emeritus state you voluntarily retire from the project,
following [1] or by replying to a WaT mail.

The account will be put into the 'emeritus' state. It will get locked
and their keys are moved to a separate keyring. Their email will
continue to work for 6 months.  They lose vote, upload and -private
reading privileges.

People in this stage can get their DD status back with a reduced NM
process.


The disabled state is for people where the WaT mail bounced or who don't
reply. For the first 12 months things are the same as 'emeritus', after
that they will need to pass full NM if they want to get their DD status
back.


[1] 
http://www.us.debian.org/doc/developers-reference/ch-developer-duties.en.html#s3.7

[2] *W*here *a*re *T*hey?

--
bye Joerg
It seems to me that the account creation step could be fully automated:
checking the box "approved by DAM" could trigger an insert into the LDAP
database thereby creating the account.
   <[EMAIL PROTECTED]>





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

Bug#410359: ITP: python-pudge -- documentation generator for Python projects

[Piotr Ozarowski]

Package: wnpp
Severity: wishlist
Owner: Piotr Ozarowski <[EMAIL PROTECTED]>

* Package name: python-pudge
  Version : 0.1.2+svn134-1
  Upstream Author : Ryan Tomayko <[EMAIL PROTECTED]>
* URL : http://pudge.lesscode.org/
* License : MIT
  Programming Lang: Python
  Description : documentation generator for Python projects

 Pudge is a documentation system for Python projects.
 .
 Its highlights are:
  * Generate documentation for Python packages, modules, classes, functions,
and methods.
  * Module and Class index hierarchies
  * Support for Restructured Text in docstrings
  * Easily apply common free documentation licenses (GNU, CC)
  * Syntax colored source HTML generation with anchors for line numbers
  * Generated reference documents link to source for all modules, classes,
functions, and methods
  * Basic Restructured Text document templating (brings external documents into
the flow of generated pages)
  * Support for HTML 4.01 or XHTML 1.0 output
  * Basic Trac integration (adds Trac project links to navigational elements)
  * Uses a combination of runtime inspection and Python source code scanning
  * Extensible and customizable using kid templates

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


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

Re: ITP memlockd

[Russell Coker]

On Friday 09 February 2007 22:47, [EMAIL PROTECTED] wrote:
> superb, I've wanted one of these for a long time :-)
>
> Other scenarios might include having a working system if the binary
> images are not acccessible for some other reason such as h/w failure ??

If the kernel umounts a filesystem because of IO errors then you can't execute 
the program without a directory entry.  However if you have a running program 
and memlockd had kept it in ram then it should keep running after a drive 
fails (unless of course it's data pages had been swapped out).  To keep a 
program running after a failure the mlockall() system call might be the best 
option.

> I had thought that the sticky bit had once been used like this?
> but I went away and read just now that it was a bit different.

The sticky bit was apparently aimed for better performance during regular 
operation.  Shared objects and aggressive disk caching made it less useful so 
it was never implemented in Linux.

> How does it interact with the filesystem? I imagine that if I rm
> /bin/bash then I can no longer simply execute it in the usual way,
> even if the pages are still locked in memory (and do you unlock
> the pages when the underlying file is removed ?)

My program won't notice a file removal unless you kill -1 it.

> Is there any guarantee that the various directories and inodes needed
> (are they needed??) will be in memory ?

No.

> Where can I get the code ?  :-)

As it's only 1K compressed I've attached an early version of the source 
(consider it version 0).

-- 
[EMAIL PROTECTED]
http://etbe.blogspot.com/  My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development


memlockd.cpp.gz
Description: GNU Zip compressed data

Re: NEW queue frozen?

[Yves-Alexis Perez]

On ven, 2007-02-09 at 17:47 +0100, Bastian Venthur wrote:
> Is the NEW queue frozen or something? Currently 190 packages are
> waiting
> in NEW. I've only noticed this since I'm waiting for the current
> version
> of libgpod which is needed to get (not only) my IPod working again
> with
> Amarok from experimental. 

NEW is currently processed. Not really that fast, but still moving. See
http://heracles.corsac.net/~corsac/debian/new/
-- 
Yves-Alexis


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

Re: about gstreamer0.8 and python2.3 removal

[Tshepang Lekhonkhobe]

On 2/9/07, Loïc Minier <[EMAIL PROTECTED]> wrote:

On Fri, Feb 09, 2007, Tshepang Lekhonkhobe wrote:
> Pretty surprising. Was there a discussion in which this decision was
> made or is this just the assumed position?

 


I saw that thread which seemed to die off without a clear indication
of the decisions taken as regards removal, hence 'assumed' position:
One guy wants gst0.8 removed and another wants to keep it in due to
goobox, there's some arguments, and.. nothing (not even mails to
release or security team).

This situation is similar to the GNOME 2.14 vs. 2.16 for Etch thing
that I only noticed accidentally, or perhaps some people assumed
everybody reads planet.debian.org and other DD blogs...

sorry if you feel this is noise, but there should really be better comms...

Re: Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875

[David Härdeman]

reassign 409875 libdevmapper1.02
retitle 409875 libdevmapper should provide more helpful error messages
severity 409875 minor
thanks

On Fri, Feb 09, 2007 at 09:44:32PM +0100, Johannes Schlumberger wrote:
Thanks, this looks mighty suspicious...it looks like /dev/md0 is mounted 
as your root partition by the initramfs? Please provide me with "ls -al 
/dev/root" and "cat /proc/cmdline" as well as the contents of your grub 
or lilo config file.


I am so sorry for stealing yours and other persons time like this. I had
root=/dev/md0 in my menu.lst and / as /dev/hdd6 in my fstab. I have to say I am
strongly embarassed.


No problem, it happends to all of us. There still is a bug here 
though...the error messages from libdevmapper are obtuse to say the 
least.


libdevmapper explained that /dev/md0 is in use with the message:
"Command failed: device-mapper: reload ioctl failed: Invalid argument"

That is a bug in my book.

I'll reassign this bug to libdevmapper (and retitle it accordingly).

I'll also CC all people that I've bugged earlier so that they know that 
this issue is no more.



Thank you a lot for figuring this out and all your patience.


That's ok, you just owe me a beer.

--
David Härdeman

Re: RFC: use readable $(cmd) syntax instead of unreadable `cmd`

[John H. Robinson, IV]

Jari Aalto wrote:
> 
> I have seen following construct to be used in shell-context
> (makefiles, sh-scripts, Perl):
> 
>   `cmd` [1]
> 
> However, the POSIX standard and SUSv[23] declares alternative way of
> accomplishing the same with in *sh context:
> 
>   $(cmd) [2]

The only problem I see with $() is that older /bin/sh (SunOS) does not
support $(), but it does support ``.

When I make a /bin/sh, I want it able to be run on a /bin/sh, even if
that /bin/sh is on SunOS. I avoid $() and I do not consider `` a bug at
all. I use ``. If I need to nest, then I will use $() and usually mark
it as /bin/bash. Not a hard and fast rule, but as a guideline.

A line in a Makefile is simply a /bin/sh one-liner. Same rules apply as
for /bin/sh.

Perl suports qx() which I do tend to use over ``.

If I were to get a wishlst bug, I would mark it wontfix and leave it as
such. Even with a patch.

-- 
John H. Robinson, IV  [EMAIL PROTECTED]
 http  
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type.  spiders.html  


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

Re: about gstreamer0.8 and python2.3 removal

[Loïc Minier]

On Fri, Feb 09, 2007, Tshepang Lekhonkhobe wrote:
> Pretty surprising. Was there a discussion in which this decision was
> made or is this just the assumed position?

 

-- 
Loïc Minier <[EMAIL PROTECTED]>


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

How many packages in Sid should reach Etch?

[Tshepang Lekhonkhobe]

Hi,

The useful bjorn,haxx.se/debian lists nearly 2000 packages trying to
enter Testing which keeps on growing these days due to manual hinting
of course. By I actually wonder if the release team is able to keep
up. I know there's certain kinds of packages never meant to reach
Testing, but is there an automated way of determining exactly how many
packages are actually intended to reach Etch?

A more silly and related question:
If the 100 RC bugs were suddenly fixed and d-i were released tomorrow,
would the dozens of non-RC hint requests (translations, important
bugs) be ignored and Etch be released anyways?


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

Re: about gstreamer0.8 and python2.3 removal

[Tshepang Lekhonkhobe]

On 2/9/07, Loïc Minier <[EMAIL PROTECTED]> wrote:

On Fri, Feb 09, 2007, Tshepang Lekhonkhobe wrote:
> It's been a while since someone mentioned removal of gst0.8 and py2.3
> and wonder what's going on.

 Concerning GStreamer 0.8, teatime, goobox and muine remain rdeps in
 unstable, so GStreamer 0.8 is kept for etch.


Pretty surprising. Was there a discussion in which this decision was
made or is this just the assumed position?

By the way, teatime and muine got gst0.10 patches. It would just be
interesting to see if that patched version of muine would reach Etch
since it's also an upstream version and is in experimental.

thanks for the reply

Re: about gstreamer0.8 and python2.3 removal

[Adam D. Barratt]

On Fri, 2007-02-09 at 20:57 +0200, Tshepang Lekhonkhobe wrote:
> Hi,
> 
> It's been a while since someone mentioned removal of gst0.8 and py2.3
> and wonder what's going on.

python2.3 is no more, as of a month ago today:

 python2.3 | 2.3.5-3sarge1 |stable | source, alpha, arm, hppa, i386, 
ia64, m68k, mips, mipsel, powerpc, s390, sparc
 python2.3 | 2.3.5-3sarge2 | proposed-updates | source, alpha, arm, hppa, i386, 
ia64, m68k, mips, mipsel, powerpc, s390, sparc

Adam


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

Re: RFC: use readable $(cmd) syntax instead of unreadable `cmd`

[J.A. Bezemer]

On Fri, 9 Feb 2007, Jari Aalto wrote:

> FOREWORD
> 
> I have seen following construct to be used in shell-context
> (makefiles, sh-scripts, Perl):
> 
>   `cmd` [1]
> 
> However, the POSIX standard and SUSv[23] declares alternative way of
> accomplishing the same with in *sh context:
> 
>   $(cmd) [2]

[..]
> All Debian *sh compatible shells support $() and are thus POSIX/SUS
> compliant in this respect. 

[..]
> The Single UNIX Specification, Version 2 (SUSv2):
> "Shell Command Language"
> 
> 
> ...The input characters within the quoted string that are
> also enclosed between "$(" and the matching ")" will not
> be affected by the double-quotes, but rather define that
> command whose output replaces the $(...)

Your mail makes it sound like $( ) is the only command substitution
allowed by POSIX/SUSv[23]. It is not. Let me quote the _really_ relevant
section of SUSv2,
http://www.opengroup.org/onlinepubs/007908799/xcu/chap2.html#tag_001_006_003
and SUSv3 = POSIX (IEEE1003.1, 2004 Edition),
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_03

Command substitution allows the output of a command to be substituted
in place of the command name itself. Command substitution shall occur
when the command is enclosed as follows:

$(command)

or (backquoted version):

`command`


Further, you didn't yet mention the only disadvantage of backquotes that I
personally find important enough to consider, namely that (multi-level)
nesting quickly gets horrible. So I personally tend to use $( ) only when
nesting.

And exactly that is also the only reason mentioned in the Rationale volume
of SUSv3/POSIX,
http://www.opengroup.org/onlinepubs/009695399/xrat/xcu_chap02.html#tag_02_02_06_03

... Because of these inconsistent behaviors, the backquoted variety of
command substitution is not recommended for new applications __that
nest command substitutions or attempt to embed complex scripts__.

(my underlining.)


Best regards,

  Anne Bezemer


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

Re: about gstreamer0.8 and python2.3 removal

[Loïc Minier]

On Fri, Feb 09, 2007, Tshepang Lekhonkhobe wrote:
> It's been a while since someone mentioned removal of gst0.8 and py2.3
> and wonder what's going on.

 Concerning GStreamer 0.8, teatime, goobox and muine remain rdeps in
 unstable, so GStreamer 0.8 is kept for etch.

-- 
Loïc Minier <[EMAIL PROTECTED]>


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

about gstreamer0.8 and python2.3 removal

[Tshepang Lekhonkhobe]

Hi,

It's been a while since someone mentioned removal of gst0.8 and py2.3
and wonder what's going on.


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

Re: RFC: use readable $(cmd) syntax instead of unreadable `cmd`

[John Goerzen]

On Fri, Feb 09, 2007 at 07:26:21PM +0100, Marco d'Itri wrote:
> > I'm askinf if it is ok to to reopen such bugs based of better QA
> > aspects. Possibly by providing patches if the maintainer is busy
> > elsewhere to handle such a "minor issue" from his perspective.
> No, it's not. Even if a patch is provided, handling a bug is a time
> consuming activity (*horribly* time consuming if the patch is for
> upstream code).
> If you really think this crusade is worth being pursued then I suggest
> you just mail patches to Debian maintainers for original scripts and to
> the upstream maintainers for the rest.

I agree.  And I would add that this is not a bug (not a defect, etc) at
all.  It is perfectly valid syntax.  If you're going to open up bugs on
this, then you might as well file a bug against the kernel for not
indenting like GNU does, against libc for not indenting like Linus does,
and against gnome for not indenting like either of them do.  

-- John


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

Re: NEW queue frozen?

[Joerg Jaspert]

On 10925 March 1977, Bastian Venthur wrote:

> Is the NEW queue frozen or something?

No, its not that cold yet.

-- 
bye Joerg
 I'm James Troup, long term source of all evil in Debian. you may
know me from such debian-devel-announce gems as "Serious
Problems With "


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

Re: RFC: use readable $(cmd) syntax instead of unreadable `cmd`

[Sune Vuorela]

On 2007-02-09, Jari Aalto <[EMAIL PROTECTED]> wrote:
> - The backtick version is not easily readable in high resolution screens
>   or in terminals with small fonts 

Solution: get glasses.

> - There may be problems in distinguishing character ' from ` with sme
>   particularly selected font.

Solution: use a proper font.

> - The missing backtick is hard to find in highly quoted context, where
>   single, double quotes and backticks play the code tune.

Solution: use a editor that can help you.

> - The backtick is awkwardly located in some keyboards. (possible
>   orphan/adopt/NMU maintenance problem)

The backticks are better located here than the $( sequence.

>  "If your development environment cannot display ` differently than ' ,
>  you need to get a new one."

Quite reasonable reasoning.

>
> I'm askinf if it is ok to to reopen such bugs based of better QA
> aspects. Possibly by providing patches if the maintainer is busy
> elsewhere to handle such a "minor issue" from his perspective.

I prefer backticks.

/Sune


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

Re: RFC: use readable $(cmd) syntax instead of unreadable `cmd`

[Marco d'Itri]

On Feb 09, Jari Aalto <[EMAIL PROTECTED]> wrote:

> I have reported bugs against backtick and suggested to change to use
> the more readable alternative. The result was surprising. To quote
> one message (bug closed reasoning):
> 
>  "If your development environment cannot display ` differently than ' ,
>  you need to get a new one."
Reasonable answer.

> I'm askinf if it is ok to to reopen such bugs based of better QA
> aspects. Possibly by providing patches if the maintainer is busy
> elsewhere to handle such a "minor issue" from his perspective.
No, it's not. Even if a patch is provided, handling a bug is a time
consuming activity (*horribly* time consuming if the patch is for
upstream code).
If you really think this crusade is worth being pursued then I suggest
you just mail patches to Debian maintainers for original scripts and to
the upstream maintainers for the rest.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: RFC: use readable $(cmd) syntax instead of unreadable `cmd`

[Lars Wirzenius]

On pe, 2007-02-09 at 20:11 +0200, Jari Aalto wrote:
> I'm askinf if it is ok to to reopen such bugs based of better QA
> aspects.

It's a matter of style and taste. Unless you can quote verifiable
statistics that using backticks instead of $() is causing problems (that
is, bug numbers), let it be. There's real problems to be fixed.

(Personally, I prefer $() instead of backticks. Haven't used backticks
for a while now.)

If you insist going forward with this, then please also file bugs (with
patches, preferably) to pre-emptively prevent problems when the wrong
programming language is used (C instead of Python, Perl instead of Lisp,
Haskell instead of assembler), and also for all packages that are
lacking test cases that excercise at least every statement in the code.

-- 
Fundamental truth #2: Attitude is usually more important than skills.


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

Re: RFC: use readable $(cmd) syntax instead of unreadable `cmd`

[Norbert Preining]

On Fre, 09 Feb 2007, Jari Aalto wrote:
> I'm askinf if it is ok to to reopen such bugs based of better QA
> aspects. Possibly by providing patches if the maintainer is busy
> elsewhere to handle such a "minor issue" from his perspective.

I would leave it to the discretion of the developer what notation he
prefers. If he prefers backticks and knows about the problems which
could be present, it is ok for me.

I was using backticks, and thanks to Florent's comments (similar to
yours) I have switched to use $(...), but as I said, this is up to the
discretion of the developer.

Best wishes

Norbert

---
Dr. Norbert Preining <[EMAIL PROTECTED]>Università di Siena
Debian Developer <[EMAIL PROTECTED]> Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
"What was the self-sacrifice?"
"I jettisoned half of a much loved and I think
irreplaceable pair of shoes."
"Why was that self-sacrifice?"
"Because they were mine!" said Ford crossly.
"I think we have different value systems."
"Well mine's better."
"That's according to your... oh never mind."
 --- Douglas Adams, The Hitchhikers Guide to the Galaxy


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

RFC: use readable $(cmd) syntax instead of unreadable `cmd`

[Jari Aalto]

FOREWORD

I have seen following construct to be used in shell-context
(makefiles, sh-scripts, Perl):

  `cmd` [1]

However, the POSIX standard and SUSv[23] declares alternative way of
accomplishing the same with in *sh context:

  $(cmd) [2]

I would see following problems quality wise with [1]:

- The backtick version is not easily readable in high resolution screens
  or in terminals with small fonts 

- There may be problems in distinguishing character ' from ` with sme
  particularly selected font.

- The missing backtick is hard to find in highly quoted context, where
  single, double quotes and backticks play the code tune.

- The backtick is awkwardly located in some keyboards. (possible
  orphan/adopt/NMU maintenance problem)

- Lastly, isually impaired people have problems with non-easily
  dintinguishable content. ' and ` fall into this category.

All Debian *sh compatible shells support $() and are thus POSIX/SUS
compliant in this respect. 

BUG REPORTS -- AND REPONSES

I have reported bugs against backtick and suggested to change to use
the more readable alternative. The result was surprising. To quote
one message (bug closed reasoning):

 "If your development environment cannot display ` differently than ' ,
 you need to get a new one."

I'm askinf if it is ok to to reopen such bugs based of better QA
aspects. Possibly by providing patches if the maintainer is busy
elsewhere to handle such a "minor issue" from his perspective.

Jari

REFERENCES

The Single UNIX Specification, Version 2 (SUSv2):
"Shell Command Language"


...The input characters within the quoted string that are
also enclosed between "$(" and the matching ")" will not
be affected by the double-quotes, but rather define that
command whose output replaces the $(...)


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

Re: NEW queue frozen?

[Ying-Chun Liu (PaulLiu)]

Bastian Venthur wrote:
> Hi,
> 
> Is the NEW queue frozen or something? Currently 190 packages are waiting
> in NEW. I've only noticed this since I'm waiting for the current version
> of libgpod which is needed to get (not only) my IPod working again with
> Amarok from experimental.
> 
> Sorry if this has been announced/explained elsewhere.
> 
> 
> Cheers,
> 
> Bastian
> 

It seems the new queue is not frozen because some new packages are still
going into unstable, like flickrfs. Just slow I think.

regards,
 Ying-Chun Liu

-- 
PaulLiu(Ying-Chun Liu)
E-mail address: [EMAIL PROTECTED]



signature.asc
Description: OpenPGP digital signature

NEW queue frozen?

[Bastian Venthur]

Hi,

Is the NEW queue frozen or something? Currently 190 packages are waiting
in NEW. I've only noticed this since I'm waiting for the current version
of libgpod which is needed to get (not only) my IPod working again with
Amarok from experimental.

Sorry if this has been announced/explained elsewhere.


Cheers,

Bastian

-- 
Bastian Venthur  http://venthur.de
Debian Developer venthur at debian org


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

Re: [Pkg-cryptsetup-devel] Bug#409875: cannot setup device-mapper mapping ontop of /dev/md* device

[Henrique de Moraes Holschuh]

On Fri, 09 Feb 2007, David Härdeman wrote:
> > On Thu, Feb 08, 2007, David Härdeman wrote:
> >> dmsetup / cryptsetup both fail to create a mapping on top of a raid
> >> device (/dev/md0 in this case).
> >
> >  I don't know where the error lies, but I created two loop devices loop0
> >  and loop1, added them to a new RAID 1 md0 device, and ran cryptsetup on
> >  the resulting md0 successfully.
> 
> Ditto. I've succesfully setup a crypto mapping on a raid1 device under
> qemu, which leads me to believe that it is something specific to Johannes
> setup.

Warning: It is not safe on all kernels out there, due to kernel bugs.  See
recent flow of patches from the md maintainer in LKML.  I don't know if they
all landed on 2.6.16.y and 2.6.19.y and 2.6.20 yet.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Problem resolving bug http://bugs.debian.org/407494

[Henrik Andreasson]

Hi All!

I've been trying to figure out why caudium dont work with the current 
pike7.6 package (7.6.93) but there is not much progress at this 
time, I've tried contacting the debian maintainer and the caudium 
community but no real progress with that.


Is there any possibility at this time to upload a newer version (7.6.98) 
of the package that works?


If there is anybody that has time to check my packages out please do so:

deb http://thoth.han.pp.se/debian/ unstable main
deb-src http://thoth.han.pp.se/debian/ unstable main

I'm afraid caudium will be removed from etch if we dont solve this soon.

Please advice.

//Henrik Andreasson




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

Re: [Pkg-cryptsetup-devel] Bug#409875: cannot setup device-mapper mapping ontop of /dev/md* device

[David Härdeman]

On Fri, February 9, 2007 11:45, Loic Minier said:
> On Thu, Feb 08, 2007, David Härdeman wrote:
>> dmsetup / cryptsetup both fail to create a mapping on top of a raid
>> device (/dev/md0 in this case).
>
>  I don't know where the error lies, but I created two loop devices loop0
>  and loop1, added them to a new RAID 1 md0 device, and ran cryptsetup on
>  the resulting md0 successfully.

Ditto. I've succesfully setup a crypto mapping on a raid1 device under
qemu, which leads me to believe that it is something specific to Johannes
setup.

So I'm hoping that someone will come up with some suggestions on how to
troubleshoot it further on his machine.

(This is my last cross-post on this subject, I promise, please keep
further discussions to the bug report address only -
[EMAIL PROTECTED])

-- 
David Härdeman


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

Re: ITP memlockd

[paddy]

On Fri, Feb 09, 2007 at 08:57:19AM +1100, Russell Coker wrote:
> memlockd - daemon to lock files into RAM
> 
> When a system starts paging excessively it may be impossible for the sysadmin 
> to login for the purpose of killing the runaway processes (sometimes the 
> login program times out due to thrashing).  Memlockd allows important system 
> files (such as /bin/login, /bin/getty, and the admin shell) to be locked in 
> memory so that there will be no delay in accessing executable pages.  In my 
> tests this can decrease the time required for the administrator to login on a 
> thrashing system by a factor of more than 3.
> 
> GPL, I wrote it.

superb, I've wanted one of these for a long time :-)

Other scenarios might include having a working system if the binary
images are not acccessible for some other reason such as h/w failure ??

I had thought that the sticky bit had once been used like this? 
but I went away and read just now that it was a bit different.

I take it you handle package installs ?

How does it interact with the filesystem? I imagine that if I rm
/bin/bash then I can no longer simply execute it in the usual way,
even if the pages are still locked in memory (and do you unlock
the pages when the underlying file is removed ?)

Is there any guarantee that the various directories and inodes needed
(are they needed??) will be in memory ?

I have too many questions ...

Where can I get the code ?  :-)

Regards,
Paddy


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

Nesta Semana na Compwork - Imbativel

[Compwork]

Caso não visualize este e-mail clique aqui


MP3 Player 512MB Preto c/ Prata Cyber
R$ 135,36
ou 3x R$ 45,12

Teclado e Mouse Ópico PS2 s/ Fio A4TECH KBS-1527RP
R$ 174,31
ou 3x R$ 58,10

Nobreak SMS Manager NET3+ USM 1400VA Bifx 115 Cinza
R$ 459,00
ou 3x R$ 153,00


Wireless Broadband Router 54MBPS PLANET WRT415
R$ 218,30
ou 3x R$ 72,77

WebCam VIEWCAM PK-635 A4TECH
R$ 90,00
ou 3x R$ 30,00

Gravador DVD 18X LG GSA-H22N
R$ 147,26
ou 3x R$ 49,09

Re: Bug#409875: cannot setup device-mapper mapping ontop of /dev/md* device

[David Härdeman]

Executive summary:
dmsetup / cryptsetup both fail to create a mapping on top of a raid 
device (/dev/md0 in this case).

For much more details, see the bug report, any help appreciated as I'm out
of ideas on how to diagnose the error:

http://bugs.debian.org/409875

-- 
David Härdeman



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

Re: /foo has been mounted xx times... check forced

[Enrico Zini]

On Thu, Feb 08, 2007 at 10:24:14PM -0500, Theodore Tso wrote:

> > You do need a mounted /proc at that time, though, which may be the
> > reason it's not working for you.
> A mounted /proc and if ACPI has been built using modules, the ACPI
> battery module needs to be installed, since that's how we tell whether
> we are running on the AC mains or battery

Right.  But would it actually be officially safe to interrupt with ^C ?
That would give the user an opportunity to decide how in a hurry they
are, and quickly get out of a difficult situation.

If the answer is yes, ^C is officially safe, then I propose to add "if
in a hurry, interrupt with ^C " to the "check forced" message.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: ITP memlockd

[Russell Coker]

On Friday 09 February 2007 10:43, Brian May <[EMAIL PROTECTED]> wrote:
> How much memory typically needs to be locked for this to be
> beneficial?

It's best to have the shell used by the sysadmin, the login chain (getty + 
login or sshd and the PAM stuff), some utilities (EG busybox), and all shared 
objects used by them.  But you can get by with a lot less.

I've attached a sample config file that causes just under 10M of RAM to be 
used.  No big deal on a machine with 256M of RAM that is likely to experience 
a DOS attack.

-- 
[EMAIL PROTECTED]
http://etbe.blogspot.com/  My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development
/bin/bash
/lib/libncurses.so.5
/lib/tls/i686/cmov/libdl.so.2
/lib/tls/i686/cmov/libc.so.6
/usr/sbin/sshd
/lib/libwrap.so.0
/lib/libpam.so.0
/lib/tls/i686/cmov/libdl.so.2
/lib/libselinux.so.1
/lib/tls/i686/cmov/libresolv.so.2
/usr/lib/i686/cmov/libcrypto.so.0.9.8
/lib/tls/i686/cmov/libutil.so.1
/usr/lib/libz.so.1
/lib/tls/i686/cmov/libnsl.so.1
/lib/tls/i686/cmov/libcrypt.so.1
/usr/lib/libgssapi_krb5.so.2
/usr/lib/libkrb5.so.3
/usr/lib/libk5crypto.so.3
/lib/libcom_err.so.2
/usr/lib/libkrb5support.so.0
/lib/tls/i686/cmov/libc.so.6
/lib/ld-linux.so.2
/lib/libsepol.so.1
/bin/busybox
/lib/tls/i686/cmov/libm.so.6