Re: xfce-goodies - help needed; Rudy Godoy MIA?

[Emanuele Rocca]

* [ 17-01-05 - 01:50 ] Simon Huggins <[EMAIL PROTECTED]> wrote: 
>  On Sun, Jan 16, 2005 at 02:57:57PM -0800, Steve Langasek wrote:
>  > There are currently 11 orphaned xfce4-* packages in unstable, including
>  > three that have just been removed from testing due to RC bugs that went
>  > virtually unnoticed since the last upload in May.
>  
>  I know the -goodies packages are in bad shape.
>  
>  > Please take some time to help figure out what should be done with
>  > these packages -- cleaned up/adopted, or removed from the archive --
>  > before ITPing more packages in the xfce4 namespace.
>  
>  Sure.  I think for sarge they can be cleaned up/updated.  I've just
>  finished a stretch getting the 22 packages for the main body of xfce4
>  for 4.2.0 for experimental sorted this weekend so I'm a bit knackered
>  currently.
>  
>  To be honest I'd been expecting others to sort out the -plugins for
>  sarge given people had said they would.

You're right, but (for what concerns me) I am a bit busy with real life
in these days.

>  Likewise Emanuele Rocca seemed interested.

I am. 

>  There were some packages that made it to mentors.debian.net - and there
>  is still some work up there.
>  http://mentors.debian.net/debian/pool/main/x/

WNPP bugs for some of the -goodies need to be retitled from O: to ITP:.

I found the time to check -battery-plugin and -clipman-plugin, and I 
must admit that they're not in a good shape (ITP bugs not closed in the
changelog, bugs marked as fixed are actually still reproducible, lintian
is not happy)...

I don't want to be rude, but I am wondering if Rudy is the right person
for these 13 packages, considering that he's got 9 packages in main 
yet.
Rudy, have you really got the time to maintain all the -goodies 
properly?

Why is the Debian Xfce Packages Alioth project dead? [0]
IMHO putting these packages under collaborative maintenance would be a
better idea.

ciao,   
ema

[0] http://alioth.debian.org/projects/pkg-xfce/


signature.asc
Description: Digital signature

Re: xfce-goodies - help needed; Rudy Godoy MIA?

[Simon Huggins]

On Tue, Jan 18, 2005 at 10:22:14AM +0100, Emanuele Rocca wrote:
> * [ 17-01-05 - 01:50 ] Simon Huggins <[EMAIL PROTECTED]> wrote: 
> >  There were some packages that made it to mentors.debian.net - and there
> >  is still some work up there.
> >  http://mentors.debian.net/debian/pool/main/x/
> WNPP bugs for some of the -goodies need to be retitled from O: to ITP:.

> I found the time to check -battery-plugin and -clipman-plugin, and I 
> must admit that they're not in a good shape (ITP bugs not closed in the
> changelog, bugs marked as fixed are actually still reproducible, lintian
> is not happy)...

Ok.

> I don't want to be rude, but I am wondering if Rudy is the right
> person for these 13 packages, considering that he's got 9 packages in
> main yet.  Rudy, have you really got the time to maintain all the
> -goodies properly?

Fair enough.

> Why is the Debian Xfce Packages Alioth project dead? [0]

Madkiss hasn't revived it for whatever reason.  *shrug* I asked in the
summer when you and Rudy were talking about the plugins and nothing
happened.

> IMHO putting these packages under collaborative maintenance would be a
> better idea.

I set up the xfce4-debian list for exactly that reason so we can
coordinate stuff.


Simon.

-- 
[ "Ah, here we are - `How to Raise the Dead.'" - Bart Simpson  ]


pgpKrzTk9WXlV.pgp
Description: PGP signature

General question about releases

[Kevin Mark]

Hi DDs,
I was just wondering about the number of packages that go through the
debian flavors per release.
X packages went in stable, Y packages went in testing, Z
packages went in unstable, 
where X < Y << Z
for potato, woody and sarge(so far).
IE. woody(x)=8000 and sarge(x)=15000
Any pointers to where this info can be found appreciated.
My guess is that Z would be based on debian-devel-changes.
And Y may be based on bug resolution?
-Kev
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!

(__)
(oo)
  /--\/
 / |||
*  /\---/\
   ~~   ~~
"Have you mooed today?"...


signature.asc
Description: Digital signature

Re: General question about releases

[Goswin von Brederlow]

Kevin Mark <[EMAIL PROTECTED]> writes:

> Hi DDs,
> I was just wondering about the number of packages that go through the
> debian flavors per release.
> X packages went in stable, Y packages went in testing, Z
> packages went in unstable, 
> where X < Y << Z
> for potato, woody and sarge(so far).
> IE. woody(x)=8000 and sarge(x)=15000
> Any pointers to where this info can be found appreciated.
> My guess is that Z would be based on debian-devel-changes.
> And Y may be based on bug resolution?
> -Kev
> -- 
> counter.li.org #238656 -- goto counter.li.org and be counted!
>
> (__)
> (oo)
>   /--\/
>  / |||
> *  /\---/\
>~~   ~~
> "Have you mooed today?"...

