Re: Bug#444368: ITP: dvd95 -- DVD9 to DVD5 converter

[Josselin Mouette]

Le vendredi 28 septembre 2007 à 13:17 +1000, Paul Wise a écrit :
> On Thu, 2007-09-27 at 23:26 -0300, Carlos Laviola wrote:
> 
> >   * Needs no additional packages - embedded versions of vamps and
> > dvdauthor are used, to be as fast as possible.
> 
> Please notify the Debian security team so they can add dvd95, vamps,
> dvdauthor to their list of packages with duplicated code. 

Or please patch it so that the code isn't duplicated for such bogus
goals.

-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Bug#444442: ITP: mail-spf-perl -- Perl implementation of Sender Policy Framework and Sender ID

[Julian Mehnle]

Package: wnpp
Severity: wishlist
Owner: Julian Mehnle <[EMAIL PROTECTED]>


* Package name: mail-spf-perl
  Version : 2.005
  Upstream Author : Julian Mehnle <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/Mail-SPF/
* License : BSD
  Programming Lang: Perl
  Description : Perl implementation of Sender Policy Framework and Sender ID

Mail::SPF is an object-oriented Perl implementation of the Sender Policy
Framework (SPF) e-mail sender authentication system .

It supports both the TXT and SPF RR types as well as both SPFv1 (v=spf1) and
Sender ID (spf2.0) records, and it is fully compliant to RFCs 4408 and 4406.
(It does not however implement the patented PRA address selection algorithm
described in RFC 4407.)


The source package would generate two binary packages: libmail-spf-perl
and spf-tools-perl, the latter of which would ship the executables
included with the Mail::SPF upstream package (currently spfquery and
spfd).



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

Re: Packaging a library that requires cross-compiled code

[Vincent Danjean]

Julien BLACHE wrote:
> Shachar Shemesh <[EMAIL PROTECTED]> wrote:
> 
>> I think we need a change in policy for handling cases where free
>> software requires free software in order to compile which is, non the
>> less, non buildable on the same platform.
> 
> It exists already, it's called the contrib section of the archive.

No. The contrib section is for free software that requires non-free software.

However, all is free software in this thread. The problem does not come
from the license but from the difficulty to setup a correct build environment
(due to cross compilation to another architecture or another platform)

> JB.
> 


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

Bug#444448: ITP: twiki-ldapcontrib -- LDAP services for TWiki

[Olivier Berger]

Package: wnpp
Severity: wishlist
Owner: Olivier Berger <[EMAIL PROTECTED]>


Hi.

I intent to propose a generic Debian package for the following software.

We've made a local package already, on an old version of the program, which 
suited our needs for the PicoForge platform (some details at 
https://picoforge.int-evry.fr/cgi-bin/twiki/view/Picoforge/Web/TwikiLdapcontribDeb
 ).

Now is time to try and contribute such a package to Debian for more general use 
by the community.

* Package name: twiki-ldapcontrib
  Version : 060802
  Upstream Author : [EMAIL PROTECTED]
* URL : http://twiki.org/cgi-bin/view/Plugins/LdapContrib
* License : GNU GPL
  Programming Lang: Perl
  Description : LDAP services for TWiki

Excerpt from http://twiki.org/cgi-bin/view/Plugins/LdapContrib :

This package offers basic LDAP services for TWiki and offers authentication of 
TWiki users by binding to an LDAP server as well as incorporate LDAP user 
groups into TWiki's access control.

Upstream states : (c) 2006 Michael Daum http://wikiring.com. This work was 
partly funded by Spanlink Communications and Trivadis.


Packaging an up-to-date version will need some more work than the initial work 
done for the August 2 version for PicoForge.

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

Kernel: Linux 2.6.18-5-xen-686 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Bug#444443: ITP: net-dns-resolver-programmable-perl -- programmable DNS resolver class for offline emulation of DNS

[Julian Mehnle]

Package: wnpp
Severity: wishlist
Owner: Julian Mehnle <[EMAIL PROTECTED]>


* Package name: net-dns-resolver-programmable-perl
  Version : 0.003.1
  Upstream Author : Julian Mehnle <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/Net-DNS-Resolver-Programmable/
* License : Perl (GPL-2 / Artistic)
  Programming Lang: Perl
  Description : programmable DNS resolver class for offline emulation of DNS

Net::DNS::Resolver::Programmable is a Net::DNS::Resolver descendant class that
allows a virtual DNS to be emulated instead of querying the real DNS.  A set
of static DNS records may be supplied, or arbitrary code may be specified as a
means for retrieving DNS records, or even generating them on the fly.


The source package would generate a libnet-dns-resolver-programmable-perl
binary package.



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

Re: Packaging a library that requires cross-compiled code

[Julien BLACHE]

Vincent Danjean <[EMAIL PROTECTED]> wrote:

