Re: Extending the update-rc.d API to change runlevel and disable scripts?

[sean finney]

On Friday 25 April 2008 06:24:41 pm Russ Allbery wrote:
> Yes please.  Another desperately needed feature is a query interface that
> will tell you exactly the current state of a given init script, for use by
> other automated tools.  Currently, Puppet hacks around this in some really
> ugly ways since there's no good interface for this.

you mean like invoke-rc.d --query ?

otherwise, yes i think it would be quite useful to have those features, as i 
regularly see people recommending users in #debian the *wrong* thing to do to 
disable a service with the existing update-rc.d implementation.

either that or have something like chkconfig/insserv installed by default.

sean


signature.asc
Description: This is a digitally signed message part.

Re: Extending the update-rc.d API to change runlevel and disable scripts?

[Russ Allbery]

sean finney <[EMAIL PROTECTED]> writes:
> On Friday 25 April 2008 06:24:41 pm Russ Allbery wrote:

>> Yes please.  Another desperately needed feature is a query interface
>> that will tell you exactly the current state of a given init script,
>> for use by other automated tools.  Currently, Puppet hacks around this
>> in some really ugly ways since there's no good interface for this.

> you mean like invoke-rc.d --query ?

No, that seems to be something completely different.

Puppet needs to know if a given init script is configured to ever start or
whether it's administratively disabled (K scripts at every runlevel), what
runlevels it starts and stops at (more generally), and its priority
(although dependency-based boot should make that unnecessary).

Puppet would also love to be able to disable a script and then put it back
with the same priority that it had before, although dependency-based boot
will make that obsolete soon enough, hopefully.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: [OT] Need old Packages.gz and Release Files

[Andreas Metzler]

Gunnar Wolf <[EMAIL PROTECTED]> wrote:
> Thomas Weber dijo [Fri, Apr 25, 2008 at 09:25:04AM +0200]:
>> >  j> By the way, it would be great if the mirrors kept more than just a
>> >  j> week of Diffs.
[...]
> Diffs are often quite small. The time needed to establish a connection
> is often comparable to the time a diff takes to be downloaded... So,
> even with pipelining and all, storing too many diffs becomes
> irrelevant. 

That is only true if you trying to optimize for time, instead of minimal
download volume. And I doubt that 7 days is the sweet spot, Packages.gz is
huge:

[EMAIL PROTECTED]:/org/ftp.root/debian/dists/sid/main/binary-i386$ du -sh 
/org/ftp.root/debian/dists/sid/main/binary-i386/Packages.gz 
/org/ftp.root/debian/dists/sid/main/binary-i386/Packages.diff/
6,7M/org/ftp.root/debian/dists/sid/main/binary-i386/Packages.gz
344K/org/ftp.root/debian/dists/sid/main/binary-i386/Packages.diff/

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


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

Bug#475772: marked as done (dpkg should set GREP_OPTIONS)

[Debian Bug Tracking System]

Your message dated Sat, 26 Apr 2008 16:23:56 +0900
with message-id <[EMAIL PROTECTED]>
and subject line Your odd GREP_OPTIONS setting is not package problem
has caused the Debian Bug report #475772,
regarding dpkg should set GREP_OPTIONS
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
475772: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475772
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---

Package: a lot of them

I've recently set GREP_OPTIONS='--color=always' in my bashrc.  I do this 
mainly so that I can see grep's highlighted findings even when viewing 
through a pipeline, such as with less.  '--color=auto' won't work 
because it will turn off the color escapes if it's going down the 
pipeline, which is not what I want when I use less.


