Re: debian-private list archives

[Pascal Hakim]

On Mon, Nov 01, 2004 at 06:50:44AM +0100, Martin Godisch wrote:
> Hi,
> 
> Who can tell me, where the debian-private list archives can be found?
> Looks like they moved somewhere...
> 

master:/home/debian/archive/debian-private/

Pasc
-- 
Pascal Hakim  0403 411 672
Do Not Bend

Debconf is not a registry (was: Right Way to make a configuration package)

[Marc Haber]

On Sun, 31 Oct 2004 01:07:05 +0200, Petter Reinholdtsen
<[EMAIL PROTECTED]> wrote:
>Well, the solution to this problem is to _never_ use debconf to store
>information.  The configuration info should be stored in the
>configuration files, and the current debconf values should be set
>based on the content of the configuration files.  The values in the
>debconf database should only be used when no configuration file exist.
>
>(This is sometimes summarized using statements like 'debconf is not a
>registry'.)

Why is the information given during package installation stored
persistently in the first place?

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Debconf is not a registry (was: Right Way to make a configuration package)

[sean finney]

On Mon, Nov 01, 2004 at 08:04:14AM +0100, Marc Haber wrote:
> Why is the information given during package installation stored
> persistently in the first place?

it's not stored persistently, that's why it's in /var/cache :)


sean

-- 


signature.asc
Description: Digital signature

hand embroidery badges

[longfly]

Dear Sirs,
It is immense pleasure to introduce you ourselves as we are one of the leading
manufacturers and exporters all kinds of hands embroidery badges,sashes,
pennants,flags,flagstaff,banners,family crest,emblems,and also other sorts of
products in the markets.
Therefore,we do cordially request you to please give us a chance and see 
our abilities
in the workmanship.and assure you with guarantee that we shall supply you 
our very
finest qualities of products with the cost of very low.

After having your reply and advise then we shall send you a sample for your 
inspection

and approval.and fulfill your whole requirements in time. please be sure.
Thank you very much in advance,we remain.
Truly yours
M.Jahangir
> 

Re: Apt-Torrent project

[Arnaud Kyheng]

Matthew Palmer a écrit :
[...]
If we can get individually-signed .debs, you won't even need to worry so
much about getting the torrent files off a trusted mirror...
That's the idea, since the .torrent are fetched from a trusted server. 
The .torrents contains a SHA1 checksum which is checked against 
downloaded file.

At any rate, it looks good, and I, for one, hope to see a lot more about it
in the future.
Cool :). Atm I'm trying to set up a better seeder with some adsl friends 
connections, to have a decent downloading rate.

Arnaud

Re: Debconf is not a registry

[Frank Küster]

sean finney <[EMAIL PROTECTED]> schrieb:

> On Mon, Nov 01, 2004 at 08:04:14AM +0100, Marc Haber wrote:
>> Why is the information given during package installation stored
>> persistently in the first place?
>
> it's not stored persistently, that's why it's in /var/cache :)