Count the number of entries in the Packages / Sources file?

You should realy count source packages I think as that better reflects
the amount of software than all the multi deb packages.

MfG
Goswin


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

Re: General question about releases

[Jorge Bernal]

On Tuesday 18 January 2005 13:04, Goswin von Brederlow wrote:
> Count the number of entries in the Packages / Sources file?
>
> You should realy count source packages I think as that better reflects
> the amount of software than all the multi deb packages.
>
> MfG
> Goswin

Quick test:

[EMAIL PROTECTED] ~ $ for dist in stable testing unstable;do COUNT=`wget -q -O 
- http://ftp.debian.org/debian/dists/$dist/main/source/Sources.gz | gzip -cd | 
grep "^Package:" | wc -l`; echo "$dist: $COUNT";done
stable: 5220
testing: 8502
unstable: 8923


-- 
Jorge Bernal "Koke"
Personal:  [EMAIL PROTECTED]
Jabber:  [EMAIL PROTECTED]
Blog:  http://www.amedias.org/koke/

"Computer Science is no more about computers than astronomy is about 
telescopes." - Edsger Dijkstra


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

Bug#291069: ITP: pitivi -- GStreamer based non-linear audio/video editing software

[Andrew Lau]

Package: wnpp
Severity: wishlist

* Package name: pitivi
  Version : 0.1.1
  Upstream Author : European Institute of Technology
* URL : http://www.pitivi.org/
* License : GPL
  Description : GStreamer based non-linear audio/video editing software

*** DRAFT (i.e. will rewrite later) ***

Pitivi is a new application using the GStreamer multimedia framework to
manipulate a large sort of multimedia sources,

At this level of development it can be compared to a classic video
editing software. 

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.9-2-k7
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)

-- 
---
Andrew "Netsnipe" Lau   
 Debian GNU/Linux Maintainer & UNSW Computing Students' Society President
 -
  "Nobody expects the Debian Inquisition!
 Our two weapons are fear and surprise...and ruthless efficiency!"
---


signature.asc
Description: Digital signature

Bug#291071: ITP: cupid -- GStreamer based video/audio capture tool

[Andrew Lau]

Package: wnpp
Severity: wishlist

* Package name: cupid
  Version : 0.0.1
  Upstream Author : Ronald Bultje <[EMAIL PROTECTED]>
* URL : http://ronald.bitfreak.net/me/cupid.php
* License : GPL
  Description : GStreamer based video/audio recorder

*** DRAFT (will revise before release) ***

Cupid is a video/audio application based on the GStreamer multimedia
framework and supports all codecs and container formats that have
GStreamer plugins.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.9-2-k7
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)

-- 
---
Andrew "Netsnipe" Lau   
 Debian GNU/Linux Maintainer & UNSW Computing Students' Society President
 -
  "Nobody expects the Debian Inquisition!
 Our two weapons are fear and surprise...and ruthless efficiency!"
---


signature.asc
Description: Digital signature

Re: LVM packages up for adoption

[Tim Cutts]

On 17 Jan 2005, at 5:42 pm, Bastian Blank wrote:
On Mon, Jan 17, 2005 at 09:28:56AM +, Patrick Caulfield wrote:
lvm2	- in active development, upstream helpful but often busy.
device-mapper   - largely stable. occasional releases.
lvm10	- stable. no more upstream development at all.
lvm-common  - native package. small number of bugs need sorting 
out
multipath-tools - in active development, upstream very helpful.
I'm interrested onm co-maintaining lvm2 and device-mapper.
As am I - we use these heavily on some fairly serious kit at work, so I 
can justify the time... co-maintaining sounds like a sensible thing to 
do.

Tim
--
Dr Tim Cutts
Informatics Systems Group, Wellcome Trust Sanger Institute
GPG: 1024D/E3134233 FE3D 6C73 BBD6 726A A3F5  860B 3CDD 3F56 E313 4233
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LVM packages up for adoption

[Patrick Caulfield]

On Tue, Jan 18, 2005 at 03:46:18PM +, Tim Cutts wrote:
> 
> On 17 Jan 2005, at 5:42 pm, Bastian Blank wrote:
> 
> >On Mon, Jan 17, 2005 at 09:28:56AM +, Patrick Caulfield wrote:
> >>lvm2- in active development, upstream helpful but often 
> >>busy.
> >>device-mapper   - largely stable. occasional releases.
> >>lvm10   - stable. no more upstream development at all.
> >>lvm-common  - native package. small number of bugs need sorting 
> >>out
> >>multipath-tools - in active development, upstream very helpful.
> >
> >I'm interrested onm co-maintaining lvm2 and device-mapper.
> 
> As am I - we use these heavily on some fairly serious kit at work, so I 
> can justify the time... co-maintaining sounds like a sensible thing to 
> do.
> 

