Re: Building packages with exact binary matches

[Manoj Srivastava]

On Wed, 26 Sep 2007 12:31:51 +0200, Martin Uecker <[EMAIL PROTECTED]> said: 

> On Wed, Sep 26, 2007 at 12:25:02AM -0500, Manoj Srivastava wrote:

>> Just because you have _heard_ anyone diss special relativity being
>> the sole reason to believe in it is in the same ball park as
>> blissful, you know, ignorance.

> It is not about hearsay. It is about finding an error in a
> predictation.  And I do not care *who* finds the error. Of course the
> predications have actually be checked. So you are right with your
> argument, if nobody actually does this, it would be ignorant to
> believe in a scientifc theory for the sole reason that nobody
> complains. Similar, if nobody recompiles the packages and checks for
> mismatches, then silence would in fact not imply that things are
> ok. But I question your premise: I have no doubt that some people
> would actually recompile packages and compare the hash. Even if it is
> not done normally, somebody would do this if doubts come up for some
> reason (e.g. some debian hosts are compromised again.).  This alone
> would actually be worth a lot.

But recompiling from what? If you do not get the exact same
 source, you have no hope of getting the same result.  And the way
 things work, the chances are that if the binary is tainted, the source
 would be tainted -- and you have got nowhere.

>> The difference is evidence.  If there is some merit to the notion
>> that a buildd is compromised, the solution is not bunches of people
>> building from potentially tainted sources and comparing checksums.

> If know that the source code wich has hash 4457575757575 compiled in
> the build environment with hash 4837373737 gives a package with hash
> 366336363, then it is actually *evidence* that something is seriously
> wrong if you end up with a package with a different hash.

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?

manoj

-- 
"VMS is a text-only adventure game. If you win you can use Unix." Bill
Davidsen ([EMAIL PROTECTED])
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: semi-virtual packages?

[Manoj Srivastava]

On Wed, 26 Sep 2007 04:04:33 -0600, Bruce Sass <[EMAIL PROTECTED]> said: 

> On Tue September 25 2007 09:22:02 am Manoj Srivastava wrote:
>> On Tue, 25 Sep 2007 02:36:24 -0600, Bruce Sass <[EMAIL PROTECTED]> said:
>> > On Sun September 23 2007 03:08:59 pm Manoj Srivastava wrote:
>> >> On Sun, 23 Sep 2007 14:26:29 -0600, Bruce Sass <[EMAIL PROTECTED]>
>> >> said:

> [I've cut a lot of duplication. If I cut something which doesn't get
> addressed below, feel free to bring it back.]

>> > The scheme I described was under the written assumption there are
>> > no such situations which would not already have a virtual package.
>> 
>> Ah.  That assumption turns out to be incorrect.

> Haha. There is nothing wrong with the assumption. That is kinda like
> saying pylint is incorrect for spitting out errors when given a
> correct perl program. You ignored a sign which would have taken you
> down a different path, and now appear to be complaining because the
> path you ended up on took you to the wrong place---neither the sign or
> paths are incorrect, you just didn't pay attention and got lost.

Hmm? You assumed, and I quote "there are no such situations
 which would not already have a virtual package".  Since there are
 situations where there is no virtual package, it certainly seems to me
 that the assumption you made is invalid.

If your assumption is correct, then I have missed something
 somewhere. 

>> > Why would you think any of that scheme was applicable to the case
>> > you were thinking of if it is a case in which there is no virtual
>> > package?
>> 
>> I am not sure how to answer that.  I assumed that the scheme under
>> discussion was going to be universal (or else it does not seem to be
>> much good, really -- it would still leave files around that are not
>> associated with anything).

> I don't see why it would need to be universal, "one size" stuff often
> doesn't fit anyone very well and it is not like being universal is
> pervasive and this would stand out as a wart.

If we are not talking about a policy to be made, and you are
 only talking about an opt in scheme for some  orphan files, then
 indeed, I have nothing to add to the conversation.

manoj
-- 
algorithm, n.: Trendy dance for hip programmers.
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]

Bug#444249: ITP: pyexiv2 -- Python binding to Exiv2

[Michal Čihař]

Package: wnpp
Severity: wishlist
Owner: "Michal Čihař" <[EMAIL PROTECTED]>


* Package name: pyexiv2
  Version : 0.1
  Upstream Author : Olivier Tilloy <[EMAIL PROTECTED]>
* URL : http://tilloy.net/dev/pyexiv2/
* License : GPL
  Programming Lang: C++/Python
  Description : Python binding to Exiv2

 pyexiv2 is a python binding to exiv2, the C++ library for manipulation
 of EXIF and IPTC image metadata. It is a python module that allows your
 python scripts to read and write metadata (EXIF, IPTC, thumbnail)
 embedded in image files (JPEG, TIFF, ...).

 It is designed as a high level interface to the functionalities offered
 by exiv2 (and is built on top of it). Using python's built-in data
 types and standard modules, it provides easy manipulation of image
 metadata. 

-- 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/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Re: modified email address in debian/copyright file

[Holger Levsen]

Hi,

On Thursday 27 September 2007 08:39, 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...

Whether or not it its an requirement to be able to contact the author, doesnt 
have anything to do with obfuscating the email address or not. (Assuming its 
not obfuscated beyond recognitition.) (*)

Unless you talk about the requirement to be able to contact the author without 
human intervention. But I haven't read anybody requiring that.

And as Lars wrote in the email you replied to:

> Mind you, I don't like obfuscation, and I think it's a nuisance myself,
> but we shouldn't violate people's wish to try to avoid spam by
> publishing their addresses in un-obfuscated form. That only makes people
> angry at us for little or no benefit, since there are no situations when
> we want to automatically send e-mails to upstream developers anyway.