> Julien BLACHE wrote:
>> Shachar Shemesh <[EMAIL PROTECTED]> wrote:
>> 
>>> I think we need a change in policy for handling cases where free
>>> software requires free software in order to compile which is, non the
>>> less, non buildable on the same platform.
>> 
>> It exists already, it's called the contrib section of the archive.
>
> No. The contrib section is for free software that requires non-free software.

Policy 2.2.2
[...]
Examples of packages which would be included in contrib are:

  * free packages which require contrib, non-free packages or
packages which are not in our archive at all for compilation
or execution, and
[...]

> However, all is free software in this thread. The problem does not come
> from the license but from the difficulty to setup a correct build environment
> (due to cross compilation to another architecture or another platform)

Yeah, right, seems to fit.

JB.

-- 
 Julien BLACHE <[EMAIL PROTECTED]>  |  Debian, because code matters more 
 Debian & GNU/Linux Developer|   
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


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

Bug#444409: ITP: emusic-remote -- browser and download manager for eMusic.com

[Ben Hutchings]

Package: wnpp
Severity: wishlist
Owner: Ben Hutchings <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: emusic-remote
  Version : 1.0.0.1
  Upstream Author : emusic.com
* URL : http://code.google.com/p/emusicremote/
* License : LGPL
  Programming Lang: C++
  Description : browser and download manager for eMusic.com

eMusic Remote is the officially supported browser and download manager
for the eMusic.com music store.  It can also import downloaded files
into other programs automatically.

- -- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable'), (100, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.22-2-686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG/OJ479ZNCRIGYgcRAqdmAJ90qeOLUzBcYmdI1R7G8Av+QaUj5gCgu6Zu
L1lcIckVEM8EEVfVyenrkO0=
=SXqE
-END PGP SIGNATURE-



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

Re: Packaging a library that requires cross-compiled code

[Ian Jackson]

David Anderson writes ("Packaging a library that requires cross-compiled code"):
> 2) Package an arm7 cross-compiling gcc with just the right set of
> options, integrate that with the packaging tools, and then package
> with a Build-Depends on the cross-compiler.
> 
> Pro: feels like the Right Way, in a perfect world. Cons: opens the
> floodgates of packaging cross-compilers, likely requires
> additions/modifications to packaging tools, and takes way more time
> than I'm personally ready to put into packaging my code.

This is the right answer I think.  Several other embedded systems
already have cross-compilers in Debian, so this isn't opening any
floodgates or getting into anything too unusual.  I can see why it
would be hard work for you to learn about packaging cross-compilers.


> 3) Somehow make the packaging tools properly cross-compile the .bin
> without having a cross-compiler package around. This was briefly
> suggested on #debian-mentors, but I have no idea how this would be
> implemented.

It's not clear what you mean here.  136 bytes seems very little.  Is
it written in an assembly language or in C ?

> Pros: less time involved than 2), would make the package
> self-contained. Cons: building a cross-compiler in the packaging
> process just to build a 136 byte binary blob feels like killing a flea
> with a bazooka, and makes building the package much, much longer than
> it should be, given the amount of code and logic it actually carries.

Yes, but I think that sounds like an acceptable alternative.


> 1) Ship a built copy of the code in the package's .diff.gz, and DTRT
> at package creation time to move the .bin from debian/ to the right
> place in the staging tree. The source code for the .bin is in
> .orig.tar.gz, under a free license. Anyone is free to modify or
> rebuild the .bin, provided they obtain an arm7 cross-compiler by
> non-debian means (instructions provided). People who just want to
> rebuild the package can do so, without caring that there is
> cross-compiled code involved.
> 
> Pro: dead simple, the packaging problem goes away. Con: means shipping
> a binary blob in the source distribution, which appears to be frowned
> upon, regardless of whether the source is also freely available in the
> source distribution.

This is (unfortunately for you) not acceptable for Debian proper.
Everything in Debian must be buildable from source using tools in
Debian.


> 4) Give up and stay away from the Debian main repositories, just put
> the package up on a private package repository.
> 
> Pro: trivial solution. Cons: I'd like to do things right rather than
> cobbling something together.

You could put the package in contrib.  I think contrib would be
a possibility for this.  But it's far from ideal - think of the poor
users who want to change the 136-byte loader program.


Ian.


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

Re: modified email address in debian/copyright file

[Ian Jackson]

Ben Finney writes ("Re: modified email address in debian/copyright file"):
> I argue that the only fair place to draw the line is "valid RFC 2821
> email address". The alternative is to leave it to ongoing subjective
> judgement of unspecified Debian parties as to which addresses make
> sense or not — or to avoid the question of valid contact information
> altogether, as seems to be current practice.

Yes, and that current practice is just fine.

The whole point of having human beings do packaging is so that we can
apply our judgement, interpersonal skills, and so forth.

Ian.

Re: Packaging a library that requires cross-compiled code