So how about you three co-maintain lvm2 & devmapper (and maybe lvm-common ? it's
as much part of LVM as the lvm2 package really), and I'll hang onto lvm10 &
multipath. 

-- 

patrick


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

Re: initrd, lvm, and devfs

[Peter Samuelson]

[Brian May]
> Whatever happened to the idea of even numbered kernels being
> "stable"?

You didn't get the memo?  That's an obsolete standard - the 2.6.x line
of development has been much more aggressive than past stable series,
as far as allowed tree changes, and last July or so (I think it was),
Andrew Morton announced that this policy would be purposely continued
as it seemed to be working well.

They've forfeited the responsibility to produce absolutely stable
kernels in favor of more aggressive development.  The kernel people now
say that the distribution trees are where final stabilization needs to
happen.  Which is not to say the kernel.org kernels are meant to be as
disruptive as, say, 2.3.7, but they are no longer attempting to
asymptotically approach 'perfectly stable', like 2.2.25.

Andrew Morton left open the possibility of opening up a 2.7 kernel tree
some time when some proposed tree changes were going to be *too*
disruptive (like real-SMP and dcache were in 2.1.x, I guess), but this
won't necessarily happen for awhile.


> I guess this means sarge won't work "out-of-the-box" with 2.6.11 and
> LVM unless you compile your own kernel (one that doesn't require an
> initrd image), or fix this initrd image.

If a 2.6.11 kernel makes it into sarge, then yes, someone'll have to
fix up initrd-tools for sarge as well.  Since the Debian kernel team
also maintains initrd-tools, I don't expect this issue to go unnoticed.

Peter


signature.asc
Description: Digital signature

Re: [Pre-RFA] Intending to drop twenty-some packages

[Rafael Laboissiere]

* Dirk Eddelbuettel <[EMAIL PROTECTED]> [2005-01-15 11:51]:

> I have tried to unload this onto Rafael for a few years now, but he can't
> take Octave either.  This may be best served by a maintainer group via
> alioth, and I could be persuaded to help. But I can't set up such a group
> or lead it, for lack of time.

The project pkg-octave has just been created at Alioth, as well as a mailing
list for general development discussion
([EMAIL PROTECTED]).  I set the Reply-To for this
message to that list, so that further discussion can continue there.  

The goal is to encourage co-maintenance of as many Octave-related packages
in the pkg-octave project at Alioth as we can.  Developing a common
infrastructure for add-on Octave package building is also in our plans.  Any
Debian maintainer/developer interested in Octave related packages is
encouraged to join this project.
 
-- 
Rafael


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

Re: LVM packages up for adoption

[Tim Cutts]

On 18 Jan 2005, at 4:06 pm, Patrick Caulfield wrote:
On Tue, Jan 18, 2005 at 03:46:18PM +, Tim Cutts wrote:
On 17 Jan 2005, at 5:42 pm, Bastian Blank wrote:
On Mon, Jan 17, 2005 at 09:28:56AM +, Patrick Caulfield wrote:
lvm2	- in active development, upstream helpful but often 
busy.
device-mapper   - largely stable. occasional releases.
lvm10	- stable. no more upstream development at all.
lvm-common  - native package. small number of bugs need sorting
out
multipath-tools - in active development, upstream very helpful.
I'm interrested onm co-maintaining lvm2 and device-mapper.
As am I - we use these heavily on some fairly serious kit at work, so 
I
can justify the time... co-maintaining sounds like a sensible thing to
do.

So how about you three co-maintain lvm2 & devmapper (and maybe 
lvm-common ? it's
as much part of LVM as the lvm2 package really), and I'll hang onto 
lvm10 &
multipath.
Sounds good to me.  I'll be able to help you with testing 
multipath-tools too; that and lvm2 are the principal bits we use (we 
don't use Debian device-mapper stuff because we build our own kernels 
from scratch)

We use this stuff on both IA64 (HP rx4640) and i386 (HP DL360/380, 
mostly) architectures to talk to our dual-fabric SAN (HP StorageWorks 
HSV110 controllers on the back)

How should we coordinate this?
Tim
--
Dr Tim Cutts
Informatics Systems Group, Wellcome Trust Sanger Institute
GPG: 1024D/E3134233 FE3D 6C73 BBD6 726A A3F5  860B 3CDD 3F56 E313 4233
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LVM packages up for adoption

[Andres Salomon]

On Tue, 18 Jan 2005 17:11:50 +, Tim Cutts wrote:

