Re: Documentation for new maintainers

[Adam Di Carlo]

[Two in one here]

In article <[EMAIL PROTECTED]>, "Buddha M.D. Buck" <[EMAIL PROTECTED]> writes:
> I don't think it's really a wasted effort.  There is a lot of
> information there, most of it is FAQ-material.  Probably half of the
> questions asked in debian-mentors could be answered by it.  Spread
> out all over the place makes it hard to find.  I know that -I- would
> be helped by it.

Well, sure.  But creating new documents is going to spread it out more.

I suggest (a) volunteer to help the FAQ-O-Matic
  (b) volunteer to help with the new install doco for slink
  (c) join  and ask how you can help
  (d) check out DDP - http://www.debian.org/~elphick/ddp/index.html

In article <[EMAIL PROTECTED]>, Stephane Bortzmeyer <[EMAIL PROTECTED]> writes:
> On Friday 30 October 1998, at 20 h 52, the keyboard of Raphael
> Hertzog <[EMAIL PROTECTED]> wrote:

>> as we speak about new-maintainers problems, I think a document
>> intented for them could be helpful. I'll write something as soon as
>> I can.

> Good idea. As several people mentioned there *are* documents but
> most of them are out of date and the maintainers does not seem very
> reactive (overloaded, fed up, I don't know).

Well, someone is gung ho today, but will the be around in 2 years?
No?  Then we have more stale, unmaintained documentation.

Documentation is a process, not a product.  You have to build
consensus and work on something that other people will help you on,
and read, and contribute to.

> It clearly a dark area of the Debian project.

I agree, although I would say that there's a general problem of Free
documentation.  Can hackers document well?

> The maintainers feel under attack when there is a criticism about it
> but it's true.

Well, the most frustrating thing is (a) complaints with no action, or
(b) claims that someone is going to write something then no delivery
(I'm as guilty here as the next)

> I would advise new developers to do not trust documents in
>  apart from the Policy Manual and the
> Developers Reference. Most of them should be removed from the
> Developer's Corner.

Go to the DDP pages.  Adopt a document!  Learn CVS and SGML; hell, it
might land you a job in "document engineering" while you're at it.

BTW, IMHO, the best place to start for new maintainer documentation
might be Jaldhar H. Vyas's rather aborted but nice effort (but in
HTML, blech) at http://va.debian.org/~jaldhar/.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Maintaining a non-US package?

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, Chris Leishman <[EMAIL PROTECTED]> writes:
> On Wed, Nov 04, 1998 at 11:14:48PM +1100, Hamish Moffatt wrote:
>> On Sat, Oct 31, 1998 at 06:48:51PM +1100, Chris Leishman wrote: >
>> The postinst modifies the /etc/exports file to add a 2 lines as
>> follows
>> 
>> I don't know about /crypt etc; obviously the FSSTND/FHS doesn't
>> exactly say anything about it. But modifying another package's
>> configuration files (ie /etc/exports) is not allowed.
>> 
>> Unless the nfs-server package provides a mechanism for you to add
>> stuff to /etc/exports, you have to let the user do it.

> Hmm...thats annoying (but probably reasonable).  I would, however,
> like to make the installation as transparent as possible, without
> complicating the matter with making the user add stuff by hand (and
> having to explain why).  The major problem in this case is that the
> package relies very, very heavily on the nfs system, and won't work
> without a dummy entry in there

> Is it reasonable to prompt the user and ask if they would like it
> added (and removed at postinst)?  Or is that still bad?

Yes, unfortunately.  You could make an /etc/exports.cfs file, and tell
the user to move that into place.  Or work with the nfs server
maintainers to work out a way to add/remove export programmatically.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: reverse dependencies for packages

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, James Troup <[EMAIL PROTECTED]> writes:

> Matthias Klose <[EMAIL PROTECTED]> writes:
>> I would like to know on which given package other packages depend.
>> (yes, this has been posted somewhere last month, but I cannot find
>> this)

> pkg-revdep from pkg-order.

Or:

<[EMAIL PROTECTED]:doc> apt-cache showpkg /var/cache/apt/pkgcache.bin hello
Package: hello
Versions: 1.3-14.3,
Reverse Depends: 
  hello-debhelper,hello
  hello-debhelper,hello
  hello-debmake,hello
Dependencies: 
1.3-14.3 - libc6 (0 (null)) 
Provides: 
1.3-14.3 - 

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: NMU: Incompatibility between dpkg-dev and developers-reference

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, John Lapeyre <[EMAIL PROTECTED]> writes:

> On 29 Oct 1998, James Troup wrote:
james> Martin Schulze <[EMAIL PROTECTED]> writes:
james> 
james> > Any help/patch/comments?
james> 
james> Help: Simply upload the orig.tar.gz manually.
james> 
james> No, that's plain wrong.  If you do that the .changes file won't
james> list it.  Instead pass `-sa' to dpkg-buildpackage(1).

>   Well I uploaded them by hand for a while, and the install
> script looks and finds it even if it isn't in the changes
> file. (Still it should be documented). 

Good call; I added this just now to devel-ref "5.5 Interim releases".

> I switched to fakeroot
> dpkg-buildpackage -sa a while ago and have not had any problems.  It
> seems that I get an automatic complaint about missing source, even
> if the source has not changed. So I just upload it every time.

Yes, if you can't have a md5sum'd upstream source in your changes,
dinstall will properly ignore it.  And a good thing, too!

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Beginners problem with cvs-buildpackage

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Hi, Eeek. I do not actually test the scripts for remote CVS
> operation (and I haven't done so for months now), since I have a
> local repository. Could you please do a bash -x /usr/bin/cvs-*
>  and see if you can exactly where things are failing? A
> script showing the errors would be nice.

Manoj, you're getting forgetful.

This seems to be a cvs bug.  See
http://www.debian.org/Bugs/db/24/24585.html.  IN case you're lazy, the
output is below showing the bug. *sigh* I wish the cvs maintainer
wasn't such a slacker.

Maybe you could work around it.  cvs-buildpackage has never worked for
me, BTW, on client/server CVS.

Manoj, I'd be happy to point you to my CVS area there and you could
see for yourself.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

<[EMAIL PROTECTED]:developers-reference> echo $CVSROOT
:ext:[EMAIL PROTECTED]:/cvs/debian-doc
<[EMAIL PROTECTED]:developers-reference> pwd
/home/apharris/debian/developers-reference
<[EMAIL PROTECTED]:developers-reference> ls
CVS   historic
developers-reference  typescript
<[EMAIL PROTECTED]:developers-reference> cvs -q export -d 
/home/apharris/debian/developers-reference/developers-reference-2.4.1.3 -r 
debian_version_2_4_1_3 developers-reference
cvs [export aborted]: cannot make directory : No such file or directory
<[EMAIL PROTECTED]:developers-reference> cvs -q export -d 
developers-reference-2.4.1.3 -r debian_version_2_4_1_3 developers-reference
U developers-reference-2.4.1.3/developers-reference.desc
U developers-reference-2.4.1.3/developers-reference.sgml

Re: keyword=value in debian/changelog

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, Martin Schulze <[EMAIL PROTECTED]> writes:
> Rafael Laboissiere wrote:
>> > "MS" == Martin Schulze <[EMAIL PROTECTED]>
>> writes:
>> 
MS> Uff.  What name would you propose?  I will consist of four
MS> dpkg-divert statements.
>>
MS> All files are found at
MS> ftp://ftp.infodrom.north.de/pub/people/joey/auto-close-dpkg/
>>  You have already a name: auto-close-dpkg.  What is wrong with it?

> I don't feel it's appropriate, and all others I was thinking of were
> even more unappropriate.

How about "waiting-for-guydot" ?  (Bad literary pun, sorry).

Honestly, it might be better to make patches on dinstall than to
packge this bad boy, clever as it is.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: stupid question...

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, Mitch Blevins <[EMAIL PROTECTED]> writes:
> For an X-based graphical system administration utility (i.e. -
> gtksamba),

> where goes the binary?  /usr/sbin?  /usr/X11R6/bin?

There's a lot of dispute on this one.  I would say, /usr/sbin .

> where goes the man page?  /usr/man/man8?  /usr/X11R6/man/man1?
> /usr/X11R6/man/man8?

That would be /usr/man/man8

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: netscape's .deb package

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, Hubert Weikert <[EMAIL PROTECTED]> writes:
> IMHO the prefered way to install netscape communicator is:

...

My preferred way is to use Adam Heath's non-installer packages!

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Closing bug report when bug remains in stable?

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, Joel Rosdahl <[EMAIL PROTECTED]> writes:
> [Please CC: replies to me.]  Hi,

> I've got the impression that it's customary to close bug reports as
> soon as a fixed version of the package in question is available on
> the ftp site.  However, this hides the problem in the stable
> distribution, especially when the closed bug has been cleaned out
> (after some 28 days).  When another person detects the bug, {s,}he
> (hopefully) will file a new bug report on the same subject, et c.
> In some way, I want it to be clear that the problem exists in the
> stable version of the package.  So:

> How do I accomplish that?  (Do I?)

You don't, really, unless it's a security bug.  Generally, we don't
fix bugs in stable releases unless the are crippling or they are
security problems.  I know it can be frustrating, but as long as we
have release cycles which are pretty short (i.e., 6 months, rather
than 18) it's really the best way.

I know there are some who like to re-engineer the release process
entirely so proven good versions of packages trickle into stable.
However, I don't know when or whether this will happen.

> When will "hamm-fixed" (or whatever it will be called) be created,
> and who decides what it will include?

We have 'stable-updates'.  Read the developer's reference.

The decision is made by the archive maintainers.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Source code location?

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Julian Gilbey) writes:

> I am trying to repackage a new upstream Stanford GraphBase (sgb).  I
> would like to include the source code in the .deb package, as the
> value of the included programs is really as a demonstration of what
> the library code can do (libgb), and the documentation of the
> library is in its literate source code.

Hmm. Interesting.  So how do you use it?  You *extend* the library?
Or you just read about it? ;)

> So here's the question: where do I place the CWEB source code?  Do I
> put it in:

>  o /usr/share/sgb although the use of /usr/share is not particularly
> well documented, or

It's documented in the FHS standard,
http://www.pathname.com/fhs/>, which is not officially sanctioned
by policy, but, nevertheless, is the right place for architecture
independant *data* files (or scripts).

>  o /usr/lib/sgb, especially as /usr/lib/sgb/data is where the
> datasets for the library are stored, or

>  o /usr/doc/sgb/examples, since they are somewhere between examples
> and the documentation?

> My gut feeling is to go for /usr/lib/sgb, but I would like advice
> before I proceed.

My gut feeling would be under /usr/doc/sgb/examples, I suppose.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Source code location?

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Julian Gilbey) writes:
>[Me]
>> Hmm. Interesting.  So how do you use it?  You *extend* the library?
>> Or you just read about it? ;)

> You use the library as any library by linking it to your code.
> However, imagine if some library had no independent documentation
> other than well documented source code.  And I mean SO well
> documented that it's a pleasure to read, and even enjoy.  That's
> what the SGB library is like.  (In fact, it's so readable that it's
> been published as a book.  Being written in CWEB means that you can
> create TeXable output from the source code, which can be
> pretty-printed.)

Yes, I'm familiar with the concept of literate programming.  Nice to
see a nice real world example.  My *practical* objection w/ literate
programming is that programmers generally don't write the best
documentation. ;)

>> My gut feeling would be under /usr/doc/sgb/examples, I suppose.

> OK, I'll go for that, thanks.  Would it be out of order to include a
> symlink /usr/doc/sgb/src -> /usr/doc/sgb/examples?  I hope not.

Sounds good to me... why not!

Also, another ok suggestion: /usr/src/sgb, and symlink
/usr/doc/sgb/src -> ../../src/sgb

It really come down to the "principle of least suprise".

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: My vanity Web page on Debian

[Adam Di Carlo]

"Raphael" == Raphael Hertzog <[EMAIL PROTECTED]> writes:
> Le Tue, Nov 17, 1998 at 11:34:06AM +0100, Stephane Bortzmeyer
> écrivait:
>> Is there a policy about developer's Web pages? I saw that I can put
>> pages on master and they are available as
>> http://master.debian.org/~bortz. But I would like them to be on
>> www.debian.org (specially since master is not intended as a
> We just talked about it on debian-private ! You can use it for
> debian specific purpose or for any (free) software you maintain and
> for which you need a web page. For other purpose, you should ask on
> debian-private.

>> I observed that some developers publish URLs on www.debian.org. Is
>> this reserved to some people? If not, where are the instructions on
>> how to do it, with just my regular account on master?

> No, just install the web pages ~/public_html on va.debian.org (not
> master).

Need I even add that this is all covered in the Developer's
Reference?

Stephen, you're other issue about 'frozen' is covered there too, in
great detail.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: correct location for (java) jar files

[Adam Di Carlo]

"Allan" == Allan M Wind <[EMAIL PROTECTED]> writes:
> What is the correct location for (java) jar files?  /usr/lib/java
> /usr/share/lib/java

> Or something else?

> It would (also?) be useful to have a $DIR with symlinks from other
> locations, say: /usr/lib/jdk1.1/lib -> $DIR for building correct and
> up-to-date CLASSPATH's (jdk1.2 for instance).

Alan, a *very* good question.  I would look at other Java packages and
maybe join .  There are people there who
are trying to define a coherent CLASSPATH management system.

If you're developing Java on Debian, roll up yer sleeves, join
, and get to work! ;)

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: xwatch package done

[Adam Di Carlo]

"Peter" == Peter S Galbraith <[EMAIL PROTECTED]> writes:
> I wrote:

>> I'd be pleased if someone could take a look at my xwatch package in
>> ~psg/ on master.  I'll upload it only after I get blessing, since
>> it's my first package.

> One glitch I'm aware of is that I'm still using hamm, so may not
> have the `appropriate' compiling environment for unstable.

> If that's the case, perhaps people can tell what C packages should
> be upgraded (I want to wait until slink is stable and then get it on
> CD before I upgrade the whole thing.  I work on this machine and
> need stability)

Slink is frozen and quite stable. I recommend you upgrade your box
before uploading.  Or buy another disk and install an alternate slink
installation, or another box!  You might be able to get away with just
upgrading dpkg, libc6, and xlib6g (and -dev for all these) packages.
Or, if you're really lazy, just have someone with an up-to-date slink
system test it pretty hard for you.

You depend on XForms.  Two points: xforms 0.88 is out.  Also, you
cannot put this package in 'main' since it depends on XForms, which is
non-free.  The best you can hope for is contrib.  See Debian Policy
for details.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Source in upload?

[Adam Di Carlo]

"Mitch" == Mitch Blevins <[EMAIL PROTECTED]> writes:
> James Troup wrote:
>> Yep. `-sa' to dpkg-buildpackage is your friend.  See the fine
>> manual for more details.

> =20 Very good, thanks.  This will help me to avoid this problem in
> the future.  For now, do I just manually upload the *.orig.tar.gz?

Nope.  The .changes file, PGP-signed, must contain a line for the
.orig.tar.gz as well as a proper MD5sum, or the .orig.tar.gz file will
not get picked up.  And thank god, otherwise we'd have a gaping
security hole.

Just rebuild with 'dpkg-buildpackage -sa ...' as James pointed out.
No way around it.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

debmake radically breaks Debian Policy -- other pkgs conffiles

[Adam Di Carlo]

Package: debmake
Version: 3.5.15
Severity: normal

debmake is guilty of allowing, indeed, seeming to encourage packages
to modify the conffiles of other packages.

>From Policy v. 2.5.0.0:

  Only packages that are tagged conflicting with each other may specify
  the same file as conffile. A package may not modify a configuration
  file of another package.

>From /usr/bin/debstd, line 299:

  # etc files that could need some tweaking
  for i in services inittab crontab protocols profile shells rpc shells \
syslog.conf conf.modules modules aliases \
X11/Xresources X11/config X11/window-managers X11/xinit ; do
if [ -f $3$i ]; then
  FILEX="$i"
  cat /usr/lib/deb-make/etc.first.postinst $3$i \
/usr/lib/deb-make/etc.last.postinst | addscript postinst
  addscript postrm From /usr/lib/deb-make/etc.first.postinst

  # etc file modification generated by debmake #DATE#
  if ! grep -q '#-- #PACKAGE# begin' /etc/#FILE#; then
cat >>/etc/#FILE# 

--- Begin Message ---
Raphael Hertzog wrote:
> Why not, but why does debstd provide the possibilitry of modifying :
> - /etc/aliases
> - /etc/syslog.conf
> - /etc/inetd.conf
> - /etc/services
> - /etc/inittab
> - /etc/protocols
> - /etc/profile
> - /etc/modules
> - /etc/X11/window-managers
> - probably some others
> 
> It seems to me unlogical since debstd should help the developers
> to follow the Debian Policy... Should we consider that debstd is out of 
> date ?

It was written before it was against policy to modify conffiles, and it is
not being kept up to date with policy. If you want a policy complient
debstd, install debhelper and use dh_debstd (or just use debhelper ;-).

-- 
see shy jo


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



--- End Message ---

Re: package in frozen with a grave bug

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, Ben Collins <[EMAIL PROTECTED]> writes:
> I just started maintaining the 'chos' package which had a grave bug
> report filed against it
> (http://www.debian.org/Bugs/db/29/29223.html) in the slink
> distribution. The bug can cause severe super block curruption and
> loss of data. I upgraded the the upstream source to a newer version
> to fix the problem (and several others) and also changed a few other
> things in order to fix another bug and generally make the package a
> little more tidy.

> Question: should i still upload the package to frozen or just let
> the package get pulled from slink since it may introduce more bugs
> (more meaning the newer source may have other undocumented bugs)?

I'm feeling conservative today so I'd say upload new version to
unstable (potato) and file a bug to have it removed from frozen
(slink).  I guess it kinda depends on how many people are going to be
upset of slink doesn't ship with the package.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: libtool

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, Hamish Moffatt <[EMAIL PROTECTED]> writes:
> On Sat, Nov 21, 1998 at 02:14:36PM +1100, Hamish Moffatt wrote:
>> I've just encountered libtool and the dreaded -rpath. How do I fix
>> it so that it doesn't do it?
>> 
>> There is a top level ./libtool script, and one of the
>> subdirectories's Makefile.in specifies a -rpath parameter to
>> libtool. When I removed the -rpath and the parameter in the
>> Makefile.in, libtool complained that -rpath wasn't specified.

> Found /usr/doc/lintian/libtool-workarounds.txt, trying it now.

Hamish, if you feel heroic, try to find a clean way to patch the
source and talk to the upstream maintainer about including it.  But
please be careful, read about the libtool history with this issue
(info on the libtool web page), etc.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Non-maintainer release

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Rainer Dorsch) writes:

> What is the right procedure to do a non-maintainer upstream release?
> I do not want to upload my non-maintainer debian packages to the
> Debian server, but potentially distribute them.

Yes, you still should follow NMU guidelines, including 'patch
minimly', and using an NMU revision number.

See:
http://www.debian.org/~elphick/manuals.html/developers-reference/index.html
especially Chapter 6.

> My major concern is
> that, if I am doing only a

>   dch -v  

> the comment is entered in changelog as it would be from the
> maintainer. Further my name should be clearly visible, when it comes
> to problems, to avoid that the original maintainer gets lots of bug
> reports.

Well, for one, it it does behave this way you should submit a bug.  I
don't use 'dch' (I use emacs) so I don't know...

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: dupload problem

[Adam Di Carlo]

In article <[EMAIL PROTECTED]@>, Nathan Sandver <[EMAIL PROTECTED]> writes:
> Hi.  I'm having a problem with dupload. I'm hoping someone on this
> list can help me. Does anyone have an explanation for this:

> darkland:~$ ps aux | grep dupload ares 21678 30.8 82.0 105720 51920
> 5 R 12:43 0:42 \ perl /usr/bin/dupload

> Eventually, I get this:

> darkland:~/src/guitar$ dupload --to master
> guitar_0.0.3-1_i386.changes Out of memory!  Segmentation fault

> I have a P133, 64MB physical ram, 120MB swap, and I'm running
> slink. Any ideas would be appreciated. Thanks.

Hmm.  Probably there's something malformed in your changes file which
is causing dupload to fail?  Try 'perl -d dupload --to master' to run
the script in the perl debugger.  Submit a bug.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: replacing packages

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, James LewisMoss <[EMAIL PROTECTED]> writes:
> OK I've deprecated the xemacs19 packages leaving only the xemacs20
> packages (the xemacs20-nomule package is equivalent to the xemacs19
> package and has newer el files, is more stable, and is faster to
> boot).

> OK so now the problem with disappearing packages has appeared.  Is
> there any way to make the xemacs20 packages replace the xemacs19
> packages in dselect (or whatever) so that the user doesn't have to
> think about it?  I'm guessing there isn't since I've seen similar
> discussions before, but before I tell this person there's not a lot
> I can do I wanted to check to make sure I was correct.

Replaces/conflicts is the best you can do.

Are you really sure this isn't good enough?  What about a user, lets
call him 'Jonam', which has 23 MB of emacs lisp tuned to xemacs19 ?

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Request for advisor

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, Dave Swegen <[EMAIL PROTECTED]> writes:

> As a new package maintainer I would very much appreciate it if some
> kind soul could take it upon them to occasionally put themselves
> through the traumatic and boring ordeal of answering dumb questions
> on the subject of packaging...The package I'm going to maintain is
> Xmahjongg, the tile-based solitaire game. TIA.
 
That's what this list is for.  If you want more interactive, try
#debian on the linpeople IRC network.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: xwatch package done

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, Peter S Galbraith <[EMAIL PROTECTED]> writes:
> Are developers _required_ to run unstable?  I know it makes a whole
> lot of sense for debugging purposes, otherwise it never get stable.
> But until I upgrade my PC at home that will be difficult to do.

Good question and we don't really have a clear answer yet.
I'll file it away for resolving as part of Developer's Reference.

>> You depend on XForms.  Two points: xforms 0.88 is out.

> It's incompatible with 0.88.  The package need a new upstream
> maintainer, preferably one that would port it to GTK (or other open
> source toolkit).
>> Also, you cannot put this package in 'main' since it depends on
>> XForms, which is non-free.  The best you can hope for is contrib.

> Oups.  Forgot to do that.  It is enough to edit the Section line in
> the control file to `Section: contrib/utils' ?

Yup.

> To upload it, all I have to do is move all files to the proper
> directory on master?  Or do I have to learn a new tool.

You can upload them manually or use dupload if you feel like it.
See dupload(1).

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

[old] follow w.r.t. french developers

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, Stephane Bortzmeyer <[EMAIL PROTECTED]> writes:
>> seriously tough, in the new maintainer doc it says that encrypting
>> is not per mitted in francebut signature yes ? does anyone know
>> something about it ?

> I do (I studied the law, I even asked for a formal authorization of
> PGP - refused - and I participated in several official hearings
> about it).

> The Debian documentation is misleading. It says that you *can* use
> cryptography in France for authentification. But the law says you
> can use only a program which *cannot* do anything else than
> authentification. Therefore, my formal appliance for a PGP clearance
> (signature only) was refused because "PGP can be used for other
> purposes". (PGP is not forbidden in France, you just have to request
> a clearance which is always refused.)