[David Anderson]

On 9/27/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> I think this is the way to go unless you get some concrete objections.
> There is certainly precedent - see for instance the ia32-libs /
> amd64-libs packages (which are frowned upon for whole different
> reasons).

[replying here, but this is a more general reply to the whole thread]

Thanks for the thoughts on this, I've decided to go with the above for
the time being, with the following addendums.

The upstream release (which I also author, but besides the point) also
bundles the binary driver, due to the difficulty of building it
directly. Given that I doubt this driver will ever change again now
that it works, that the source code is provided, and that the driver
is an internal implementation detail and not a pivotal component of
the software, it seems like the thing to do.

I also have a Debian package almost working now (lintian still has a
few complaints, and I need to file an ITP iiuc), which uses the
upstream binary driver to build the debian package. I don't know
whether this now qualifies as main or contrib, given that the binary
is provided by upstream, and therefore no special software is required
to actually build the package.

- Dave


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

Bug#444392: ITP: miniupnpc -- UPnP IGD client lightweight library

[Thomas GOIRAND]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand <[EMAIL PROTECTED]>

* Package name: miniupnpc
  Version : 1.0-RC9
  Upstream Author : Thomas Bernard <[EMAIL PROTECTED]>
* URL : http://miniupnp.free.fr/
* License : BSD
  Programming Lang: C, C++
  Description : UPnP IGD client lightweight library

The UPnP protocol is supported by most home adsl/cable routers and Microsoft
Windows 2K/XP. The aim of the MiniUPnP project is to bring a free software
solution to support the "Internet Gateway Device" part of the protocol. The
MediaServer/MediaRenderer UPnP protocol is also becoming very popular but here
we are talking about IGD.

Miniupnpc aims at the simplest library possible, with the smallest footprint
and no dependencies to other libraries such as XML parsers or HTTP
implementations. All the code is pure ANSI C. Compiled on a x86 PC, the
miniupnp client library have less than 15KB code size. For instance, the upnpc
sample program is around 20KB. The miniupnp daemon is much smaller than any
other IGD daemon and is ideal for using on low memory device for this reason.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (700, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17.7
Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1)



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

Bug#444399: ITP: minissdpd -- UPnP IGD discovery speed enhancer for miniupnpc

[Thomas GOIRAND]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand <[EMAIL PROTECTED]>

* Package name: minissdpd
  Version : 1.0-RC9
  Upstream Author : Thomas Bernard <[EMAIL PROTECTED]>
* URL : http://miniupnp.free.fr/
* License : BSD
  Programming Lang: C, C++
  Description : UPnP IGD discovery speed ehancer for miniupnpc

In order to reduce discovery time in UPnP enabled applications, MiniSSDPd was
developped for use in conjunction with MiniUPnPc. MiniSSDPd receive and
process SSDP announces broadcasted on the network by UPnP devices so when an
application starts, it does not need to do the whole discovery process.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (700, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17.7
Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1)



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

Re: Building packages with exact binary matches

[Martin Uecker]

On Thu, Sep 27, 2007 at 06:31:58PM -0500, Manoj Srivastava wrote:
> On Thu, 27 Sep 2007 11:28:47 +0200, Martin Uecker <[EMAIL PROTECTED]> said: 

[...]
 
> >> But recompiling from what? If you do not get the exact same source,
> >> you have no hope of getting the same result.
> 
> > I had the impression that Debian distributes the source code from
> > which the binaries are actually compiled and not some random
> > variation.
> 
> Yup, complete with all the trojans in the binary and all.

You are seriously stating that is as easy to hide a trojan in
the source code as in the binary? I have seen a lot trojans
hiding in binaries but I have never seen that an open source
project distributed trojaned source code. Maybe they where such
incidents but there are certainly rare.
 
> >> And the way things work, the chances are that if the binary is
> >> tainted, the source would be tainted -- and you have got nowhere.
> 
> > If I wanted to hide a trojan somewhere I would to it in the binary and
> > not in the source code. People actually look into source code on a
> > regular basis but they seldom disassemble a binary.
> 
> The window of opportunity is small. You have to replace the
>  binary .deb in between the time it was built, and it was signed. 

That's a small window if you measure the time but it is not
small window of opportunity. If the building host is compromised
than it is trivial. And it seems that DDs do upload binaries
which are compiled on their local machines. So it is actually
enough if any of those machines is compromised.

[..]
 
> >> 
> >> So, someone replaces the binary compiled on the buildd with a fake
> >> one, in between the binary being built and it being signed?  All the
> >> work to get bit-for-bit reproducibility for such a low priority
> >> attack vector?
> 
> > I do not think it is a low priority attack vector. If I would be a
> > cracker and had a rootkit installed on a debian build host it would
> > certainly insert a backdoor in ssh everytime it is compiled: Access to
> > all debian running computers world wide!
> 
> Compromise gcc? I see. So, fro all you know, every copy of gcc
>  in the world now has the compile trojan into ssh built in, and again,
>  no way for people peering at bits to see if there is a trojan buried in
>  there to find out.