> 
> On 18 Jan 2005, at 4:06 pm, Patrick Caulfield wrote:
> 
>> On Tue, Jan 18, 2005 at 03:46:18PM +, Tim Cutts wrote:
>>>
>>> On 17 Jan 2005, at 5:42 pm, Bastian Blank wrote:
>>>
 On Mon, Jan 17, 2005 at 09:28:56AM +, Patrick Caulfield wrote:
> lvm2  - in active development, upstream helpful but often 
> busy.
> device-mapper   - largely stable. occasional releases.
> lvm10 - stable. no more upstream development at all.
> lvm-common  - native package. small number of bugs need sorting
> out
> multipath-tools - in active development, upstream very helpful.

 I'm interrested onm co-maintaining lvm2 and device-mapper.
>>>
>>> As am I - we use these heavily on some fairly serious kit at work, so 
>>> I
>>> can justify the time... co-maintaining sounds like a sensible thing to
>>> do.
>>>
>>
>> So how about you three co-maintain lvm2 & devmapper (and maybe 
>> lvm-common ? it's
>> as much part of LVM as the lvm2 package really), and I'll hang onto 
>> lvm10 &
>> multipath.
> 
> Sounds good to me.  I'll be able to help you with testing 
> multipath-tools too; that and lvm2 are the principal bits we use (we 
> don't use Debian device-mapper stuff because we build our own kernels 
> from scratch)
> 
> We use this stuff on both IA64 (HP rx4640) and i386 (HP DL360/380, 
> mostly) architectures to talk to our dual-fabric SAN (HP StorageWorks 
> HSV110 controllers on the back)
> 
> How should we coordinate this?
> 

My recommendation would be an LVM alioth project, w/ a svn or arch
(preferred) repository.  I've kept track of lvm2 stuff in arch for a
number of years, it has worked well.

Patrick, it might even be worth all 4 of us maintaining all the LVM
related packages (throwing lvm10 in with the rest), since Tim uses
multipath-tools, and none of us care much for lvm10.




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

/sbin/halt always changes its access rights

[Otto Wyss]

I've set the s attrtibute of halt since on my desktop any user may stop
the system. But about each second month or so it's set back to it's
original rights probably by a package upgrade. Is there a way to keep
the access rights or any better way to handle these kind of problems.

O. Wyss

-- 
Development of frame buffer drivers: http://linux-fbdev.sf.net
Sample code snippets for wxWidgets: http://wxcode.sf.net
How to build well-designed applications: http://wxguide.sf.net
Desktop with a consistent look and feel: http://wyodesktop.sf.net


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

Re: /sbin/halt always changes its access rights

[Peter Samuelson]

[Otto Wyss]
> I've set the s attrtibute of halt since on my desktop any user may
> stop the system. But about each second month or so it's set back to
> it's original rights probably by a package upgrade. Is there a way to
> keep the access rights or any better way to handle these kind of
> problems.

dpkg-statoverride --add root root 02755 /sbin/halt

Peter


signature.asc
Description: Digital signature

Re: initrd, lvm, and devfs

[Alex Owen]

Some of us have woody running on LVM1... well I have this with 2.4 Debian
kernel and LVM1. For LVM1 to work with a kernel that has devfs compiled in
(debian kernels for woody do) then /dev/ has to be a mounted devfs.

For people such as myself sarge as it stands will provide a 2.4.27 kernel
with devfs and LVM1... This will allow us to upgrade to sarge fairy
painlessly.

Debian-installer on the other hand will install sarge on LVM2 and that
gives people in my position the hint that we need to migrate to LVM2 during
the lifetime of sarge (and probably 2.6 kernels too).

During the testing of etch (ie when etch is "testing") debian will hit
this "removal of devfs" problem... this will not affect sarge (Assuming sarge
_IS_ released by then). etch is the place to fix the problem. The fix will
be in 4 parts...
(1) the kernel package will have no devfs!
(2) initrd-tools will be fixed to support the kernel packages.
(3) udev can provide compatability links for devfs names if needed.
(4) debian-installer will be ported to use udev rather than devfs

People who wish to use non-debian stable kernels on sarge (when it is
released) will have to backport these fixes from etch to sarge... much as
I have had to from sarge to woody to get LVM1 to work on woody!

Taking these in reverse...
(4) from what I've seen of the d-i work the d-i folks know that a port
from devfs to udev is on the post sarge todo list.

(3) udev can alredy provide devfs style device nodes... can it do
compatability links?

(2) this thread has alerted initrd-tools people... I hope!

(1) this thread has alerted kernel people... I hope!


The only remaining question is are the devfs device names burned into the
LVM2 metadata stored on disk somewhere??? I suspect not... I think that
LVM2 uses somekind of UUID to identify devices that form part of an LVM2
VG. If this UUID business is the case then do we need (3) ???

Hopefully by the time etch arrives as stable there will be a sane upgrade
for sarge-LVM2 people to become etch-LVM(n>1) people.

I hope this is a usefull contribution and not just a brain dump!

Alex Owen
Debian User and SysAdmin


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

