Debian-devel your lucky day!

[Isaac Holmes]

man! 7 best xxx sites for free
only today
7ForFree dot com

Anna Jacob


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

semi-virtual packages?

[Bruce Sass]

On Sat September 22 2007 10:21:43 pm Manoj Srivastava wrote:
> 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.

True, but...
Since such a file is owned by none, it can not be owned by anyone.
The same solution would apply, if we could create a package for it on 
the fly.

Is there any situation where ownership has collided, and a virtual 
package is/(could) not (be) Provide:-ed?

[Realizing that discussion about wild ideas is far from sublime, I 
decided to put some thoughts to rhyme, hope it works this time.]

[assuming a, "no", to the above... ya, both question and poetry :D ]

Perhaps virtual packages need to have a real presence on the system when 
such a situation exists.

If you are willing to go for that,
and assuming dpkg triggers can be used for this kind of thing:

A package generating a file which is most properly owned by a virtual 
package it Provides: could trigger, `add these paths to the list of 
paths owned by .' Same game as above, different 
package name.

- dpkg (controlled code) would need to create an entry in the DB (i.e., 
status, info/*, ...) for these semi-virtual packages, and remove/purge 
them when the last package providing a virtual package is 
removed/purged.

- Since these semi-virtual packages would only exist if a real package 
was providing them there should be no problem with respect to 
dependency calculations if they actually exist in the DB.

- I suspect a new Provided-by: field in the DB could help dpkg keep 
track of what's up during failed upgrades, and if not, the frontend 
tools would probably like to be able to convey the info onto users.


- Bruce


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

Re: User-Agent strings, privacy and Debian browsers

[Mark Brown]

On Sat, Sep 22, 2007 at 12:39:25PM -0700, Peter Eckersley wrote:
> On Sat, Sep 22, 2007  at 11:36:41 +0100, Mark Brown wrote:

> > I would strongly expect that any user sufficiently concerned about
> > these issues to take active steps like those would be willing to use

> I think this misunderstands the problem.  Having stronger privacy is
> like an insurance policy: most of the people who end up having needed it
> never knew they were going to need it.  So they weren't going to have
> gone out and installed Privoxy (maybe with Tor) /and/ then examined it
> closely enough to realise that it doesn't alter their User-Agent by
> default, and configured it to masquerade as Firefox on Windows or
> something. 

That sounds like an argument for improving the default configuration of
privoxy and similar tools more than anything else.  Like I say, you're
explicitly talking about users who have already taken active steps to
protect their privacy.

> Which brings us to a separate point: it's no use to have Privoxy
> configured to block User-Agent strings, since that means you'll be the
> one person with no User-Agent, which gives you an even smaller anonymity
> sets than the default debian packages.  Yes, smart users will copy

Right; I've never actually seen an implementation of this feature that
didn't substitute in a new browser string rather than simply removing
the existing one.  This feature is more commonly used to work around
browser detection in web sites than for privacy reasons so most
implementations actually come with a prepreparaed list of common user
agent strings and offer the ability to specify something else only as an
advanced option.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Re: modified email address in debian/copyright file

[Andre Majorel]

On 2007-09-20 23:10 +1000, Ben Finney wrote:

> I would not be against a policy requirement that email addresses
> in package metadata should be the literal address without
> munging.

I would not be against a policy requirement that packagers *ask*
third parties before publishing their email addresses.

-- 
André Majorel 
Thanks to the Debian project for keeping my email address secret and
keeping me from being spammed.


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

Re: First CFV for Constitutional amendment: reduce the length of DPL election process

[Juan Manuel García Molina]

El Sunday 23 September 2007 01:50:42 Debian Project Secretary escribió:
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> acf05695-2c74-4751-a58a-ab7eb8282300
> [ 1 ] Choice 1: Reduce the length of DPL election process
> [ 2 ] Choice 2: As above, but do not change election start date in section 
5.2.2
> [ 3 ] Choice 3: Further discussion
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-




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

Re: Some questions about Debian

[Ondrej Certik]

> - Do you think that this initiative is interesting?

Yes, I think this initiative is very interesting, because those are
details that I think are the most important, yet it's very difficult
to get those from the respective webpages (like debian.org, etc.).

I am unable to connect to [1] though, so I am looking forward when
it's up again to read the answers.

Ondrej

[1] http://www.lucas-nussbaum.net/


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

Re: Some questions about Debian

[Lucas Nussbaum]

On 23/09/07 at 16:01 +0200, Ondrej Certik wrote:
> > - Do you think that this initiative is interesting?
> 
> Yes, I think this initiative is very interesting, because those are
> details that I think are the most important, yet it's very difficult
> to get those from the respective webpages (like debian.org, etc.).
> 
> I am unable to connect to [1] though, so I am looking forward when
> it's up again to read the answers.

Up again, but I haven't published the answers yet. I will as soon as
I'll have the "next step" figured out.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: Some questions about Debian

[Ondrej Certik]

> Up again, but I haven't published the answers yet. I will as soon as
> I'll have the "next step" figured out.

BTW, I noticed you are a Ubuntu developer, do you use PPA? I would
like to have it in Debian, so I am working on it [1], [2], but very
slowly, don't have much time.

Ondrej

[1] http://code.google.com/p/debppa/
[2] http://wiki.debian.org/svnbuildstat


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

Re: semi-virtual packages?

[Manoj Srivastava]

On Sun, 23 Sep 2007 04:13:41 -0600, Bruce Sass <[EMAIL PROTECTED]> said: 

> On Sat September 22 2007 10:21:43 pm Manoj Srivastava wrote:
>> 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:

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

> True, but...  Since such a file is owned by none, it can not be owned
> by anyone.  The same solution would apply, if we could create a
> package for it on the fly.

We can create any number of dummy packages on the fly, but what
 is the use case we are trying to solve here? Why are we adding a
 virtual package, having package provide the virtual package, given that
 this virtual package does not provide any functionality, and so no
 other package is going to depend on it?

> Perhaps virtual packages need to have a real presence on the system
> when such a situation exists.

> If you are willing to go for that,

I might be willing to go for that if there was a clear statement
 of benefit gained, what use case we are satisfying, and if there were
 convincing arguments that other solutions are not a better fit than
 trying to shoe horn dpkg -L  to be the solution to whatever use case we
 are attempting to solve (this is no longer the original use case
 presented -- I-do-not-know-where-the-documentation-is).

So, can we start over, and have a clear problem statement,
 alternate solutions (does this move into tripwire space?), and then
 decide what the preferred solution is?

manoj
-- 
If you ever drop your keys into a river of molten lava, let'em go,
because, man, they're gone.
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: Bug#443528: ITP: xmms-pulse -- Pulseaudio Output plugin for xmms

[Steve Greenland]

On 22-Sep-07, 12:32 (CDT), Daniel Baumann <[EMAIL PROTECTED]> wrote: 
> Thomas Goirand wrote:
> > Does it mean that I should try and make it work with xmms2 instead,
> > which means open an ITP for xmms2-pulse?
> 
> Hi Thomas,
> 
> please don't upload any xmms packages anymore; but go for xmm2 or
> audacious (unless you want to take over xmms itself).

Audacious already has pulse support.

Steve
-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: Proposal regarding future packaging

[Oleg Verych]

23-09-2007, Manoj Srivastava:
[]
>>> It doesn't catch files created by Maintainer scripts?
>
>> This is the design flaw in those scripts (even in whole package
>> management).
>
> I am not sure you have made your case here.
>
> Currently, using maintainer scripts, it is indeed possible to
>  create a configuration file that is referred to by many packages, but
>  is owned by none -- so the file survives even though the package that
>  created it went away.
>
> Why is this a design flaw?

Where to find information about those files easily?

Negative search on `dpkg -L *' ?:)