Why all copies of gcc? A single copy of a gcc on a single host where
official debian packages are compiled. And the gcc binary on the disc
is unmodified: The compiler is patched after loading it in the memory
by a rootkit. Not that a single binary copy of gcc was ever completely
dissassembled and checked for trojans. That would probably take at least 
a year to do.
 
> > BTW I did some tests and for 'dpkg' the only files which change
> > between builds are the manpages and that's just because gzip stores
> > the date of the orginal in the compressed file.
> 
> This is one of the things, yes. ANy package with a tar archive
>  would suffer similarly.

That all files which are created by the actualy build process are already 
bit-identical (for dpkg) and only a postprocessing step adds time stamps
is very promising, I think.


Martin



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

Re: User-Agent strings, privacy and Debian browsers

[Sam Leon]

My only complaint is that alot of website traffic analyzer programs pick 
up the debian iceweasel browser as "unknown browser" and "unknown 
operating system"



Sam


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

Re: Re: hoi gia ve may bay

[TranTuan QuocTuan]

Xin chao! Toi muon Dat ve may Bay di ve Viet Nam vao khoang 30thang 12 nam 2007 
va tro lai Nhat vao khoang 12 thang 1 nam 2008 thi phai Dat mua o dau ! thu tuc 
nhu the nao , lien he voi ai ! va gia ve Khu hoi trong thoi diem do la nhu the 
nao ! Rat mong duoc su Huong van va giup do!! Hien Toi dang o Shizuoka -Nhat 
Ban . 
   Chan 
thanh Can on nhieu!!!
   

   
-
Hỏi, đáp và kết nối với cư dân mạng trên Yahoo! Hỏi & Đáp

Bug#444390: ITP: python-contract -- Programming by contract for python