This poses a problem for a lot of scripts, which assume that text coming 
from their stdin is free from (color) escapes.  For instance, I recently 
went to install postgresql-client-8.2 in Ubuntu.  (I recognize that 
Ubuntu != Debian.  However, this is also a problem in Etch that I just 
didn't report earlier, and I think it could be addressed in both distros.)


> $ sudo apt-get install postgresql
>...

Setting up postgresql-client-8.2 (8.2.7-0ubuntu0.7.10) ...
update-alternatives: unable to make 
/usr/share/postgresql/8.2/man/man1/dropuser.1.gz.dpkg-tmp a symlink to 
/etc/alternatives/dropuser.1.gz: No such file or directory


^^^

The  is color-escaped, which is no good for the symlinking.

I think an appropriate solution would be to unset or export 
GREP_OPTIONS='--color=none' in the beginning of scripts that rely on grep.


Kevin


--- End Message ---
--- Begin Message ---
Hi,

(I do not understand why the submitter does not use
GREP_OPTIONS='--color=auto'.)

Anyway, you can break many normal program operations if you set
unreasonable value to environment variables.  This is not just
GREP_OPTION for grep but you can have fun with TAPE or TAR_OPTIONS for
tar. It is only yourself to blame.

Since submitter said "smart" to other fix method, it is best to close
this bug.

Cheers,

Osamu


--- End Message ---

Re: Blocking uploads of packages involved in the Python 2.5 transition

[Daniel Baumann]

Adeodato Simó wrote:
> A list of blocked packages can be found at [3].

would it be possible to add the maintainer information to that list?

rather than

  - $package

it would be helpful to have something like

  - $package ($maintainer)

Regards,
Daniel

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  [EMAIL PROTECTED]
Internet:   http://people.panthera-systems.net/~daniel-baumann/


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

Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo

[Riku Voipio]

On Fri, Apr 25, 2008 at 05:06:59PM +0200, Petter Reinholdtsen wrote:
> 'arm' is said to be LE, but I believe it differ for integers and
> floating point numbers.  Is 'arm' in the list the 'arm' archtecture?
> What about 'armel' and 'armeb'?

on arm (unlike armeb and armel), doubles are two little-endian words
stored bigendian.


-- 
"rm -rf" only sounds scary if you don't have backups


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

Re: Blocking uploads of packages involved in the Python 2.5 transition

[Adeodato Simó]

* Daniel Baumann [Sat, 26 Apr 2008 10:41:17 +0200]:

> Adeodato Simó wrote:
> > A list of blocked packages can be found at [3].

> would it be possible to add the maintainer information to that list?

> rather than
>   - $package

> it would be helpful to have something like
>   - $package ($maintainer)

That'd be a bit inconvenient to maintain for us, plus it'd require
further changes in dak, making the parser a bit more complex, which I
think ftpmaster wants to avoid.

However, it's trivial to generate a list of maintainers:

  % wget -qO- http://ftp-master.debian.org/testing/hints/transitions.yaml |
sed -ne 's/^[^-]*- //p' | dd-list --stdin

Maybe, if there's enough demand, we/somebody could set a cron to create
such listing.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
The pure and simple truth is rarely pure and never simple.
-- Oscar Wilde


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

Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo

[Florian Weimer]

* Cyril Brulebois:

> I'm wondering whether the ArchitectureSpecificsMemo[1] wiki page is
> (well-)known, and whether its content got reviewed, esp. by porters of
> each architecture, who could fix obvious errors or typos, or eventually
> add special-cases, exceptions, and the like.

I hope the table can be simplified, along the categories LP32/LP64,
endianness, char signedness.  sizeof(long double) needs to be listed
separately, along with it's range/precision.

Hopefully, we will never end up with an architecture where sizeof(long)
!= sizeof(void *) or sizeof(int) != 4.


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

Package builds when depending a specific locale

[Murat Demirten]

Hi,

I've a problem with manpages-tr package build process. It is binary
independent package, basically contains man pages.

But package author uses a different aproach to build man pages from xml
sources. There is an xml2man.c which used on build process
to obtain man pages. And this utility can not be run properly if tr_TR.UTF-8
locale does not exist at build system. This breaks our automatic
rebuild systems, so how can we address this problem? Any ideas..

murat,

Re: Package builds when depending a specific locale

[Bernhard R. Link]

* Murat Demirten <[EMAIL PROTECTED]> [080426 13:24]:
> I've a problem with manpages-tr package build process. It is binary
> independent package, basically contains man pages.
> 
> But package author uses a different aproach to build man pages from xml
> sources. There is an xml2man.c which used on build process
> to obtain man pages. And this utility can not be run properly if tr_TR.UTF-8
> locale does not exist at build system. This breaks our automatic
> rebuild systems, so how can we address this problem? Any ideas..

Build-depending on locales-all, maybe?

Hochachtungsvoll,
Bernhard R. Link


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

Re: Package builds when depending a specific locale

[Murat Demirten]

Hi,

But locales-all package doesn't install the pre-compiled locales into right
destinations.

It contains /usr/lib/locales-all/supported.tar.lzma file which includes all
the locales but you have to manually extract it.

So, problem still continue, any suggestion?

On Sat, Apr 26, 2008 at 2:40 PM, Bernhard R. Link <[EMAIL PROTECTED]> wrote:

> * Murat Demirten <[EMAIL PROTECTED]> [080426 13:24]:
> > I've a problem with manpages-tr package build process. It is binary
> > independent package, basically contains man pages.
> >
> > But package author uses a different aproach to build man pages from xml
> > sources. There is an xml2man.c which used on build process
> > to obtain man pages. And this utility can not be run properly if
> tr_TR.UTF-8
> > locale does not exist at build system. This breaks our automatic
> > rebuild systems, so how can we address this problem? Any ideas..
>
> Build-depending on locales-all, maybe?
>
> Hochachtungsvoll,
>Bernhard R. Link
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
>
>


-- 
Murat Demirten
Genel Müdür
Yenihayat Bilişim Teknolojileri A.Ş.
(212) 210 77 36

Bug#72140: bug #72140 closed by recent dpkg?

[Alvaro Herrera]

Hi,

Isn't this bug closed by the 1.14.17 dpkg upload?

-- 
Alvaro Herrera  Developer, http://www.PostgreSQL.org/
"La fuerza no está en los medios físicos
sino que reside en una voluntad indomable" (Gandhi)



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

Re: Bug#477699: general: No read permission for /usr/include/GL directory

[Heikki Orsila]

On Fri, Apr 25, 2008 at 08:18:04PM +0200, Tollef Fog Heen wrote:
> * Heikki Orsila 
> 
> (Cc-ing you as I don't know if you're on debian-devel or not;
> apologies if you are subscribed).

Thanks. I'm not on the list.

> Somebody suggested the proprietary Nvidia and ATI installers sometimes
> set the permissions wrongly.  Have you used either of those?  If not,
> I think we'll have to put this down as a heisenbug which we can't fix
> unless you find a way to reproduce the problem.

I have installed several versions of nVidia drivers with their shell 
script installer.

-- 
Heikki Orsila
[EMAIL PROTECTED]
http://www.iki.fi/shd


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

Bug#478051: ITP: php5-geoip -- This package provides a module for Maxmind's GeoIP functions in PHP

[Sergey B Kirpichev]

Package: wnpp
Severity: wishlist
Owner: Sergey B Kirpichev <[EMAIL PROTECTED]>

* Package name: php5-geoip
  Version : 1.0.2
* URL : http://pecl.php.net/package/geoip
* License : PHP
  Programming Lang: C
  Description : This package provides a module for Maxmind's GeoIP 
functions in PHP

  This PHP extension allows you to find the location of an IP
  address - City, State, Country, Longitude, Latitude, and other information
  as all, such as ISP and connection type. For more info, please
  visit Maxmind's website.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (1001, 'testing'), (50, 'unstable')
Architecture: i386 (i686)



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

Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo

[Ben Hutchings]

On Sat, 2008-04-26 at 12:29 +0200, Florian Weimer wrote:
> * Cyril Brulebois:
> 
> > I'm wondering whether the ArchitectureSpecificsMemo[1] wiki page is
> > (well-)known, and whether its content got reviewed, esp. by porters of
> > each architecture, who could fix obvious errors or typos, or eventually
> > add special-cases, exceptions, and the like.
> 
> I hope the table can be simplified, along the categories LP32/LP64,
> endianness, char signedness.  sizeof(long double) needs to be listed
> separately, along with it's range/precision.
> 
> Hopefully, we will never end up with an architecture where sizeof(long)
> != sizeof(void *)

Linux has a convention predating intptr_t of using long for that
purpose, so Linux won't allow such an ABI.

>  or sizeof(int) != 4.

GNU requires that, unless I'm much mistaken.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo

[Ben Hutchings]

On Sat, 2008-04-26 at 00:15 -0400, Zack Weinberg wrote:
> I looked at the page: this seems like an appropriate moment to mention
> something that should be a lot more widely known than it is:
> 
>sizeof(char) == 1
>sizeof(signed char) == 1
>sizeof(unsigned char) == 1
> 
> Those three equalities are not part of any ABI.  They are written into
> the C standard, in the definition of the sizeof() operator.  They will
> never be false.

I just removed them for this reason.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Re: NMU rules for security fixes (was: DEP1: Clarifying policies and workflows for Non Maintainer Uploads)

[Thijs Kinkhorst]

On Saturday 26 April 2008 02:07, Don Armstrong wrote:
> On Sat, 26 Apr 2008, Paul Wise wrote:
> > I'd prefer the security team did not delay fixes at all by default.
> > Exceptions for specific maintainers, transitions or other reasons
> > are fine too of course.
>
> For stable and testing, I agree. However, for unstable and
> experimental the maintainer should be at least given a chance to
> resolve the issue. [That is to say, I object to filing a bug and
> immediately NMUing for unstable; in almost all cases the bug should be
> a few days old before that happens.]

I agree with that. The cases where the available "patch" for a security issue 
was insufficient or broke other things are not quite rare. The maintainer of 
a package is the first one responsible for it and should be given the 
opportunity to comment on the patch and/or apply it himself. At least a few 
days, and of course depending on the impact of the bug: no need to rush in 
patches for low impact bugs.


cheers,
Thijs


pgp2SgrRiqj4U.pgp
Description: PGP signature

Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
>>sizeof(char) == 1

> I just removed them for this reason.

Maybe we need to specify CHAR_BITS instead?

Gruss
Bernd


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

Re: Package builds when depending a specific locale

[Adam Borowski]

On Sat, Apr 26, 2008 at 02:24:03PM +0300, Murat Demirten wrote:
> I've a problem with manpages-tr package build process. It is binary
> independent package, basically contains man pages.
> 
> But package author uses a different aproach to build man pages from xml
> sources. There is an xml2man.c which used on build process
> to obtain man pages. And this utility can not be run properly if tr_TR.UTF-8
> locale does not exist at build system. This breaks our automatic
> rebuild systems, so how can we address this problem? Any ideas..

You can do the following:
1. build-depend on "locales"
2. put the "locale-gen" script I attached into debian/locale-gen
   (changing en_US.UTF-8 to tr_TR.UTF-8 in your case)
3. in debian/rules:

manpages:
sh debian/locale-gen
LOCPATH=$(CURDIR)/locales $(MAKE) manpages

The idea is not mine, but I don't remember whose anymore :(.  But hey, it
works for me.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.
#!/bin/sh

LOCPATH=`pwd`/locales
export LOCPATH

[ -d $LOCPATH ] || mkdir -p $LOCPATH

umask 022

echo "Generating locales..."
while read locale charset; do
case $locale in \#*) continue;; esac
[ -n "$locale" -a -n "$charset" ] || continue
echo -n "  `echo $locale | sed 's/\([EMAIL PROTECTED]).*/\1/'`"
echo -n ".$charset"
echo -n `echo $locale | sed 's/\([EMAIL PROTECTED])\([EMAIL 
PROTECTED])*/\2/'`
echo -n '...'
if [ -f $LOCPATH/$locale ]; then
input=$locale
else
input=`echo $locale | sed 's/\([^.]*\)[EMAIL PROTECTED](.*\)/\1\2/'`
fi
localedef -i $input -c -f $charset $LOCPATH/$locale #-A 
/etc/locale.alias
echo ' done'; \
done <

[OT] Need old Packages.gz and Release Files

[peter green]

I have had an accident on my Debian-Archiv-Server and  unfortunatly  the
files "Packages.gz",  "Packages.bz2",  "Sources.gz",  "Sources.bz2"  and
"Release" from the directories

Afaict snapshot.debian.net has woody down to r4 and all point release of sarge 
and etch.

For older point releases of woody you could grab the jigdo/template files for the CDs from 
http://cdimage.debian.org/cdimage/archive/jigdo/ , you will have to reconstruct a single big 
packages/release file set from the broken down ones on the CDs yourself though and 
unfortunately downloads of those .jigdo files seem to be hanging for me at the moment.


For potato I doubt you have much hope except for the last point release (which 
is availible on archive.debian.org).



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

Re: Package builds when depending a specific locale

[Murat Demirten]

Very good solution, thanks for your help Adam. I'm preparing new packages.
It is a corner case I see but maybe we should accept
this as a general solution for the problem.

murat,

2008/4/26 Adam Borowski <[EMAIL PROTECTED]>:

> On Sat, Apr 26, 2008 at 02:24:03PM +0300, Murat Demirten wrote:
> > I've a problem with manpages-tr package build process. It is binary
> > independent package, basically contains man pages.
> >
> > But package author uses a different aproach to build man pages from xml
> > sources. There is an xml2man.c which used on build process
> > to obtain man pages. And this utility can not be run properly if
> tr_TR.UTF-8
> > locale does not exist at build system. This breaks our automatic
> > rebuild systems, so how can we address this problem? Any ideas..
>
> You can do the following:
> 1. build-depend on "locales"
> 2. put the "locale-gen" script I attached into debian/locale-gen
>   (changing en_US.UTF-8 to tr_TR.UTF-8 in your case)
> 3. in debian/rules:
>
> manpages:
>sh debian/locale-gen
>LOCPATH=$(CURDIR)/locales $(MAKE) manpages
>
> The idea is not mine, but I don't remember whose anymore :(.  But hey, it
> works for me.
>
> --
> 1KB // Microsoft corollary to Hanlon's razor:
>//  Never attribute to stupidity what can be
>//  adequately explained by malice.
>



-- 
Murat Demirten
Genel Müdür
Yenihayat Bilişim Teknolojileri A.Ş.
(212) 210 77 36

Re: Package builds when depending a specific locale

[Bernhard R. Link]

* Murat Demirten <[EMAIL PROTECTED]> [080426 15:07]:
> But locales-all package doesn't install the pre-compiled locales into right
> destinations.
> 
> It contains /usr/lib/locales-all/supported.tar.lzma file which includes all
> the locales but you have to manually extract it.

Are you sure? I've never done anything manually but the postinst code
seems to extract it automatically uppon installation.

Hochachtungsvoll,
Bernhard R. Link
-- 
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth


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

Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo

[Ben Hutchings]

On Sat, 2008-04-26 at 20:21 +0200, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> >>sizeof(char) == 1
> 
> > I just removed them for this reason.
> 
> Maybe we need to specify CHAR_BITS instead?

Maybe some day Debian will run on an architecture where CHAR_BITS != 8,
but I doubt it; too much software depends on having exactly-8-bit types.
Until then, why bother?  (Similarly there's little point in including
sizeof(short) and sizeof(int); they don't vary between our current
architectures and are very unlikely to do so in future.)

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo

[Florian Weimer]

* Bernd Eckenfels:

> In article <[EMAIL PROTECTED]> you wrote:
>>>sizeof(char) == 1
>
>> I just removed them for this reason.
>
> Maybe we need to specify CHAR_BITS instead?

Too much Java programming? 8-)