What i mean is absolute freedom in maintainer scripts. Bad freedom, where
scripts can do anything they like. No comprehensive logging/tracing
infrastructure at all, everything is ad hoc.

Also RC scripting. But this is another story, though.



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

Bug#443745: ITP: wxremind -- wxRemind is a graphical front/back-end for Remind and yeaGTD

[Kurt B. Kaiser]

Package: wnpp
Severity: wishlist
Owner: "Kurt B. Kaiser" <[EMAIL PROTECTED]>

* Package name: wxremind
  Version : 0.9.13
  Upstream Author : Daniel Graham <[EMAIL PROTECTED]>
* URL : http://www.duke.edu/~dgraham/wxRemind/
* License : GPL
  Programming Lang: Python
  Description : wxRemind is a graphical front/back-end for Remind and yeaGTD

wxRemind is a graphical front/back-end for Remind, a powerful calendar
and alarm application, and for yeaGTD, a text based application for
'getting things done'. The display features a calendar and daily event
list suitable for visualizing your schedule at a glance, together with a
flexible display of your GTD todo list. Dates and associated events can
be quickly selected either with the mouse or cursor keys, and dates in
the calendar are color coded to reflect the total duration of scheduled
events. wxRemind integrates with an external editor of your choice to
make editing of reminder and GTD files more efficient, provides hotkeys
to quickly access the most commonly used options, and allows popup,
sound, and/or spoken alarms.

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

Kernel: Linux 2.6.18-3-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash



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

Re: Bug#443370: ITP: asmutils -- coreutils replacement written in i386 assembler

[Oleg Verych]

22-09-2007, Steinar H. Gunderson:
> On Fri, Sep 21, 2007 at 09:44:04AM +1245, Andreas Fleckl wrote:
>> It features the smallest possible size and memory requirements, the fastest
>> speed, and offers fairly good functionality.
>
> Size and memory aside, I sort of doubt asmutils' sort is faster than
> coreutils' sort just because it's written in assembly.
>
> /* Steinar */

I second this.

Also. Those programmers are inventing wheels again, fsck. Why they don't
want to make (at least) C (at least gcc or tcc) compiler more efficient:
fast but with good optimization?

And this is not saying about portability of that userspace tools (see
klibc), usability, maintenance. Sigh.



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

Re: Some questions about Debian

[Manoj Srivastava]

On Sun, 23 Sep 2007 17:32:18 +0200, Ondrej Certik <[EMAIL PROTECTED]> said: 

>> Up again, but I haven't published the answers yet. I will as soon as
>> I'll have the "next step" figured out.

> BTW, I noticed you are a Ubuntu developer, do you use PPA? I would
> like to have it in Debian, so I am working on it [1], [2], but very
> slowly, don't have much time.

> Ondrej

> [1] http://code.google.com/p/debppa/[2]
> http://wiki.debian.org/svnbuildstat

Any particular reason this seems to be targeted only to svn/git,
 and seems to be (based on the name) biased towards svn? It can very
 easily be adapted to Arch, as well, and I am sure bzr and darcs should
 be easily added. Given that, vcsbuildstat could be a better name.

Try baz get http://arch.debian.org/arch/private/srivasta/grab/fvwm
 A simple shell script can then update all the bested projects when it
 is time for the next build.

The arch backend to this is simple to write; if the rest (buildd
 operational details) were handled.

manoj
-- 
"When anyone says `theoretically,' they really mean `not really.'" David
Parnas
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#443747: ITP: yeagtd -- Produce nicely formatted reports of simple GTD project files.

[Kurt B. Kaiser]

Package: wnpp
Severity: wishlist
Owner: "Kurt B. Kaiser" <[EMAIL PROTECTED]>

* Package name: yeagtd
  Version : 0.7.11
  Upstream Author : Daniel Graham <[EMAIL PROTECTED]>
* URL : http://www.duke.edu/~dgraham/yeaGTD/
* License : GPL
  Programming Lang: Python
  Description : Produce formatted reports of simple GTD project files.

Yeagtd is a python script which extracts information from simple text
files (which describe Getting Things Done projects) and produces
formatted summary reports. Flexible rules can be used to specify
repeated projects. Context, project and date views are supported and
output can be filtered in a variety of ways and selected by all actions,
completed actions, remaining actions or available actions.  Output can
be printed or sent to standard output in several formats. Commands are
provided for marking tasks complete, opening files for editing and
backing up project files.

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