Re: Bug#271567: Can you disables the "locking" of the keyboard, mouse, ...

[Osamu Aoki]

Hi,

(Disclaimer: I never coded C seriously for any useful commands.)

On Mon, Jan 17, 2005 at 11:24:05PM -0200, Gustavo Noronha Silva wrote:
> Em Qui, 2005-01-13 às 19:12 +0100, Osamu Aoki escreveu:
> >  * Parsing of GNU long-option and /etc/gksu.conf may share codes.
> 
> I don't know what you mean, maybe I'm doing some dumb thing on my patch,
> but I don't think how to completely share code here.

First add these extra long options to "struct option long_opts[] = { ..."

Then right before calling "gtk_init (&newargc, &newargv);" you source
/etc/gksu.conf and treat each line (not started with #) being part of
long option on the command line arguments by appending to this command
line option, I guess, to list started with &newargv.  (I forgot how
argument is passed to getopt_long function.  But as long as the logic of
parsing command line arguments is properly combined with gksu.conf
parsing, it should work.)

At last, assign short option character to each long options.

getopt_long is shared this way.

> >  * All /etc/gksu.conf entries to match gnu-long-options of gksu command-line
> >  * add new long-option: --force-grab
> 
> Why add this? I don't see a reason.

Without this, once account is compromised, it is easy to mkodify user
menu to --allow-grab and you may unknowlingly run gksu while other
process watching the keystroke of root password.  By preventing it
forcebly, it gives extra thin layer of protection.

> >  * add new long-option: --sudo-mode (Start it with gksudo mode)
> 
> Done.
> 
> >  * add new long-option: --limit-uid=UID1:UID2:UID3:...
> >  * add new long-option: --limit-gid=GID1:GID2:GID3:...
> 
> If we add this, then we really need to have the gksu.conf have priority
> over user-options, or this simply should not be a long option at all,
> because gksu has no suid parts, so a user can simply build a costumized
> version which will ignore this. I don't see a real point.

This is for a system user should not even try to run program with gksu.
Since menu will present these program such as synaptic, people expect
something to happen by entring password.  We may give them a chance to
break it by chance (root password may be easy one to guess.).  Why not
just tell "You are not allowed tun this program."  This is more for
administerd host.  Totally wishlist item you canm ignore this time.

> >  * add new long-option: --prompt (prompt before locking I/O)
> >  * add new long-option: --no-prompt (do not prompt before locking I/O: 
> > default)
> 
> Then we only need one of these.

* add new long-option: --prompt (prompt before locking I/O)
only is fine with me.

> > I think the setting in /etc/gksu.conf should have priority over
> > command-line so super user controls this command's behavior.  Gksu
> 
> As I explained above, I don't see a reason for this to be like this. I
> think it should contain defaults, not mandatory options.

If you chose not to impliment --limit-uid/gid thingy, this is true.

> > simple trick to prevent freeze for start-up situation.  This is not
> > fancy trick which works for Gnome or KDE.  Just provide prompt screen
> > before locking I/O.
> 
> That's a solution, but I would still love to find out how to play with
> session stuff without adding a Depends on libgnomeui.

Prompting is ugly hack but certainly avoid it without Depends on
libgnomeui.  If you find a good alternative, I will be happy with that too.

> > Then you can close all the bugs I listed in the previous mail and no one
> > will complain.  We will add hints to README.Debian for SCIM.
> 
> =D
> 
> > PS: I browsed your code to find gksudo binary being the same hardlink as
> > gksu except filename.  Please also link gksudo.1 to manpage :-)
> 
> Yeah, have to document gksudo again =/.
> 
> I've made a simple patch, a first implementation for this whole that
> still needs to be polished a lot. Would you mind to apply it, test it
> and criticize it? Here:
> 
> http://people.debian.org/~kov/gksu/patches/conf-file.diff
> 
> It worked alright with a simple test config file:
> 
> $ cat /etc/gksu.conf
> # isso é um comentário
> disable-grab = yes # isso é outro comentário
> # mais comentário

That is pt-br.  Although pt-br may be 2nd most spoken foreign language
in Japan, I do not understand :-(  (I used to hear quite a bit of pt-br
in the shopping center in suburban Nagoya when I was living in Japan.)

Osamu

Re: binaries for different architectures in debian packages

[Chad Walstrom]

I don't read the Debian Devel list all that often, as it's traffic rate
is far too much for me to keep up with. ;-)  In any case, I was referred
to your post by the Debian Weekly News article on it (you're pretty
popular right now).  I would have to agree with posters that suggested
you follow the standard FHS recommendations for file placement: binary
files in a /usr/lib subdirectory, architecture independent files in a
/usr/share directory, etc.