POSIX requires CHAR_BITS to be 8 these days.


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

Re: intend to hijack GnuPG

[Bernd Zeimetz]

Hi,

>> Various people can't reach him[2]. On the other hand, he seems to be
>> active on Ubuntu[3], he joined to Launchpad security this january at
>> least. Moritz Muehlenhoff noted[4] that it should be hijacked and get in
>> shape for Lenny. Thus I have created a preliminary package[5] which
>> fixes some important bugs and get v1.4.9 to the archive.
>> Does the Release Team allow this hijack, should I upload it as an NMU
>> instead or just leave it alone?
> 
> 
> I think this is a very good initiative. However, I encourage you to
> setup a collaborative project for this (on Alioth, with repository,
> mailing-list, etc.). Several people have expressed
> interest in helping to maintain Gnupg and this is certainly something
> that should, from the start, be maintained by more than one person.

What's the status here? Is there a team being setup, or anybody else
working on gnupg?


-- 
 Bernd Zeimetz   Debian GNU/Linux Developer
 GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79


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

Re: intend to hijack GnuPG

[David Paleino]

On Sun, 27 Apr 2008 01:00:38 +0200, Bernd Zeimetz wrote:

> >> Various people can't reach him[2]. On the other hand, he seems to be
> >> active on Ubuntu[3], he joined to Launchpad security this january at
> >> least. Moritz Muehlenhoff noted[4] that it should be hijacked and get in
> >> shape for Lenny. Thus I have created a preliminary package[5] which
> >> fixes some important bugs and get v1.4.9 to the archive.
> >> Does the Release Team allow this hijack, should I upload it as an NMU
> >> instead or just leave it alone?
> > 
> > 
> > I think this is a very good initiative. However, I encourage you to
> > setup a collaborative project for this (on Alioth, with repository,
> > mailing-list, etc.). Several people have expressed
> > interest in helping to maintain Gnupg and this is certainly something
> > that should, from the start, be maintained by more than one person.
> 
> What's the status here? Is there a team being setup, or anybody else
> working on gnupg?