> So, people living in France are formally forbidden to participate to
> the Debian project. So much for the influence of France in the
> world.

> According to a recent discussion on debian-french, most french
> Debian packagers choose the following solution: thrice a week, they
> take a plane to a free country (Germany is the closest from you, you
> just have to cross the Rhine with your bicyle) with a floppy, they
> sign and upload the packages there and they come back to France
> after that.

As I understood it, if some developer in the free world had the
gumption to create a stripped down pgp 2.6.2i (or whatever) which
could only perform signing/verifying functions, and which had all the
crypto functions stipped out, then French developers could participate
freely in Debian.

Is there an effort to do with GPG?

Is this not done because no French people care about Debian? ;)
[Take that as a challenge...]

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Where to patch?

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, Bob Hilliard <[EMAIL PROTECTED]> writes:
>  When is the correct time to apply a patch to the upstream
> source?  I have a small patch to the source code of the dictd source
> code.  Of course, I am submitting it to the upstream author, and I
> hope he will incorporate it in the next version.  In the meantime I
> will apply the patch and upload a new version of the package.
> Should I modify debian/rules to apply the patch, or should I apply
> the patch to the source before building the package?

Having been forced to try to patch a tar.gz from within debian/rules
before for a package -- don't ask, and no, I don't have to do this
anymore -- I would suggest *not* patching source from debian/rules.
Consider that the debian/rules clean target would have to unpatch.
Consider whether everything is idempotent (i.e., you can run
'debian/rules clean' or 'debian/rules build' many times, in any
order).