I completly agree with those five lines.


regards,
Holger

(*) BTW, I dont have an example at hand, but I'm pretty sure I have seen code 
in Debian written by anonymous and friends. You can't contact them either.


pgp1ZwP7gNX1Y.pgp
Description: PGP signature

Re: Changing name of source package

[Francesco P. Lovergine]

On Wed, Sep 26, 2007 at 07:26:51PM -0700, Steve Langasek wrote:
> 
> The only other thing you need to worry about is filing a bug report against
> ftp.debian.org to get the old php4-ps source package removed, since this
> won't happen automatically.
> 

If it is not still required in stable/oldstable isn't it?

-- 
Francesco P. Lovergine


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

Re: Building packages with exact binary matches

[Martin Uecker]

Ben Finney <[EMAIL PROTECTED]> wrote:

> Martin Uecker <[EMAIL PROTECTED]> writes:
>
> > On Tue, Sep 25, 2007 at 06:33:40PM -0500, Manoj Srivastava wrote:
> > > Ah, security through blissful ignorance :) You do not
> > >  actually trust the archive, or the developers, you trust the
> > >  silence.
> > 
> > I trust special relativity, because nobody has disproven it yet.
>
> Really? I trust the theory of special relativity because there is
> enormous evidence supporting it, and little evidence against it.

There is enormous evidence for the Aristotle' believe that more
massive objects fall faster and little evidence against it.
Only a carefully crafted experiment shows that it is false.

> In the case of "there are no messages, therefore I trust the security
> of the system", that's faith â belief in spite of an utter lack of
> evidence.

The predictions must be testable by everbody and - of course -
some must actually try to falsify them. Exact binary matches
would allow everbody to check the integrity of the binary
packages and I am quite sure that some people would do it.
In this case "no messages" stating that something is wrong
is not the same as lack of evidence, it is actually evidence
for the assumption that everything is ok.

> > Do you think this is blissfull ignorance, too? 
>
> Worse, it's foolish.

It is foolish to base his trust purely on the authority
of some person. People's belief that massive objects
fall faster was based on the authority of Aristotle.
Debian user's trust in the integrity of some binary package
is based on the authority of the person putting a gpg
signature on it.

> In the lack of *any* evidence either way on a question, it's foolish
> to hold any position but "unknown";

That is a common misbelief. Some things are inherently more
probable than other.

> and, if the question is important for a matter of trust,
> it's imperative to *get* some evidence before extending any trust.

That is certainly true.


Martin

Re: Changing name of source package

[Adeodato Simó]

* Francesco P. Lovergine [Thu, 27 Sep 2007 11:01:34 +0200]:

> On Wed, Sep 26, 2007 at 07:26:51PM -0700, Steve Langasek wrote:

> > The only other thing you need to worry about is filing a bug report against
> > ftp.debian.org to get the old php4-ps source package removed, since this
> > won't happen automatically.

> If it is not still required in stable/oldstable isn't it?

Removals by ftpmaster (whether of binaries, source, or both) normally
happen against unstable only. The removal then propagates to testing,
which means that the *next* stable release won't have them.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Listening to: Joan Manuel Serrat - Algo personal


-- 
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 02:26:49AM -0500, Manoj Srivastava wrote:
> On Wed, 26 Sep 2007 12:31:51 +0200, Martin Uecker <[EMAIL PROTECTED]> said: 
> 
> > On Wed, Sep 26, 2007 at 12:25:02AM -0500, Manoj Srivastava wrote:
> 
> >> Just because you have _heard_ anyone diss special relativity being
> >> the sole reason to believe in it is in the same ball park as
> >> blissful, you know, ignorance.
> 
> > It is not about hearsay. It is about finding an error in a
> > predictation.  And I do not care *who* finds the error. Of course the
> > predications have actually be checked. So you are right with your
> > argument, if nobody actually does this, it would be ignorant to
> > believe in a scientifc theory for the sole reason that nobody
> > complains. Similar, if nobody recompiles the packages and checks for
> > mismatches, then silence would in fact not imply that things are
> > ok. But I question your premise: I have no doubt that some people
> > would actually recompile packages and compare the hash. Even if it is
> > not done normally, somebody would do this if doubts come up for some
> > reason (e.g. some debian hosts are compromised again.).  This alone
> > would actually be worth a lot.
> 
> 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.

>  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 difference is evidence.  If there is some merit to the notion
> >> that a buildd is compromised, the solution is not bunches of people
> >> building from potentially tainted sources and comparing checksums.
> 
> > If know that the source code wich has hash 4457575757575 compiled in
> > the build environment with hash 4837373737 gives a package with hash
> > 366336363, then it is actually *evidence* that something is seriously
> > wrong if you end up with a package with a different hash.
> 
> 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!

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.

Martin

Releasing packages with 'pending' RC bugs

[Daniel Baumann]

Hi,

out of curiousity.. imagine a package where:

  * the Debian maintainer is also upstream maintainer
  * the package has practically no users (popcon << 10)
  * the package has RC bugs
  * the RC bugs are fixed upstream
  * the RC bugs are tagged pending in the BTS
  * the fixed package doesn't get uploaded (e.g. due to ENOSPONSOR)

If I am not wrong (otherwise please do correct me) such a package would
enter testing on the normal way, and hence, would be part of the
upcoming stable release.

I don't know if many of these cases extists, but, are they actually
dealt with somehow by someone, or are they currently slipping through?

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: Releasing packages with 'pending' RC bugs

[Adam D. Barratt]

Daniel Baumann wrote, Thursday, September 27, 2007 11:43 AM