[Mike O'Connor]

Package: wnpp
Severity: wishlist
Owner: "Mike O'Connor" <[EMAIL PROTECTED]>


* Package name: python-contract
  Version : 1.4-1
  Upstreem Author : Terence Way <[EMAIL PROTECTED]>
* URL : http://www.wayforward.net/pycontract/
* License : Python License, GPL-3, Artistic
  Programming Lang: Python
  Description : Programming by contract for python
  
 This package provides a means for programming by contract in python.
 Programming by contact is a methodology whereby a API designer can
 define checkable preconditions and postconditions for method calls,
 and invariants for classes and methods.  The most famous use of this
 methodology is in the Eiffel programming language.
 .
 This implementation of programming by contract has the developer
 write constraints in the docstrings of methods and classes that can
 be optionally checked at runtime.  If the constraints are not met,
 an exception is raised.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.21-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Bug#444415: ITP: tklib -- The standard Tk library

[Sergei Golovan]

Package: wnpp
Severity: wishlist
Owner: Sergei Golovan <[EMAIL PROTECTED]>


* Package name: tklib
  Version : 0.4.1
  Upstream Author : Various people (every module has its own author(s))
* URL : http://sourceforge.net/projects/tcllib/
* License : BSD
  Programming Lang: Tcl
  Description : The standard Tk library

Tklib, the standard Tk library, is a collection of common utility
functions and widgets all written in pure Tcl/Tk.

Modules included:
  autoscroll: automatically maps scrollbars when they are needed;
  ctext: a text widget with syntax highlighting support;
  cursor: provides a few cursor routines;
  datefield: an entry widget for the purpose of date entry;
  Diagrams: helps drawing diagrams, like flowcharts;
  getstring: a dialog which prompts for a string input;
  history: provides a history for mechanism for entry widgets;
  ico: provides functions for reading and writing windows icons;
  ipentry: a widget for the entering of an IP address;
  khim: provides key bindings for entering international
characters on a keyboard that does not support them;
  Plotchart: provides simple plotting and charting commands;
  style: provides simple theming using Tk options;
  swaplist: a dialog which allows to move options between two lists;
  tablelist: a multicolumn listbox widget;
  tkpiechart: 2D or 3D pie chart object in a canvas;
  tooltip: provides tooltips for Tk widgets;
  widget: a set of megawidgets based on snit system.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-amd64
Locale: LANG=ru_RU.CP1251, LC_CTYPE=ru_RU.CP1251 (charmap=CP1251)



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

Bug#444393: ITP: miniupnpd -- UPnP IGD lightweight daemon

[Thomas GOIRAND]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand <[EMAIL PROTECTED]>

* Package name: miniupnpd
  Version : 1.0-RC9
  Upstream Author : Thomas Bernard <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : BSD
  Programming Lang: C, C++
  Description : UPnP IGD lightweight daemon

The UPnP protocol is supported by most home adsl/cable routers and Microsoft
Windows 2K/XP. The aim of the MiniUPnP project is to bring a free software
solution to support the "Internet Gateway Device" part of the protocol. The
MediaServer/MediaRenderer UPnP protocol is also becoming very popular but here
we are talking about IGD.

Miniupnpc aims at the simplest library possible, with the smallest footprint
and no dependencies to other libraries such as XML parsers or HTTP
implementations. All the code is pure ANSI C. Compiled on a x86 PC, the
miniupnp client library have less than 15KB code size. For instance, the upnpc
sample program is around 20KB. The miniupnp daemon is much smaller than any
other IGD daemon and is ideal for using on low memory device for this reason.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (700, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17.7
Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1)



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

Re: Link Exchange Request

[Serviced Apartments London]

Sorry i cant add ur link, i need atleast PR-3 link pages:

My link info are here - if any one interested please let me know:

Dear Webmaster,



I'm a webmaster of following travel related websites:



http://www.apartotels.com/

http://www.discountcityhotels.net/

http://www.discountcityhotels.com/

http://www.luxurycityhotels.com/



And I would like to exchange link with the travels/Hotels related websites
only. In case you have any kind of related and good PR link pages, please
add a link to each of the above website with the detail below and I will add
your link on your choice of PR-3 pages from the list given below:



http://www.apartotels.com/Apartments_Links.asp

http://www.apartotels.com/Apartments_Apartotels_Links.asp

http://www.discountcityhotels.net/partners.asp

http://www.discountcityhotels.net/partners/index.htm

http://www.discountcityhotels.com/Links/Useful-Links4.htm

http://www.discountcityhotels.com/Links/Useful-Links3.htm

http://www.luxurycityhotels.com/Links.asp





My Link information is as follows:





1.



URL:   http://www.apartotels.com/

Title:   Paris Apartments

Description: For a wide range of Serviced Apartments in London, Paris our
Serviced apartments are suitable for a single person to a large family and
small businesses to corporate. Whether you are looking for a long-term
apartment or a short term stay Apartotels.com is confident that we can match
you needs



2.



URL:   http://www.luxurycityhotels.com/

Title:   Luxury Hotels

Description:  A collection of Luxury Hotels in London & Paris, especially
compiled for you, luxury hotels, luxury city hotels, Luxury London hotels,
luxury Paris hotels, Paris hotels, luxury ... More





3.



URL:   http://www.discountcityhotels.com

Title:   Cheap Hotels London

Description:  Discount London Hotels - www.discountcityhotels.com offers
great deals on cheap London hotels, last minute hotel deals at the lowest
rates in London and Paris. We have a huge collection of luxury Hotels,
suites and apartments from 2 star budget hotels to 5 star deluxe luxury
hotels centrally located in London & Paris.



4.



URL:   http://www.discountcityhotels.net

Title:   London Hotels

Description:   www.discountcityhotels.net offers great deals on Last Minute
Bargain Hotels, Late Availability London Hotels, Bed and Breakfast Hotels
and Budget Hotels in London. Up to 70% discounts on wide range of hotels
from 5 star Luxury Hotels to Budget Hotels for family, business & leisure
travelers.





Looking forward to hear from you soon.



thanks,

dchseoteam


On 9/28/07, Internet Marketing Manager <[EMAIL PROTECTED]> wrote:
>
> Dear Sir,
>
> I visited your web site earlier today and I just wanted to congratulate
> you on a well presented, and informative web site. It is not often that
> I come across a web site that offers a wealth of quality and hard to
> find information.
>
> I have a web site, www.whatahotel.com and have spent a lot of time and
> effort to ensure my visitors gain the maximum benefit from the
> information that I have offered.
>
> If you would be interested, You can add our link with the following info:
>
>
>
> Linking Info:
> Title: Canyon Ranch Hotels & Resorts Canyon Ranch Resorts Canyon Ranch
> Hotels
> URL:http://www.whatahotel.com/browse_hotel.cfm?HotelID=957
> Des: Award Winning site featuring the world's best luxury Canyon Ranch
> hotels & resorts in Canyon Ranch, each offering site visitors who make a
> booking exclusive perks and the best rates. We assure our guests a VIP
> status in Canyon Ranch. Book a reservation at Canyon Ranch and vacation
> in style.
>
>
> Your link will be placed at :
> http://www.coolsiteslist.com/hotel/hotel.shtml (Any category you choose)
> Please note that all the existing links on this page have good Google
> Page rank and it will be a big advantage for your website to be listed
> with reputed websites only. If you need any more information please feel
> free to contact us.
>
>
>
> Thanks and Regards
> Links Administartor
> Whatahotel.com
>
>
>

Re: Building packages with exact binary matches

[Don Armstrong]

On Fri, 28 Sep 2007, Martin Uecker wrote:
> You are seriously stating that is as easy to hide a trojan in the
> source code as in the binary?

Consider the fact that we've already had such a case,[1] whereas we've
not (to my knowledge) distributed a trojaned binary. I'm not sure
which is easier to hide, but it seems that making a source trojan is
at least more frequent if not easier to create.


Don Armstrong
1: mICQ anyone? http://lists.debian.org/debian-devel/2003/02/msg00872.html
-- 
[A] theory is falsifiable [(and therefore scientific) only] if the
class of its potential falsifiers is not empty.
 -- Sir Karl Popper _The Logic of Scientific Discovery_ §21

http://www.donarmstrong.com  http://rzlab.ucr.edu

Re: modified email address in debian/copyright file

[Andre Majorel]

On 2007-09-27 16:39 +1000, Ben Finney wrote:
> Lars Wirzenius <[EMAIL PROTECTED]> writes:
> 
> > I don't think there is any requirement to have any upstream contact
> > information whatsoever in order to be able to distribute a package.
> 
> This seems to be the point of disagreement. I think this should be
> required, in order that Debian users can have more confidence [0] in
> the copyright status of works in Debian.

This is your goal. It's up to you to find a way to meet it while
respecting the wishes of the upstream authors. If you can't, the
wishes of the upstream authors take precedence and you don't
distribute the package. Do we agree on that ?

-- 
André Majorel 
Thanks to the Debian project for going to such lengths never to
disclose the email addresses of their users. Think of all the
spam we would get if they didn't !


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

Re: Packaging a library that requires cross-compiled code

[David Anderson]

On 9/28/07, Ian Jackson <[EMAIL PROTECTED]> wrote:
> > Pro: feels like the Right Way, in a perfect world. Cons: opens the
> > floodgates of packaging cross-compilers, likely requires
> > additions/modifications to packaging tools, and takes way more time
> > than I'm personally ready to put into packaging my code.
>
> This is the right answer I think.  Several other embedded systems
> already have cross-compilers in Debian, so this isn't opening any
> floodgates or getting into anything too unusual.  I can see why it
> would be hard work for you to learn about packaging cross-compilers.

It would be hard work because such a package would be my second ever
debian package. Packaging something as complex as a cross-compiler
with multiple variants doesn't seem like the right second thing to
package.

But, if there is precedent, it might not be too painful to mimick
existing cross-compiler packages to build my own. I'll see what I can
do.

> > 3) Somehow make the packaging tools properly cross-compile the .bin
> > without having a cross-compiler package around. This was briefly
> > suggested on #debian-mentors, but I have no idea how this would be
> > implemented.
>
> It's not clear what you mean here.  136 bytes seems very little.  Is
> it written in an assembly language or in C ?