Kernel: Linux 2.6.18-3-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash



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

Re: Proposal regarding future packaging

[Goswin von Brederlow]

"Ken Spath" <[EMAIL PROTECTED]> writes:

> Proposal regarding future packaging:
>
> Add an additional manual page to new/future/updated packages that is
> the same as the package name. IF and only IF there would NOT be a
> conflict with an existant necessary manual page AND IF there is no
> binary in a package that is the same as the package name.

I did run into the same problem a few times myself and it always
bugged me. So yes, please keep at this.

Maybe it could be as simple as a dh_* command that looks at
[/usr]/[s]bin and /usr/share/man and generates a pretty printed
version of the contents. It could maybe extract the NAME section of
manpages for binaries to give an idea of what they do:

PACKAGE(x)   Debian Package  PACKAGE(x)

NAME
x - The Debian x package

BINARIES
   bash - GNU Bourne-Again SHell
   cp - copy files and directories
   sed - stream editor for filtering and transforming text

DOCUMENTATION
/usr/share/doc/x/README.Debian
/usr/share/doc/x/examples

SEE ALSO
   bash(1), info cp, sed(1)


Hope that encourages you to work on this.

MfG
Goswin


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

Re: Bug#443370: ITP: asmutils -- coreutils replacement written in i386 assembler

[Steffen Moeller]

On Sunday 23 September 2007 21:18:48 Oleg Verych wrote:
> 22-09-2007, Steinar H. Gunderson:
> > On Fri, Sep 21, 2007 at 09:44:04AM +1245, Andreas Fleckl wrote:
> >> It features the smallest possible size and memory requirements, the
> >> fastest speed, and offers fairly good functionality.
> >
> > Size and memory aside, I sort of doubt asmutils' sort is faster than
> > coreutils' sort just because it's written in assembly.
> >
> > /* Steinar */
>
> I second this.
>
> Also. Those programmers are inventing wheels again, fsck. Why they don't
> want to make (at least) C (at least gcc or tcc) compiler more efficient:
> fast but with good optimization?
>
> And this is not saying about portability of that userspace tools (see
> klibc), usability, maintenance. Sigh.

I can confirm that it is not faster since I tested it once, I think 'wc' it 
was. And it is definitely not portable to other platforms either :-) 
Nevertheless the package brings with it some spirit that is good to have: 
love to assembly as a language. Maybe there are applications of this package 
in the embedded world or for some "UNIX on a floppy disk"-kind of 
distributions. I do not care for the moment. The educational aspect of this 
package is what makes me want it for our distribution.

Steffen


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

Re: semi-virtual packages?

[Bruce Sass]

On Sun September 23 2007 11:00:58 am Manoj Srivastava wrote:
> On Sun, 23 Sep 2007 04:13:41 -0600, Bruce Sass <[EMAIL PROTECTED]> said:
> > On Sat September 22 2007 10:21:43 pm Manoj Srivastava wrote:
> >> 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:
> >> >
> >> > 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.
> >
> > True, but...  Since such a file is owned by none, it can not be
> > owned by anyone.  The same solution would apply, if we could create
> > a package for it on the fly.
>
> We can create any number of dummy packages on the fly, but
> what is the use case we are trying to solve here? Why are we adding a
> virtual package, having package provide the virtual package, given
> that this virtual package does not provide any functionality, and so
> no other package is going to depend on it?

Why are you asking that. You provided the use case---"a file shared by 
many packages but really owned by none."

I have written nothing about "adding a virtual package", and the 
functionality of the existing virtual packages which I would manifest 
is obvious---provide a home for the files "shared by many packages but 
really owned by none."

> > Perhaps virtual packages need to have a real presence on the system
> > when such a situation exists.
> >
> > If you are willing to go for that,
>
> I might be willing to go for that if there was a clear
> statement of benefit gained, what use case we are satisfying, and if
> there were convincing arguments that other solutions are not a better
> fit than trying to shoe horn dpkg -L  to be the solution to whatever
> use case we are attempting to solve (this is no longer the original
> use case presented -- I-do-not-know-where-the-documentation-is).

Huh. You provided the case, and the benefit should be obvious---and if 
it is not then why did you bring up addressing, "the case of a file 
shared by many packages but really owned by none"?

WTF does "shoe horn dpkg -L" have to do with what I wrote?
That sounds a lot like the wedging we used to do back in the early 80's 
when the OS was in ROM and it wasn't practical to rewrite it. I would 
hope Debian can do better than such hacks.

Ya, this is different from "I-do-not-know-where-the-documentation-is", 
but then that should not be surprising since I'm not addressing that. I 
did not even realize that is what the thread's originator was asking 
until he clarified by answering someone who appears to have had the 
same misunderstanding as I about what he was asking.

> So, can we start over, and have a clear problem statement,
>  alternate solutions (does this move into tripwire space?), and then
>  decide what the preferred solution is?

"tripwire", again, WTF. What I mentioned no more moves into "tripwire 
space" than installing or upgrading any other package does. So, it 
would be handled by whatever mechanism currently does that. Surely you 
don't think the OS should cater to whatever deficiencies some app 
running on it has.

I don't see any need for myself to start over. I answered Oleg's 
question, and addressed your case. You, on the other hand: seem to have 
forgotten what you wrote; failed to answer the one question I asked; 
and brought up irrelevant stuff like, "shoe horn dpkg -L", 
and "tripwire space." I think you need to start over.