out of curiousity.. imagine a package where:

 * the Debian maintainer is also upstream maintainer
 * the package has practically no users (popcon << 10)
 * the package has RC bugs
 * the RC bugs are fixed upstream
 * the RC bugs are tagged pending in the BTS
 * the fixed package doesn't get uploaded (e.g. due to ENOSPONSOR)

If I am not wrong (otherwise please do correct me) such a package would
enter testing on the normal way, and hence, would be part of the
upcoming stable release.


You're wrong. Assuming that the RC bugs are not present in testing already, 
the testing scripts will not allow the package to migrate. Tagging bugs as 
pending does not stop them being RC and makes no difference to their impact 
on testing migration.


If the package in testing is RC buggy it will get removed by the release 
team before release anyway.


Adam 



--
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/27/07, Bernd Zeimetz <[EMAIL PROTECTED]> wrote:
> > 4) Give up and stay away from the Debian main repositories, just put
> > the package up on a private package repository.
>
> Please don't choose this way to solve the problem. Lego Mindstorms are
> used a lot for education, including universities, as it is just very
> easy to build objects with Lego bricks, so you have more time to think
> about the code then about how to handle metal or other raw material.

I agree. As I said, I want to do things right if I can.

> Unfortunately I still have no clue about cross-compiling, but please let
> me know if you need any help with the python parts. Feel free to join
> #debian-python on OFTC, all questions regarding python apps/modules are
> welcome there

Thanks, I'll be there, since I actually do have a few questions on
that part as well.

> Imho one very fast way to solve the problem would be to package all the
> python tools, including fwflash - but without the actual firmware blob.
> Instead you ask the people to download the file or let the tool handle
> this automatically - at least this would make sure people are able to
> use your tools with mindstorms while you have enough time to figure out
> how to ship the precompiled firmware in a debian package. For example
> you could build the firmware package on arm only and let your tools
> download and extract the package.

If you look at the previous version of my library, which is in C and
builds with SCons ( http://code.google.com/p/libnxt/ ), in C I
embedded the binary image directly into the source code before
compiling, using a small python script. And that python script does
detect the absence of the compiled firmware image, and asks the user
whether the binary should be downloaded from code.google.com. The
alternative is to abort the build, make the binary image locally, and
rerun.

While this is a workable solution, I find it annoying because it
places part of the burden of packaging on the user, for an
implementation detail. I have seen this kind of thing done before, but
for licensing reasons (non-free firmware that cannot be bundled in the
package), whereas this seems to be a purely technical issue.

Could the same kind of thing be done at package creation time, ie.
prompt the packager to either build or download a working version of
the binary image when the package is built (or just download it
automatically if non-interactive is required) ? The end result is the
same, except that end users don't have to care any more, which is
always nice.

If you couldn't tell btw: I think that the first solution I mentionned
would work well. The flash driver is tiny, and so trivial that it is
highly unlikely that it will change in the future, so I consider
bundling it a debian-specific fix to the upstream build system more
than anything else (so that the packaging process doesn't need to
download something from the web, which is what the python setup.py is
likely going to do to get around the cross-compiler issue).

- Dave


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

Re: modified email address in debian/copyright file

[Darren Salt]

I demand that Lars Wirzenius may or may not have written...

[snip]
> Obfuscation which can easily be reversed by a human, but not so easily by a
> computer, does not render contact information incorrect. If I write my
> e-mail address as follows, it's still correct: "My full name is Lars Ivar
> Wirzenius, and you can send me e-mail by taking my initials and putting
> them in front of the at sign and iki.fi after it."

But is that LIW or liw or Liw or...? :-)

[snip]
-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Travel less. Share transport more.   PRODUCE LESS CARBON DIOXIDE.

A clean and tidy desk is a sign of a *very* sick mind.


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

Re: modified email address in debian/copyright file

[Stephen Gran]

This one time, at band camp, Darren Salt said:
> I demand that Lars Wirzenius may or may not have written...
> 
> [snip]
> > Obfuscation which can easily be reversed by a human, but not so easily by a
> > computer, does not render contact information incorrect. If I write my
> > e-mail address as follows, it's still correct: "My full name is Lars Ivar
> > Wirzenius, and you can send me e-mail by taking my initials and putting
> > them in front of the at sign and iki.fi after it."
> 
> But is that LIW or liw or Liw or...? :-)

I know it was a joke, but since email is (usually) case-insensitive, it
won't matter in practice.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Maintainer of package joystick may be missing

[laszlo kajan]

Dear Aníbal,

I uploaded the button and axis remapping patch against
joystick/20051019-1.1. This most recent patch also includes updates for
the jscal manpage, documenting the new command line arguments.

Thank you for your help.

Best regards,

Laszlo Kajan


Aníbal Monsalve Salazar wrote:
> On Tue, Sep 25, 2007 at 05:24:14PM +0200, laszlo kajan wrote:
>> Please show me the way I can have my patch included in jscal.c of the
>> joystick package. I believe it is useful and I immediately wanted to
>> share it with others.
> 
> Please file a bug report (including the patch) against the joystick
> package.
> 
> Aníbal Monsalve Salazar


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

Re: modified email address in debian/copyright file

[paddy]

On Thu, Sep 27, 2007 at 12:59:18PM +0100, Stephen Gran wrote:
> This one time, at band camp, Darren Salt said:
> > I demand that Lars Wirzenius may or may not have written...
> > 
> > [snip]
> > > Obfuscation which can easily be reversed by a human, but not so easily by 
> > > a
> > > computer, does not render contact information incorrect. If I write my
> > > e-mail address as follows, it's still correct: "My full name is Lars Ivar
> > > Wirzenius, and you can send me e-mail by taking my initials and putting
> > > them in front of the at sign and iki.fi after it."
> > 
> > But is that LIW or liw or Liw or...? :-)
> 
> I know it was a joke, but since email is (usually) case-insensitive, it
> won't matter in practice.