If a team is being setup, I'd like to be added as well (hanska-guest on Alioth).

David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Building with -msse

[Russ Allbery]

gnubg supports optionally building with SSE support for increased speed in
the analytical engine.  I have to date kept this disabled to not generate
binaries that might not run on all otherwise-supported Debian systems.

However, a user mentioned that he thinks all chips that fall into the
amd64 architecture have SSE and hence adding -msse would be safe for the
amd64 build.  Is that correct?  And in general are there any guidelines
about things like this?  I assume that using -msse for the i386 build is
still out since we still support 486 chips.

(I don't think the performance gain warrants the complexity of building
two binaries, although it is noticable.)

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Building with -msse

[Paul Wise]

On Sun, Apr 27, 2008 at 10:05 AM, Russ Allbery <[EMAIL PROTECTED]> wrote:

>  However, a user mentioned that he thinks all chips that fall into the
>  amd64 architecture have SSE and hence adding -msse would be safe for the
>  amd64 build.  Is that correct?

http://en.wikipedia.org/wiki/X86-64 says:

"SSE and SSE2 are available in 32-bit mode in modern x86 processors;
however, if they're used in 32-bit programs, those programs will only
work on systems with processors that support them. This is not an
issue in 64-bit programs, as all processors that support AMD64 support
SSE and SSE2, so using SSE and SSE2 instructions instead of x87
instructions does not reduce the set of machines on which the programs
will run."

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Building with -msse