It is written in C, with an asm bootstrap. The idea was to basically
download and build an arm7 cross-compiler as a part of running
dpkg-buildpackage. Insane and wrong, don't say it, I know. I was just
being exhaustive as to what had already been suggested.

> > Pros: less time involved than 2), would make the package
> > self-contained. Cons: building a cross-compiler in the packaging
> > process just to build a 136 byte binary blob feels like killing a flea
> > with a bazooka, and makes building the package much, much longer than
> > it should be, given the amount of code and logic it actually carries.
>
> Yes, but I think that sounds like an acceptable alternative.

If I'm going to build a cross-compiler in the process of building my
package, might as well go the extra mile and make the cross-compiler
into a package of its own.

> > 4) Give up and stay away from the Debian main repositories, just put
> > the package up on a private package repository.
> >
> > Pro: trivial solution. Cons: I'd like to do things right rather than
> > cobbling something together.
>
> You could put the package in contrib.  I think contrib would be
> a possibility for this.  But it's far from ideal - think of the poor
> users who want to change the 136-byte loader program.

I am trying as hard as possible to think of cases where you would
actually want to change the program, but I'm drawing blank. All the
driver does is the equivalent of "memcpy(flash_addr, ram_addr,
chunk_size); *FLASH_CONTROL = FLASH_WRITE_CMD;". The only thing a user
could do by changing that code is damage the flash chip by messing
with the timing settings.

If packaging the cross-compiler is unavoidable, I'll file an ITP and
try to see how that can be done. But if it goes beyond the time I'm
prepared to put into it, I'll go with option 4, and host it outside
the main debian archive.

- Dave


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

Re: modified email address in debian/copyright file

[Steve Langasek]

On Fri, Sep 28, 2007 at 10:13:39PM +0200, Andre Majorel wrote:
> On 2007-09-27 16:39 +1000, Ben Finney wrote:
> > Lars Wirzenius <[EMAIL PROTECTED]> writes:

> > > I don't think there is any requirement to have any upstream contact
> > > information whatsoever in order to be able to distribute a package.

> > This seems to be the point of disagreement. I think this should be
> > required, in order that Debian users can have more confidence [0] in
> > the copyright status of works in Debian.