not at all. 

rfc2821 2.4 "The local-part of a mailbox MUST BE treated as case sensitive."

So, senders should use LIW@ but the MTA at the other end is free to accept
liw@ and Liw@ etc ...

;-)

Regards,
Paddy


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

Re: Packaging a library that requires cross-compiled code

[Bastian Blank]

On Wed, Sep 26, 2007 at 06:38:02PM -0700, Steve Langasek wrote:
> (Otherwise, you'd be building the arch: all package from the binary-arch
> rule on arm only; this would work, but cause brain-twistiness wrt the
> separation between arch: all and arch: any.)

sbuild does not allow this.

Bastian

-- 
If a man had a child who'd gone anti-social, killed perhaps, he'd still
tend to protect that child.
-- McCoy, "The Ultimate Computer", stardate 4731.3


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

Re: Releasing packages with 'pending' RC bugs

[Daniel Baumann]

Adam D. Barratt wrote:
> You're wrong.

that...

> If the package in testing is RC buggy it will get removed by the release
> team before release anyway.

and that is good to know, thanks for the correction/explenation ;)

-- 
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: Proposed menu changes

[Bill Allombert]

On Fri, Sep 21, 2007 at 03:23:04AM -0500, Manoj Srivastava wrote:
> Hi,
> 
> While in the process of working on a new fvwm package, I
>  noticed that the Menu policy has changed some of the old titles to new

I was hoping I had sufficiently advertised the proposal and the changes
so that it would have reached you sooner.

>  ones.  For example, WindowManagers => "Window Managers", Modules =>
>  "FVWM Module" (which is incorrect; the correct way to address the wm
>  is Fvwm). 

In that case, please report a bug to debian-policy requesting the
change. This is a trivial matter to fix.

> But this means that people  who use Debian menus in fvwm have
>  now got to change their .fvwm/.fvwmrc files; and use the new names.
>  For example, 
> + "&WindowManagers" Popup /Debian/WindowManagers
> + "&FVWM Modules" Popup "/Debian/Modules"
>  nust become.
> + "&FVWM Modules" Popup "/Debian/FVWM_Modules"
> + "&Window Managers" Popup "/Debian/Window_Managers"
> 
> So, with the new menu policy, Fvwm users have to edit their
>  configuration files.  Are there any plans for preserving backwards
>  compatibility, or at least a transition plan?

I would say it is a job for the menu-method, not for menu itself.
Does FVWM allow to define aliases to menu section, or something similar?
You could define "WindowManagers" as an alias for "Window Managers",
etc.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Re: Packaging a library that requires cross-compiled code

[Daniel Jacobowitz]

On Thu, Sep 27, 2007 at 02:59:16AM +0200, David Anderson wrote:
> 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.

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).

-- 
Daniel Jacobowitz
CodeSourcery


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

Re: modified email address in debian/copyright file

[Stephen Gran]

This one time, at band camp, [EMAIL PROTECTED] said:
> On Thu, Sep 27, 2007 at 12:59:18PM +0100, Stephen Gran wrote:
> > This one time, at band camp, Darren Salt said:
> > > I demand that Lars Wirzenius may or may not have written...
> > > 
> > > [snip]
> > > > Obfuscation which can easily be reversed by a human, but not so easily 
> > > > by a
> > > > computer, does not render contact information incorrect. If I write my
> > > > e-mail address as follows, it's still correct: "My full name is Lars 
> > > > Ivar
> > > > Wirzenius, and you can send me e-mail by taking my initials and putting
> > > > them in front of the at sign and iki.fi after it."
> > > 
> > > But is that LIW or liw or Liw or...? :-)
> > 
> > I know it was a joke, but since email is (usually) case-insensitive, it
> > won't matter in practice.
> 
> not at all. 
> 
> rfc2821 2.4 "The local-part of a mailbox MUST BE treated as case sensitive."
> 
> So, senders should use LIW@ but the MTA at the other end is free to accept
> liw@ and Liw@ etc ...

  "However, exploiting the case sensitivity of mailbox local-parts impedes 
  interoperability and is discouraged."

Hence the '(usually) case-insensitive'.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: semi-virtual packages?

[Bruce Sass]

On Thu September 27 2007 01:33:21 am Manoj Srivastava wrote:
> On Wed, 26 Sep 2007 04:04:33 -0600, Bruce Sass <[EMAIL PROTECTED]> said:

> Hmm? You assumed, and I quote "there are no such situations
>  which would not already have a virtual package".  Since there are
>  situations where there is no virtual package, it certainly seems to
> me that the assumption you made is invalid.

That is not correct, what I assumed was:
a, "no", to the above [question]

What you quoted is not a primary assumption (as you've been treating it 
as), it is based on a condition having been met.

> If your assumption is correct, then I have missed something
>  somewhere.

The bit you're still missing is the first part of the question you 
didn't answer: "Is there any situation where ownership has collided"

IOW: if the file shared by many packages isn't having ownership problems 
there is no need to consider it (no point trying to fix something that 
is not broken, eh).


> > I don't see why it would need to be universal, "one size" stuff
> > often doesn't fit anyone very well and it is not like being
> > universal is pervasive and this would stand out as a wart.
>
> If we are not talking about a policy to be made, and you are
>  only talking about an opt in scheme for some  orphan files, then
>  indeed, I have nothing to add to the conversation.

s/some/all but a few/I suspect


- Bruce


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

Re: modified email address in debian/copyright file

[paddy]