[Faidon Liambotis]

Russ Allbery wrote:

However, a user mentioned that he thinks all chips that fall into the
amd64 architecture have SSE and hence adding -msse would be safe for the
amd64 build.  Is that correct?  And in general are there any guidelines
about things like this?  I assume that using -msse for the i386 build is
still out since we still support 486 chips.

AFAIK, the amd64 gcc enables those extension by default.

Regards,
Faidon


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

Re: Building with -msse

[Russ Allbery]

Faidon Liambotis <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:

>> However, a user mentioned that he thinks all chips that fall into the
>> amd64 architecture have SSE and hence adding -msse would be safe for the
>> amd64 build.  Is that correct?  And in general are there any guidelines
>> about things like this?  I assume that using -msse for the i386 build is
>> still out since we still support 486 chips.

> AFAIK, the amd64 gcc enables those extension by default.

Yeah, that was one of the things that was confusing me.  It looks like
gnubg also has some custom code that's enabled based on a configure
argument as well.

Also, it looks like it probes at runtime for SSE, so I may be able to
build with that on i386 as well.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Extending the update-rc.d API to change runlevel and disable scripts?

[Stefano Zacchiroli]

On Fri, Apr 25, 2008 at 10:15:27AM +0200, Petter Reinholdtsen wrote:
> I believe we should extend the update-rc.d interface to provide a few
> more operations that are commonly needed and commonly done wrong.