> This is your goal. It's up to you to find a way to meet it while
> respecting the wishes of the upstream authors. If you can't, the
> wishes of the upstream authors take precedence and you don't
> distribute the package. Do we agree on that ?

"You" don't distribute the package?

Ben Finney is not a Debian Developer.  The views expressed by Ben Finney on
this mailing list are not representative of the views of the Debian Project
or any of its members.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Re: Packaging a library that requires cross-compiled code

[Simon Richter]

Hi,

David Anderson wrote:


But, if there is precedent, it might not be too painful to mimick
existing cross-compiler packages to build my own. I'll see what I can
do.


Please coordinate any such effort with [EMAIL PROTECTED] :-)

I'm working on infrastructure to aid generation of cross-compiler 
packages (a templating mechanism that generates the necessary Package 
stanzas in debian/control from another file that uses a descriptive 
language; "debian-xcontrol" would be the package you are looking for, 
however that bit is not yet done as I concentrated on features that will 
allow cross-compilation of other packages first).


   Simon


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

Re: Building packages with exact binary matches

[Martin Uecker]

On Fri, Sep 28, 2007 at 09:05:59AM -0700, Don Armstrong wrote:
> On Fri, 28 Sep 2007, Martin Uecker wrote:
> > You are seriously stating that is as easy to hide a trojan in the
> > source code as in the binary?
> 
> Consider the fact that we've already had such a case,[1] whereas we've
> not (to my knowledge) distributed a trojaned binary. I'm not sure
> which is easier to hide, but it seems that making a source trojan is
> at least more frequent if not easier to create.

I would not call this a trojan. But I guess I have to change
my opinion anyway. Manoj is right: Trojaned upstream sources
are a major security risk, against which exact binary matches
do not help. But I still think they would still eliminate a lot
of other risks, which should IMHO not be ignored.

There is some other thing I do not like about the way Debian
packages work. Every package I install can actually completely
compromise my system, because the maintainer scripts are run
as root. It would be nice if normal packages would not be allowed
to have maintainer scripts and would only be allowed to install
binaries in certain paths.


Martin






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

Re: Building packages with exact binary matches

[Roberto C . Sánchez]

On Fri, Sep 28, 2007 at 11:04:00PM +0200, Martin Uecker wrote:
> 
> There is some other thing I do not like about the way Debian
> packages work. Every package I install can actually completely
> compromise my system, because the maintainer scripts are run
> as root. It would be nice if normal packages would not be allowed
> to have maintainer scripts and would only be allowed to install
> binaries in certain paths.
> 
Please define a "normal" package.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: semi-virtual packages?

[Bruce Sass]

Someone wrote:
> If you actually need to make this sort of response, could you do the
> rest of us a favor and not do so publicly?

Ya, you're right. Sorry.

My frustration got the better of me.


- Bruce


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

Re: User-Agent strings, privacy and Debian browsers

[Ben Finney]

Sam Leon <[EMAIL PROTECTED]> writes:

> My only complaint is that alot of website traffic analyzer programs
> pick up the debian iceweasel browser as "unknown browser" and
> "unknown operating system"

That's a bug in those web sites, of course. They shouldn't even be
trying to sniff User-Agent to determine what document to send, they
should send a standards-compliant document.

I do appreciate, of course, that most sites with this bug also have
the "doesn't respond well to feedback" bug.

-- 
 \   "The generation of random numbers is too important to be left |
  `\ to chance."  -- Robert R. Coveyou |
_o__)  |
Ben Finney


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

Re: modified email address in debian/copyright file

[Ben Finney]

Andre Majorel <[EMAIL PROTECTED]> writes:

> On 2007-09-27 16:39 +1000, Ben Finney wrote:
> > I think [valid contact information for copyright holders at the
> > time of packaging] should be required, in order that Debian users
> > can have more confidence [0] in the copyright status of works in
> > Debian.
> 
> This is your goal. It's up to you to find a way to meet it while
> respecting the wishes of the upstream authors.

The way seems fairly simple: Define a package without valid
copyright-holder contact information as an unacceptable risk for
Debian to take on behalf of its users.

> If you can't, the wishes of the upstream authors take precedence and
> you don't distribute the package. Do we agree on that ?

I think we should "respect the wishes of the upstream authors" in the
same manner as their license terms.

We are already in the habit of encouraging upstream copyright holders
to re-license their works under terms that pass the DFSG, rather than
dropping the package without trying. I don't see why valid contact
information of the copyright holder shouldn't be treated the same way.

-- 
 \ "I have an answering machine in my car. It says, 'I'm home now. |
  `\  But leave a message and I'll call when I'm out.'"  -- Steven |
_o__)   Wright |
Ben Finney


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

Re: modified email address in debian/copyright file

[Ben Finney]

Steve Langasek <[EMAIL PROTECTED]> writes:

