Re: Bug#415862: ITP: why -- A software verification tool

[Pierre THIERRY]

Scribit Samuel Mimram dies 22/03/2007 hora 18:10:
> * Package name: why

That's great! I had begun to play a bit with why, but having it as an
official Debian package will make it easier. As I'm beginning to do some
packaging, if you ever need it, I'd gladly help (packaging a new
upstream, triaging bugs, etc.).

Provably
Pierre
-- 
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A


signature.asc
Description: Digital signature

Re: Installing packages with arch i686

[Hamish Moffatt]

On Wed, Apr 04, 2007 at 05:27:35PM -0300, Rodrigo Tavares wrote:
> I created one package for architeture i686, in control
> file.
> 
> # dpkg -i pacote-1.1.6.i686.deb
> dpkg: error processing pacote-1.1.6.i686.deb
> (--install):
>  package architecture (i686) does not match system
> (i386)
> Errors were encountered while processing:
> pacote-1.1.6.i686.deb
> 
> How to resolve it ?

Don't do that?

All of our x86 support is in the 'i386' architecture. We don't have an
i686 architecture. Some packages provide some optimised binaries which
may be detected and used at runtime, eg in /usr/lib/i686.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: Re: primary mirrors, debootstrap and d-i (was Modifying/etc/apt/sources.list in postinst)

[Philippe Cloutier]

Am I right in thinking that normal d-i installations ensure that at
least one primary mirror is selected (or at least strongly advise that
one primary should exist)?


No


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

Re: Override CFLAGS when using cdbs

[Loïc Minier]

On Wed, Apr 04, 2007, Andreas Tille wrote:
> Which I learned by this example and which makes me wonder whether
> there is absolutely no way out to enforce overriding CFLAGS.

 It is possible, but really a bad idea.  See "override" in make.  I
 really recommend you don't use it.

> This makes no real sense because it concerns a relative path to
> a subdirectory in the source tree that does not exist from
> every subtree location.

 Add "-I $(top_src_dir)/somedir", not "-I somedir".

> >change the upstream build to use its internal CFLAGS and still honor
> >"user" (that's you) provided CFLAGS.  For an explanation on why the
> >upstream build should honor CFLAGS but not use them, see:
> >.
> Well, the project does not use automake and thus I can not
> reasonably use this option.

 This was only a pointer at good Makefile style: honoring CFLAGS as an
 user variable, and only that.  Something which is expected to be empty
 unless the users wishes otherwise.

>  I think one reasonable way would
> be to unset CFLAGS for cdbs (well, CFLAGS_="" is in
> fact not unsetting it, because it just get's a new value but
> it is defined and overrides the upstream setting) and use
> a MYCFLAGS instead that I can append to the upstream CFLAGS
> later on when needed.  Unfortunately I have not found a way
> to prevent cdbs from defining CFLAGS.

 It's really not cdbs' fault, but an upstream design issue of the
 Makefile you're trying to use.

> Moreover I'm really amazed that there is no way force replacement
> of CFLAGS inside a Makefile once it is setted outside.  I would
> call this an insane constraint of make.

 There is, try "override" -- but just to see how it works. :)

-- 
Loïc Minier


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

Installing packages with arch i686

[Rodrigo Tavares]

Hello,

I created one package for architeture i686, in control
file.

Se the below commands:

uname -m
i686

# dpkg -s libc6-i686
Package: libc6-i686
Status: install ok installed
Priority: extra
Section: libs
Installed-Size: 2476
Maintainer: GNU Libc Maintainers

Architecture: i386

When I try to install the package, in same machine
come this error:

# dpkg -i pacote-1.1.6.i686.deb
dpkg: error processing pacote-1.1.6.i686.deb
(--install):
 package architecture (i686) does not match system
(i386)
Errors were encountered while processing:
pacote-1.1.6.i686.deb

How to resolve it ?

Best regards,

Faria

__
Fale com seus amigos  de graça com o novo Yahoo! Messenger 
http://br.messenger.yahoo.com/ 


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