On Thu, Sep 27, 2007 at 02:54:08PM +0100, Stephen Gran wrote:
> This one time, at band camp, [EMAIL PROTECTED] said:
> > On Thu, Sep 27, 2007 at 12:59:18PM +0100, Stephen Gran wrote:
> > > This one time, at band camp, Darren Salt said:
> > > > I demand that Lars Wirzenius may or may not have written...
> > > > 
> > > > [snip]
> > > > > Obfuscation which can easily be reversed by a human, but not so 
> > > > > easily by a
> > > > > computer, does not render contact information incorrect. If I write my
> > > > > e-mail address as follows, it's still correct: "My full name is Lars 
> > > > > Ivar
> > > > > Wirzenius, and you can send me e-mail by taking my initials and 
> > > > > putting
> > > > > them in front of the at sign and iki.fi after it."
> > > > 
> > > > But is that LIW or liw or Liw or...? :-)
> > > 
> > > I know it was a joke, but since email is (usually) case-insensitive, it
> > > won't matter in practice.
> > 
> > not at all. 
> > 
> > rfc2821 2.4 "The local-part of a mailbox MUST BE treated as case sensitive."
> > 
> > So, senders should use LIW@ but the MTA at the other end is free to accept
> > liw@ and Liw@ etc ...
> 
>   "However, exploiting the case sensitivity of mailbox local-parts impedes 
>   interoperability and is discouraged."
> 
> Hence the '(usually) case-insensitive'.

yes, I caught that '(usually)'. figured that was what you meant :-)

I don't think that drawing the conclusion I did counts as 
"exploiting the case sensititivity of mailbox local-parts",
it being explictly covered in the passage I quoted, although 
I would agree that perhaps Lars should be discouraged from 
depending on this interpretation ...  ;-)

On the other hand, relying on the case-insensitivity of the local-part is
explicitly broken, even if it works in practice :-)

I'm so glad we have standards to make these things clear ;-)

Regards,
Paddy


-- 
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]

Holger Levsen <[EMAIL PROTECTED]> writes:

> Whether or not it its an requirement to be able to contact the
> author, doesnt have anything to do with obfuscating the email
> address or not. (Assuming its not obfuscated beyond recognitition.)

That just pushes the question to a different location, without
answering it: what do we accept as a valid email address, and what do
we categorise as so far obfuscated that it's no longer useful.

It also puts one in the untenable position of having to make
*individual* decisions on every case of obfuscation: is this one too
far munged? Is that one? On what do I base my judgement of "too far"?

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.

> (*) BTW, I dont have an example at hand, but I'm pretty sure I have
> seen code in Debian written by anonymous and friends. You can't
> contact them either.

I don't doubt that's true. It's a regrettable situation, because the
copyright statement for that person's work is unverifiable even at the
time the code is accepted into Debian, let alone later in the future.