It's just no worth it; use the functionality that is already there by
patching the source directly.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: [wnpp@debian.org: WNPP ACK: 19981201 t.landschoff@gmx.net]

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, Torsten Landschoff <[EMAIL PROTECTED]> writes:
> I mailed my intention to overtake linux-conio to [EMAIL PROTECTED] and
> I got the following reply:

[...]
> (You are assumed to be in the process of becoming a Debian Developer
> -- [EMAIL PROTECTED]: 19981201.)

[...] 

> But I am already registered as new maintainer. Is this normal or do
> I have to use my debian.org address for mails to [EMAIL PROTECTED]

Hmm.  Sounds like a little buglet in whatever scripts WNPP uses to
maintain the list.  I wouldn't worry about it.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: /var/state ?

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, Paul Slootman <[EMAIL PROTECTED]> writes:
> I've used /var/state, and I don't add anything to smb.conf
> automatically or ask anything during install.

Sounds good.

> However, if there was
> already a linpopup entry in smb.conf, but commented out, I re-enable
> it. On deinstallation I turn it into a comment, with an appropriate
> marker so that I can find it again. I feel that changing smb.conf on
> deinstallation is justified by the fact that otherwise error
> messages will appear in samba's logs.

No, changing smb.conf at all is a Policy violation.  You cannot touch
smb.conf (since it is a configuration file of another package) at all.
Sorry.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Why is "1" appended to package name?

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, Ossama Othman <[EMAIL PROTECTED]> writes:

> Hi, When I ran deb-make on my package source, it appended a "1" to
> the package name in debian/control, for example.  Why does deb-make
> do this?

BTW, while debmake is supported and does work, you probably want to be
using debhelper rather than debmake.

I know, our new maintainer documentation is out of date -- we're
working on that!

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: A few new-maintainer questions.

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, Manoj Srivastava <[EMAIL PROTECTED]> writes:
Zephaniah> This seems to come up a bit too often, hmm, perhaps
Zephaniah> something in the policy could help?

>   Develoeprs reference, maybe. This is not a policy issue.

*perk up*  Huh? What?   What are we talking about here?

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: new maintainer: upload to frozen?

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, "Stephen J. Carpenter" <[EMAIL PROTECTED]> 
writes:
> I would personally save the minor bug for unstable and if you really
> feel you need to change the maintainer field...just change that and
> re-upload with the text in the changelog reflecting that you are the
> new maintainer and nothing else.

Yeah, well, I don't really personally think it's worth it to reupload
to slink just to get a maintainer change in.  I bet it's a little
fuzzy in the developers-reference because it really doesn't matter one
way or another.  A frozen upload with just a maintainer name change
should be accepted, however, since it is "no new code", after all.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: converted config file ?

[Adam Di Carlo]

In article <[EMAIL PROTECTED]>, Christian Hammers <[EMAIL PROTECTED]> writes:
> Hi !  I have a problem with my wwwoffle package: it has a config
> file /etc/wwwoffle.conf.  When installing I try to convert existing
> config files with a shipped config file converter and only if that
> fails because it is the first install of wwwoffle, I copy the
> example conf file from the /usr/doc.

> The problem is now, that I have mark the /etc/wwwoffle.conf as
> "configfile" in the ./debian/conffiles file. But when building,
> dpkg complains that the named conffile is not there, what is quit
> right, since while shipping, the file isn't in /etc, but in
> /usr/doc...

> What should I do now ?  simply let dpkg handle the
> overwriting/not-installing of the config file and mark the file in
> debian/conffiles or did not mark it in debian/conffiles and let
> postinst handle the file.

> Both will earn me some bug reports :-)

Ain't that the truth ;).

Well, I would just ship your new conffile in the std location,
/etc/wwwoffle.conf or whatever, and not bother with this /usr/doc
stuff.  In the preinst, before that file is replaced, check if there's
an old-style configfile and if so, copy it to a safe location (i.e.,
/etc/wwwoffle.conf.old-style).  Then, in the postinst, check for this
old-style config file in /etc/wwwoffle.conf.old-style or whatever, and
(maybe interactively, maybe automatically) deal with that in a
reasonable way.

Most package maintainers actually don't manage to automatically
convert conffiles from old styles to new ones; it's a pain and has
hidden pitfalls.  Consider the problem of package downgrade then
upgrade again.  Can be tricky stuff.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: problem with ldconfig and packaging libs

[Adam Di Carlo]

"Ionutz" == Ionutz Borcoman <[EMAIL PROTECTED]> writes:
> Oscar Levi wrote:
>>  On Thu, Dec 17, 1998 at 06:22:47AM +0900, Ionutz Borcoman wrote: >
>> James Troup wrote: > > > > Ionutz Borcoman
>> <[EMAIL PROTECTED]> writes: > > > > > If I run this
>> as root, how can I sign the package, as my pgp key was > > >
>> created for my personal account.  > > > > sudo is your friend.  > >
>> sudo says > > Sorry, user borco is not allowed to execute
>> "/sbin/ldconfig" as root on > borco-ei.eng.hokudai.ac.jp.
>> 
>> Read up on it.  Check the /usr/doc/sudo directory and the man
>> pages.

> I have found a better solution, with no sudo at all. I have simply
> changed the ldconfig to:

> /sbin/ldconfig -n

> It seems to do what I want.

Yes; I think the other advice was rather bad.  Either you want to
build with fakeroot, or you can really become root using super or sudo
(not sure how those have to be setup, but).  I know some have problems
with fakeroot (or it's successor in potato, libtricks) but most
x86-based developers tend to prefer it.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: dev and dbg packages

[Adam Di Carlo]

"Ionutz" == Ionutz Borcoman <[EMAIL PROTECTED]> writes:
> Hi, I want to package the VDK libs. But I have to take a decission:
> how to make the dbg package.

First off, this is all described in the Packaging Manual.

> The VDK, if compiled with "-g -DVDKDEBUG" can provide additional
> information, like the activity of the garbage collector (gc),
> regardless of statically or dynamically linkage. Also, dynamically
> linking with these libs, I am still able to browse through the libs
> with ddd when debuging.

Well, actually, I think you're only confusing the issue with
'-DVDKDEBUG'.  -dbg is for versions of libraries which debugging
symbols exposed so that problems may be debugged.  Compiling with a
different define, at least in my opinion, lowers the usefulness of the
-dbg package since it's actually different (i.e., a bug for libfoo
might not show up in libfoo-dbg, since different *code* may be
included.).

> So please tell me what am I missing here (aka why debugging works
> also on shared libs) and how should I organise my packages:
> a. libvdk1: shared libs, no debug info
> libvdk-dev: include files, conflicts libvdk-dev, require libvdk1 
  ^^^
  dbg

Also, provide the .so link and the .a (static lib) -- see the
Packaging manual.

> libvdk-dbg: static libvdk.a
> with -g -DVDKDEBUG, conflicts libvdk-dbg, require libvdk-dev

Again, I would suggest not bothering with '-DVDKDEBUG'.

> or

> b. libvdk1: shared libs, no debug info libvdk-dev: include files
> libvdk-dbg: static AND SHARED libs with -g -DVDKDEBUG, conflicts
> with libvdk1, libvdk-dev, provides libvdk, libvdk-dev

Actually, I'm not sure whether the -dbg needs to generally conflict
with the -dev packages (I hope not), and or whether it generally
includes both shared and static versions with debugging info.

You'd have to check some other -dbg packages.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Rebuild process

[Adam Di Carlo]

"Dave" == Dave Swegen <[EMAIL PROTECTED]> writes:
> Thanks for the help...But just out of curiousity, is all this
> described all in one place somewhere? I don't like to think I was
> being completely blind...I was going to mail the bloke who is
> writing the new version of the deb new maintainers guide about it,
> as it is something that virtually every developer will come across.

Go to http://www.debian.org/~elphick/ddp/index.html> and follow
the link to the new maintainers guide.  Also read the Packaging Manual
and the Developers Reference.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Documentation directories

[Adam Di Carlo]

"Matthias" == Matthias Klose <[EMAIL PROTECTED]> writes:
> Is it allowed to use /usr/doc/, if no binary
> packages with the  exists? I don't see anything in
> the policy, which explicitely forbids this.

It can use that dir, but there must be at least a symlink for
/usr/doc// .

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: problem with ldconfig and packaging libs

[Adam Di Carlo]