Re: Override CFLAGS when using cdbs

[Andreas Tille]

On Wed, 4 Apr 2007, [iso-8859-1] Loïc Minier wrote:


Actually, the CFLAGS passed to the top-level $(MAKE) are overriding
everything.


Which I learned by this example and which makes me wonder whether
there is absolutely no way out to enforce overriding CFLAGS.


I suggest you either try to set -I for the whole build or


This makes no real sense because it concerns a relative path to
a subdirectory in the source tree that does not exist from
every subtree location.


change the upstream build to use its internal CFLAGS and still honor
"user" (that's you) provided CFLAGS.  For an explanation on why the
upstream build should honor CFLAGS but not use them, see:
.


Well, the project does not use automake and thus I can not
reasonably use this option.  I think one reasonable way would
be to unset CFLAGS for cdbs (well, CFLAGS_="" is in
fact not unsetting it, because it just get's a new value but
it is defined and overrides the upstream setting) and use
a MYCFLAGS instead that I can append to the upstream CFLAGS
later on when needed.  Unfortunately I have not found a way
to prevent cdbs from defining CFLAGS.

Moreover I'm really amazed that there is no way force replacement
of CFLAGS inside a Makefile once it is setted outside.  I would
call this an insane constraint of make.

For instance I also tried

  CFLAGS:=$(if $(CFLAGS),"$(CFLAGS) -I$(INCLUDEDIR)","-I$(INCLUDEDIR)")

which also did not show any effect.

Kind regards

   Andreas.

--
http://fam-tille.de

Re: primary mirrors, debootstrap and d-i (was Modifying /etc/apt/sources.list in postinst)

[Neil Williams]

On Wed, 04 Apr 2007 10:47:00 +0200
Goswin von Brederlow <[EMAIL PROTECTED]> wrote:

> Parse sources.list. Many people have multiple suites in there and you
> will want to add multiple entries then.

apt-cache policy already covers that output and it is easier to parse -
the code offered by Ben Hutchings adds to my own code by supporting the
priority figure specified in apt-cache policy, I was already parsing
the rest. Thanks Ben.

> You also want to pick a mirror
> near to the mirror already used.

That won't work - the only reason to add a primary mirror is when the
system is not using ANY primary mirrors, just something like
ftp.debian.org as set by debootstrap. Therefore, there is no reliable
way of telling what mirror is close because the existing setting has
not been set by the user. AFAICT this only happens with debootstrap.
I'm actually now thinking of *not* adding a primary mirror *unless*
ftp.debian.org is the only source in apt-cache policy. Then I'll add
some code that tries to check that the provided mirror(s) support the
architectures requested. (The code already exists, it just needs to
make a more usable error message once these postinst changes have done
what can be done to narrow down the reasons for the error.) I'm
undecided whether adding the primary mirror outside a debootstrap
installation should be an automated step or just a usable error message
with a detailed note in the manpage.

However, it is important that debootstrap installations
using ftp.debian.org are handled automatically, so that I can build
scripts around debootstrap without the hassle of patching it and
without needing user intervention. (debootstrap takes long enough
without the user finding that it's stalled waiting for an obvious
answer to a prompt.)

Am I right in thinking that normal d-i installations ensure that at
least one primary mirror is selected (or at least strongly advise that
one primary should exist)?

The Emdebian repository would still be added but there is no other
mirror for that so there's no question of finding anything nearer to
the user. That isn't a problem, that repository only contains the
toolchains. Adding a second primary mirror isn't actually that much of
a problem anyway - apt will prefer the first mirror
in /etc/apt/sources.list before using files in /etc/apt/sources.list.d/
so the *only* time that the primary mirror is needed is when
emdebian-tools itself tries to read: apt-cache -o Apt::Architecture=arm
or whatever because apt will not be able to find that arch at
ftp.debian.org and will therefore use the added primary.

I will look at 'ucf' to manage the file in /etc/apt/sources.list.d/
- as you suggested. However, if no primary mirror needs to be added
to /etc/apt/sources.list.d/emdebian.sources.list, I'm not sure ucf is
necessary - ucf isn't relevant in a debootstrap chroot.

Options, options . . .

--


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpW4K5GfXedI.pgp
Description: PGP signature

Bug#417804: RFA: vegastrike -- A 3d space combat game

[Mike Furr]

Package: wnpp
Severity: normal

I request an adopter for the vegastrike suite of packages.  The data
package is pretty big weighing in at ~150MB making it one of the larger
packages in Debian.  It has a pretty good user base, and upstream is still 
active.  However, development is quite slow now-a-days, so don't expect 
frequent releases.  The code base is also quite large, consisting mostly 
of C++, but with all of the game logic in python.  A good maintainer 
should also watch their message boards as people occasionally post 
package related problems there.  Several bugs in the BTS which could be 
addressed.  Due to the package size and being somewhat buggy, I have 
traditionally not allowed this package into testing, however any adopter 
can certainly change that (#295595).

The package description is:
 Vegastrike is an OpenSource 3d Space Simulator. Currently in Beta
 development, the project, at version 1.0, is to be a generic space
 simulator. Current features include split-screen play, trading,
 exploration and of course plenty of shoot 'em up action .

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Bug#417805: RFA: chromium -- Fast paced, arcade-style, scrolling space shooter

[Mike Furr]

Package: wnpp
Severity: normal

I request an adopter for the chromium package.  The game is dead upstrem, 
but clearly still has a large set of users.  It has recently been discovered
that some of the music is non-free and some of the sounds are 
non-distributable.  The issues are discussed in #385115.  However, a 
slightly stripped version should fit happily in contrib/non-free.  Also, I 
already received one email of someone offering some replacements audio files 
(will forward this to the new maintainer).  There are a few other small bugs 
(with patches) that also need to be addressed (although I'm not convinced why 
the patch in #411614 solves the problem).

The package description is:
 Chromium is a top down fast paced high action scrolling space shooter
 which uses the SDL libs. In this game you are the captain of the
 cargo  ship Chromium B.S.U., and responsible for
 delivering supplies to our troops on the front line. Your ship
 has a small fleet of robotic fighters which you control from the
 relative safety of the Chromium vessel.
 .
 Homepage: http://www.reptilelabour.com/software/chromium/

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Re: Bug#417261: dch: please use dates in UTC

[Christoph Berg]

Re: Stefano Zacchiroli 2007-04-02 <[EMAIL PROTECTED]>
> I share the feeling of "niceness" of the personal touch, but this isn't
> a technical reason, and the point of uniforming a timezone so that it's
> easier to compare dates among different changelog is definitely a valid
> one.

If we want to (mechanically) compare timestamps we have to parse them
anyway. Parsing the timezone along is not even extra work, as other
posters here have indicated.

The main use for the timestamps for me is to know when I did the last
change, and there knowing the local time helps greatly.

What about supporting a variable DEBCHANGE_TZ in ~/.devscripts that
lets the user set UTC, but defaults to $TZ?

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/

Re: Bug#417261: dch: please use dates in UTC

[Paul TBBle Hampson]

On Mon, Apr 02, 2007 at 03:11:23PM +0200, Stefano Zacchiroli wrote:
> I share the feeling of "niceness" of the personal touch, but this isn't
> a technical reason, and the point of uniforming a timezone so that it's
> easier to compare dates among different changelog is definitely a valid
> one.

Is comparing dates of different changelogs a serious usecase? Given that
it doesn't neccessarily bear a relation to the date of upload,
particularly if a package build is heavily tested before uploading...

Upload dates themselves are somewhere else in the system...

[EMAIL PROTECTED], or something like that? _That_ should be
easy to compare, because it's a single chronological log, formatted
like a set of emails.

Granted, those are not exactly upload dates... But they're prolly closer
to what you think you want to know.

-- 
---
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
 -- Kristian Wilson, Nintendo, Inc, 1989

License: http://creativecommons.org/licenses/by/2.1/au/
---


pgpaAIVf3j35M.pgp
Description: PGP signature

Re: Bug#416490: acpi-support: IBM Ultrabase X4 DVD/CDOM Undetected On Dock

[Bernd Zeimetz]

Heya,
>> I fear that the IDE bus is not really hotplug friendly and that we
>> simply have no way to discover this automatically (hence the need of
>> a tool to ask for a rescan of the IDE bus by the kernel). But I'm
>> neither an hardware expert nor a kernel specialist, so I may be wrong.
>> 
>
>  I think hdparm has some flags to do this.
>
>   
The hdparm way resulted in some bad bad bugs some time ago due to the
more or less broken ide stack. This is supposed to be fixed, though.
I think hdparm -R is the option, which is still marked as dangerous in
the readme.
In the hdparm package you'll find /usr/share/doc/hdparm/contrib/, which
contains a README and two scriptst ultrabayd and idectl. They were
supposed to do those things before the ibm_acpi module was created. Not
sure how far the ibm_acpi module takes care of those things - at least
it works well for the integrated ultrabay, you want to make sure that it
is loaded. Have a look into /proc/acpi/ibm then.
IBM-Acpi's homepage is here: http://ibm-acpi.sourceforge.net/


Hope that helps,

cheers

Bernd


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

Re: Modifying /etc/apt/sources.list in postinst ; determining the suite in postinst

[Goswin von Brederlow]

Neil Williams <[EMAIL PROTECTED]> writes:

> On Tue, 03 Apr 2007 19:27:17 +
> Lars Wirzenius <[EMAIL PROTECTED]> wrote:
>
>> On ti, 2007-04-03 at 16:28 +0100, Neil Williams wrote:
>> With regards to Debian Policy, you need to read section 10.7.
>
> That's why I'm changing the existing method (which does simply append
> data to /etc/apt/sources.list). The previous hack isn't good.
> :-)
>
> However, determining the suite from within postinst is my main issue at
> the moment.
>
> Is it safe to use `apt-cache policy` ?

Parse sources.list. Many people have multiple suites in there and you
will want to add multiple entries then. You also want to pick a mirror
near to the mirror already used.

>> Basically, since sources.list is a configuration file belonging to
>> apt, your package may only edit it in postinst if apt provides
>> commands for doing so. I don't think apt does that, but I could be
>> wrong.
>
> It does have a method: /etc/apt/sources.list.d/
>
> I'm going to put a sources file in there which can be purged when the
> package is purged.

Use ucf so you can set the best mirror in postinst.

>> With regards to the life of a sysadmin, don't do it.
>
> I can't see sysadmins having to manage many cross-building buildd
> machines but I will provide a README.Debian. The Emdebian repository
> only stores the cross-building toolchains.
>
>> Provide a README.Debian that tells what needs to be done, and
>> possibly provide a command to do it easily.
>
> The package is unusable without the added sources. Providing a
> userspace command doesn't ensure that the repository is removed from
> the sources list when the package is purged.
>
> The modified package is currently in the Emdebian repository, v0.1.4.

MfG
Goswin


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

Re: many rejects (Re: Second call for votes for the debian project leader election 2007)

[Michal Čihař]

Hi

On Wed, 04 Apr 2007 02:21:48 -0500
Manoj Srivastava <[EMAIL PROTECTED]> wrote:

> One of your ballots (msg00250) did pass the gpg check -- but
>  you must have voted with the same ballot, since devotee says:
>Failure: The signature on the message, though valid, has been seen
>before.  This could be a potential replay attack

I resent same mail only not encrypted, so this is quite correct. Thanks
for fixing this issue (especially when the only reject caused by this
seems to be mine).

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Re: What is the reason glibc is at version 2.3 for etch?

[Michael Ablassmeier]

hi Lex,

Lex Hider <[EMAIL PROTECTED]> schrieb:
> Hi,
> I've been discussing with some #fluendo people about their codecs not being 
> compatible with etch (requires glibc 2.4+).
>
> Can anyone give a brief answer to why etch will be shipping the glibc at 2.3.
> I couldn't provide an explanation as to why it is only 2.3 being shipped.

this has been discussed before (also related to fluendo, though), see: 

 http://www.grep.be/blog/en/computer/debian/glibc_2.3

bye,
- michael


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

Re: Override CFLAGS when using cdbs

[Loïc Minier]

Hi,

On Tue, Apr 03, 2007, Andreas Tille wrote:
> I try to package a project that needs to add some include
> pathes to the existing default CFLAGS and thus I tried
> to patch a Makefile in one subdir to
> CFLAGS=$(CFLAGS) -I$(INCLUDEDIR)
> but I had to learn that the CFLAGS variable that is used
> in the call
>   cd subtree; $(MAKE)

 Actually, the CFLAGS passed to the top-level $(MAKE) are overriding
 everything.  I suggest you either try to set -I for the whole build or
 change the upstream build to use its internal CFLAGS and still honor
 "user" (that's you) provided CFLAGS.  For an explanation on why the
 upstream build should honor CFLAGS but not use them, see:
 .

   Bye,
-- 
Loïc Minier


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

Re: Bug#416490: acpi-support: IBM Ultrabase X4 DVD/CDOM Undetected On Dock

[Loïc Minier]

On Tue, Apr 03, 2007, Raphael Hertzog wrote:
> I fear that the IDE bus is not really hotplug friendly and that we
> simply have no way to discover this automatically (hence the need of
> a tool to ask for a rescan of the IDE bus by the kernel). But I'm
> neither an hardware expert nor a kernel specialist, so I may be wrong.

 I think hdparm has some flags to do this.

-- 
Loïc Minier
PS: NO I'M NOT ADDING THIS TO acpi-support, in fact I didn't really
write the above, someone else did


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

Re: many rejects (Re: Second call for votes for the debian project leader election 2007)

[Manoj Srivastava]

On Sun, 1 Apr 2007 22:02:18 +0200, Michal Čihař <[EMAIL PROTECTED]> said: 

> Maybe I read RFC 3156 wrong, but I think it says exactly what I
> sent:

> 6.1.  RFC 1847 Encapsulation

>In [2], it is stated that the data is first signed as a
>multipart/signature body, and then encrypted to form the final
>multipart/encrypted body.  This is most useful for standard MIME-
>compliant message forwarding.

No, you were quite correct; I had zone on RFC 1847
 Encapsulation while writing up dvt-gpg. Mind you, implementing this
 was icky, since this breaks the nice little work-flow where first we do
 mime decoding, and then gpg verifications; now devotee has to decrypt
 the mail message, note that there did not seem to be any signatures
 on the message, run the mime parser on the newly decrupted body, see
 if there are exactly two parts with the proper mime encoding, save
 the body and the signature, and then run gpg again over the new body
 and sig, and properly bubble up any errors at any stage of the
 processing.

No wonder people tried to warn me away from implementing my
 own mail handling and mime and gpg parsing when I started thinking
 about writing devotee.

I added all this icky code to devotee, and now devotee is
 indeed fully compliant with RFC 3156.

Anyway, there were 10 ballots which could have been affected,
 so I re-ran these ballots through devotee.

9 failed to verify the sig.

One of your ballots (msg00250) did pass the gpg check -- but
 you must have voted with the same ballot, since devotee says:
   Failure: The signature on the message, though valid, has been seen
   before.  This could be a potential replay attack

So, after all this, no rejected ballot has been accepted --
 and indeed, 9 of the 10 were correctly rejected in the first place.

But I'm happy to say that any RFC 3156 compliant message
 should now be correctly interpreted by devotee.

manoj
-- 
Authors (and perhaps columnists) eventually rise to the top of
whatever depths they were once able to plumb.  -- Stanley Kaufman
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C