-- 
 \   Eccles: "I just saw the Earth through the clouds!"  Lew: "Did |
  `\ it look round?"  Eccles: "Yes, but I don't think it saw me."  |
_o__)  -- The Goon Show, _Wings Over Dagenham_ |
Ben Finney


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

Re: Packaging a library that requires cross-compiled code

[Shachar Shemesh]

David Anderson wrote:
> Therefore, question: how should I get from this situation to having a
> working .deb (including the cross-compiled driver), while at the same
> time playing nicely with Debian packaging policies?
>   
In the general case, the problem is much wider. Let me give you an example.

We currently package Xen and other free virtualization solutions. Some
of them can even run proprietary OSes, such as Windows. Now, suppose
that one would like to improve the way Windows runs under Xen by
writing, say, a custom mouse driver for Windows that para-virtualizes
the mouse on Windows. Such things are quite common in todays' world.

The problem is that this driver is a kernel level driver for Windows. If
it were user space we could still claim it could be compiled with
cross-mingw, but this is not the case here. Setting up an environment
for compiling Windows kernel drivers merely so we can build this tiny
blob seems out of proportion.

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.

Shachar


-- 
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]

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.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 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]

Re: User-Agent strings, privacy and Debian browsers

[Michelle Konzack]

Sorry for the late reply but currently I am porting a new architecture
and have not very much time...

Am 2007-09-21 18:03:05, schrieb Peter Eckersley:
> Consider for a moment a typical User-Agent string sent by a Debian web 
> browser:
> 
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070802 
> Iceape/1.1.4 (Debian-1.1.4-1)
> 
> Unfortunately, the fact that this information identifies a specific
> package and version of that package means that Debian users (already a
> select group) have their browsing identities further distinguished by
> their User-Agent strings.

Which quiet helpful IF YOU NEED complex websites which MUST work
with ANY browsers

> This means, in practice, that many sites will be able to track Debian
> users by their User-Agent, even if (say) the user is blocking cookies or
> limiting them to a single session and is changing IP address regularly.

Tracking $USER is not possibel if you check the popularity-contest.
Mean:  there 100th of thousands Debian-User using the same Program.

> What do people think of picking a single User-Agent string for all
> versions of all of Debian's Gecko-based browsers?

Which leed to errors while trying to resolv bugs.

> Would there be any serious harm in terms of browser debugging?  Are
> there many sites which usefully treat different Gecko browsers
> differently?

Yes, at least my Website an some Intranet-Sites of the french military...

> As a far more hypothetical question, what would people think of picking
> a single User-Agent for Gecko-based browsers for a larger set of
> GNU/Linux distributions?  Obviously, there is much more politics there,
> because any distributions that joined would be losing the ability to
> measure their desktop market share by looking at web statistics.

Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSN LinuxMichi
0033/6/6192519367100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: User-Agent strings, privacy and Debian browsers

[Michelle Konzack]

Am 2007-09-22 11:16:55, schrieb Peter Eckersley:
> But maybe you use open wifi networks, and other Debian users also use
> those networks.  Maybe there are other Debian users behind your NAT.
> Maybe your friends come over sometimes and they also use Debian.  In
> those cases, standardising the User-Agent string increases the size of
> your anonymity sets for various activities.

...and if you have a faulty browser in your network?
(e.g. forgotten to make a security-update or an interrupted one)

Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSN LinuxMichi
0033/6/6192519367100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: Changing name of source package

[Magnus Holmgren]

On torsdagen den 27 september 2007, Francesco P. Lovergine wrote:
> On Wed, Sep 26, 2007 at 07:26:51PM -0700, Steve Langasek wrote:
> > The only other thing you need to worry about is filing a bug report
> > against ftp.debian.org to get the old php4-ps source package removed,
> > since this won't happen automatically.
>
> If it is not still required in stable/oldstable isn't it?

ftpmaster doesn't delete the source package, he just tells the system that the 
package is no longer wanted. When no suite references the package any longer, 
it is deleted, and _that_ part happens automatically.

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)


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

Bug#444334: ITP: libmowgli -- a high performance development framework for C

[Patrick Schoenfeld]

Package: wnpp
Severity: wishlist
Owner: Patrick Schoenfeld <[EMAIL PROTECTED]>

* Package name: libmowgli
  Version : 0.4.0
  Upstream Author : Atheme Project
* URL : http://www.atheme-project.org/projects/mowgli.shtml
* License : BSD
  Programming Lang: C
  Description : a high performance development framework for C

mowgli is a development framework for C (like GLib), which provides high
performance and highly flexible algorithms. It can be used as a suppliment
to GLib (to add additional functions (dictionaries, hashes), or replace some
of the slow GLib list manipulation functions), or stand alone. It also provides
a powerful hook system and convenient logging for your code, as well as a high
performance block allocator.

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

Kernel: Linux 2.6.22-2-k7 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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]

Call for tests: new ThinkFinger package in experimental (PAM-0.99.7.1)

[Luca Capello]

Hello!

A new ThinkFinger [1] package has been uploaded to experimental [2]:
this package was built with PAM in unstable and since a while it's
working with no major problems on my sid.  I wrote "major" because
there're indeed some problems (links available at [2])...

1) not all the application that perform authentication supports
   ThinkFinger, the worst being screensavers and gksudo [3]

2) a really annoying problem is the SSH segfault [4]: this is still
   unsolved and could deserve an RC bug (but I'd go anyway to lenny
   for wider testing (comments welcome)

So, this is call for people who have an UPEK/STMicroelectronics
fingerprint reader (0483:2016), usually found either as a standalone
USB device, built into USB keyboards or built into laptops (usually
From Dell, IBM/Lenovo and Toshiba).  Please test the package in
experimental and report any (unknown) problem in the BTS.  Otherwise,
I'll upload the experimental package to unstable after 10 days from
this mail (and after lenny to bakcports, too).

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://thinkfinger.sourceforge.net
[2] 
http://lists.alioth.debian.org/pipermail/fingerforce-devel/2007-September/07.html
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=444059
[4] 
http://news.gmane.org/group/gmane.linux.drivers.thinkfinger/thread=434/force_load=t


pgpaHyFt1flOb.pgp
Description: PGP signature

Re: Building packages with exact binary matches

[Manoj Srivastava]

On Thu, 27 Sep 2007 11:28:47 +0200, Martin Uecker <[EMAIL PROTECTED]> said: 

> On Thu, Sep 27, 2007 at 02:26:49AM -0500, Manoj Srivastava wrote:
>> On Wed, 26 Sep 2007 12:31:51 +0200, Martin Uecker <[EMAIL PROTECTED]>
>> said:
>> 
>> > On Wed, Sep 26, 2007 at 12:25:02AM -0500, Manoj Srivastava wrote:
>> 
>> >> Just because you have _heard_ anyone diss special relativity being
>> >> the sole reason to believe in it is in the same ball park as
>> >> blissful, you know, ignorance.
>> 
>> > It is not about hearsay. It is about finding an error in a
>> > predictation.  And I do not care *who* finds the error. Of course
>> > the predications have actually be checked. So you are right with
>> > your argument, if nobody actually does this, it would be ignorant
>> > to believe in a scientifc theory for the sole reason that nobody
>> > complains. Similar, if nobody recompiles the packages and checks
>> > for mismatches, then silence would in fact not imply that things
>> > are ok. But I question your premise: I have no doubt that some
>> > people would actually recompile packages and compare the hash. Even
>> > if it is not done normally, somebody would do this if doubts come
>> > up for some reason (e.g. some debian hosts are compromised again.).
>> > This alone would actually be worth a lot.
>> 
>> 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.

>> 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. 

>> >> The difference is evidence.  If there is some merit to the notion
>> >> that a buildd is compromised, the solution is not bunches of
>> >> people building from potentially tainted sources and comparing
>> >> checksums.
>> 
>> > If know that the source code wich has hash 4457575757575 compiled
>> > in the build environment with hash 4837373737 gives a package with
>> > hash 366336363, then it is actually *evidence* that something is
>> > seriously wrong if you end up with a package with a different hash.
>> 
>> 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.

> 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.

manoj
-- 
The bug starts here.
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: semi-virtual packages?

[Manoj Srivastava]

On Thu, 27 Sep 2007 08:08:49 -0600, Bruce Sass <[EMAIL PROTECTED]> said: 

> The bit you're still missing is the first part of the question you
> didn't answer: "Is there any situation where ownership has collided"

> IOW: if the file shared by many packages isn't having ownership
> problems there is no need to consider it (no point trying to fix
> something that is not broken, eh).

The start of this thread was a rant about not loose files
 floating around in /etc; not necessarily about whether these files in
 themselves had ownership problems (whtever that means).

Here is the original context. Note how you say the problem
 (actually, design flaw) is about current tools do not "catch files
 created by Maintainer scripts"?

Nice to see the design flaw has become stuff that is not broken
 and does not have to be fixed.  That is all I cared about, really.

manoj

On Fri, 21 Sep 2007 03:25:23 + (UTC), Oleg Verych (Gmane)
<[EMAIL PROTECTED]> said:  

> 19-09-2007, Bruce Sass: []
>>> > I like this too. Finding what a package has just installed is one
>>> > of the biggest holes in Debian right now, IMO. I have to use dpkg
>>> > -L to figure this out, and that's just too crude to be a real
>>> > solution.
>>> 
>>> Too crude?  That's a simple command, easily found in a relevant
>>> manpage.  In true Unix fashion, its output can be easily piped to
>>> other commands.  What's crude about it?
>> 
>> It doesn't catch files created by Maintainer scripts?

> This is the design flaw in those scripts (even in whole package
> management).

-- 
You know how to win a victory, Hannibal, but not how to use it. Maharbal
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: semi-virtual packages?

[Bruce Sass]

On Thu September 27 2007 05:38:53 pm Manoj Srivastava wrote:
> On Thu, 27 Sep 2007 08:08:49 -0600, Bruce Sass <[EMAIL PROTECTED]> said:
> > The bit you're still missing is the first part of the question you
> > didn't answer: "Is there any situation where ownership has
> > collided"
> >
> > IOW: if the file shared by many packages isn't having ownership
> > problems there is no need to consider it (no point trying to fix
> > something that is not broken, eh).
>
> The start of this thread was a rant about not loose files
>  floating around in /etc; not necessarily about whether these files
> in themselves had ownership problems (whtever that means).
>
> Here is the original context. Note how you say the problem
>  (actually, design flaw) is about current tools do not "catch files
>  created by Maintainer scripts"?
>
> Nice to see the design flaw has become stuff that is not
> broken and does not have to be fixed.  That is all I cared about,
> really.

Oleg considers it a design flaw, I have stated no such opinion and 
didn't even include his statement to that effect in my reply. Why would 
you bring it up... grasping at straws, perhaps.

The original context I was responding to, and which you jumped in on, is 
this:
-
On Sat, 22 Sep 2007 03:46:26 -0600, Bruce Sass <[EMAIL PROTECTED]> said: 

> On Sat September 22 2007 12:16:18 am Oleg Verych (Gmane) wrote:
>> 21-09-2007, Bruce Sass:
>> > On Thu September 20 2007 09:25:23 pm Oleg Verych (Gmane) wrote:
>> >> 19-09-2007, Bruce Sass:
>> >> > I'm hoping the dpkg "triggers" functionality Ian Jackson has
>> >> > been working on will help solve that wart though.
>> >>
>> >> How exactly?
>> >
>> > Exactly? I don't know. I haven't followed what is happening close
>> > enough.
>> >
>> > Basically, it allows a package to toss up a flag saying, `I'm here
>> > and  needs to be done.' It may require some convention
>> > and a little more infrastructure, but that is close to letting a
>> > package say, `add these paths to the list of paths which I
>> > control.'
>> 
>> Sure. But i thought, we are talking about finding/listing of
>> generated files.

> It is not feasible (imo) to automatically find files created by
> maintainer scripts. Having packages append .list themselves
> would (afaict) require they know too much about dpkg's internal
> operation, and all packages generating files would need to implement
> the algorithm.

> However, maintainer scripts can easily pass a list of generated paths
> on to a shared piece of code which dpkg controls. "triggers" looks
> like it could be the mechanism by which a package flags that it has
> generated files, and by which dpkg exerts control.

But this does not address the case of a file shared by many
 packages but really owned by none.

manoj
-

You then proceeded to demonstrate that you: have trouble reading, 
following arguments, keeping track of what your own use case actually 
is, and using logic.  You are now finishing up with misquotes and 
misrepresentation of anothers position.  Do you wonder why you get in 
so many fights and pointless arguments. :-/

Bye-bye, and I wish you luck in whatever little fantasy world you've 
constructed for yourself.


- Bruce


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

Intent to remove libxaw6 from Debian [security issues]

[Drew Parsons]

Dear Debian Developers,

the X Strike Force intends to remove libxaw6 from the archive.

The reason is explained in bug #172890.  In short, libxaw6 has a
security flaw where it displays passwords in plain text.

The flaw is fixed in libxaw7.  All packages in Debian now use libxaw7
rather than libxaw6.  We therefore consider it prudent to remove libxaw6
from the archive to avert any possible future misuses.

This has the potential to impact on any third party packages which use
libxaw6.  We don't believe this should annul the package's removal
however, because
a) these packages should be rebuilt against libxaw7 anyway, and
b) libxaw6 can still be taken from etch if really needed.

The LSB does not specify any requirements for libxaw (v7 or otherwise).

Please let us know (by replying to bug #172890) if you have any
objections or can otherwise present an argument in favour of keeping
libxaw6.

Otherwise, we will remove it in a week or so.

Drew Parsons
\hat{XSF}





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

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

[Carlos Laviola]

Package: wnpp
Severity: wishlist
Owner: Carlos Laviola <[EMAIL PROTECTED]>

* Package name: dvd95
  Version : 1.2p1
  Upstream Author : J. F. Coulon <[EMAIL PROTECTED]>
* URL : http://dvd95.sourceforge.net/
* License : GPL
  Programming Lang: C
  Description : DVD9 to DVD5 converter

  dvd95 is a GNOME application to convert DVD9 to DVD5 (4.7GB).

  * Needs no additional packages - embedded versions of vamps and
dvdauthor are used, to be as fast as possible.
  * Interface is pretty simple to use.
  * Shrinking factor may be computed for best results, or an adaptive
compression ratio method may be used.
  * DVDs can be converted to file trees or ISOs.
  * The end result can be viewed and burned with regular third party
players and DVD recording software.

  * DVD95 supports two copy modes:
  - Without menus, one video title set, multiple audio tracks and subtitles.
  - With menus, one video title set, multiple audio tracks and subtitles.

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

Kernel: Linux 2.6.22-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.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: Bug#444368: ITP: dvd95 -- DVD9 to DVD5 converter

[Paul Wise]

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. 

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: User-Agent strings, privacy and Debian browsers

[Drew Parsons]

Peter Eckersley wrote:
> Consider for a moment a typical User-Agent string sent by a Debian web 
> browser:
> 
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070802 
> Iceape/1.1.4 (Debian-1.1.4-1)
> 
> Unfortunately, the fact that this information identifies a specific
> package and version of that package means that Debian users (already a
> select group) have their browsing identities further distinguished by
> their User-Agent strings.
> ...
> What do people think of picking a single User-Agent string for all
> versions of all of Debian's Gecko-based browsers?


>From the other responses, it seems clear that we do not want to do this
for technical reasons.

Your concern addresses a potential social problem, not a technical
problem. Perhaps you will have more success getting us to appreciate
what you're trying to say if you can explain it more thoroughly in
social terms?  

That is, what problem are you trying to solve exactly? 

Can you provide actual examples where identification by User-Agent has
led to tangible harm, or may be reasonably expected to lead to harm in
the near future, rather than than simply being some hypothetical tool
open to abuse by some future tyrannical government or corporation?

If we can be convinced the actual danger is real, then the technical
solution is of course trivial.

Drew


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

Work-needing packages report for Sep 28, 2007

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 308 (new: 2)
Total number of packages offered up for adoption: 76 (new: 0)
Total number of packages requested help for: 35 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   dguitar (#443783), orphaned 4 days ago
 Description: Guitar Pro 3/4 tablature viewer and player
 Installations reported by Popcon: 174

   xfonts-ay (#443805), orphaned 3 days ago
 Installations reported by Popcon: 335

306 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 76 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   aboot (#315592), requested 826 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot aboot-cross dfsbuild ltsp-client-core
 Installations reported by Popcon: 114

   apt-build (#365427), requested 516 days ago
 Description: Need new developer(s)
 Installations reported by Popcon: 851

   apt-show-versions (#382026), requested 415 days ago
 Description: lists available package versions with distribution
 Installations reported by Popcon: 2999

   athcool (#278442), requested 1066 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 290

   cvs (#354176), requested 581 days ago
 Description: Concurrent Versions System
 Reverse Depends: bonsai crossvc cvs-autoreleasedeb cvs-buildpackage
   cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta (15
   more omitted)
 Installations reported by Popcon: 20889

   dpkg (#282283), requested 1041 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: alien alsa-source apt-build apt-cross apt-src
   backuppc build-essential bzr-builddeb clamsmtp crosshurd (87 more
   omitted)
 Installations reported by Popcon: 65037

   elvis (#432298), requested 80 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console elvis-tools
 Installations reported by Popcon: 305

   gentoo (#422498), requested 144 days ago
 Description: a fully GUI-configurable, two-pane X file manager
 Installations reported by Popcon: 277

   grub (#248397), requested 1235 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: dfsbuild replicator
 Installations reported by Popcon: 59636

   ispell-et (#391105), requested 358 days ago
 Description: Estonian dictionary for Aspell/Ispell/MySpell
 Installations reported by Popcon: 44

   kradio (#429873), requested 99 days ago
 Description: Comfortable Radio Application for KDE
 Installations reported by Popcon: 286

   loop-aes-utils (#385614), requested 392 days ago
 Description: Tools for mounting and manipulating filesystems
 Reverse Depends: loop-aes-modules-2.6.22-2-486
   loop-aes-modules-2.6.22-2-4kc-malta loop-aes-modules-2.6.22-2-686
   loop-aes-modules-2.6.22-2-686-bigmem
   loop-aes-modules-2.6.22-2-alpha-generic
   loop-aes-modules-2.6.22-2-alpha-legacy
   loop-aes-modules-2.6.22-2-alpha-smp loop-aes-modules-2.6.22-2-amd64
   loop-aes-modules-2.6.22-2-footbridge
   loop-aes-modules-2.6.22-2-iop32x (33 more omitted)
 Installations reported by Popcon: 761

   mc (#380999), requested 422 days ago
 Description: midnight commander - a powerful file manager
 Reverse Depends: junior-system
 Installations reported by Popcon: 15224

   mol (#436450), requested 51 days ago
 Description: The Mac-on-Linux emulator
 Reverse Depends: mol-drivers-linux mol-drivers-macos
   mol-drivers-macosx mol-modules-source
 Installations reported by Popcon: 71

   mwavem (#313369), requested 836 days ago (non-free)
 Description: Mwave/ACP modem support software
 Installations reported by Popcon: 16

   nas (#354174), requested 581 days ago
 Description: The Network Audio System
 Reverse Depends: acm acm4 alsaplayer-nas amarok apollon
   aqbanking16-qt-wizard ark arson asc audiooss (224 more omitted)
 Installations reported by Popcon: 47879

   ntp (#373824), requested 469 days ago
 Description: Network Time Protocol: network utilities
 Reverse Depends: radioclk
 Installations reported by Popcon: 20586

   openoffice.org