"Oscar" == Oscar Levi <[EMAIL PROTECTED]> writes:
> On Thu, Dec 17, 1998 at 01:35:07AM -0500, Adam Di Carlo wrote:
>> Yes; I think the other advice was rather bad.

> Really.  That sounds like a jab.  Is there an ego needing a snack?

No, I don't think so.  Maybe I wasn't clear.  

It is bad advice for someone asking help about fakeroot to tell them
to also use sudo or super.  Pick one and one only.

> What is 'bad' about using sudo?  If I have a package that needs to
> be owned by root what is wrong with sudo?

> I'm not sure what is to like about fakeroot.  It lets me create a
> setuid root program without asking me if I want to grant this
> priviledge to my users.  At least sudo has a permission check.

If you even think that Linux itself will even *let* you do this, you
need to do a little RTM'ing.

fakeroot simple *pretends* it is creating files with an ownership of
root or what-have you. It doesn't actually do any such thing.  Try it.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: problem with ldconfig and packaging libs

[Adam Di Carlo]

"Oscar" == Oscar Levi <[EMAIL PROTECTED]> writes:
> On Thu, Dec 17, 1998 at 02:38:16AM -0500, Adam Di Carlo wrote:
>> It is bad advice for someone asking help about fakeroot to tell
>> them to also use sudo or super.  Pick one and one only.

> I read that he needed to have root priviledges as I have when
> creating packages.  I didn't see him asking for help with fakeroot.

I read that he had a problem with /usr/sbin not being on his path. ;)

> When I tried it, I saw it changing the permissions and ownership of
> my sample file.  On trying it again, it doesn't.  I'd guess I was in
> a root shell, but I remember trying to run the commands with and
> without fakeroot and seeing an error when I didn't.  Oh well.
> Fakeroot looks like a fine tool for avoiding permission denied
> errors.

Yes; well eveyone needs some level of 'root'ness when creating .debs,
since files in debs, by policy, should be owned by root.  fakeroot
lets you pretend a file is owned by root without bothering to su and
all that.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: problem with ldconfig and packaging libs

[Adam Di Carlo]

"Ionutz" == Ionutz Borcoman <[EMAIL PROTECTED]> writes:

> Ben Collins wrote:
>>  Sounds to me like you just need to run ldconfig as root one time
>> to update your ld.so.cache file. It should resolve your problem the
>> Right Way.
>> 
> I have a posinst that says:

> #!/bin/sh

> set -e

> ldconfig

> #DEBHELPER#

> Isn't this enough ? Installing the package and a program that
> depends on it worked OK so I have presumed that I have solved the
> problem. As you can install deb files only as root, the ldconfig is
> run at installation time as root. No need to run it at deb creation
> time. Am I missing something ?

No, you just need to be careful and to read the Packaging Manual,
where it says:

 Any package installing shared libraries in a directory that's listed
 in `/etc/ld.so.conf' or in one of the default library directories of
 ld.so (currently, these are `/usr/lib' and `/lib') must call ldconfig
 in its postinst script if and only if the first argument is
 `configure'. However, it is important not to call ldconfig in the
 postrm or preinst scripts in the case where the package is being
 upgraded (see section 6.3, `Details of unpack phase of installation or
 upgrade'), as ldconfig will see the temporary names that dpkg uses for
 the files while it is installing them and will make the shared library
 links point to them, just before dpkg continues the installation and
 removes the links!

You are running ldconfig at all times, which is downright incorrect.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: problem with ldconfig and packaging libs

[Adam Di Carlo]

"James" == James Troup <[EMAIL PROTECTED]> writes:
> Adam Di Carlo <[EMAIL PROTECTED]> writes:
>> It is bad advice for someone asking help about fakeroot to tell
>> them to also use sudo or super.  Pick one and one only.

> It's not bad advice.  I see fakeroot consistently causing problems
> for people
[...]
> So I'll continue to pimp sudo as long as people continue to have
> problems with fakeroot.  YMMV

James, you misread me.  I had not intention of debating the various
options here. I simply said that using fakeroot + {sudo|super} is
absurd.

This whole thread is absurd since the question was about someone
running ldconfig in debian/rules, which is a big nasty no-no as well,
and I can't think of a possible reason why it would be necessary.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: My `Section' and `Priority' lines have gone missing?

[Adam Di Carlo]

On Fri, 18 Dec 1998 17:05:17 +0100 (CET), Santiago Vila <[EMAIL PROTECTED]> 
said:
> Ok, I have just read the web page. It says:

>  * Creating a Package using Debmake (hopefully this and the
> following will be merged) Note: use of debmake is deprecated. Use
> debhelper instead. Once someone writes a debhelper tutorial, it will
> replace the debmake info on this page.

> Of course, I don't think this is 100% fair.

> In the first place, I would consider fundamentally wrong any "new
> maintainer's guide" or new maintainer's web page which tells
> *either* "use debmake" or "use debhelper".

Well, I agree.  Moreover, it's not really anyone's place to say, "this
packaging tool is bad", or "this one is good".  Any tool which helps
maintainers create pacakges which comply with our policies is good.  I
have problems with debmake, mostly because no-one has given a thorough
review of the source code with Policy compliance in mind.

> I hope noone will object if I ask the webmasters to replace that by
> the following:

> "Note: Many people seem to prefer debhelper over debmake. Once
> someone writes a debhelper tutorial, it will replace the debmake
> info on this page."

There is a debhelper-based tutorial, see the DDP pages.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: packaging on master/va

[Adam Di Carlo]

On Tue, 22 Dec 1998 12:38:21 +0100 (CET), Santiago Vila <[EMAIL PROTECTED]> 
said:
> Please, consider to sumbit a wishlist bug against
> developers-reference if this is not clearly stated there.

It is, but only in newer (unofficially released) versions.  I'm going
to actually have a whole chapter about porters, at the request of a
porter, which is really the only thing that needs doing for the next
developer's reference.

You can see the unreleased newer version at the DDP pages.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: is this a bashism?

[Adam Di Carlo]

On Mon, 21 Dec 1998 19:16:04 -0600, "Marcelo E. Magallon" <[EMAIL PROTECTED]> 
said:
> #!/bin/sh -e [ -x /usr/bin/update-menus ] && update-menus

>  I've got a bug report that says it is. Ash bails out with exit
> status 1 if update-menus doesn't exist.

This is irrelevant to you original question, but I really prefer to
use the POSIX 'command' command in order to determine whether an
executable exists on the path.  I feel it is problematic to hard-code
paths into scripts, and any way to avoid that is a good thing.

if command -v update-menus >/dev/null 2>&1;
then
update-menus
fi

I'm CC'ing the debhelper maintainer to see what he thinks, since he says:

   if [ -x /usr/bin/update-menus ] ; then update-menus ; fi

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: No upstream version, et al

[Adam Di Carlo]

On Tue, 29 Dec 1998 13:14:08 +0800, Anthony Wong <[EMAIL PROTECTED]> said:
> Hi Debian developers, I'm still very new in creating Debian
> packages, so here are two of my silly questions :)

> Q1: What should be the version of a package if the upstream source
> does not have a version number? Should I use yymmdd or mmdd as
> the version?

Clearly MMDD is better.  If the upstream maintainers might
eventually add version numbers, you could version it as 0.0.MMDD.

I think this is documented somewhere but I'm too lazy to find it.

> Q2: Currently I'm packaging a program that lets people install
> Newton programs to their PDA from Linux. As this program requires
> access permission to the serial ports, only root can use the program
> in normal condition. But I also want the program can be used by
> common users, so what should I do?  Just inform people to add users
> to the group 'dialout' in postinst?  Or suid/sgid the program?

Don't suid/sgid a program that wasn't written with that in mind.  The
fewer suid programs there are in Debian, the more secure it will be.

So just inform the users.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Becoming a new Developer

[Adam Di Carlo]

James Troup <[EMAIL PROTECTED]> writes:

> The phone calls do often cause delays. 

Isn't there some information I can add to the developer's reference
about (a) what time of day they should expect your call (GMT) and,
maybe (b) giving new-maintianer the right phone number or a couple of
numbers in case of, say, work and home number?

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Packages with symlinks and CVS

[Adam Di Carlo]

Julian Gilbey <[EMAIL PROTECTED]> writes:

> That's OK, except that this package currently has 258 symlinks, and
> both the number and details are likely to change on a fairly regular
> basis.  The thought of keeping that up to date is quite terrifying.
> There must surely be a better way?

No, not really.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: the place for file

[Adam Di Carlo]

Michael Sobolev <[EMAIL PROTECTED]> writes:

> I'm trying to create a small package for myself (for `local'
> part of the archive :)
> 
> The package consists of a script that processes an SGML-file and produces a
> HTML file.  The resulting file makes use of an external stylesheet I want to
> put into the package as well.  Where should I put this stylesheet?