Ya know, I thought that if I was really very lucky there was an outside 
chance of getting a, `posts on -devel rarely make me smile, but yours 
seems to have walked that mile', but if you really want to be pissy and 
obtuse... I can do that too.


- Bruce


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

Re: Bug#443370: ITP: asmutils -- coreutils replacement written in i386 assembler

[Bernd Zeimetz]

> I can confirm that it is not faster since I tested it once, I think 'wc' it 
> was. And it is definitely not portable to other platforms either :-) 
> Nevertheless the package brings with it some spirit that is good to have: 
> love to assembly as a language. Maybe there are applications of this package 
> in the embedded world or for some "UNIX on a floppy disk"-kind of 
> distributions. I do not care for the moment. The educational aspect of this 
> package is what makes me want it for our distribution.

For the educational aspect it would now nice to have this package at
least in mips assembly, too, which is at least at my university used to
teach assembly. It would also allow to compare the same implementation
for different architectures.


Bernd

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Re: Proposal regarding future packaging

[Manoj Srivastava]

On Sun, 23 Sep 2007 19:12:29 + (UTC), Oleg Verych <[EMAIL PROTECTED]> said: 

> 23-09-2007, Manoj Srivastava: []
 It doesn't catch files created by Maintainer scripts?
>> 
>>> This is the design flaw in those scripts (even in whole package
>>> management).
>> 
>> I am not sure you have made your case here.
>> 
>> Currently, using maintainer scripts, it is indeed possible to create
>> a configuration file that is referred to by many packages, but is
>> owned by none -- so the file survives even though the package that
>> created it went away.
>> 
>> Why is this a design flaw?

> Where to find information about those files easily?
> Negative search on `dpkg -L *' ?:)

This is part of a use case.  Apart from curiosity, is there a
 reason to want to know "information about a file"? (Given that most of
 the information we know about other files in /etc is that they might
 belong to a package).  Is there a reason we want this information?

If a file does not belong to any particular package, why is that
 a deficiency that we must solve?

> What i mean is absolute freedom in maintainer scripts. Bad freedom,
> where scripts can do anything they like. No comprehensive
> logging/tracing infrastructure at all, everything is ad hoc.

I think this is going overboard with loaded words.  The scripts
 have to follow Debian policy, after all, and not create problems for
 other packages and such.  Restricting freedom for the sake of
 restricting freedom is also bad, if you want a counter argument in
 similar idiom.

manoj
-- 
If Bill Gates is the Devil then Linus Torvalds must be the
Messiah. Unknown source
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 Sun, 23 Sep 2007 14:26:29 -0600, Bruce Sass <[EMAIL PROTECTED]> said: 

> On Sun September 23 2007 11:00:58 am Manoj Srivastava wrote:

>> We can create any number of dummy packages on the fly, but what is
>> the use case we are trying to solve here? Why are we adding a virtual
>> package, having package provide the virtual package, given that this
>> virtual package does not provide any functionality, and so no other
>> package is going to depend on it?

> Why are you asking that. You provided the use case---"a file shared by
> many packages but really owned by none."

Yup, I provided that use case.  I see no reason to create a
 virtual package to implement the use case I provided.

I ask again, do you have a use case which led you down the path
of proposing a virtual package?

> I have written nothing about "adding a virtual package", and the
> functionality of the existing virtual packages which I would manifest
> is obvious---provide a home for the files "shared by many packages but
> really owned by none."

>> > Perhaps virtual packages need to have a real presence on the system
>> > when such a situation exists.
>> >
>> > If you are willing to go for that,
>> 
>> I might be willing to go for that if there was a clear statement of
>> benefit gained, what use case we are satisfying, and if there were
>> convincing arguments that other solutions are not a better fit than
>> trying to shoe horn dpkg -L to be the solution to whatever use case
>> we are attempting to solve (this is no longer the original use case
>> presented -- I-do-not-know-where-the-documentation-is).

> Huh. You provided the case, and the benefit should be obvious---and if
> it is not then why did you bring up addressing, "the case of a file
> shared by many packages but really owned by none"?

No, my use case merely says that we should be able to have a
 situation where we have a configuration file that does not belong to a
 package.  And yes, I see the benefits of this use case immediately. 

> WTF does "shoe horn dpkg -L" have to do with what I wrote?  That
> sounds a lot like the wedging we used to do back in the early 80's
> when the OS was in ROM and it wasn't practical to rewrite it. I would
> hope Debian can do better than such hacks.

I do not follow.

> Ya, this is different from "I-do-not-know-where-the-documentation-is",
> but then that should not be surprising since I'm not addressing
> that. I did not even realize that is what the thread's originator was
> asking until he clarified by answering someone who appears to have had
> the same misunderstanding as I about what he was asking.

I ask again, what use case are you addressing? The use case I
 proposed does not need a virtual package. 

>> So, can we start over, and have a clear problem statement, alternate
>> solutions (does this move into tripwire space?), and then decide what
>> the preferred solution is?

> "tripwire", again, WTF.

Again?

> What I mentioned no more moves into "tripwire space" than installing
> or upgrading any other package does. So, it would be handled by
> whatever mechanism currently does that. Surely you don't think the OS
> should cater to whatever deficiencies some app running on it has.

What are these deficiencies? I see a situation, currently, where
 some files belong to a particular package. They are shipped in the
 .deb.  Other files do not belong to the package, and are handled
 separately. 

Now, I suppose you are only worried about files in /etc and sch;
 and not files under /var  (no way to associate a lot of those files
 with the packages that contain the entities that created them). The
 question is, why are we trying to assign parentage to the files created
 by maintainer scripts? Curiosity? or something else?  Is the benefit
 gained worth the cost of the solution? (a virtual package that provides
 no services, and no package ever depends on, and is only there to have
 a dpkg -L listing of files).

> I don't see any need for myself to start over. I answered Oleg's
> question, and addressed your case. You, on the other hand: seem to
> have forgotten what you wrote; failed to answer the one question I
> asked; and brought up irrelevant stuff like, "shoe horn dpkg -L", and
> "tripwire space." I think you need to start over.

Could we be less confrontational, perhaps?