But debconf itself thinks that the information should be persistant. I
once deleted /var/cache/debconf/* (don't remember how or why), and since
then debconf occasionally complains upon upgrade of a package that
answers and templates have been lost, and that it will try to restore
them. This doesn't sound as if this was planned as usual business
(although the "try" is understatement, of course it always works).

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Apt-Torrent project

[Arnaud Kyheng]

Matt Zimmerman a écrit :
(CCing the BTS, where this feature request is already tracked)
On Sat, Oct 30, 2004 at 10:35:53AM +0200, Arnaud Kyheng wrote:

I love the Debian project, and I have worked on a new development for 
it: Apt-Torrent :)

Apt-Torrent is an apt proxy to the Bittorrent network. For security, the 
package listing, and the .torrent files are downloaded from a regular 
http server, as usual for a package, but then the whole package is 
fetched via bittorrent protocol and forwarded to apt :)

Interesting; I hadn't considered implementing this as a proxy.  It would
probably be better to subclass an existing HTTP server implementation,
rather than to implement a subset of HTTP in your package.
At the moment apt-torrent is implemented like a real http server. This 
line is added in /etc/apt/sources.list by the package:
deb http://127.0.0.1:6968/debian/ unstable main

From the apt point of view, it's a real http package repository, which 
could also be a package source repository (deb-src) as well.

Arnaud

Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy

[Frank Küster]

[I'm not subscribed to -policy, please respect M-F-t or Cc me]

Hi all,

early this year, some guidelines for the handling of orig.tar.gz files
for Debian packages were discussed on debian-devel
(http://lists.debian.org/debian-devel/2004/01/msg01796.html). I have
tried to write together what seemed to be a consensus on that, and
submitted it as a wishlist bug (#278524) to the Developer's
Reference. A new version of the added section, 6.1, is available
(slightly updated compared to the original patch) at

http://people.debian.org/~frank/ch-best-pkging-practices.en.html

There are some points, however, that are unclear, or where no
consensus was achieved. I would be glad to receive some feedback on the
following points:

1. Should this be included in the Developer's Reference, or shouldn't
   (parts of) it rather be included in Debian Policy? If you think it
   should be in Policy, would it be appropriate to include it in the
   Developer's Reference as long as Policy is frozen pre-sarge?

The main discussion on the list back then was about reasons for
repackaging, namely whether the need to add or change binary files is a
reason to create a new orig.tar.gz file. In the new section 6.1.3, I
have tried to summarise the different possibilities mentioned without
giving one of them preference. However, this is inconsistent with the
following sentence in 6.1.2 that I adopted from Henning for the
description of "repackaged upstream source":

,
| A repackaged .orig.tar.gz [...] must not contain any file that does not
| come from the upstream author(s), or whose contents has been changed by
| you. 
`

This poses the following questions:

2. Do you think that - although alternative methods exist - a binary
   file may be changed or added by creating a new orig.tar.gz file? Or
   do you think this must be done by adding a uuencode'd file (or
   similar) in diff.gz?

3. If you think a binary change is a reason for a new orig.tar.gz, do
   you think the sentence cited above should get an exception for binary
   files, or should it rather be dropped or rephrased completely? [Note
   also the footnote the sentence has]

4. What is the right place to document the changes made to the
   orig.tar.gz file? Some possible places would be

   - the get-orig-source target in debian/rules (see Policy 4.8)

   - a README.Debian-source in the debian directory (i.e. in the
 diff.gz) 

   - a README.Debian-source file added to the orig.tar.gz 


Personally, I think that the last possibility should be a
requirement. The main reason is that I think that our archive should be
a good source for Free Software even when one does not want to use the
Debian Operating System (and indeed we provide lots of mirrors for
software with no or only a couple of mirrors). It would be annoying if
one had to download the diff.gz just in order to learn what was changed
in the orig.tar.gz file.

Having the get-orig-source target is nice, but there might be cases
where this is impractical.


One final question: I'd like to have a footnote at the beginning of the
new 6.1.3, explaining a simple case where it is necessary to add or
change a binary file. I can imagine several, but I'd like to have one
that can be explained in one or two short sentences without lengthy
discussions about DFSG-freeness or non-automated generation of pdf files
or whatever. Suggestions?

Thanks for reading,
Frank

-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Bug#279175: ITP: goobox -- CD player and ripper for GNOME

[Dan Korostelev]

Package: wnpp
Severity: wishlist

* Package name: goobox
  Version : 0.3.0
  Upstream Author : Paolo Bacchilega <[EMAIL PROTECTED]>
* URL : http://ftp.gnome.org/pub/GNOME/sources/goobox/
* License : GPL
  Description : CD player and ripper for GNOME

 Goobox is an CD player and ripper for GNOME 2 environment.
 It follows the "Just Works" principle so its interface is
 beautiful and easy-to-use.
 .
 It uses GNOME/GTK+ for its user interface, GStreamer framework
 for CD playing and ripping operations and neon library to search
 album cover images with Google.
 .
 Homepage: http://ftp.gnome.org/pub/GNOME/sources/goobox/

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-1-k7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Bug#278524: Info received (was Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy)

[Debian Bug Tracking System]

Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the package maintainer(s)
and to other interested parties to accompany the original report.

Your message has been sent to the package maintainer(s):
 Adam Di Carlo <[EMAIL PROTECTED]>

If you wish to continue to submit further information on your problem,
please send it to [EMAIL PROTECTED], as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Re: Apt-Torrent project

[Arnaud Kyheng]

Mike Furr a écrit :
Arnaud Kyheng wrote:
| Hello,
|
| I love the Debian project, and I have worked on a new development for
| it: Apt-Torrent :)
Thank you for your contribution.  However, I looked at doing something
similar to this a little while ago and found that bittorrent is not
very well suited for doing package downloads.  Of the ~15k binary
packages in Debian about 87% are under 1 meg in size and 98% are under
10 megs.  The bit-torrent protocol works best on files significantly
larger than this.  Also, the protocol is not as efficient as it could be
for the server hosting the .torrent file, which means it scales quite
poorly when there are lots of requests for small files, as would be the
case for Debian packages.
I don't agree with the little package problem with Bittorrent. With 
Bittornado I'm using as a backend, the super-seeder option answer to 
this problem since if the package is already well available on the 
network, it'll not answer to the client but let it download from peers.

Furthermore the .torrent files are very small ~2k and could be easily 
cached by ISPs.

And also, if you think that the tracker overhead not worth a 5k package, 
you could as well split the downloading system in two. I mean  put only 
>= 5k packages files on the apt-torrent server and let the others be 
fetched directly in http.

This can be done easily since apt-torrent is fetching the Packages.gz as 
usual. I mean I could add a special header in the Packages.gz 
description to tell the proxy where to download the package direct-http, 
or apt-torrent-server for example.


However, I do feel that having a p2p backend to apt is a very
interesting and feasible distribution method.  There is a lot of
structure in the way Debian lays out its archive, from the Package files
to the .deb's themselves, which can be exploited to make this very
efficient.  There has also been a myriad of research papers exploring
overlay networks and application level multicast which could be adopted
to form a package network that would provide advantages over our current
mirror infrastructure.  (I've actually done a little work on exploring
this, but haven't gotten very far due to time constraints.)
My original idea was to save bandwidth of the Debian server, and improve 
the downloading speed of the packages for users that are even far of a 
mirror. I found that the Bittorrent was really mature and will fit well. 
 In the future, I could as well use GNUnet as a backend :)

With apt-torrent you may also reduce the number of proximity servers. We 
don't need extreme latency response for 2k .torrent files, and except if 
the mirror is an ISP, it'll not overload the ISPs peers, by Bittorent 
scheme. Furthermore it'll load more the ISPs cache with the .torrent files.

With lesser proximity servers/seeders, it might also save rsync 
bandwidth needed to sync Debian repository servers.

Arnaud

looking for Bernd S. Brentrup

[Laszlo 'GCS' Boszormenyi]

Hi,

 I am looking for Bernd. I have lost contact with him ages ago, I
haven't seen any upload/svn commit from him since then. However his
package has NMU, without any reaction from him. I hope he is fine and
just has a rest, maybe retired? Anyone knows exact information?

Thanks,
Laszlo/GCS

Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy

[Bill Allombert]

On Mon, Nov 01, 2004 at 10:58:55AM +0100, Frank Küster wrote:
> [I'm not subscribed to -policy, please respect M-F-t or Cc me]
> 
> | A repackaged .orig.tar.gz [...] must not contain any file that does not
> | come from the upstream author(s), or whose contents has been changed by
> | you. 
> `
> 
> This poses the following questions:
> 
> 2. Do you think that - although alternative methods exist - a binary
>file may be changed or added by creating a new orig.tar.gz file? Or
>do you think this must be done by adding a uuencode'd file (or
>similar) in diff.gz?

I think it is more of a practical matter. If you have a few binary files
to add, uuencode them. ( Also remember that Debian menu icons must be in
XPM so you don't need to uuencode them.) When a new upstream version
appear, you can reuse the diff.gz and automatically get the binary files
without messing with the tarball.

If you have a whole directory of binary files, you might consider
making a new source package for them. (For example a Debian theme
for a program).

> 3. If you think a binary change is a reason for a new orig.tar.gz, do
>you think the sentence cited above should get an exception for binary
>files, or should it rather be dropped or rephrased completely? [Note
>also the footnote the sentence has]

I don't know, my experience is that developers that changed source
packages to add binary files did it because they had no better idea
on how to handle that situation. Your text address that.

> 4. What is the right place to document the changes made to the
>orig.tar.gz file? Some possible places would be
> 
>- the get-orig-source target in debian/rules (see Policy 4.8)
> 
>- a README.Debian-source in the debian directory (i.e. in the
>  diff.gz) 
> 
>- a README.Debian-source file added to the orig.tar.gz 

> Personally, I think that the last possibility should be a
> requirement. The main reason is that I think that our archive should be
> a good source for Free Software even when one does not want to use the
> Debian Operating System (and indeed we provide lots of mirrors for
> software with no or only a couple of mirrors). It would be annoying if
> one had to download the diff.gz just in order to learn what was changed
> in the orig.tar.gz file.

I disagree for practical reason: one cannot improve and fix errors in
README.Debian-source without issuing a new orig.tar.gz which is usually
quite painful. Allowing developers to fix that file more easily will
lead to higher quality. Also your proposal is not compatible with
  | A repackaged .orig.tar.gz [...] must not contain any file that does not
  | come from the upstream author(s), or whose contents has been changed by
  | you.

> Having the get-orig-source target is nice, but there might be cases
> where this is impractical.

debian/rules get-orig-source is code, not a documentation.
If you provide a script that build a new orig.tar.gz without user
hand-holding, then you should arrange for debian/rules get-orig-source
to call it, especially if the script is likely to work with new
upstream version.

> One final question: I'd like to have a footnote at the beginning of the
> new 6.1.3, explaining a simple case where it is necessary to add or
> change a binary file. I can imagine several, but I'd like to have one
> that can be explained in one or two short sentences without lengthy
> discussions about DFSG-freeness or non-automated generation of pdf files
> or whatever. Suggestions?

Adding some PNG files to use in the Debian configuration ?

|>3. should, except where impossible for legal reasons, preserve the
|>   entire building and portablility infrastructure provided by the
|>   upstream author. For example, it is not appropriate to omit source
|>   files that are used only when building on MS-DOS

Unfortunately, there are lots of precedent for MS-DOS specific files to
carry a non-free license, so removing them can be the safe option.

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

Imagine a large red swirl here. 

open office help

[Raghuveer]

Hello,
 
   We are using progress as programming langauge and open office for reports purpose. I wanted to know does open office supports DDE (Dynamic data exchange) ?. Is there any other way we can write from progress to open office. Are do we need to use any other programming langauge (C++ / Java ) and pass data to c++/java and then write to open office. This seems to be complicated method. Please suggest alternative for this. 
Thanks for your help.
 
Regards
Raghuveer
L + L
Germany
		Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now.

Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy

[Frank Küster]

Hello,

thanks for the feedback.

Bill Allombert <[EMAIL PROTECTED]> wrote:

> On Mon, Nov 01, 2004 at 10:58:55AM +0100, Frank Küster wrote:
>
>> 3. If you think a binary change is a reason for a new orig.tar.gz, do
>>you think the sentence cited above should get an exception for binary
>>files, or should it rather be dropped or rephrased completely? [Note
>>also the footnote the sentence has]
>
> I don't know, my experience is that developers that changed source
> packages to add binary files did it because they had no better idea
> on how to handle that situation. Your text address that.

Well, yes. But having no better idea might be because other options have
big disadvantages, or just because one didn't even start thinking about
alternatives. I myself have been really sloppy in repackaging in the
past, and some text in Policy or D-R could have made me think more
carefully. 

>>- a README.Debian-source file added to the orig.tar.gz 
>
[...]
> I disagree for practical reason: one cannot improve and fix errors in
> README.Debian-source without issuing a new orig.tar.gz which is usually
> quite painful. Allowing developers to fix that file more easily will
> lead to higher quality. 

That's a good point.

> Also your proposal is not compatible with
>   | A repackaged .orig.tar.gz [...] must not contain any file that does not
>   | come from the upstream author(s), or whose contents has been changed by
>   | you.

There is a "besides that [the README.Debian-source file]" in the "..."
part above for that.

>> Having the get-orig-source target is nice, but there might be cases
>> where this is impractical.
>
> debian/rules get-orig-source is code, not a documentation.

In this case it's both, at least if some comment says that this is the
way the orig.tar.gz was actually prepared.

> |>3. should, except where impossible for legal reasons, preserve the
> |>   entire building and portablility infrastructure provided by the
> |>   upstream author. For example, it is not appropriate to omit source
> |>   files that are used only when building on MS-DOS
>
> Unfortunately, there are lots of precedent for MS-DOS specific files to
> carry a non-free license, so removing them can be the safe option.

That's why I (or Henning) wrote "except where impossible for legal
reasons". Since we can include files only if the license is clear and
DFSG-free, any MS-DOS stuff which is "probably LGPL" or similar must be
dropped. But MS-DOS stuff that is surely GPL should be kept.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Xsession doesn't use umask setting from /etc/login.defs

[Tollef Fog Heen]

* Branden Robinson 

| I'm not thrilled with it, but maybe you can make something useful out of
| that.
| 
| Thanks again for the lightning-fast coding.  :)

Thanks for the description; the package is now sitting in the NEW
queue.  Sorry for taking a bit of time, I have been away on vacation.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: Why sysklog uses its own logrotate and not logrotate script

[Marc Haber]

On Thu, 28 Oct 2004 21:42:09 +0400, "Nikita V. Youshchenko"
<[EMAIL PROTECTED]> wrote:
>> and before anybody asks, I already but all the things into logrotate. I
>> just curious why its not there from beginning.
>
>With current default configuration, if I add some more log files
>info /etc/syslog.conf (e.g. to catch localN facilities), they get rotation
>automatically. Can the same be achieved with logrotate same (without having
>to add new files to logrotate configuration manually - it's always bad to
>duplicate configuration)?

It would be easy if all syslogd log files were in a single directory,
which is not the case.

It would be easier for logrotate if it would support backticks in a
logrotate config file:

  `syslogd-listfiles` {
  
   }

Geez, one more point for the logrotate++ todo list.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Bug#277766: ITP: moniwiki -- MoniWiki is yet another WikiEngine written in PHP. It is fast, light and easy to install. Also it has many enhanced and new features. Moni is slightly modified sound which means What? or What is it? in Korean. The name also indicates that MoniWiki is nearly compatible with the MoinMoin. MoniWiki WikiFormattingRules were inspired and adopted from MoinMoin. Check MoniWikiFeatures to see what MoniWiki has to offer.

[Tollef Fog Heen]

* Ki-Heon Kim 

|   Description : MoniWiki is yet another WikiEngine written in PHP. It is 
fast, light and easy to install. Also it has many enhanced and new features. 
Moni is slightly modified sound which means What? or What is it? in Korean. The 
name also indicates that MoniWiki is nearly compatible with the MoinMoin. 
MoniWiki WikiFormattingRules were inspired and adopted from MoinMoin. Check 
MoniWikiFeatures to see what MoniWiki has to offer.

Does it have problems with line breaks?

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: Why sysklog uses its own logrotate and not logrotate script

[Martin Schulze]

Graham Wilson wrote:
> On Wed, Oct 27, 2004 at 06:10:43PM +0200, Martin Schulze wrote:
> > Clemens Schwaighofer wrote:
> > > I would like to know why sysklog package uses its own logrotation
> > > scripts and not logrotate.
> > 
> > Try to convert it to logrotate and soon you will understand why it still
> > uses savelog.
> 
> It seems like he did. It's something I always do on machines I install.
> I fail to see why sysklogd still uses savelog.

Please send me the patch.

Regards,

Joey

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.

Please always Cc to me when replying to me on the lists.

Re: debian-private list archives

[Martin Schulze]

Martin Godisch wrote:
> Who can tell me, where the debian-private list archives can be found?
> Looks like they moved somewhere...

Did the mailing list footer change while we were not paying attention?

Mine still says:


Please respect the privacy of this mailing list.

Archive: file://master.debian.org/~debian/archive/debian-private/

To UNSUBSCRIBE, use the web form at .


Regards,

Joey

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.

Please always Cc to me when replying to me on the lists.

Re: Debconf is not a registry (was: Right Way to make a configuration package)

[Colin Watson]

On Mon, Nov 01, 2004 at 08:04:14AM +0100, Marc Haber wrote:
> On Sun, 31 Oct 2004 01:07:05 +0200, Petter Reinholdtsen
> <[EMAIL PROTECTED]> wrote:
> >Well, the solution to this problem is to _never_ use debconf to store
> >information.  The configuration info should be stored in the
> >configuration files, and the current debconf values should be set
> >based on the content of the configuration files.  The values in the
> >debconf database should only be used when no configuration file exist.
> >
> >(This is sometimes summarized using statements like 'debconf is not a
> >registry'.)
> 
> Why is the information given during package installation stored
> persistently in the first place?

As a convenience so that you don't have to waste time answering
questions again and again.

-- 
Colin Watson   [EMAIL PROTECTED]

Re: Why sysklog uses its own logrotate and not logrotate script

[Colin Watson]

On Thu, Oct 28, 2004 at 10:53:12AM +0200, Adeodato Simó wrote:
> * Clemens Schwaighofer [Wed, 27 Oct 2004 23:02:44 +0900]:
> > I would like to know why sysklog package uses its own logrotation
> > scripts and not logrotate.
> 
>   albeit both are Priority: important, sysklogd is Section: base. and,
>   iiuc, base should be self-contained (that is, packages in base must
>   not depend on packages outside it).

I don't believe such a restriction exists. "Section: base" is pretty
much a relic, obsoleted long ago by debootstrap.

-- 
Colin Watson   [EMAIL PROTECTED]

Re: open office help

[Manu Abraham]

On Mon November 1 2004 4:18 pm, Raghuveer wrote:
> Hello,
>
>We are using progress as programming langauge and open office for
> reports purpose. I wanted to know does open office supports DDE (Dynamic
> data exchange) ?. Is there any other way we can write from progress to open
> office. Are do we need to use any other programming langauge (C++ / Java )
> and pass data to c++/java and then write to open office. This seems to be
> complicated method. Please suggest alternative for this. Thanks for your
> help.
>

There are perl modules on CPAN which will allow you to do so.
OpenOffice::OODoc will allow you to do so.

One can even use C/C++/Java to write out into required XML format for OO.

Regards,
Manu

Re: Debconf is not a registry

[Frank Küster]

Colin Watson <[EMAIL PROTECTED]> schrieb:

> On Mon, Nov 01, 2004 at 08:04:14AM +0100, Marc Haber wrote:
>> On Sun, 31 Oct 2004 01:07:05 +0200, Petter Reinholdtsen
>> <[EMAIL PROTECTED]> wrote:
>> >Well, the solution to this problem is to _never_ use debconf to store
>> >information.  The configuration info should be stored in the
>> >configuration files, and the current debconf values should be set
>> >based on the content of the configuration files.  The values in the
>> >debconf database should only be used when no configuration file exist.
>> >
>> >(This is sometimes summarized using statements like 'debconf is not a
>> >registry'.)
>> 
>> Why is the information given during package installation stored
>> persistently in the first place?
>
> As a convenience so that you don't have to waste time answering
> questions again and again.

But that could as well be achieved by parsing the configuration files:

if mypackage_parseconfig; then
   db_set mypackage/item1 "$itemone"
   db_set mypackage/item2 "$itemtwo"
   db_set mypackage/item3 "$itemthree"
else
   db_input mypackage/item1
   db_input mypackage/item2
   db_input mypackage/item3
   db_go
fi

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy

[Manoj Srivastava]

On Mon, 01 Nov 2004 10:58:55 +0100, Frank Küster <[EMAIL PROTECTED]>
said:  

> ,
>> A repackaged .orig.tar.gz [...] must not contain any file that does
>> not come from the upstream author(s), or whose contents has been
>> changed by you.
> `

That sounds reasonable to me. oir.tar.gz is supposed to be
 _upstream's_ sources. not a mix of stuff from upstream plus stuff
 added later. It may not have _all_ the upstream provided things, if
 we can't distribute them.

> This poses the following questions:

> 2. Do you think that - although alternative methods exist - a binary
>file may be changed or added by creating a new orig.tar.gz file?

No.

>Or do you think this must be done by adding a uuencode'd file (or
>similar) in diff.gz?

That is the eay it is usually done, yes.

> 4. What is the right place to document the changes made to the
>orig.tar.gz file? Some possible places would be

>- the get-orig-source target in debian/rules (see Policy 4.8)

Not visible enough.

>- a README.Debian-source in the debian directory (i.e. in the
>  diff.gz)

This sounds fine, since this can then also be shipped with the
 binary .deb file.

>- a README.Debian-source file added to the orig.tar.gz

Nothings gets added to the upstream in orig.tar.gz

> Personally, I think that the last possibility should be a
> requirement. The main reason is that I think that our archive should
> be a good source for Free Software even when one does not want to
> use the Debian Operating System (and indeed we provide lots of
> mirrors for software with no or only a couple of mirrors). It would
> be annoying if one had to download the diff.gz just in order to
> learn what was changed in the orig.tar.gz file.

If you get the .dsc fle, or you get the .deb, which are the
 units we distribute, you shall have exact;ly what was done to the
 upstream tarball.  Not having you download the diff.gz is not
 valuable enough to destroy the invariant that we add nothing to the
 orig.tar.gz, or that everything in the orig.tar.gz came from the
 upstream author.  Violating these basic invariants for the sake of
 something as ephemeral as optimizing for bandwidth would be a
 fallacy; bandwidth costs decrease ast. apt-get source foo is as valid
 a way of getting sources from debian as any (indeed, getting the
 source package may be the _only_ supported way of getting sources
 from Debian).

Since the modification is available whenever you get a source
 or binary package from Debian, documenting it in a README file in the
 debian diff is eminently satisfactory, in my opinion, and it has the
 least element of surprise, in that we did not add anything to a file
 meant to carry sources from the upstream author.


manoj
-- 
Well, the handwriting is on the floor. Joe E. Lewis
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy

[Bill Allombert]

On Mon, Nov 01, 2004 at 02:32:27PM +0100, Frank Küster wrote:
> Bill Allombert <[EMAIL PROTECTED]> wrote:
> >> Having the get-orig-source target is nice, but there might be cases
> >> where this is impractical.
> >
> > debian/rules get-orig-source is code, not a documentation.
> 
> In this case it's both, at least if some comment says that this is the
> way the orig.tar.gz was actually prepared.

In second though I reread policy:
 
 `get-orig-source' (optional)
  This target fetches the most recent version of the original
  source package from a canonical archive site (via FTP or WWW, for
  example), does any necessary rearrangement to turn it into the
  original source tar file format described below, and leaves it in
  the current directory.

so get-orig-source is not a way to convert the upstream tarball to a
Debian tarball: if upstream upload a new version after the package is
uploaded, get-orig-source will build the new Debian tarball, not the
one shipped as .orig.tar.gz. This difference is important if upstream
site only carry out the latest version without archiving older versions
(yes that does happen). 

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

Imagine a large red swirl here. 

Bug#199316: Info received (was Apt-Torrent project)

[Debian Bug Tracking System]

Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the package maintainer(s)
and to other interested parties to accompany the original report.

Your message has been sent to the package maintainer(s):
 APT Development Team <[EMAIL PROTECTED]>

If you wish to continue to submit further information on your problem,
please send it to [EMAIL PROTECTED], as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Re: Apt-Torrent project

[Mike Furr]

Arnaud Kyheng wrote:
I don't agree with the little package problem with Bittorrent. With 
Bittornado I'm using as a backend, the super-seeder option answer to 
this problem since if the package is already well available on the 
network, it'll not answer to the client but let it download from peers.
[...]
And also, if you think that the tracker overhead not worth a 5k package, 
you could as well split the downloading system in two. I mean  put only 
 >= 5k packages files on the apt-torrent server and let the others be 
fetched directly in http.
This would probably help as long as you didn't abuse super-seeding.  One 
solution may be to only super seed those packages which are smaller than 
some threshold and are also in base or have a priority > standard(or 
something).  Like most things, the distribution of popular packages 
appears to have a zipf distribution(at least, according to popcon), so 
you could also gain efficiency by exploiting this data.

This can be done easily since apt-torrent is fetching the Packages.gz as 
usual. I mean I could add a special header in the Packages.gz 
description to tell the proxy where to download the package direct-http, 
or apt-torrent-server for example.
Well, I wouldn't edit the Packages.gz file directly since it will no 
longer match the hash in the Release file, I would have this in a 
separate file, if at all.


My original idea was to save bandwidth of the Debian server, and improve 
the downloading speed of the packages for users that are even far of a 
mirror. I found that the Bittorrent was really mature and will fit well. 
 In the future, I could as well use GNUnet as a backend :)
Although I personally get fantastic download speeds from the push 
primary mirrors, I guess this is not the case everywhere.  I agree that 
moving some load off of the mirror network would be beneficial.

I look forward to trying apt-torrent and hope that it works out well. 
Since it appears that you are not a debian developer, are you looking 
for someone to package/sponsor this?

-Mike

Problem with dpkg on alpha ?

[Jean-Yves LENHOF]

Is'nt there something wrong with dpkg on alpha... it seems to segfault a
lot these days...

http://buildd.debian.org/build.php?&pkg=mozilla-firefox&ver=0.99%2B1.0RC1-2&arch=alpha&file=log
http://buildd.debian.org/build.php?&pkg=cxref&ver=1.6-3&arch=alpha
http://buildd.debian.org/build.php?&pkg=fribidi&ver=0.10.4-6&arch=alpha&file=log

Regards,

PS : I'm not on the list
-- 
Jean-Yves LENHOF <[EMAIL PROTECTED]>

Is membership in staff supposed to imply root access?

[Rob Browning]

It looks like our installs set up /usr/local/bin to be group staff and
writable by staff, and place /usr/local/(s)bin before /usr/(s)bin in
root's PATH.

I was a little surprised because I thought we used to exclude the
/usr/local directories from root's path by default, but perhaps we
changed our policies or perhaps my memory is mistaken.

Also, I wonder if our handling of /usr/local isn't a bit inconsistent
since it doesn't look like we include /usr/local/lib in the ld.so
defaults.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4

Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy

[Chris Waters]

On Mon, Nov 01, 2004 at 10:22:12AM -0600, Manoj Srivastava wrote:
> On Mon, 01 Nov 2004 10:58:55 +0100, Frank Küster <[EMAIL PROTECTED]>
> said:  
> 
> > ,
> >> A repackaged .orig.tar.gz [...] must not contain any file that does
> >> not come from the upstream author(s), or whose contents has been
> >> changed by you.
> > `

>   That sounds reasonable to me. oir.tar.gz is supposed to be
>  _upstream's_ sources. not a mix of stuff from upstream plus stuff
>  added later.

That assumes an easily measurable definition of "upstream".  And a
sharp distinction between "upstream" and "DD" that may not actually
exist (e.g. a DD may be a member of upstream).

I'm not at all sure how this rule would apply, for example, to my own
pilot-manager_1.107.0pre108.orig.tar.gz.  Everything in there is from
upstream's website, except my own note on how I put the pieces
together.  Do I need to remove that note?  That seems like a really
bad idea.  Anyway, I was upstream project leader for most of the last
year, up until about a week ago, when I stepped down in favor of
someone more enthusiastic.  But I'm still an upstream developer.

-- 
Chris Waters   |  Pneumonoultra-osis is too long
[EMAIL PROTECTED]   |  microscopicsilico-to fit into a single
or [EMAIL PROTECTED] |  volcaniconi-  standalone haiku

Re: Problem with dpkg on alpha ?

[John Goerzen]

I've seen that on the buildd but my own Alpha isn't having any trouble.

A message on this topic to debian-alpha yielded no replies either, so I
suspect the buildd machine is the only one hosed.

-- John

On Mon, Nov 01, 2004 at 07:42:01PM +0100, Jean-Yves LENHOF wrote:
> Is'nt there something wrong with dpkg on alpha... it seems to segfault a
> lot these days...
> 
> http://buildd.debian.org/build.php?&pkg=mozilla-firefox&ver=0.99%2B1.0RC1-2&arch=alpha&file=log
> http://buildd.debian.org/build.php?&pkg=cxref&ver=1.6-3&arch=alpha
> http://buildd.debian.org/build.php?&pkg=fribidi&ver=0.10.4-6&arch=alpha&file=log
> 
> Regards,
> 
> PS : I'm not on the list
> -- 
> Jean-Yves LENHOF <[EMAIL PROTECTED]>
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy

[Henning Makholm]

Scripsit Frank Küster <[EMAIL PROTECTED]>

First, thank you for taking hand of this issue!

> > |>3. should, except where impossible for legal reasons, preserve the
> > |>   entire building and portablility infrastructure provided by the
> > |>   upstream author. For example, it is not appropriate to omit source
> > |>   files that are used only when building on MS-DOS

> > Unfortunately, there are lots of precedent for MS-DOS specific files to
> > carry a non-free license, so removing them can be the safe option.

> That's why I (or Henning) wrote "except where impossible for legal
> reasons".

To prevent this misunderstanding, perhaps change to

  For example, it is not sufficient reason to omit a file that it is
  used only when buidling on MS-DOS. Similarly, a Makefile provided by
  upstream should not be omitted even if the first thing your
  debian/rules does is to overwrite it by running a configure script.


Some minor typos, most certainly originally made by me:

officially distributed to the upstream author: s/to/by/

non-DFGS-free material: s/GS/SG/

the latter two points it to let: s/it/is/

-- 
Henning Makholm  "Also, the letters are printed. That makes the task
of identifying the handwriting much more difficult."

Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy

[Manoj Srivastava]

On Mon, 1 Nov 2004 10:39:44 -0800, Chris Waters <[EMAIL PROTECTED]> said: 

> On Mon, Nov 01, 2004 at 10:22:12AM -0600, Manoj Srivastava wrote:
>> On Mon, 01 Nov 2004 10:58:55 +0100, Frank Küster
>> <[EMAIL PROTECTED]> said:
>> 
>> > ,
>> >> A repackaged .orig.tar.gz [...] must not contain any file that
>> >> does not come from the upstream author(s), or whose contents has
>> >> been changed by you.
>> > `

>> That sounds reasonable to me. oir.tar.gz is supposed to be
>> _upstream's_ sources. not a mix of stuff from upstream plus stuff
>> added later.

> That assumes an easily measurable definition of "upstream".  And a
> sharp distinction between "upstream" and "DD" that may not actually
> exist (e.g. a DD may be a member of upstream).


Red herring.  The upstream sources mean sources available from
 _upstream_ -- and has little to do with what comprises upstream
 teams, or whether the upstream team is mostly debian developers.

How about this rule of thumb: If you get stuff from the
 primary NON DEBIAN distribution site, that is what you call
 upstream. What someone unconnected to debian, not using debian
 archives, downloads is what we also offer as upstream orig.tar.gz
 files. 

> I'm not at all sure how this rule would apply, for example, to my
> own pilot-manager_1.107.0pre108.orig.tar.gz.  Everything in there is
> from upstream's website, except my own note on how I put the pieces
> together.  Do I need to remove that note?

I think so, yes.

> That seems like a really bad idea.

Why? There are a number of ways I can think of to enhance
 upstream sources -- like adding man pages, etc. In any case, how you
 put things together for Debian belongs in the changes you made for
 debian. Pristine upstream means pristine upstream. Either get your
 notes added to upstream website, or put them in the diffs.

So, please curb your interest in improving upstream sources by
 modifying the upstream tarball.  If the changes are not Debian
 specific, then by all means push them upstream. Do not prevaricate to
 our suers by pretending that some material is the same as they can
 get upstream, when it is not.

>Anyway, I was upstream project leader for most of the
> last year, up until about a week ago, when I stepped down in favor
> of someone more enthusiastic.  But I'm still an upstream developer.

That is quite irrelevant.

manoj
-- 
It's more than magnificent -- it's mediocre. Sam Goldwyn
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Problem with dpkg on alpha ?

[Steve Langasek]

Cc:ed to the alpha buildd maintainer, so he can take a look at this problem
if he hasn't already.

On Mon, Nov 01, 2004 at 01:20:58PM -0600, John Goerzen wrote:
> I've seen that on the buildd but my own Alpha isn't having any trouble.

> A message on this topic to debian-alpha yielded no replies either, so I
> suspect the buildd machine is the only one hosed.

> On Mon, Nov 01, 2004 at 07:42:01PM +0100, Jean-Yves LENHOF wrote:
> > Is'nt there something wrong with dpkg on alpha... it seems to segfault a
> > lot these days...
> > 
> > http://buildd.debian.org/build.php?&pkg=mozilla-firefox&ver=0.99%2B1.0RC1-2&arch=alpha&file=log
> > http://buildd.debian.org/build.php?&pkg=cxref&ver=1.6-3&arch=alpha
> > http://buildd.debian.org/build.php?&pkg=fribidi&ver=0.10.4-6&arch=alpha&file=log

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy

[Joachim Breitner]

Hi,

Am Montag, den 01.11.2004, 10:58 +0100 schrieb Frank Küster:
>- a README.Debian-source file added to the orig.tar.gz 

I think this is should be done, or any other way that clearly marks
the .tar.gz as modified (even if only files are removed, it is a
modification). Anyone downloading a .orig.tar.gz file from debian should
be able to safely assume that it really is the "original .tar.gz". If
this for any reason is not right, there should be a note attached. The
most convenient way to do so is to include a file like this in the
tar.gz.

The problem of changes of this file is a true one. Therefore, maybe we
can agree on a standard wording for these file, something like:


This file was modified by the debian package maintainer in the following
way:
These files were removed:
rfc/12345.txt
bin/firmware.bin

Re: Why sysklog uses its own logrotate and not logrotate script

[Marc Haber]

On Mon, 1 Nov 2004 15:29:36 +0100, Martin Schulze <[EMAIL PROTECTED]>
wrote:
>Please send me the patch.

Honestly, looking at sysklogd's bug list doesn't make people get the
impression that it makes sense to file patches against the sysklogd
package.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Why sysklog uses its own logrotate and not logrotate script

[Steve Langasek]

On Mon, Nov 01, 2004 at 09:39:51PM +0100, Marc Haber wrote:
> On Mon, 1 Nov 2004 15:29:36 +0100, Martin Schulze <[EMAIL PROTECTED]>
> wrote:
> >Please send me the patch.

> Honestly, looking at sysklogd's bug list doesn't make people get the
> impression that it makes sense to file patches against the sysklogd
> package.

Honestly, comments like these don't give people the impression that you're
interested in working with maintainers to get bugs fixed.  If you aren't
willing to submit a patch to address the bug in question, you really have no
business complaining about the state of another maintainer's package.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy

[Chris Waters]

On Mon, Nov 01, 2004 at 01:47:02PM -0600, Manoj Srivastava wrote:
> On Mon, 1 Nov 2004 10:39:44 -0800, Chris Waters <[EMAIL PROTECTED]> said: 

> > I'm not at all sure how this rule would apply, for example, to my
> > own pilot-manager_1.107.0pre108.orig.tar.gz.  Everything in there is
> > from upstream's website, except my own note on how I put the pieces
> > together.  Do I need to remove that note?

>   I think so, yes.

So in other words, I'm to be punished for my negligent maintaining of
the upstream website?  And all I need to do to satisfy your silly
complaint is to scp my note to the website somewhere?  Do I need to
provide a link anywhere?  How about if I simply add a link on the
upstream website to the tarball on Debian's servers?

-- 
Chris Waters   |  Pneumonoultra-osis is too long
[EMAIL PROTECTED]   |  microscopicsilico-to fit into a single
or [EMAIL PROTECTED] |  volcaniconi-  standalone haiku

Re: Is membership in staff supposed to imply root access?

[Santiago Vila]

On Mon, 1 Nov 2004, Rob Browning wrote:

> It looks like our installs set up /usr/local/bin to be group staff and
> writable by staff, and place /usr/local/(s)bin before /usr/(s)bin in
> root's PATH.
> 
> I was a little surprised because I thought we used to exclude the
> /usr/local directories from root's path by default, but perhaps we
> changed our policies or perhaps my memory is mistaken.

We have had /usr/local directories in the PATH for root at least since 1995
(by looking at the "base" package version 1.1.0-13).

> Also, I wonder if our handling of /usr/local isn't a bit inconsistent
> since it doesn't look like we include /usr/local/lib in the ld.so
> defaults.

Yes, I wonder the same.

DpartialMirror (was Re: [ANNOUNCE] debian-multimirror)

[Otto Wyss]

> On Wed, 29 Sep 2004, Pedro Larroy wrote:
> 
> As a long standing debmirror user and with the knowledge that there is a
> debpartial-mirror project which is very actively developed I just wonder
> if people have to much spare time to invent one wheel after an other.
> 
Sorry for the late reply but in case you mean with deppartial-mirror
project my "DpartialMirror" project, I've to say that I set its state to
mature. While I still use it daily I don't actively develop it further
since as long as Debian doesn't use gzip --rsyncable, it doesn't make
much sense. Without it the gain just a few percents.

See "http://dpartialmirror.sourceforge.net/";.

O. Wyss

-- 
See a huge pile of work at "http://wyodesktop.sourceforge.net/";

Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy

[Chris Waters]

On Mon, Nov 01, 2004 at 01:47:02PM -0600, Manoj Srivastava wrote:

>   How about this rule of thumb: If you get stuff from the
>  primary NON DEBIAN distribution site, that is what you call
>  upstream. What someone unconnected to debian, not using debian
>  archives, downloads is what we also offer as upstream orig.tar.gz
>  files. 

I think it's more important that our users *know what they're getting*
than that we try to enforce some sort of arbitrary distinction between
"Debian" and "upstream".  Clarity is why I chose "107.0pre108" as a
version number.  I don't see how it's that much different from our
various cvs-snapshot packages, except that in my case, upstream wasn't
using any sort of version control at the time I made the package -
they just had a loose collection of patches and replacement files
available on their website.

>  Pristine upstream means pristine upstream. Either get your
>  notes added to upstream website, or put them in the diffs.

We don't require "pristine upstream".  For example, we remove non-DFSG
compliant portions.  Many licenses require that changes be
documented.  So if we modify the upstream source to remove the
non-DFSG portions, and _don't document that_ (because of a new policy
rule that forbids any debian-authored portions of _orig tarballs),
then we may be violating licenses.

>  Do not prevaricate to our suers by pretending that some material is
>  the same as they can get upstream, when it is not.

I don't think I am - I think it's quite clear that 107.0pre108 is
quite different from 107.

> >Anyway, I was upstream project leader for most of the
> > last year, up until about a week ago, when I stepped down in favor
> > of someone more enthusiastic.  But I'm still an upstream developer.

>   That is quite irrelevant.

Actually, I agree.  I think the fact that I can solve "the problem" by
sticking the tarball I made on the upstream website at any moment I
choose is, or should be, irrelevant.  I think the tarball I created
should be acceptable in any case.  I think it's quite clear what I
created, and I don't think there's any intent to confuse our users,
and I think that should be sufficient.

-- 
Chris Waters   |  Pneumonoultra-osis is too long
[EMAIL PROTECTED]   |  microscopicsilico-to fit into a single
or [EMAIL PROTECTED] |  volcaniconi-  standalone haiku

Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy

[Manoj Srivastava]

On Mon, 01 Nov 2004 21:16:20 +0100, Joachim Breitner <[EMAIL PROTECTED]> said: 

> Hi, Am Montag, den 01.11.2004, 10:58 +0100 schrieb Frank Küster:
>> - a README.Debian-source file added to the orig.tar.gz

> I think this is should be done, or any other way that clearly marks
> the .tar.gz as modified (even if only files are removed, it is a
> modification). Anyone downloading a .orig.tar.gz file from debian
> should be able to safely assume that it really is the "original
> .tar.gz". If this for any reason is not right, there should be a
> note attached. The most convenient way to do so is to include a file
> like this in the tar.gz.

Substitute "source package" for orig.tar.gz , and you have my
 support.  We _should_ docment any deletions we made from the upstream
 sources in our own source package, but I think we should do it
 without munging the upstream source file any further.  Yes, people
 downloading source packages from Debian should not be in the dark,
 but we should not be adding material to the upstream source tarball
 willy nilly.

manoj
-- 
All of life is a blur of Republicans and meat!
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy

[Manoj Srivastava]

On Mon, 1 Nov 2004 12:45:36 -0800, Chris Waters <[EMAIL PROTECTED]> said: 

> On Mon, Nov 01, 2004 at 01:47:02PM -0600, Manoj Srivastava wrote:
>> On Mon, 1 Nov 2004 10:39:44 -0800, Chris Waters <[EMAIL PROTECTED]>
>> said:

>> > I'm not at all sure how this rule would apply, for example, to my
>> > own pilot-manager_1.107.0pre108.orig.tar.gz.  Everything in there
>> > is from upstream's website, except my own note on how I put the
>> > pieces together.  Do I need to remove that note?

>> I think so, yes.

> So in other words, I'm to be punished for my negligent maintaining

Oh, _do_ grow up.

> of the upstream website?  And all I need to do to satisfy your silly
> complaint is to scp my note to the website somewhere?  Do I need to
> provide a link anywhere?  How about if I simply add a link on the
> upstream website to the tarball on Debian's servers?

You may throw how ever many childish tenmper tantrums you
 want, or exercise your 'leet abilities to "Look! I can change
 upstream to match whatever I ship! Anytime! Mua hah ahhaha", but the
 simple fact remains: what you are shipping as orig.tar.gz does not
 match what people can download from the upstream site, and it is
 deviating from the recommendation that we ship pristine upstream as
 far as legally possible.

manoj

-- 
Please don't put a strain on our friendship by asking me to do
something for you.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy

[Henning Makholm]

Scripsit Chris Waters <[EMAIL PROTECTED]>
> On Mon, Nov 01, 2004 at 01:47:02PM -0600, Manoj Srivastava wrote:
> > On Mon, 1 Nov 2004 10:39:44 -0800, Chris Waters <[EMAIL PROTECTED]> said: 

> > > I'm not at all sure how this rule would apply, for example, to my
> > > own pilot-manager_1.107.0pre108.orig.tar.gz.  Everything in there is
> > > from upstream's website, except my own note on how I put the pieces
> > > together.  Do I need to remove that note?

> > I think so, yes.

> So in other words, I'm to be punished for my negligent maintaining of
> the upstream website?

How is it "punishment" to put things in the proper place in your
source packages? Please elaborate.

-- 
Henning Makholm"Anything you can discover we
 would be most happy to review."

Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy

[Manoj Srivastava]

On Mon, 1 Nov 2004 14:04:44 -0800, Chris Waters <[EMAIL PROTECTED]> said: 

> On Mon, Nov 01, 2004 at 01:47:02PM -0600, Manoj Srivastava wrote:
>> How about this rule of thumb: If you get stuff from the primary NON
>> DEBIAN distribution site, that is what you call upstream. What
>> someone unconnected to debian, not using debian archives, downloads
>> is what we also offer as upstream orig.tar.gz files.

> I think it's more important that our users *know what they're
> getting* than that we try to enforce some sort of arbitrary
> distinction between "Debian" and "upstream".

And so they should. Every source packages from debian should
 have that information. (And I mean source package formally -- .dsc
 and friends). 

> Clarity is why I chose "107.0pre108" as a version number.  I don't

That is another red herring, though it is good you selected a
 clear version number.

> see how it's that much different from our various cvs-snapshot
> packages, except that in my case, upstream wasn't using any sort of
> version control at the time I made the package - they just had a
> loose collection of patches and replacement files available on their
> website.

Umm, CVS snapshot packages have a clear version number as
 well -- which again is good -- but is irrelevant to mangling upstream
 source tar balls.

>> Pristine upstream means pristine upstream. Either get your notes
>> added to upstream website, or put them in the diffs.

> We don't require "pristine upstream".  For example, we remov

Did I say we required them? We do, however, recommend that we
 ship pristine upstreams as far as possible.
e
> non-DFSG compliant portions.  Many licenses require that changes be
> documented.  So if we modify the upstream source to remove the
> non-DFSG portions, and _don't document that_ (because of a new
> policy rule that forbids any debian-authored portions of _orig
> tarballs), then we may be violating licenses.

Bravo, for belabouring the obvious.

>> Do not prevaricate to our suers by pretending that some material is
>> the same as they can get upstream, when it is not.

> I don't think I am - I think it's quite clear that 107.0pre108 is
> quite different from 107.

But you are stuffing material in there that us not in the
 upstream sources. If merely versioning makes itr clear to users that
 things are different, why do you need to mangle the upstream by
 adding material in there?

>> >Anyway, I was upstream project leader for most of the
>> > last year, up until about a week ago, when I stepped down in
>> > favor of someone more enthusiastic.  But I'm still an upstream
>> > developer.

>> That is quite irrelevant.

> Actually, I agree.  I think the fact that I can solve "the problem"
> by sticking the tarball I made on the upstream website at any moment
> I choose is, or should be, irrelevant.  I think the tarball I
> created should be acceptable in any case.  I think it's quite clear
> what I created, and I don't think there's any intent to confuse our
> users, and I think that should be sufficient.

Just because you can fix the situation by retroactively
 modifying upstream does not alter the fact that you have chosen to
 add material to a file you call orig.tar.gz , which, I think,
 violates at least the principle of least surprise.

manoj
-- 
The test of intelligent tinkering is to save all the parts. Aldo
Leopold
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy

[Henning Makholm]

Scripsit Joachim Breitner <[EMAIL PROTECTED]>

> I think this is should be done, or any other way that clearly marks
> the .tar.gz as modified (even if only files are removed, it is a
> modification). Anyone downloading a .orig.tar.gz file from debian should
> be able to safely assume that it really is the "original .tar.gz".

In general, you can assume that if it unpacks to a directory called
-.orig, then it has been touched by the Debian
maintainer. The new section ought to increase the chance that this
only happens if the Debian maintainer has actually done something
to the upstream source, but previously many maintainers (including me)
have repackaged source without changing any files simply because we
had the misunderstanding that repackaging was the Right Thing to do.

> I think there should be no justification or similar in there, the file
> should be as short as possible.

If we put an explanation at all into the .orig.tar.gz, I cannot see
any reason not to put a rationale in the explanation. It need not be
long:

  Removed the files
doc/manual.texi
examples/frizbotx/*
  due to licensing problems. See the thread at
   for
  further discussion.
A. Maintainer <[EMAIL PROTECTED]>, Sat Feb 26 22:31:21 GMT 2005

-- 
Henning Makholm "We're trying to get it into the
parts per billion range, but no luck still."

Re: Is membership in staff supposed to imply root access?

[Rob Browning]

Santiago Vila <[EMAIL PROTECTED]> writes:

> We have had /usr/local directories in the PATH for root at least
> since 1995 (by looking at the "base" package version 1.1.0-13).

Ahh, thanks.  I haven't been depending on it either way (I'd have
checked otherwise), so it's not a big deal.  I'm not sure where I got
the idea things were otherwise.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4

Bug#279281: ITP: e16menuedit2 -- A graphical menu editor for enlightenment

[jbernard]

Package: wnpp
Severity: wishlist


* Package name: e16menuedit2
  Version : 0.0.1
  Upstream Author : Andreas Volz <[EMAIL PROTECTED]>
* URL : http://www.enlightenment.org/
* License : MIT
  Description : A graphical menu editor for enlightenment

e16menuedit2 is a graphical menu editor for the enlightenment window
manager written in C and GTK+. You can create and modify single menu
entries as well as submenus. This package offers several enhancements
over e16menuedit as well as support for GTK2.

-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.9
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

fftw3 needs testing on K6

[Paul Brossier]

Hi all,

fftw3 needs testing on AMD K6. The solution suggested by the upstream
authors is available at http://piem.org/~piem/debian/fftw3/ .  it would
be nice if a K6 owner could reproduce the bug (for instance running
jamin with fftw3 3.0.1-10) and then try again using the above version.
Please CC your reports to [EMAIL PROTECTED] 

Many thanks, piem

Minutes fo DebConf5 IRC meeting of 20041101 at 20:00 UTC

[Anibal Monsalve Salazar]

Hello,

The minutes were done by Lars Wirzenius and are at:

http://wiki.debian.net/index.cgi?DebConf5Meeting20041101

The logs of the meetings are at:

http://www-personal.monash.edu.au/~anibal/debconf5-20041101.html

The web page above have links that you can follow.

There were about 20 nicks present at #debconf-team during the meeting.

Anibal Monsalve Salazar
--
 .''`. Debian GNU/Linux  |
: :' : Free Operating System | http://www.debiancolombia.org/
`. `'  http://debian.org/| http://www-personal.monash.edu/~anibal
  `-


signature.asc
Description: Digital signature

Re: Bug#277766: ITP: moniwiki -- MoniWiki is yet another WikiEngine written in PHP. It is fast, light and easy to install. Also it has many enhanced and new features. Moni is slightly modified sound which means What? or What is it? in Korean. The nam

[êêí]

On Mon, 01 Nov 2004 14:38:20 +0100, Tollef Fog Heen <[EMAIL PROTECTED]> wrote:
> * Ki-Heon Kim
> 
> |   Description : MoniWiki is yet another WikiEngine written in PHP. It 
> is fast, light and easy to install. Also it has many enhanced and new 
> features. Moni is slightly modified sound which means What? or What is it? in 
> Korean. The name also indicates that MoniWiki is nearly compatible with the 
> MoinMoin. MoniWiki WikiFormattingRules were inspired and adopted from 
> MoinMoin. Check MoniWikiFeatures to see what MoniWiki has to offer.
> 
> Does it have problems with line breaks?
No, I had a mistake. :-)

Regards,

Ki-Heon
> 
> --
> Tollef Fog Heen,''`.
> UNIX is user friendly, it's just picky about who its friends are  : :' :
>   `. `'
> `-
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 
>

retitle 264107 ITA: dia2code -- a dia-UML code generator

[pagarcia]

retitle 264107 ITA: dia2code -- a dia-UML code generator

I'm looking for a sponsor for this package.  It's available at
.

Thanks,
Polkan Garcia
-- 
Debian Hint #19: If you're interested in building packages from source, you
should consider installing the apt-src package.


signature.asc
Description: Digital signature