/usr/lib/sgml/stylesheet/dsssl/...

Look at where I put stylesheets from docbook-stylesheet,
cyngus-stylesheet, etc.

Eventually we'll move from /usr/lib/ to the proper /usr/share
(sgml-base has to drive this).  There's no reason why you couldn't use
/usr/share/... if you wanted to though.  SGML_SEARCH_PATH doesn't
matter here.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Upload failure

[Adam Di Carlo]

Matt Kern <[EMAIL PROTECTED]> writes:

> The other day I uploaded OPIE to master, but somehow fscked up and
> uploaded
>   opie_2.32-1.tar.gz
> instead of 
>   opie_2.32.orig.tar.gz and
>   opie_2.32-1.diff.gz
> 
> How can I correct my earlier blunder?

Remove the files from Incoming or even Incoming/REJECT and re-upload
properly.

Also, you might take a look at stuff like dupload (described also in
the Developer's Reference, package developers-reference).

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: SSL & Non-SSL package from one source package

[Adam Di Carlo]

Shaleh <[EMAIL PROTECTED]> writes:

> On 16-May-99 Leon Breedt wrote:
> > Is it possible to do this?
> > 
> > I.e. have one source package build for both us & non-us? 
> > 
> 
> As long as I can tell it before package build to NOT build the non-us, yes. 
> Otherwise it could be illegal, immoral or whatever (-:

Actually, this really isn't a good idea.  Porters use automated build
tools.  Anything built by the binary-indep rule in debian/rules of the
source package will be built.

Just make it easy on yourself and porters -- upload to non-us only.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: the place for file

[Adam Di Carlo]

Michael Sobolev <[EMAIL PROTECTED]> writes:

> On Mon, May 17, 1999 at 11:19:58AM -0400, Adam Di Carlo wrote:
> > > The package consists of a script that processes an SGML-file and produces 
> > > a
> > > HTML file.  The resulting file makes use of an external stylesheet I want 
> > > to
> > > put into the package as well.  Where should I put this stylesheet?
> > 
> > /usr/lib/sgml/stylesheet/dsssl/...

> Hmm...  But the script I am talking about has nothing to do with DSSSL.  Is
> your advice still viable?

Oh, um, what is it?  /usr/lib/sgml/stylesheet/{css,xsl,dsssl}/
directories are all possibilities.  If it's something else entirely,
like PerlASP or what have you, generally folks either put it in
/usr/lib/sgml/misc/ or somewhere under /usr/share//.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Upload failure

[Adam Di Carlo]

Matt Kern <[EMAIL PROTECTED]> writes:

> On 17 May 1999, Adam Di Carlo wrote:
> > Matt Kern <[EMAIL PROTECTED]> writes:
> > > The other day I uploaded OPIE to master, but somehow fscked up and
> > > uploaded
> > >   opie_2.32-1.tar.gz
> > > instead of 
> > >   opie_2.32.orig.tar.gz and
> > >   opie_2.32-1.diff.gz
> > > 
> > > How can I correct my earlier blunder?
> > 
> > Remove the files from Incoming or even Incoming/REJECT and re-upload
> > properly.
> 
> Unfortunately, the upload was already processed.  I only noticed the error
> after it hit my local mirror.  I had previously built the source and diffs
> correctly, but somehow the one I built for upload was different :(

Oh I see.  It *is* easy to not notice that a package was for some
reason considered to be a Debian only package.  Of course, I use
cvs-buildpackage so it's a bit easier to control with that.

So what you need to do is release a -2 release, the changelog being
something like:

  * use pristine upstream source

Since this is -2, dpkg-buildpackage needs the '-sa' switch, so that it
will be forced to re-upload the upstream tarball.

Ok?

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: the place for file

[Adam Di Carlo]

E O Fredrik Liljegren <[EMAIL PROTECTED]> writes:
> Hmm. I have a related question.. I have dtd's in xml.. I guess they
> according to this system should be put under /usr/lib/xml/dtd/ with a
> soft link from /usr/lib/xml/eduml/dtd/ (eduml is what the dtd is for)?
> 
> Could I put them udner /usr/share/ instead maybe?

Unfortunately, not yet.  See the info in /usr/doc/sgml-base.  It
should go in /usr/lib/sgml/dtd (will be changed to /usr/share/sgml/dtd
soon).

For XML dtds, it's pretty important to retain the upstream file name.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Should I create a group jazip

[Adam Di Carlo]

Peter S Galbraith <[EMAIL PROTECTED]> writes:

> The question is:
> 
>  Do I leave this as it is,
>  or do I create the jazip group in the package installation?
> 
> Policy says that I should create a Dynamically allocated system
> group (range 100-999) using adduser --system after checking with
> the base system maintainer (that would be base-passwd?) and
> debian-devel.
> 
> If I do this, I don't really need the user ID, but only the group.
> Can I use addgroup instead?

This is a very good question.  I think its a bug in policy that there
is no procedure identified for the creation of groups by packages...

In this case I might suggest that you just re-use the floppy group,
however.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: multiple OS partitions

[Adam Di Carlo]

Bob Nielsen <[EMAIL PROTECTED]> writes:

> On Wed, May 19, 1999 at 12:27:53AM -0400, Rod wrote:
> > i have installed redhat 5.1 on another machine and understand that Linux
> > names drives differently than Windows/Dos, my question here is how will
> > Debian GNU/Linux "see" my single HD with multiple partitions, how will I
> > insure myself that I install on the right partition?
> > 
> > Will hda be my first partition or will it be the first partition on my
> > Linux "disk"?
> 
> Your drive will be /dev/hda.  On this there will be several partitions,
> hda1, hda2, etc.  When you run Linux fdisk, it will show all the
> partitions and any empty space (in which you can create new partitions).
> If the entire disk is already partitioned, you will need to remove some
> partitions to leave raw disk space for Linux to partition and install
> unto. 

This is all described in detail in the Installation Manual, Sec 4.3,
"Device Names in Linux".

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: level of policy

[Adam Di Carlo]

Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> writes:

> On Tue, May 25, 1999 at 10:12:12PM +0200, Andrea Fanfani wrote:
> > Standards-Version: 2.4.0.0
> > 
> > How i can upgrade the level of policy on my distribution.
> 
> Check that your package meets the newer policy requirements and then
> manually upgrade the Standards-Version.

BTW, I recommend simply using the first 3 significant numbers, i.e.,
2.4.0 or 2.5.1 (the newest).  The last digit is just for grammatical
fixes, and should never require actual changes in packages.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: PRCS users

[Adam Di Carlo]

Rafael Laboissiere <[EMAIL PROTECTED]> writes:

> I finally found time to upload an upgraded prcs package.  I did mass
> bug-hunting, closing seven of them.  I hope that I did not introduce even
> more than that with my fixes!

Well, I hope your mailing patches for fixes upstream...

> I am actually writing to tell that I decided on my own to split the package
> into prcs and prcs-el, the second containing ELisp support and an explicity
> dependency on the virtual package emacsen.  I am afraid I have had to
> discuss that in this mailing list before doing the actual upload.

Why?  You don't have to discuss anything to *use* a virtual package;
you have to discuss it if you wanna *create* a virtual package.

> Anyway,
> the new version (1.2.14-1) is already in the incoming directory of master.

Cool... ever thought about prcs-buildpackage, a la cvs-buildpackage?

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: New developer (some day)

[Adam Di Carlo]

LEBLANC ERIC <[EMAIL PROTECTED]> writes:

> > I've applied to become a developer, but I read that the backlog is
> > rather long, so I have a couple of questions.

I'm not really sure that this is true.  My reports are pretty
consistent -- it takes anywhere from 2 weeks to 6 months.  The latter
is more likely if you don't strictly follow the directions in the
developers-reference and/or instructions sent by new maintainers.

Anyhow, good luck -- there's no reason to put off the application...

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: source of dbotstrap

[Adam Di Carlo]

Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> writes:

> On Fri, Jun 11, 1999 at 09:44:25AM +0200, Nicolas LAURENT wrote:
> > where could i find sources of 'dbootstrap' ?

> The boot-floppies package is what you're looking for.

Yes -- if you wanna help develop that -- and help is much needed, go
run and offer at .

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: data and config file placement

[Adam Di Carlo]

John Travers <[EMAIL PROTECTED]> writes:

> I have just started to package nightfall (an astronomy application)
> and when I run lintian everything is fine except I get a load of:
> 
> W: nightfall: executable-not-elf-or-script 
> usr/share/nightfall/doc/C/Introduction.html

Shouldn't this be in /usr/doc/nightfall ?

> 1) how do I make these non executable.?

chmod a-x 

> 2) how can I put the config (cfg) files in /etc/hightfall (the
> package uses a confgure script, but I can't specify the config file
> dir), prehaps symlinks --> how would I do this?

You can definately make a symlink.  For instance, supposing the
program expects /usr/share/nightfall/config/*, and you wanna use
/etc/nightfall/*, just install/move the config files into
/etc/nightfall/, and make a symlink from /usr/share/nightfall/config
-> /etc/nightfall.  If you don't know how to do that, you really need
to step back and bone up on Unix a bit... :)

You can also mention your need to the upstream maintainer -- maybe he
and you could work on enabling the configdir options (--sysconfigdir I
think in autoconf).

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: data and config file placement

[Adam Di Carlo]

John Travers <[EMAIL PROTECTED]> writes:

> On Sat, 12 Jun 1999, Adam Di Carlo wrote:
> > John Travers <[EMAIL PROTECTED]> writes:
> > > 1) how do I make these non executable.?

> > chmod a-x 

> I know how to do it manually! How do I do it in the debian/rules script?

Just give the right chmod command after the files have been installed
under debian/tmp or whatever.  Look at other debian/rules files if
you're confused.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: New Convert From Win--need some help

[Adam Di Carlo]

"Jeremy W." <[EMAIL PROTECTED]> writes:

>   My new system, which I'll describe later in detail to see if
> there are any compatibility inconsistencies, is being shipped to me,
> and my intent it to put the Debian distribution on it, as I've heard
> it's probably the best (though not most user-friendly)
> distribution. First, however, I'd like to ask a few questions.

Well, first off, welcome to Debian.  Secondly, you are emailing this
question to the wrong list.  I believe you want debian-user.  Thirdly,
admittedly installation of Debian is much harder than it ought to be.

> 1: How easy is it to install, and where can I find complete installation
> instructions?

http://www.debian.org/releases/stable/

> 3: Is there an included boot manager (gotta have win for my games :-)?

Of course.

> 4: Is this (below) hardware supported, or where can I find a list that will
> tell me if it is?

Linux Hardware howto, also see the installation manual.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: purging files that may be important

[Adam Di Carlo]

Gus <[EMAIL PROTECTED]> writes:

> after a "remove", i no longer run the checker, so no new messages will 
> be quarantined - should i also stop running the cron script or is it
> a good idea to continue removing old messages?

Probably you should check if the pkg is in remove state and exit early
from the cron script if so.  Actually, it could go either way, because
I could see why you would want to continue to reap old quarantined
message even if the pkg is removed

> on a "purge", should i remove this directory (and any quarantined
> messages), or should i leave them and rely on the admin noticing the
> "not empty so not removing directory" message from dpkg?
> 
> (i was going to have the postrm ask, but i'd rather avoid requiring
> interaction)
> 
> i'm thinking the best solution is to not remove the files, and echo a
> message saying that i'm not  (principle of least surprise)

Yes, sounds right.  Removing them seems like possible data loss for
the user.  YOu might even prompt for whether the quarantined msgs
ought to be removed?

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: [BOOT-FLOPPIES]: where is kernel-image-$(kver)-scsimod_*.deb?

[Adam Di Carlo]

Nicolas LAURENT <[EMAIL PROTECTED]> writes:

> where can i find kernel-image-$(kver)-scsimod_*.deb?

> (I work on boot-floppies package)

I don't know -- can you subscribe to the rather low volume debian-boot
list and ask there?

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: rejected changes

[Adam Di Carlo]

Alexander Shinn <[EMAIL PROTECTED]> writes:

> I must have modified something for the first package.  So
> I edited the .changes file to include the .orig.tar.gz file, and re-ran
> dupload, then logged in and deleted the files in rejected.

Unless you are very wizardly, hand-editing .changes files are just
going to get your packages rejected.  Remember this file is PGP
signed.

If you want to upload the .orig.tar.gz file again with a package, but
dpkg-buildpackage (or whatever you are using to build your packages)
isn't including it, you need the -sa switch (always include source).

This is well documented in many standard debian devel manuals.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Again: where to put -doc packages ?

[Adam Di Carlo]

Christian Hammers <[EMAIL PROTECTED]> writes:

> [one last try, because nobody answered me]
> > Can anybody give me a hint where in the policy/packaging-manual is a
> > rule that decides whether -doc packages should go to /doc or,
> > toghether with the binary package in /net or /x11 etc.
> >
> > The current situation on the FTP server is not clear.
> > (some grepping just told me that about 60% is in doc and the rest in the
> > specific direcories.)

I guess it could go either way.  Its too bad we don't have better
organization of software categories (rather a losing battle,
really)...

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: @ifinfo handling by makeinfo vs. texi2html

[Adam Di Carlo]

David Coe <[EMAIL PROTECTED]> writes:

> I just noticed that ispell.texinfo has a few chunks of
> documentation (one of which is its copyright) that are
> bracketed by [EMAIL PROTECTED]'' ... [EMAIL PROTECTED] ifinfo'' pairs.
> 
> This causes those paragraphs to appear in the info
> document (generated by ``makeinfo ispell.texinfo'')
> but to not appear in the html document (generated by
> ``texi2html -monolithic ispell.texinfo'').
> 
> Is this a feature or bug in texi2html, 

Feature.

> and is there an easy way around it?

Yes, remove the @[EMAIL PROTECTED] stuff.  Notify upstream of the problem,
and ask them why it is that way.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Need help with shlibs.local

[Adam Di Carlo]

"Marcelo E. Magallon" <[EMAIL PROTECTED]> writes:

> this is driving me nuts and I want to fix it once and for
>  all. wmaker (src) builds several binary packages, among them,
>  libwraster1 and libwraster1-dev.  The wmaker packages (wmaker,
>  wmaker-gnome and wmaker-kde) all should depends on libwraster1, with
>  proper versioning if necessary.  Sometimes that means it should
>  depend on the libwraster1 version that is being built, not the one
>  installed on the system.  Now, my problem is, everytime I think I got
>  this right, I realize it isn't the case.  Do you know of any source
>  package in this situation that's got this right?

jade.  Check that out.

It's more complex than it really should be to do this properly Oh well.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: dpkg "dry-run" mode?

[Adam Di Carlo]

Gopal Narayanan <[EMAIL PROTECTED]> writes:

> Maybe this is FAQ. I don't have a potato machine handy where I
> work. In general, if developers want to try installing packages they
> made for "unstable" to check if it installs okay, is there a machine
> to do that? 

Yes -- your home machine.  Sorry, thems the breaks.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: debian supported PGP stuff

[Adam Di Carlo]

Alexander Kotelnikov <[EMAIL PROTECTED]> writes:

> I'm going to apply to become a debian developer and I wanna know can I use
> combination of DSS key(from pgp5)+gnupg to send request?

Yes -- you can do it all with gnupg.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Request for sponsor or NMU

[Adam Di Carlo]

[EMAIL PROTECTED] writes:

> On Thu, Aug 26, 1999 at 09:57:39PM -0500, Steve Gore wrote:
> > I've recently submitted my application as a prospective new maintainer
> > and would like to adopt (if/when my application is approved) some
> > orphaned packages.

> > Among those I've examined as likely prospects for a first attempt is
> > sclient (a GUI MUD client).  Immediately after contacting Brian Ermovick
> > (the previous maintainer), he pointed out that there is a new upstream
> > release.  I would like to package the new release, if someone would be
> > willing to sponsor it.
> you may be interested in this location:
>   http://www.internatif.org/bortzmeyer/debian/sponsor/

In addition, you should ask the previous maintainer if they'd sponsor
for you.  They are well-equipped to do this already.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Building Packages on Development Machines

[Adam Di Carlo]

Paul Serice <[EMAIL PROTECTED]> writes:

> So, is it possible to logon  to pandora and build these packages without
> having root access.  Is that the purpose of the fakeroot package? 

Should be if the -dev packages you need are installed.

> Also,  if I  could build  packages on  kubrick and  faure, then  I could
> easily verify that my packages build  and work properly on the alpha and
> sparc architectures.

Yup.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: original package with CRLF as line separators

[Adam Di Carlo]

Peter S Galbraith <[EMAIL PROTECTED]> writes:

> Radovan Garabik wrote:
> 
> > I am packaging a program, which uses CRLF as end of line (don't ask me how
> > it got there :-))
> > The problem is, I have to turn it to LF, because the program is a script 
> > and won't run with CRLF. But if I do this, *.diff.gz will be as big as
> > *.orig.tar.gz. Isn't there a better way? Maybe running dos2unix in
> > debian/rules or so... 
> 
> That's what I'd do, creating new files in a staging subdirectory
> that you can remove in `make clean' (so that you can run
> `debian/rules binary' multiple times, so that the diff.gz stays
> small).

Also, if the upstream source is .zip, you can use the -a switch when
you unzip it.  Or you could just repack the .orig.tar.gz withe the
unix EOL conventions respected.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: original package with CRLF as line separators

[Adam Di Carlo]

Radovan Garabik <[EMAIL PROTECTED]> writes:

> upstream source is tar.gz
> I am not sure if repacking is a good idea.. after all, this means modifying
> the upstream source, and diff.gz is there for this purpose...

A diff to change end of line endings on all files is a perversion of
that purpose.  If he is shipping a tar.gz file, he should be shipping
it with unix EOL markers.  Correcting bugs in upstream tar files is an
acceptable reason to deviate from upstream source.

So yes, this is a good idea to repack it rather than diff the heck
outta it.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: binary package version numbers?

[Adam Di Carlo]

Hey, glad to see someone's reading the Developer's Reference closely.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: File names in the Debian archive: *.deb vs *_i386.deb

[Adam Di Carlo]

[EMAIL PROTECTED] (Zygo Blaxell) writes:

> Are the FTP archive maintenance scripts debian-packaged?

No.  The main one is called 'dinstall' -- it is in CVS I think but
no-one has packaged it, unfortunately.  Several times people have
said, "Real soon now" but it's still not there for some reason.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Ownership of data files

[Adam Di Carlo]

Bjoern Brill <[EMAIL PROTECTED]> writes:
> I'm working on a program that collects information to be used by the sys
> admin. I don't want the collected information to be world writable (even
> though this wouldn't be a security hole), but I want the program to run
> from user accounts (with write access to its data).
> 
> Obviously, I have to make it SUID or SGID to something then, with
> 'something' being the owner of the programs data files, but I'd like
> to avoid 'something' to be root, if possible. Is there a predefined user
> or group in Debian I can use for this purpose or do I have to create one
> in an install script?

You should be able to create a group during installation (remove it,
perhaps, during purge?).  I think this is kosher.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: porting a package

[Adam Di Carlo]

Christopher C Chimelis <[EMAIL PROTECTED]> writes:

> Currently, Alpha has a mailing list that's like a quinn-diff "on
> steroids" that gives the Alpha porters a list of what's different between
> i386 and alpha.  We usually work from that rather than rely on
> debian-devel-changes.  It might help to have someone set up a list
> providing a similar service for i386.

I dunno, most porters I know just use the buildd logs (failed builds
only) or quinn-diff auto-maintained lists on the web at
buildd.debian.org .

> In my opinion, it's best for the maintainers to compile their own packages
> on other arches if possible (using the many build hosts that Debian has on
> the net) and just ask for testing from the arch lists prior to uploading
> the new package(s).

I don't think this is really a very practical suggestion.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: [boot-floppies] `mke2fs' and new Linux 2.2 ext2 features ?

[Adam Di Carlo]

[EMAIL PROTECTED] (Karl M. Hegbloom) writes:

>  I don't agree with this change.  I would rather it get asked always,
>  and that the default is for the button that enables the new features
>  and rejects Linux 2.0 compatability be highlighted by default, so
>  that pressing [Enter] will take that branch, [Tab][Enter] will turn
>  off the new filesystem features.  Perhaps the quiet flag would then
>  take the default of enable the new features.

I don't think this should be asked by default, since only experts will
care to diverge from the default (whatever we establish that the
reasonable default is).

>  What advantage are the new features?  What do they provide us with?
>  Do they make the filesystem more efficient?  What do they do?

Given that you can't even say what's the benefit of removing back
compatability, it seems to me that retaining back-compatability is
more desirable than removing it.

-- 
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: [boot-floppies] `mke2fs' and new Linux 2.2 ext2 features ?

[Adam Di Carlo]

[EMAIL PROTECTED] (Karl M. Hegbloom) writes:
>  I see this as an argument for leaving the question in; that is, don't
>  make it a `verbose'-mode only question.  I would like it to default
>  to the 2.2 kernel case, but offer the compat mode.

I disagree.  I would assent to change the default and the "severity"
of the question if you can point out how the particular e2fs options
in question are in fact very important to retain.

Since no one has done this, I can only assume that no one knows or
cares about the particular options, and thus, it hurts very few to
leave them out.

-- 
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: [boot-floppies] `mke2fs' and new Linux 2.2 ext2 features ?

[Adam Di Carlo]

Bruce Sass <[EMAIL PROTECTED]> writes:

> How is this issue going to affect the users?

It's hard for us to say exactly.  Hence, I tend to be rather
conservative.

> E.g.: Can one boot up a slink system then access a /home directory on a
> potato built fs.

If the 2.2 ext2fs features are enabled, no, I don't believe you could.
I'm leaving those features off by default...

> Is there a documented right way and wrong way of
> upgrading to the new filesystem features.

I don't know -- you'd have to take it up with the e2fsprogs guys.

> Where does this ext2 to ext2+ switch fall on a scale that goes from
> "users should not be compelled" to "users should be compelled"  to
> upgrade old systems?

"should not be" IMHO.

> Does this upgrade require user intervention?
> - if not then maybe do it in the background, over time?

I don't know -- you'd have to take it up with the e2fsprogs guys.

-- 
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: dbootstrap

[Adam Di Carlo]

Andrew D Dixon <[EMAIL PROTECTED]> writes:

> I'm working my way through a peculiar install (the box is a briq from
> Total Impact http://www.totalimpact.com ).  The box is booting over the
> network and I haven't been able to run dbootstrap. 

What architecture?

> I've managed to
> activate and mount the swap partition and mount the root partition which
> lets me boot the box in single user mode.

You are booting the install system in single user mode?  You are
forced to do this?  Why?

> My problem is that I can't
> change to runlevel 2 or 3.
> When I turned debugging on in /etc/init.d/rc it would hang on
> #telinit 1

Uh, booting from the install system (stuff on root.bin), I've never
tried telinit.  Let's just say that's "unsupported".

> as well.  Anyway I was trying to find out what dbootstrap does to the
> init scripts. 

Nothing, really.  I mean, it does fudge around a bit with
/target/etc/inittab if that's what you mean?

Confused...

> I can't find the source to dbootstrap and I was wondering
> if someone could point me to where it lives so that I could take a look
> at it.

It's in the boot-floppies package.

-- 
.Adam Di [EMAIL PROTECTED]http://www.onshored.com/>

Re: dbootstrap

[Adam Di Carlo]

Andrew D Dixon <[EMAIL PROTECTED]> writes:

> I'm working my way through a peculiar install (the box is a briq from
> Total Impact http://www.totalimpact.com ).  The box is booting over the
> network and I haven't been able to run dbootstrap. 

What architecture?

> I've managed to
> activate and mount the swap partition and mount the root partition which
> lets me boot the box in single user mode.

You are booting the install system in single user mode?  You are
forced to do this?  Why?

> My problem is that I can't
> change to runlevel 2 or 3.
> When I turned debugging on in /etc/init.d/rc it would hang on
> #telinit 1

Uh, booting from the install system (stuff on root.bin), I've never
tried telinit.  Let's just say that's "unsupported".

> as well.  Anyway I was trying to find out what dbootstrap does to the
> init scripts. 

Nothing, really.  I mean, it does fudge around a bit with
/target/etc/inittab if that's what you mean?

Confused...

> I can't find the source to dbootstrap and I was wondering
> if someone could point me to where it lives so that I could take a look
> at it.

It's in the boot-floppies package.

-- 
.Adam Di [EMAIL PROTECTED]http://www.onshored.com/>


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