> Ya know, I thought that if I was really very lucky there was an
> outside chance of getting a, `posts on -devel rarely make me smile,
> but yours seems to have walked that mile', but if you really want to
> be pissy and obtuse... I can do that too.

I guess you have succeeded eminently, then.

manoj

-- 
You are destined to become the commandant of the fighting men of the
department of transportation.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email

Re: using "Breaks:", or how to replace it?

[Felipe Sateler]

Lucas Nussbaum wrote:

> * dpkg and apt have support for Breaks in lenny, but this doesn't mean
>   that we are supposed to use it before lenny+1 (according to
>   #debian-devel)

However neither taktuk nor kanif are in etch, so I don't know if this is
really an issue: etch users won't have your packages installed.


-- 

  Felipe Sateler


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

Re: Building packages three times in a row

[Martin Uecker]

Patrick Winnertz wrote:
> Am Dienstag, 18. September 2007 21:12:44 schrieb Julien Cristau:
> > > Hmmhh, what do you do about programs etc that encode the build-time in
> > > the binary? I mean they obviously will change between builds?
> >
> > Hopefully they don't encode the build-time in the file list?
> We checked not for files which differ, but only for files which are missing 
> in the first package. or which are missing in the second package.
>

I think it would be really cool if the Debian policy required
that packages could be rebuild bit-identical from source. 
At the moment, it is impossible to independly verify the
integricity of binary packages.


Greetings,
Martin


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Building packages three times in a row

[Neil Williams]

On Sun, 23 Sep 2007 23:32:59 +0200
Martin Uecker <[EMAIL PROTECTED]> wrote:

> 
> Patrick Winnertz wrote:
> > Am Dienstag, 18. September 2007 21:12:44 schrieb Julien Cristau:
> > > > Hmmhh, what do you do about programs etc that encode the build-time in
> > > > the binary? I mean they obviously will change between builds?
> > >
> > > Hopefully they don't encode the build-time in the file list?
> > We checked not for files which differ, but only for files which are missing 
> > in the first package. or which are missing in the second package.
> >
> 
> I think it would be really cool if the Debian policy required
> that packages could be rebuild bit-identical from source. 
> At the moment, it is impossible to independly verify the
> integricity of binary packages.

This has been covered before - certain upstream macros are among many
factors that ensure that this is unlikely. I, for one, use such macros
upstream to indicate the build time of the actual executable installed
so this will change the binary every time it is built.

You have md5sums and GnuPG signatures on the Release files - I see no
benefit from bit-matching.

-- 

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


pgpKwGcCWCEea.pgp
Description: PGP signature

Re: Bug#443769: rt2500-source: Missing dependency on bzip2

[Ben Hutchings]

I wrote:
> Package: rt2500-source
> Version: 1:1.1.0-b4-4
> Severity: serious
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> rt2500-source includes a bzipped tarball which must be unpacked in
> order to build modules from it.  Therefore it should depend on bzip2.


In fact this applies to any module source package, since
module-assistant requires module source to be compressed with bzip2, not
gzip.

I'm not sure whether I should fix this bug in rt2500 and the other
Ralink driver packages, or whether module-assistant should be changed to
depend on bzip2 (or to install it along with build-essential).

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.


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

Re: Bug#443769: rt2500-source: Missing dependency on bzip2

[Ben Hutchings]

On Mon, 2007-09-24 at 08:40 +1000, Hamish Moffatt wrote:
> On Sun, Sep 23, 2007 at 11:37:39PM +0100, Ben Hutchings wrote:
> > I wrote:
> > > Package: rt2500-source
> > > Version: 1:1.1.0-b4-4
> > > Severity: serious
> > > 
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA1
> > > 
> > > rt2500-source includes a bzipped tarball which must be unpacked in
> > > order to build modules from it.  Therefore it should depend on bzip2.
> > 
> > 
> > In fact this applies to any module source package, since
> > module-assistant requires module source to be compressed with bzip2, not
> > gzip.
> 
> Really? nvidia-kernel-source is a .tar.gz here.

Sorry, I looked in /usr/bin/module-assistant and could only see a "tar
jxf" there, but now I realise that's for kernel tarballs.  Module
tarballs are handled by /usr/share/modass/packages/generic.sh which does
indeed support gzip and bzip2 decompression.

> > I'm not sure whether I should fix this bug in rt2500 and the other
> > Ralink driver packages, or whether module-assistant should be changed to
> > depend on bzip2 (or to install it along with build-essential).
> 
> I wouldn't expect rt2500-source to depend on bzip2 any more than I
> expect any package providing a PDF file to depend on a viewer. 

That's different because there are many PDF viewers (and other tools
that work on PDFs).  There's nothing much that can be done with a bzip2
archive without using bzip2.

> However, tools that use those files definitely have a dependency ie
> module-assistant.

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.


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

Re: Building packages three times in a row

[Martin Uecker]

Neil Williams <[EMAIL PROTECTED]>:
> Martin Uecker <[EMAIL PROTECTED]> wrote:

[...]

> > 
> > I think it would be really cool if the Debian policy required
> > that packages could be rebuild bit-identical from source. 
> > At the moment, it is impossible to independly verify the
> > integricity of binary packages.
>
> This has been covered before - certain upstream macros are among 
> many factors that ensure that this is unlikely. I, for one, use such
> macros upstream to indicate the build time of the actual executable
> installed so this will change the binary every time it is built.

This could be fixed.

> You have md5sums and GnuPG signatures on the Release files - I see
> no benefit from bit-matching.

The build host could be compromised. Not that unlikely.


Martin


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

Re: Some questions about Debian

[Ondrej Certik]

> Any particular reason this seems to be targeted only to svn/git,
>  and seems to be (based on the name) biased towards svn? It can very
>  easily be adapted to Arch, as well, and I am sure bzr and darcs should
>  be easily added. Given that, vcsbuildstat could be a better name.

No, we want to support all vcs, so we should change the name, thanks
for the suggestion. We also want to support just uploading a source
package, like Ubuntu PPA has - it will help all the people in
debian-mentors searching for a sponsor - he will just upload it to
snvbuildstat (or whatever we name it) and everyone will see if it
builds, and the lintian/linda/piuparts logs and also everyone could
easily install the package just by adding the repository to it's
sources list.

> Try baz get http://arch.debian.org/arch/private/srivasta/grab/fvwm
>  A simple shell script can then update all the bested projects when it
>  is time for the next build.

$ baz get http://arch.debian.org/arch/private/srivasta/grab/fvwmSetting
arch cache to default path: /home/ondra/.arch-cache
get: could not connect to the archive for
(http://arch.debian.org/arch/private/srivasta/grab/fvwm)

Am I doing something wrong?

But I found some information here:

http://arch.debian.org/arch/private/srivasta/

> The arch backend to this is simple to write; if the rest (buildd
>  operational details) were handled.

Ondrej


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

Re: Building packages three times in a row

[Benjamin A'Lee]

On Mon, Sep 24, 2007 at 12:54:58AM +0200, Martin Uecker wrote:
> Neil Williams <[EMAIL PROTECTED]>:
> > This has been covered before - certain upstream macros are among 
> > many factors that ensure that this is unlikely. I, for one, use such
> > macros upstream to indicate the build time of the actual executable
> > installed so this will change the binary every time it is built.
> 
> This could be fixed.

In every binary that includes the build date in it? There's rather a
lot; off the top of my head, Vim does it, and so does the Linux kernel
AFAIK.

> > You have md5sums and GnuPG signatures on the Release files - I see
> > no benefit from bit-matching.
> 
> The build host could be compromised. Not that unlikely.

And if the build host was compromised, how would that help any more than
md5sums and gpg-signing? With access to the build host, whatever list of
bits to match could be changed along with the binary, the md5sum, and
the gpg-signature.

Anyway, surely the point of hashes like md5, sha1, etc, is that it's
much faster to do that than to compare large files bit by bit?

-- 
Benjamin A'Lee <[EMAIL PROTECTED]>
http://subvert.org.uk/~bma/


signature.asc
Description: Digital signature

Re: User-Agent strings, privacy and Debian browsers

[Martin Uecker]

Joey Hess <[EMAIL PROTECTED]>:
> Joerg Jaspert wrote:
> > > On 11150 March 1977, Peter Eckersley wrote:
> > > > I've seen reports from very large sites indicating that
> > > > User-Agent
> > > > strings are almost as useful as cookies for tracking their
> > > > users.
> > > 
> > > I cant believe this. Looking at the stats from packages.debian.org
> > > - U-A
> > > is the worst possible way to "track users". Would be totally dumb
> > > to try
> > > something with U-A:
> >
> > Surely packages.debian.org is not a good example of a site with
> > generally few Debian users.

Anyway, you would combine User-Agent with other clues.

Martin



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

Re: Bug#443769: rt2500-source: Missing dependency on bzip2

[Hamish Moffatt]

On Mon, Sep 24, 2007 at 12:00:25AM +0100, Ben Hutchings wrote:
> On Mon, 2007-09-24 at 08:40 +1000, Hamish Moffatt wrote:
> > I wouldn't expect rt2500-source to depend on bzip2 any more than I
> > expect any package providing a PDF file to depend on a viewer. 
> 
> That's different because there are many PDF viewers (and other tools
> that work on PDFs).  There's nothing much that can be done with a bzip2
> archive without using bzip2.

There are virtual packages which could be used to express the PDF
-> tools relationship if it was important to do that. 
As an example, the r-doc-pdf package suggests pdf-viewer.

Perhaps rt2500-source should recommend bzip2? The relationship seems to
fit the definition - a package that is usually installed along with it
but not strictly required.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[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

[Don Armstrong]

On Sun, 23 Sep 2007, Andre Majorel wrote:
> On 2007-09-20 23:10 +1000, Ben Finney wrote:
> 
> > I would not be against a policy requirement that email addresses
> > in package metadata should be the literal address without
> > munging.
> 
> I would not be against a policy requirement that packagers *ask*
> third parties before publishing their email addresses.

The package should include in the copyright file the correct email
address for whatever contact information the upstream author(s) use to
receive queries from users and other people.

The other half is the exact text used in the copyright statement and
licensing statement; if that contains a munged e-mail address or a
non-munged one, then it should be left as-is.

Contacting authors when you package something is always a good idea,
but I see no reason to make it a requirement (or even a way to enforce
such a requirement were it to exist.]
 

Don Armstrong

-- 
S: Make me a sandwich
B: What? Make it yourself.
S: sudo make me a sandwich
B: Okay.
 -- xkcd http://xkcd.com/c149.html

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


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

Re: Building packages with exact binary matches

[Neil Williams]

On Mon, 24 Sep 2007 00:54:58 +0200
Martin Uecker <[EMAIL PROTECTED]> wrote:

> Neil Williams <[EMAIL PROTECTED]>:
> > Martin Uecker <[EMAIL PROTECTED]> wrote:
> > This has been covered before - certain upstream macros are among 
> > many factors that ensure that this is unlikely. I, for one, use such
> > macros upstream to indicate the build time of the actual executable
> > installed so this will change the binary every time it is built.
> 
> This could be fixed.

Fixed?? What the? You're asserting that this is a PROBLEM to be fixed?
It's good, it's useful, it's helpful. I'm confused, what is wrong with
that?

:-(

IMNSHO, this is not a bug, there is no good reason to prevent upstream
from using such macros and besides, there are other upstream processes
that modify the built binaries every time the build proceeds. Think
Latex and various other generation tools.

Also, any build process generates files that contain different
references and linked objects - if a package hasn't been built for a
while (no new uploads), what on earth is wrong with that not being a
binary-match for a package that was built yesterday against updated
libraries?

See also this thread:
http://lists.debian.org/debian-devel/2007/07/msg00588.html
and
http://lists.debian.org/debian-devel/2007/06/msg01076.html

If the dependencies change between builds, so will the binary.

> > You have md5sums and GnuPG signatures on the Release files - I see
> > no benefit from bit-matching.
> 
> The build host could be compromised. Not that unlikely.

That's why the autobuild process is not entirely automated. A real DD
needs to sign off the ported packages.

-- 

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


pgpPV8JohKh4z.pgp
Description: PGP signature

Re: Building packages three times in a row

[Martin Uecker]

Benjamin A'Lee <[EMAIL PROTECTED]>:
> On Mon, Sep 24, 2007 at 12:54:58AM +0200, Martin Uecker wrote:
> > Neil Williams <[EMAIL PROTECTED]>:
> > > This has been covered before - certain upstream macros are among 
> > > many factors that ensure that this is unlikely. I, for one, use
> > > such
> > > macros upstream to indicate the build time of the actual
> > > executable
> > > installed so this will change the binary every time it is built.
> > 
> > This could be fixed.
> 
> In every binary that includes the build date in it? There's rather a
> lot; off the top of my head, Vim does it, and so does the Linux
> kernel AFAIK.

I know. In a world where providing a correctly working clean
target is already an issue, that's pretty far fetched.
But IMHO being able to recreate binaries from source code in
a reproducable way would be a milestone for security and QA.

> > > You have md5sums and GnuPG signatures on the Release files - I
> > > see no benefit from bit-matching.
> > 
> > The build host could be compromised. Not that unlikely.
>
> And if the build host was compromised, how would that help any more
> than md5sums and gpg-signing? With access to the build host, whatever
> list of bits to match could be changed along with the binary, the md5sum,
> and the gpg-signature.
>
> Anyway, surely the point of hashes like md5, sha1, etc, is that it's
> much faster to do that than to compare large files bit by bit?

The idea is not to replace hashes by bit-by-bit comparison, but to
be able to *independendly* reproduce binaries from source code in
a bit-identical way. Then third parties can recreate the binaries
and publish recreated hashes. If the recreated hashes are identical
then you can be sure that nobody has tempered with the build process
and the binary is actually created from the unmodified sources. The
current scheme just protects against tempering after signing. That
is actually not very much.


Martin

Re: Some questions about Debian

[Manoj Srivastava]

On Mon, 24 Sep 2007 01:12:59 +0200, Ondrej Certik <[EMAIL PROTECTED]> said: 

>> Try baz get http://arch.debian.org/arch/private/srivasta/grab/fvwm> A
>> simple shell script can then update all the bested projects when it
>> is time for the next build.

> $ baz get
> http://arch.debian.org/arch/private/srivasta/grab/fvwmSettingarch
> cache to default path: /home/ondra/.arch-cache get: could not connect
> to the archive for
> (http://arch.debian.org/arch/private/srivasta/grab/fvwm)

> Am I doing something wrong?

No, sorry, it is just creeping senility on my part. I meant to
 say grab, not get. And you need to first register the archive.  Also,
 tla works better than baz here (need to file bug report about baz
 segfaulting in if used instead of tla in the operation below).

I actually tested this, now:
--8<---cut here---start->8---
__> mkdir /tmp/test
__> cd /tmp/test
__> tla register-archive --present-ok \
 http://arch.debian.org/arch/private/srivasta/archive-lenny
Registering archive: [EMAIL PROTECTED]
__> tla grab http://arch.debian.org/arch/private/srivasta/grab/fvwm
Grabbing: [EMAIL PROTECTED]/http://arch.debian.org/arch/private/srivasta
Source: http://arch.debian.org/arch/private/srivasta, Dest: manoj-packages
Config: configs/fvwm/debian/fvwm-1:2.5.23-2
* from revision library: [EMAIL PROTECTED]/packages--debian--1.0--patch-112
* patching for revision: [EMAIL PROTECTED]/packages--debian--1.0--patch-113
* ensuring library has [EMAIL PROTECTED]/fvwm--devo--2.5.23--patch-5
* from revision library: [EMAIL PROTECTED]/fvwm--devo--2.5.23--patch-5
* tree version set [EMAIL PROTECTED]/fvwm--devo--2.5.23
* ensuring library has [EMAIL PROTECTED]/debian-dir--fvwm--0.1--patch-8
* found immediate ancestor revision in library ([EMAIL 
PROTECTED]/debian-dir--fvwm--0.1--patch-7)
* patching for this revision ([EMAIL PROTECTED]/debian-dir--fvwm--0.1--patch-8)
* from revision library: [EMAIL PROTECTED]/debian-dir--fvwm--0.1--patch-8
* tree version set [EMAIL PROTECTED]/debian-dir--fvwm--0.1
* ensuring library has [EMAIL PROTECTED]/skeleton-make-rules--main--0.1--patch-1
* from revision library: [EMAIL 
PROTECTED]/skeleton-make-rules--main--0.1--patch-1
* tree version set [EMAIL PROTECTED]/skeleton-make-rules--main--0.1
__>
--8<---cut here---end--->8---

Your log would be different, since your revision library will
 not be all primed with cached versions, but essentially you'll get the
 source code.  We might need to add some conventions to make life easier
 for the ppa, but that is implementation details, if we want to do this.

manoj
-- 
"There is nothing new under the sun, but there are lots of old things we
don't know yet." -Ambrose Bierce
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: Building packages with exact binary matches

[Martin Uecker]

> On Mon, 24 Sep 2007 00:54:58 +0200
> Martin Uecker <[EMAIL PROTECTED]> wrote:
> 
> > Neil Williams <[EMAIL PROTECTED]>:
> > > This has been covered before - certain upstream macros are among 
> > > many factors that ensure that this is unlikely. I, for one, use
> > > such macros upstream to indicate the build time of the actual
> > > executable installed so this will change the binary every 
> > > time it is built.
> > ac
> > This could be fixed.
>
> Fixed?? What the? You're asserting that this is a PROBLEM to be
> fixed?

If policy would require the exact reproducability of binaries, then
it would be a policy violation.

> It's good, it's useful, it's helpful. I'm confused, what is wrong
> with that?
>
> :-(

I do not see how a date stamp in a binary is really usefull. Often
it is just used as a cheap replacement of fine grained versioning
information. But I do not think that's a good reason. The date on
which a binary is built is actually completely irrelevant from
a technical point of view. What's really usefull is the exact
version of the source code and the build tools. Everything else
should not matter at all!

> IMNSHO, this is not a bug, there is no good reason to prevent
> upstream from using such macros 

Ofcourse there is: reproducability

> and besides, there are other upstream processes that modify 
> the built binaries every time the build proceeds.
> Think Latex and various other generation tools.

These could be fixed too ;-)

> Also, any build process generates files that contain different
> references and linked objects - if a package hasn't been built for a
> while (no new uploads), what on earth is wrong with that not being a
> binary-match for a package that was built yesterday against updated
> libraries?
> 
> See also this thread:
> http://lists.debian.org/debian-devel/2007/07/msg00588.html
> and
> http://lists.debian.org/debian-devel/2007/06/msg01076.html
>
> If the dependencies change between builds, so will the binary.

That's an different issue. I am not complaing about the fact 
that binaries can change without source code changes, but that
it is impossible to create an identical package even when you
try.

> > > You have md5sums and GnuPG signatures on the Release files - I
> > > see no benefit from bit-matching.
> > 
> > The build host could be compromised. Not that unlikely.
>
> That's why the autobuild process is not entirely automated. A real
> DD needs to sign off the ported packages.

I do not see how this helps. Imagine a build host is compromised
and this is noticed only after a few weeks. Theoretically every
machine which downloaded and installed a package in this time
could be compromised. And even worse: it is practically impossible
to find out wether a package is actually affected! 


Martin

Re: Building packages with exact binary matches

[Manoj Srivastava]

On Mon, 24 Sep 2007 04:56:45 +0200, Martin Uecker <[EMAIL PROTECTED]> said: 

>> On Mon, 24 Sep 2007 00:54:58 +0200
>> Martin Uecker <[EMAIL PROTECTED]> wrote:
>> 
>> > Neil Williams <[EMAIL PROTECTED]>:
>> > > This has been covered before - certain upstream macros are among
>> > > many factors that ensure that this is unlikely. I, for one, use
>> > > such macros upstream to indicate the build time of the actual
>> > > executable installed so this will change the binary every time it
>> > > is built.
>> > ac This could be fixed.
>> 
>> Fixed?? What the? You're asserting that this is a PROBLEM to be
>> fixed?

> If policy would require the exact reproducability of binaries, then it
> would be a policy violation.

That is not how things work around here.  In a case like this,
 policy will _follow_ most packages being bit-for-bit identical, and
 can't be used as a stick to beat people on the head with.

> I do not see how this helps. Imagine a build host is compromised and
> this is noticed only after a few weeks. Theoretically every machine
> which downloaded and installed a package in this time could be
> compromised. And even worse: it is practically impossible to find out
> wether a package is actually affected!

Actually, if you do not trust the path down which a binary
 package flows, you can not use any information down that flow path to
 test your implementation.  You need to do a full source audit, and
 build from source -- at which point, you might just install your trused
 binary, instead of trying to verify that the upstream package is the
 same as yours.

If you find this inadequate, then your best bet to seeing this
 happen is to go ahead and start submitting patches to make package be
 bit-for-bit compatible -- starting with, perhaps, the essential
 packages.  Once you have enough of the packages converted, we can talk
 about making this a policy recommendation.

I think building gcc builds it several times, and they had a
 neat trick of ignoring the first few bytes of a file which had the time
 stamp, and comparing the rest. You could try using that technique to
 compare files in packages.

I, for one, think this technically infeasible, but hey, I'll be
 happy to be proved wrong.

manoj
-- 
"There can be no offense where none is taken" Japanese proverb
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: Building packages with exact binary matches

[Ben Finney]

Martin Uecker <[EMAIL PROTECTED]> writes:

> If policy would require the exact reproducability of binaries, then
> it would be a policy violation.

You seem to be suggesting that policy should require this *before* it
becomes common practice. That's not generally how policy is crafted:
Debian policy generally does not prescribe packaging practice, but
rather describes it.

If some practice is a good idea, the way to see it become policy is to
motivate other packagers to follow that practice, until it is common
enough that it is not onerous to describe it as packaging policy that
should always be followed.

Debian policy isn't a stick to beat others with; it's a formal
description of packaging practice that is believed to be good
independent of being written down in policy.

-- 
 \  "Any sufficiently advanced bug is indistinguishable from a |
  `\   feature."  -- Rich Kulawiec |