The reason I say this is because coupled with dpkg's ability to specify
the root directory for installation, sharing files over the network can
be customized by the operating system tools available.  For example,
using NFS with NIS or LDAP and the automount daemon can automate
mounting for diskless clients to the correct, architecture-dependent
(/usr/lib) shares as well as the architecture-independent (/usr/share)
shares.  Installing packages under /srv/arch-os and /srv/common is a
real possibility.  As a bonus, you can use the same root directories
with all (most) Debian packages for all of your diskless clients.

A trick with mount, the --bind option, would allow you to bind the
/srv/common/usr/share directory to /srv/arch-os/usr/share.  NFS, Samba,
and Netatalk wouldn't know the difference, allowing you to mount
/srv/arch-os as your root filesystem for arch-os.

You just need to be careful about how you split up your packages.  Using
an arch-independent package for the /usr/share files (a common package)
and arch-dependent packages for the /usr/lib files should make this type
of setup easy.

The NFS/NIS book by O'Reilly is a great place to start for planning a
network shared infrastructure.  Pay particular attention to some of
automount's mapfile structure and its ability to specify programs to
resolve shares and mount points.

-- 
Chad Walstrom <[EMAIL PROTECTED]>   http://www.wookimus.net/
   assert(expired(knowledge)); /* core dump */


signature.asc
Description: Digital signature

Re: initrd, lvm, and devfs

[Joey Hess]

Christoph Hellwig wrote:
> so unless Debian wants to stay with stoneage kernels you're better of
> starting to fix D-I.

We're not going to destabalise d-i by beginning to make large changes to
it, like not using devfs, until sarge is released.

FWIW, the main current d-i release blocker is a lack of security updated
kernels for all architectures in testing.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: initrd, lvm, and devfs

[Goswin von Brederlow]

Alex Owen <[EMAIL PROTECTED]> writes:

> Some of us have woody running on LVM1... well I have this with 2.4 Debian
> kernel and LVM1. For LVM1 to work with a kernel that has devfs compiled in
> (debian kernels for woody do) then /dev/ has to be a mounted devfs.
>
> For people such as myself sarge as it stands will provide a 2.4.27 kernel
> with devfs and LVM1... This will allow us to upgrade to sarge fairy
> painlessly.
>
> Debian-installer on the other hand will install sarge on LVM2 and that
> gives people in my position the hint that we need to migrate to LVM2 during
> the lifetime of sarge (and probably 2.6 kernels too).

Debian kernels (2.4.x) are already patched with the device mapper
patches and are fully lvm2 capable. Since lvm2 understands lvm1
metadata you can just update to lvm2 userspace tools, create a new
initrd and reboot.

> During the testing of etch (ie when etch is "testing") debian will hit
> this "removal of devfs" problem... this will not affect sarge (Assuming sarge
> _IS_ released by then). etch is the place to fix the problem. The fix will
> be in 4 parts...
> (1) the kernel package will have no devfs!
> (2) initrd-tools will be fixed to support the kernel packages.
> (3) udev can provide compatability links for devfs names if needed.
> (4) debian-installer will be ported to use udev rather than devfs

Without devfs the syntax of e.g. /proc/partitions changes and anything
parsing those files needs to adapt back to the old syntax.

> People who wish to use non-debian stable kernels on sarge (when it is
> released) will have to backport these fixes from etch to sarge... much as
> I have had to from sarge to woody to get LVM1 to work on woody!
>
> Taking these in reverse...
> (4) from what I've seen of the d-i work the d-i folks know that a port
> from devfs to udev is on the post sarge todo list.
>
> (3) udev can alredy provide devfs style device nodes... can it do
> compatability links?
>
> (2) this thread has alerted initrd-tools people... I hope!
>
> (1) this thread has alerted kernel people... I hope!
>
>
> The only remaining question is are the devfs device names burned into the
> LVM2 metadata stored on disk somewhere??? I suspect not... I think that
> LVM2 uses somekind of UUID to identify devices that form part of an LVM2
> VG. If this UUID business is the case then do we need (3) ???

I've used lvm2 with and without devfs and switched between them
without problems. It's just a matter of changing fstabd and the likes.

> Hopefully by the time etch arrives as stable there will be a sane upgrade
> for sarge-LVM2 people to become etch-LVM(n>1) people.
>
> I hope this is a usefull contribution and not just a brain dump!
>
> Alex Owen
> Debian User and SysAdmin

MfG
Goswin


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

Re: Bug#271567: Can you disables the "locking" of the keyboard, mouse, ...

[Gustavo Noronha Silva]

Hey!

Em Ter, 2005-01-18 Ãs 22:34 +0100, Osamu Aoki escreveu:
> First add these extra long options to "struct option long_opts[] = { ..."
> 
> Then right before calling "gtk_init (&newargc, &newargv);" you source

I see your point (even more after reading your other post), but I think
messing up with argv is evil. I would also like to keep things codes
separated, as I don't think providing every long option on the config
file is useful, and some options should only be in the config file, like
force-grab.