> Ben Finney is not a Debian Developer.  The views expressed by Ben
> Finney on this mailing list are not representative of the views of
> the Debian Project or any of its members.

With the caveat "not *necessarily* representative", we agree on that.

-- 
 \   "There's no excuse to be bored. Sad, yes. Angry, yes. |
  `\Depressed, yes. Crazy, yes. But there's no excuse for boredom, |
_o__)   ever."  -- Viggo Mortensen |
Ben Finney


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

Re: modified email address in debian/copyright file

[Josselin Mouette]

Le vendredi 28 septembre 2007 à 13:49 -0700, Steve Langasek a écrit :
> "You" don't distribute the package?
> 
> Ben Finney is not a Debian Developer.  The views expressed by Ben Finney on
> this mailing list are not representative of the views of the Debian Project
> or any of its members.

Oh, come on. You don't need to use the Anthony Towns argument, it was
already clear that Ben's requests are pointless.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Packaging a library that requires cross-compiled code

[Bernd Zeimetz]

Hi,

> I'm working on infrastructure to aid generation of cross-compiler
> packages (a templating mechanism that generates the necessary Package
> stanzas in debian/control from another file that uses a descriptive
> language; "debian-xcontrol" would be the package you are looking for,
> however that bit is not yet done as I concentrated on features that will
> allow cross-compilation of other packages first).

Which is kinda overkill for David's package - all he needs to
cross-compile is a 136 byte large blob.
Also this is a piece of code which won't be changed by users ususally,
as it does nothing but help to transfer the real firmware into the
device (a trivial memcpy implementation according to David).

All other parts of the package are arch: all, written in python, so
everything needed would be a cross compiler on at least the architecture
where the package is being built on.

Is there anybody working on an arm7 cross-compiler yet, if so, are there
plans to get it into Debian's main? I guess you want to support every
arm cpu in main!?

Or is there any other possible way to get this package into main?

Best regards,

Bernd

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Re: modified email address in debian/copyright file

[Steve Langasek]

On Sat, Sep 29, 2007 at 12:40:39AM +0200, Josselin Mouette wrote:
> Le vendredi 28 septembre 2007 à 13:49 -0700, Steve Langasek a écrit :
> > "You" don't distribute the package?

> > Ben Finney is not a Debian Developer.  The views expressed by Ben Finney on
> > this mailing list are not representative of the views of the Debian Project
> > or any of its members.

> Oh, come on. You don't need to use the Anthony Towns argument, it was
> already clear that Ben's requests are pointless.

Apparently at least one other reader of debian-devel was confused on this
point.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Bug#444485: ITP: python-pynxt -- Lego Mindstorms NXT Python interface

[David Anderson]

Package: wnpp
Severity: wishlist
Owner: David Anderson <[EMAIL PROTECTED]>


* Package name: python-pynxt
  Version : 0.0.1
  Upstream Author : David Anderson <[EMAIL PROTECTED]>
* URL : https://ssl.natulte.net/nxos/devel
* License : GPLv2
  Programming Lang: Python
  Description : Lego Mindstorms NXT Python interface

 PyNXT is a Python module that enables developers to communicate with
 Lego Mindstorms NXT bricks at a low level. It currently facilitates
 scanning the USB chain for a NXT brick and implements the SAM-BA
 bootloader communication protocol.
 .
 It comes with two utilities, fwflash and fwexec, which can be used to
 write a firmware to either flash memory or RAM, and execute it from
 there.

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

Kernel: Linux 2.6.22-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Re: Building packages with exact binary matches

[Manoj Srivastava]

On Fri, 28 Sep 2007 23:04:00 +0200, Martin Uecker <[EMAIL PROTECTED]> said: 

> There is some other thing I do not like about the way Debian packages
> work. Every package I install can actually completely compromise my
> system, because the maintainer scripts are run as root.

You can, of course, run a strict mode SELinux system, and see
 that the apt_t security domain is sufficiently confined for your
 tastes (you may have a local security policy that tightens down the
 default project wide constraints, to the level you heart desires).

manoj
-- 
"...and it's finished!  It only has to be written." Karl Lehenbauer
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: How to detect if inside a buildd chroot

[Anthony DeRobertis]

Roger Leigh wrote:
> You can't reliably (or portably) check if you are in a chroot. 
Hmm, if you're root you probably can. Something like this (completely
untested; probably doesn't even compile):

DIR *d;
int fd;
struct stat s1, s2;

mkdir("temp", 0700);
d = opendir("/");
fd = dirfd(d);
fstat(fd, &s1);

chroot("temp");
fchdir(fd);
stat("..", &s2);


if (s1.st_dev != s2.st_dev || s1.st_ino != s2.st_ino) {
/* we were in a chroot */
}
  

Actually, come to think of it, I wonder if stat'ing "/.." would work...
If it does, then you don't even need root.


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