_o__)  |
Ben Finney


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

Re: You must be The Real Woman with "huge dignity"!

[ScarryJerry]

Hi Ladies

The Girls used to laugh at me in the public restroom.
Now they gasp in horror because I took MegaHole for 6 years!
Now I laugh at them because my vagina is now the size of a walk-in closet

100% Guarantee!
Web-Site of our shop - http://somethingfishy.com/

Soros is an idiot. The things George has said do not offer a rational view.
-- 
View this message in context: 
http://www.nabble.com/You-must-be-The-Real-Man-with-%22huge-dignity%22%21-tf4409804.html#a12854327
Sent from the Debian Devel mailing list archive at Nabble.com.


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

Re: Building packages three times in a row

[Neil Williams]

On Mon, 24 Sep 2007 02:13:32 +0200
Martin Uecker <[EMAIL PROTECTED]> wrote:

> The idea is not to replace hashes by bit-by-bit comparison, but to
> be able to *independendly* reproduce binaries from source code in
> a bit-identical way. 

And what is going to happen when I used gcc-4.2.2007foo and you use
gcc-4.2.1 etc.? You have the .orig.tar.gz and you have the .diff.gz.
The standard method is to compare the .orig.tar.gz and then use
'interdiff -z' against the new .diff.gz.

> Then third parties can recreate the binaries
> and publish recreated hashes. 

Why? I see no benefit.

> If the recreated hashes are identical
> then you can be sure that nobody has tempered with the build process

You'll *only* get that if the build tools are identical - that isn't
tampering, it is bug fixing. gcc is not bug-free, each new version can
include new bugs or regressions - same applies to autotools, dpkg, etc.etc.

> and the binary is actually created from the unmodified sources.

== compare the .orig.tar.gz - nothing else is needed for that and all
the current tools already handle this portion.

> The
> current scheme just protects against tempering after signing. That
> is actually not very much.

You have to trust a DD at some point. If you can't trust me to build
packages properly, you'll just have to rebuild the entire archive
yourself.

-- 

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


pgpGxU8SODj6V.pgp
Description: PGP signature