> > >  * All /etc/gksu.conf entries to match gnu-long-options of gksu 
> > > command-line
> > >  * add new long-option: --force-grab
> > 
> > Why add this? I don't see a reason.
> 
> Without this, once account is compromised, it is easy to mkodify user
> menu to --allow-grab and you may unknowlingly run gksu while other
> process watching the keystroke of root password.  By preventing it
> forcebly, it gives extra thin layer of protection.

Added.

> This is for a system user should not even try to run program with gksu.
> Since menu will present these program such as synaptic, people expect
> something to happen by entring password.  We may give them a chance to
> break it by chance (root password may be easy one to guess.).  Why not
> just tell "You are not allowed tun this program."  This is more for
> administerd host.  Totally wishlist item you canm ignore this time.

Will ignore for now, then.

> * add new long-option: --prompt (prompt before locking I/O)
> only is fine with me.

I understand that the user might want to override the admin setting of
--prompt, so I added optional arguments for --disable-grab, --prompt and
--sudo-mode, so the user can do --prompt=no in case the admin added
"prompt = yes" to the config file.

> Prompting is ugly hack but certainly avoid it without Depends on
> libgnomeui.  If you find a good alternative, I will be happy with that too.

I'll keep trying, but prompt is there for now.

> > $ cat /etc/gksu.conf
> > # isso à um comentÃrio
> > disable-grab = yes # isso à outro comentÃrio
> > # mais comentÃrio
> 
> That is pt-br.  Although pt-br may be 2nd most spoken foreign language
> in Japan, I do not understand :-(  (I used to hear quite a bit of pt-br
> in the shopping center in suburban Nagoya when I was living in Japan.)

=D

those were simply to test comments were being ignored and not destroying
the real options parsin... it basically says:

# this is a comment
disable-grab = yes # this is another comment
# more comment

I've made a new patch I'd like you to try out:

http://people.debian.org/~kov/gksu/patches/prompt-conf-file-enhancements.diff

I hope I'll be uploading by the end of the week, after polishing this
whole thing up. Time is scarse, but I'm moving forward.

Thanks!

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
 Debian:   *  

Re: xfce-goodies - help needed; Rudy Godoy MIA?

[Andrew Lau]

On Mon, Jan 17, 2005 at 12:50:55AM +, Simon Huggins wrote:
> > There are currently 11 orphaned xfce4-* packages in unstable, including
> > three that have just been removed from testing due to RC bugs that went
> > virtually unnoticed since the last upload in May.
> 
> I know the -goodies packages are in bad shape.
> 
> > Please take some time to help figure out what should be done with
> > these packages -- cleaned up/adopted, or removed from the archive --
> > before ITPing more packages in the xfce4 namespace.
> 
> Sure.  I think for sarge they can be cleaned up/updated.  I've just
> finished a stretch getting the 22 packages for the main body of xfce4
> for 4.2.0 for experimental sorted this weekend so I'm a bit knackered
> currently.
> 
> To be honest I'd been expecting others to sort out the -plugins for
> sarge given people had said they would.

Hi Simon,

Being the maintainer that parented the xfce4-goodies Debian packages I
feel somewhat responsible for the current state that they're in. I only
have so much time free to work on them since I switched over to working
with the Debian-GNOME team, but since a freeze is "coming soon (TM)", I
would be willing to help co-maintain them and get them back on the road
again.

Apart from time constraints, I've been reluctant to update xfce4-goodies
again since I don't have XFce 4.2 libraries to build against.

One thing that would get the ball moving again would be to check
everything into a svn.debian.org tree so that almost anyone can chip in
(just like in pkg-gnome).

Cheers,
Andrew "Netsnipe" Lau

-- 
---
Andrew "Netsnipe" Lau   
 Debian GNU/Linux Maintainer & UNSW Computing Students' Society President
 -
  "Nobody expects the Debian Inquisition!
 Our two weapons are fear and surprise...and ruthless efficiency!"
---


signature.asc
Description: Digital signature

Re: hwcap supporting architectures?

[Marcelo E. Magallon]

On Mon, Jan 17, 2005 at 05:52:04PM +0900, GOTO Masanori wrote:

 > > > > Yes, and if ev67 is instruction upper compatible with ev56 (I
 > > > > guess so), I think it's acceptable to add a symlink "ln -sf
 > > > > lib/ev67/libfoo.so lib/ev56/libfoo.so".
 > > > 
 > > > Ugh... that pushes the burden of maitaining support for new
 > > > architectures to the package.
 > 
 > Yeah - I think it's trade off - whether we support library
 > optimization package or we don't get a bit performance improvement.

 So, you are trading maintainance cost for a rather subjective speed
 improvent?  Or should I say, preventing some performance degradation?

 Keep reading.

 > > >  Please bear with me, but I'm trying to understand the issue: is
 > > >  the cost of calling access(2) or stat(2) really so high?
 > > 
 > > I'd consider it quite acceptable in this case. However, as I tried
 > > to express, it's not possible with glibc's current "design", and I
 > > didn't feel like changing that.
 > 
 > Note that we should keep in mind: imagine most binaries on all debian
 > system over the world start to consume access(2)/stat(2) system call
 > cost in each binary execution time - "Many a little makes a mickle".

 Ok, I stopped buying this kind of argument long ago.  There's a
 SIGGRAPH paper (2001 IIRC) which justifies certain kind of rather
 complex optimization because a (graphics) context switch is "too
 expensive", without actually defining the situation that triggers the
 context switch in a clear fashion.  In my own testing context switches
 of the kind described in that paper are at least a factor of 100
 _faster_ than what the authors claim.

 Attached is a program that measures the time a single stat(2) call
 takes.  I get circa 5 microseconds per stat(2) call on my computer (AMD
 Athlon 1600+, can't recall what kind of memory it has right now). Note
 that the code that doesn't directly have to do with the stat(2) has a
 rather low overhead (circa 1 ns on my system).

 What that means is that you need to make about 2000 stat(2) calls to
 get _anywhere_ near what's measurable by a human and about 2 to
 start getting said human annoyed.

 If a biggish GNOME program (Epiphany Browser) links to 60 libraries,
 you need to perform a lookup in ~ 30 paths for the start up delay to be
 measurable and ~ 300 for it to be annoying.  ls(1) links to 6
 libraries.  That's one order of magnitude less, IOW, you need a path
 with ~ 3000 components to start being annoying.

 So, what exactly are you talking about?

 > > > I see for example that on start up the file /etc/ld.so.nohwcap is
 > > > accessed multiple times (and it's not present, isn't that a race?
 > > > what happens if the file suddenly appears in the middle of
 > > > program start up? what's that file anyway, I can't find it
 > > > mentioned in the documentation).
 > > 
 > > It's supposed to disable the use of hwcaps. Stating it multiple
 > > times seems like a bug.

 The contents does not matter?

 > Debian glibc has been applied a special patch to check
 > /etc/ld.so.nohwcap before loading libraries each time.  You can see
 > it in debian-glibc package ldso-disable-hwcap.dpatch written by Ben
 > and Daniel.  It enables us to upgrade smoothly even if we use
 > optimized libraries - this effort is one of debian's nice features.
 > But the drawback is it needs to pay access(2) lookup cost as you
 > pointed out.
 > 
 > Checking /etc/ld.so.nohwcap each time (some binaries call multiple
 > times) is the current patch design

 Why?  I just can't see a valid reason for "wanting" the file to
 suddenly pop up while the program is running.

 > I think this is safer than checking /etc/ld.so.nohwcap once in
 > program startup time.

 Safer in what way?

 Again, I just don't buy that "system calls are too expensive" argument.
 Anyone writing shell scripts cares about a whole lot of things *but*
 performance.  And I'm not talking about increasing running time by a
 factor of anything, I'm talking about adding a bunch of microseconds,
 which get lost in the middle of filesystem stalls, page faults and
 other rather common events.

 Marcelo
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, char * argv[])
{
const int N = 6;
char name[N+1];

for(int i=0; i < N; ++i)
name[i] = '0';
name[N] = 0;

struct timeval t0, t1;

gettimeofday(&t0, NULL);
for(int i=0; i < N;)
{
struct stat buf;
stat(name, &buf);
for(i=0; i != N && ++name[i] == '9'+1; ++i)
name[i]='0';
}
gettimeofday(&t1, NULL);

float dt = (t1.tv_sec - t0.tv_sec) + (t1.tv_usec - t0.tv_usec)*1E-6;

printf("%g\n", dt/powf(10, N));

return 0;
}

Re: hwcap supporting architectures?

[GOTO Masanori]

At Tue, 18 Jan 2005 22:09:03 -0600,
Marcelo E. Magallon <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 17, 2005 at 05:52:04PM +0900, GOTO Masanori wrote:
> 
>  > > > > Yes, and if ev67 is instruction upper compatible with ev56 (I
>  > > > > guess so), I think it's acceptable to add a symlink "ln -sf
>  > > > > lib/ev67/libfoo.so lib/ev56/libfoo.so".
>  > > > 
>  > > > Ugh... that pushes the burden of maitaining support for new
>  > > > architectures to the package.
>  > 
>  > Yeah - I think it's trade off - whether we support library
>  > optimization package or we don't get a bit performance improvement.
> 
>  So, you are trading maintainance cost for a rather subjective speed
>  improvent?  Or should I say, preventing some performance degradation?

The reason why I don't try to clear hwcap issue in documentation is: I
don't want to battle to someone about this kind of issue.  Buying new
hardware improves performance.  I don't reply any more.

Regards,
-- gotom


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