Neat, thanks for the initiative.

> Disable scripts
> ---
> 
> This has to be done manually or using one of the tools provided for
> sysv-rc, and is different for earch boot system used.  I propose an
> operation like
> 
>   update-rc.d script disable
> 
> It will rename all start symlinks to stop symlinks for all runlevels.
> For dependency based boot sequencing, it will also update the sequence
> numbers to reflect this new entry.

I would add the option to specify a (set of) runlevel, so that one can
disable a service just for a subset of the runlevels. I'm myself using
sysv-rc-conf for these things and frequently I remove links only for the
default runlevel.

It should also be considered what the default should be if no subset of
the runlevels is specified. To me, both "all" and "only the default
runlevel" make sense. Though probably "all" is better, as the default
runlevel can be changed later on without that update-rc.d notice
anything about that.

Similarly, a counter action for this new "disable" action should be
provided. I frequently dig into postinsts to retrieve the info about in
which position I should put back a service I've disabled. (Sure this
won't be needed with dependency based boot system, but in the meantime
it still is.)

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: Building with -msse

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Also, it looks like it probes at runtime for SSE, so I may be able to
> build with that on i386 as well.

If it probes, it is most likely loading an optimized asm module, and you
dont need the SSE switch at all.

Gruss
Bernd


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

Re: Extending the update-rc.d API to change runlevel and disable scripts?

[Luk Claes]

Stefano Zacchiroli wrote:
> On Fri, Apr 25, 2008 at 10:15:27AM +0200, Petter Reinholdtsen wrote:

> Similarly, a counter action for this new "disable" action should be
> provided. I frequently dig into postinsts to retrieve the info about in
> which position I should put back a service I've disabled. (Sure this
> won't be needed with dependency based boot system, but in the meantime
> it still is.)

Isn't this just a matter of stopping the service and renaming the S (K)
links to s (k) links so one can easily revert?

Cheers

Luk


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

New Mail

[Adam24h]

Xin lỗi nếu mail này làm phiền đến anh chị và các bạn!

 

   

 

 

ADAM24H

Just for men! But lady will see. 

Chỉ dành cho nam giới. Nhưng phụ nữ có quyền xem. 

  

Thử xem, bạn sẽ biết ngay mình cần gì mà. Nhanh, gọn, lẹ, không cầu kỳ mà cực 
kỳ hiệu quả.

Chỉ cần 1 cú click, click nhé! http://www.adam24h.net  

Chúc các bạn luôn hài lòng với dịch vụ đặc biệt dành riêng cho phái mạnh!!!