Re: alpine_1.0+dfsg-2_source.changes REJECTED

[Joey Hess]

Bernhard R. Link wrote:
> While a minimal chroot is good to test against missing
> build-dependencies, a full real-world system is needed to test for
> missing build-conflicts or configure switches to disable specific
> autodetections.

But nothing in the current system ensures that packages are built in
such an environment at all. A DD can easily build their package only in
a clean chroot and upload that, missing all such testing.

Source-only uploads + the build daemon from hell would be a more
consistent approach that should catch more problems too.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Copyright question (BSD with advertisement clause)

[Joey Hess]

Riku Voipio wrote:
> I think the short term solution to this dilemma is to compile a list
> of attributions needed to be included in advertizment material.
> Also a list should be compiled attributions needed n documentation
> (such as libjpeg's). Obviously most distributors/boob writers will
> not notice such lists, but that's a different problem...

Most writers don't have to worry about it, it's not as if we advertise
Debian as "Debian.. now with Thomas G. Lane's JPEG support and OpenSSL".
The advertisement clause tries to not allow those specific attributions
to be used in advertisements; it does NOT require that advertisements
contain any specific list of citations.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: RFS: talkfilters

[Joey Hess]

Please see http://kitenet.net/~joey/code/filters/talkfilters-email :

| How did you manage to get valspeak, postmodern, pansy, and fudd, whose
| authors are unknown to be GPLed? According to the info page,
|
|  While all of these filters have been available in one form or
|  another in the public domain for many years, the original authors of
|  some of the filters are unknown. Reasonable attempts were made to find
|  the authors and obtain written permission to repackage the filters as
|  GNU software, but in some cases they could not be located.
| 
| It seem to me questonable to slap the GPL and a FSF copyright on a file
| just because it is being distributed about the net. So I have some
| doubts about the validity of the copyright of some of the talkfilters. I
| would not be comfortable putting them in the Debian distribution with
| thieir copyright in this state. :-/

Its maintainer never responded to that message.

Also, your package conflicts with many of the files contained in the filters
package.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#465086: RFS: talkfilters

[Joey Hess]

David Paleino wrote:
> Is there any chance for filter to provide a "libfilters" library to interface
> with? I've packaged talkfilters because it was a possible use of libtranslate
> [2] [3], but that's not really necessary. I could try to patch it so that it
> uses your "filters" package, but that would need a library to use.

filters has programs written some in perl and some in lex, so that's not
really possible to do a shared library.

The talkfilters frankly seem like a better implementation, if they would
only not be so apparently cavalier about copyright.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: ITR: xmlrpc-epi - copyright issues

[Joey Hess]

Neil Williams wrote:
> Copyright issues:
> 1. The machine-interpretable copyright format is meant to be
> hierarchical - Files: * should not appear before any other more specific
> matches. i.e. exclude all the awkward files explicitly in turn, then the
> last stanza is "everything else".

That's not quite incorrect. Quoting the page:

| Matches should be exclusive (a file can only match one rule). The final rule
| that should be considered is the most specific one (the one that matches the
| fewer files), or if this is ambiguous, the last one in the file.
|
| Thus, in this case of getopt.c, it is the second rule that has to be taken
| into account:
| 
| Files: *
| Copyright: [the main work’s author]
| License: [the main work’s license]
| Files: getopt.*
| Copyright: © 2000 the NetBSD Foundation, Inc.
| License: other-BSD
|  [text of the NetBSD license]

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Efficiency of triggers

[Joey Hess]

Thibaut Paumard wrote:
> Indeed, the problem is that per the instructions, I've modified my  
> update-yorickdoc utility to call dpkg-trigger when invoked from a  
> package's postinst. dpkg already triggers yorick-doc once after  
> unpacking the newly installed packages, which is sufficient. Later, dpkg 
> configures the various packages in several passes, because of the order 
> of dependencies. Each pass triggers yorick-doc again, and I've gained 
> close to nothing (depending on the dependencies, the situation can be 
> slightly better, identical, or worse than before, if each package need to 
> be configured in its own run).

This can be fixed in apt, by passing the --no-triggers option to each
dpkg run, followed by running dpkg --configure --pending once at the end to
run all the triggers. See bug #473461.

> If I remove the dpkg-trigger call from my update- script, everything  
> goes fine. I still need to check what happens for upgrades rather than 
> installs (but I will require some seep before I do).
>
> So I'm currently thinking that I should, indeed, remove the dpkg-trigger 
> call from the script. Any thought?

You generally only need a file trigger, or an update- script that
manually triggers, and not both.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: dh_clean and explicit package clean lists

[Joey Hess]

Ben Finney wrote:
> I recall recently seeing mention that 'dh_clean' could obey a
> 'debian/.clean' file as a list of patterns or files to
> clean.
> 
> However, I can't find it with search engines; "package.clean" returns
> hits for "package clean", and "dh" returns hits for all the "dh_foo"
> commands.
> 
> Can someone point me to a description or specification of this
> feature?

I recently added support for dh_clean reading debian/clean (see its man
page), but didn't see any reason to support per-package
debian/package.clean, so didn't add that.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: dh_install not finding files from orig source (was: Latest upstream versions of files)

[Joey Hess]

Ben Finney wrote:
>dh_install
> cp: cannot stat `debian/tmp/cmavo.txt': No such file or directory
> dh_install: command returned error code 256
> make: *** [install] Error 1
> dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit 
> status 2
> bzr: ERROR: The build failed.
> =
> 
> Why is 'dh_install' looking for the file 'debian/tmp/cmavo.txt', when
> that's not mentioned in the 'lojban-common.install' file?

   From debhelper compatibility level 7 on, if --sourcedir is not
   specified, dh_install will install files from debian/tmp if the
   directory contains the files. Otherwise, it will install files from the
   current directory.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: dh_install not finding files from orig source

[Joey Hess]

Ben Finney wrote:
> Why, then, is it exiting with a "No such file or directory" error
> trying to read the file from 'debian/tmp'?

Because of implementation details. It's easiest to check if the source
is in . , and if not stuff the path in debian/tmp into the list of
things to install, which later fails if it's not present.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: debconf database and config files

[Joey Hess]

Christoph Biedl wrote:
> The given "config" file sources $CONFIGFILE if present but asserts
> FOO and BAR are defined there.  Is this safe?  I'd rather wipe out any
> pre-existing values:
> 
> # Load config file, if it exists.
> if [ -e $CONFIGFILE ]; then
> +   FOO=
> +   BAR=
>   . $CONFIGFILE || true

I belive this is good practice to do. (In init scripts too.)

> * "postinst" sample
> 
> If I understand correctly, all the logic shown applies only for the
> "configure" invocation.  Or did I miss something?  Therefore the
> sample should be embedded in a switch like

If you look in HACKS, it describes why sourcing the confmodule needs to
be before nearly anything else in your script. So I prefer to keep it
very close to the top in my examples.

> * config file default values
> 
> It is quite common to ship a /etc/default/daemon in the package.
> However, this leads to the situation that default values are stored in
> three different locations:
> * debian/default as set up by the maintainer
> * debian/template for debconf
> * debian/postinst where the file is created if missing
> 
> I doubt this is the best solution.

If you're managing the file with debconf, then it should not be a
conffile, so should not be included in the package.

I don't see any need to hardcode the default value in the postinst.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: RFS: di-netboot-assistant (ITP #489812)

[Joey Hess]

Franklin PIAT wrote:
> I am looking for a sponsor for my package "di-netboot-assistant".
> (I am CCing debian-boot in case someone has some interest in it)

This looks like some nice work. I wonder if it would make sense for it
to be maintained inside the d-i project?

It's tightly related to d-i, after all. Also, if you'll look at the
current debian-installer.deb package, it's a dummy package, required so that
DAK has something it knows about. Since the real meat of the installer images
is provided in a BYHAND file.

Package: debian-installer
Architecture: any
Description: Debian installer
 This package currently only contains some documentation for the Debian
 installer. We welcome suggestions about what else to put in it.

Maybe the right thing to put in this dummy package, or replace this
dummy package with, is di-netboot-assistant?



Some review:

- Minor typos in the README, mostly involving number (ie, missing
   "s" on plural words).
- It shouldn't need syslinux to be installed on the tftp server.
  - pxelinux.0 is already included in the netboot tarball
  - menu.c32 is not, but vesamenu.c32 is (in testing), and can also do
menus and submenus
- The docs say that to use the top-level menu it should use
filename "debian-installer/etch/i386/pxelinux.0";
  Why is that in etch/ ? Wouldn't it be clearer to put the file in
  debian-installer/i386/pxelinux.0?
- No checking is done of the validity of downloaded files. It should check
  the images/MD5SUMS file. (Unfortunatly there's no signed trust path for it
  to check.)
- Seems to use the french keymap by default?
- Suggest s/NetBoot Meta-menu/netboot overview menu/
- The di-sources.list seems redundant. I think that the regular sources.list
  could be parsed to get the mirror urls, and those modified to get the 
  d-i image locations. The file would still be useful for the dailies,
  or other distributions, but it would be nice to not have to modify it to
  use a !french mirror.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Lintian warning messages

[Joey Hess]

Eduardo M KALINOWSKI wrote:
> If the scripts are not directly executable, you can remove the  
> #! line from them. That should make the warning go away.
> It would be better to talk with upstream so he does that.

If I were upstream and was pestered by a distribution to remove the
hashbang lines that I add to all code files as a matter of course
(because it's the most portable way to tell editors what type of code it
is), and their rationalle was that an internal tool in the distribution
was complaining about it, I'd be hard pressed to not laugh in their
face.

Lintian has overrides so that you can turn off this type of warning,
which is useful in detecting scripts that were accidentially not
installed executable, but that has a large number of false positives.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Lintian warning messages

[Joey Hess]

Eduardo M KALINOWSKI wrote:
> If the policy suggestion that leads to that lintian warning is so
> unreasonable, it might as well be taken off the policy.

I'm not aware of any such thing in policy.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: autotools during build

[Joey Hess]

Steve Langasek wrote:
> If you rerun autoconf/automake/libtool at package build-time, when you don't
> need to, what you get are large diffs against upstream every time a new
> version of the autotools becomes available.  Aside from wasting (a little)
> space in the archive, that makes it harder for NMUers or passing developers
> to see what's going on in your package.

dpkg-source allows deletion of files from a build tree; these will be
ignored in the diff. If you run autotools at build time, remove all the
files they modify at clean time and all will be well. Examples: aalib,
acpi, kobodeluxe, xaos, xemeraldia.

This kind of thing is easy to spot if you make a habit of always running
diffstat on your .diff.gz as part of the review process before upload.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: autotools during build

[Joey Hess]

Steve Langasek wrote:
> Hmm, I'm not really sure whether that fits with policy's intent regarding
> the effects of the debian/clean target.

  This must undo any effects that the `build' and `binary' targets
  may have had, except that it should leave alone any output files
  created in the parent directory by a run of a `binary' target.

I don't see the conflict. There is an unstated intent that the clean target
should not leave the package in an unbuildable state, but it doesn't if
your rules file runs the autotools.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: RFS: Plash: a shell and restricted environment for running programs with minimum authority

[Joey Hess]

Mark Seaborn wrote:
> LD_PRELOAD isn't good enough.  Plash needs to replace *all* uses of
> system calls that use filenames, including glibc's internal uses of
> those system calls.  Back in the day of glibc 2.2.5, you *could* do
> this by overriding "__open" and "__libc_open" as well as "open".  But
> with glibc 2.3.3, a lot of these calls are now resolved internally,
> without going through the dynamic linker (glibc uses "__GI_open"
> etc.).  Furthermore, glibc inlines system calls, including "open", in
> some places.

Yeah, I know from mooix (which uses a similar but less generalised
security model as plash), that wrapping open() is horrendous.

I suppose that syscall interception was considered and not used for some
reason?

I'd be interested in sponsoring plash, but this libc issue needs to be
resolved in some way first.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: RFS: Updated packages for vrms (fwd)

[Joey Hess]

Rogério Brito wrote:
> I tried to send the message attached two times already, but it seems
> that it hasn't reached the list.
> 
> Anyway, if anybody could help, I'd be grateful.

I've been following that bug and had been expecting some activity to
occur on the vrms mailing list since they redirected you there. Since
nothing has happened, I will go ahead and sponsor this upload.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: RFS: Updated packages for vrms (fwd)

[Joey Hess]

Rogério Brito wrote:
> What exactly should I do? I would like to host this somewhere where
> others could have access to a svn repository. I think that I can
> register a new project on BerliOS, but suggestions are welcome.

alioth.debian.org is also an option for team maintenance.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: duplicate library code in a package

[Joey Hess]

Andreas Fester wrote:
> not necessarily. It must be the original, but it must not be pristine.

That's self-contradictory. And wrong.

> One reason could be to remove autotools dependencies, another could be
> to remove files which would otherwise be removed by the "clean" target
> and would end up in a huge diff.gz.

If you remove files in the clean target they will not appear in your
diff.gz. The clean target is run before generating the diff.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: python "rpm" module package

[Joey Hess]

Justin Pryzby wrote:
> I used packages.d.o to confirm that that file does not exist in (at
> least) the unstable suite.  You might have to package that, too.

The rpm source packge contains python bindings. I don't know if it's the
right one.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Creating a randomized cron entry

[Joey Hess]

Florian Weimer wrote:
> I'm not sure what users would expect from such a service.

In the case of debsecan, as an admin I would expect something
consistent, so I can, for example, start the day with a coffee and a
security report, rather than getting the report at some random time
during the day.

(As a more desktopish user, I'd rather expect something that lives in
the toolbar and pops up an alert when there is a new security hole/fix,
but that's beyond what debsecan does right now.)

> I mainly want to avoid a scenario where all clients arrive at 17
> minutes past the full hour, and need to be served at the same time.

Stefano's solution seems like a good one as long as the total max delay
isn't too long. Putting it in cron.daily at the end (zzsecan) would help
add some additional randomisation since the run time of the rest of
cron.daily varies from machine to machine.

Oh BTW, the second example on your web page seems to incorrenctly use
the same command line as the first example.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Creating a randomized cron entry

[Joey Hess]

Henrique de Moraes Holschuh wrote:
> "at" has a very bad history security-wise, and I really doubt anyone is
> seriously maintaining and fixing that thing.  Now, if someone would rewrite
> from scratch an "at" designed and implemented for security, that would be
> very cool indeed.

at had one security hole that I know of, back in 2002; a double-free bug.
It's hard to call that a very bad security history; cron and fcron have
both had more security holes than that, so has vim, so has emacs, so
has glibc.

Random useless stats mode: Since the release of woody, some 2834
security holes tracked by the testing security team have afected 892
distinct packages; of these 493 holes were the only hole found in a
package, and at the other end of the spectrum, 493 total holes were
found in a set of just 7 packages. I know which set of packages I'd be
more concerned about having installed, and it's not the set containing
at (1 hole), it's the set containing mozilla-firefox (92 holes).

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Lintian error about missing debconf dependency (which is not missing)

[Joey Hess]

Russ Allbery wrote:
> I hate to say this, since actually implementing it is a lot of work in
> supporting programs like debhelper, but if the debconf-2.0 pseudopackage
> was introduced prior to a new feature in the debconf interface there needs
> to be a debconf-2.1 or debconf-3.0 as well.  If cdebconf implements that
> protocol, it can provide that pseudopackage as well.

Any later version 2.x of the debconf protocol is intended to be backwards
compatible with 2.0. In practice, new commands such as SETTITLE and the
PROGRESS stuff can be added to the protocol without increasing the
version number since earlier versions of debconf can skip doing anything
for these commands with no undue effects (although if you want this to
work, you'll need to || true your db_settitle commands in a shell
script). The CAPB interface also allows for larger change to the protocol
without increasing the version number.

I wouldn't object to a version 2.1 being added to the protocol, but
getting anything into the policy manual has become to much of a pain for
me to bother with myself.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Policy documentation on debconf

[Joey Hess]

Manoj Srivastava wrote:
> > It would be nicer to have it completely described (and in an updated
> > manner) in a definitive reference, of course.
> 
> Sure. Should be in the documentation of debconf itself.

debconf-devel(7), anyone?

(policy also contains a formal definition of the debconf protocol amoung
other bits of debconf documentation)

-- 
see shy jo


signature.asc
Description: Digital signature

Re: RFS: base64, utility for encoding to and decoding from base64

[Joey Hess]

Anders Lennartsson wrote:
> This command line application encodes and decodes base64 and can be
> used in redirects and pipes etc.

Can't you just use uuencode -m and uudecode?

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Proposal for collaborative maintenance of packages

[Joey Hess]

Lars Wirzenius wrote:
> I'm going to dip my spoon into this soup, because I dislike soup, and
> this one especially irks me.

Even ice cream soup?

> Reviewing other people's patches in large quantities every day is
> something that few people will be happy to do for more than a few
> days. After that, they'll figure out that they could be doing
> something else, like developing their own software and have someone
> else do all the boring, tedious work.

.. or giving the patcher a svn commit bit. I tend to do it after 3 or
four good patches and a little conversation with most of my packages
(and with d-i). Because you're right, there are more interesting things
to do than merging patches.. including reading the commit logs of
everyone whom I've given commit bits to. ;-)

If the patcher is an upstream author of the software in question, I'd
pretty much give them a commit bit automatically. However, that in
practice rarely happens, I find it more effective to communicate with
the upstream, make sure we have a procedure in place to let me know
whenever they have a release, and make sure that I am packaging the
right releases at the right time. I feel this is my responsibilty as a
Debian developer, and if I can't keep up with it it's best to find
someone else to maintain that package.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: RFS: statist - Small and fast terminal-based statistics program

[Joey Hess]

Mario Iseli wrote:
> -Depends: ${shlibs:Depends}, ${misc:Depends}
> +Depends: ${shlibs:Depends}
> (You don't need the second variable, it isn't defined anywhere...)

   Automatic generation of miscellaneous dependencies.

   Some debhelper commands may make the generated package need to depend
   on some other packages. For example, if you use dh_installdebconf(1),
   your package will generally need to depend on debconf. Or if you use
   dh_installxfonts(1), your package will generally need to depend on a
   particular version of xutils. Keeping track of these miscellaneous
   dependencies can be annoying since they are dependant on how debhelper
   does things, so debhelper offers a way to automate it.

   All commands of this type, besides documenting what dependencies may be
   needed on their man pages, will automatically generate a substvar
   called ${misc:Depends}. If you put that token into your debian/control
   file, it will be expanded to the dependencies debhelper figures you
   need.

   -- debhelper(7)

If you don't care about debhelper commands needing to add new dependencies
later then you can remove it if you want to, but it is a better idea to leave
it in. It's unfortunate that dpkg generates an ugly build message if it's
empty, but it does do the right thing.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Extra debian repository

[Joey Hess]

Bas Wijnen wrote:
> I think this is because of the signing of packages which happens and is
> checked nowadays.  If two versions are available, of which only one is
> trusted, it chooses the trusted one, no matter what the versions are.

AFAIK apt does not use whether a repository is signed to make this sort
of decision.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Native package or not?

[Joey Hess]

Bernhard R. Link wrote:
> The general suggestion is to not include the debian/ directory in the
> release tarball. The reason is that by the format of the Debian source
> packages no files can be removed by another person's .diff.gz and some
> tools like debhelper act on (non)existance of specific files.

patch is capable of deleting files and even subdirectories when the diff
shows that all the lines in a file are removed. The only limitation I
know of is that a patch cannot represent the deletion of an empty file,
and it cannot represent removing all lines in a file while leaving it
empty. 

> So if anybody else wants to make packages he may need to repack the release
> tarball to do so.

Given the above, I doubt it.

> Besides the problem of a debian/ directory in a source tarball given
> above (which is inherited by native packages, as they have the debian
> directory in the release tarball by definition), one often told reason
> can be non-nativeness of the package to Debian: If you have other users
> of your package, which use other distributions than Debian, they might
> see a new version of your sources, though you only fixed some mistakes
> in the debian directory. With non-native packages those only results in
> a new .diff.gz.

That is a very weak argument. In general any change made to a source
tarball may only be of interest to some subset of the users, there's no
real reason to single out the debian directory here.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: RFS: stegsnow -- whitespace steganography for text files

[Joey Hess]

Seems highly similar to snowdrop which is already packaged..

Jari Aalto wrote:
> 
> I'm looking for sponsor.
> 
> -- Jari
> 
> Status
> 
> NEW Package, not in Debian
> 
> Availability
> 
> http://sponsors.debian.net/viewpkg.php?id=218
> 
> Other information
> 
> Lintian clean (unstable)
> Pbuilder tested
> 
> Control file content
> 
> Package: stegsnow
> Version: 20060213-1
> Section: misc
> Priority: optional
> Architecture: i386
> Depends: libc6 (>= 2.3.5-1)
> Installed-Size: 36
> Maintainer: Jari Aalto <[EMAIL PROTECTED]>
> Description: whitespace steganography for text files
>  The program snow is used to conceal messages in ASCII text by
>  appending whitespace to the end of lines. Because spaces and tabs are
>  generally not visible in text viewers, the message is effectively
>  hidden from casual observers. And if the built-in encryption is used,
>  the message cannot be read even if it is detected.
>  .
>  Snow exploits the steganographic nature of whitespace. Locating
>  trailing whitespace in text is like finding a polar bear in a
>  snowstorm (which, by the way, explains the logo). And it uses the ICE
>  encryption algorithm, so the name is thematically consistent.
>  .
>  Homepage: http://www.darkside.com.au/snow/
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Closing bugs fixed in experimental

[Joey Hess]

Rafael Laboissiere wrote:
> Is it acceptable to manually close a bug which is fixed in experimental
> but not yet in unstable, especially when there are no plans regarding the
> upload of the fixed version to unstable in the foreseeable future?

Yes, just be sure to version your close message so that the BTS knows
it's still open in unstable.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: man1 or man8?

[Joey Hess]

Tyler MacDonald wrote:
> I can't find a consistent rule for what should go into man1 vs. man8. For
> instance, "apt-get" can be used as an unprivileged user to download source
> tarballs, but it's in man8, whereas "defoma-reconfigure", which can only be
> run as root, is located in man1.

DPKG-RECONFIGURE(8)DebconfDPKG-RECONFIGURE(8)

So, no, it's in 8 where it belongs.

> Under debian, bt_xml2db and bt_db2xml will probably require you to be either
> www-data or root

man 8 probably

-- 
see shy jo


signature.asc
Description: Digital signature

Re: man1 or man8?

[Joey Hess]

Tyler MacDonald wrote:
> tarballs, but it's in man8, whereas "defoma-reconfigure", which can only be

Ups, I read defoma-reconfigure as dpkg-reconfigure. :-)

-- 
see shy jo


signature.asc
Description: Digital signature

Re: debian/rules::dh_* comments as rejection criteria (Was: Re: A list of common gotchas in Debian packaging)

[Joey Hess]

Jari Aalto wrote:
> > See  down near the bottom
> > near debian/rules.
> 
> This is bad, such micromanagement for few commented lines should not
> warrant rejection criteria by the ftp masters.

Except the FAQ doesn't say that it's a rejection criteria, just that
lots of useless comments in debian/rules are a sign of a package which
was potentially thrown together too quickly, and that if there are
enough such signs it may tip a marginal package over into the REJECT
category.

FWIW, 70-90% of packages that I look at have either 

A) a commented out debhelper command or 
B) a comment saying "We have nothing to do by default." or
C) an uncommented debhelper command that does nothing in this particular
   package right now

Of these B is the most annoying indication that someone copied a
template without thinking, while A and C are very close to the same
thing, since debhelper is *optimised* for running lots of commands that
don't do anything, so that people can just dump a whole lot of commands
into a rules file[1] and enable them by writing the appropriate debian/
files. C is also a lot harder to detect than A, you have to closely
examine the package.

It seems silly to me that the ftpmasters would take especial umbrage to
A while not caring about B, and while probably not checking for C even
though it is nearly identical to A in effect.

-- 
see shy jo

[1] Can anyone say "cdbs"?


signature.asc
Description: Digital signature

Re: Packaging automation - separation of 'debian/' directory

[Joey Hess]

Interesting thread. I've never thought about generating the tarball this
way, though I do have a lot of native packages that probably shouldn't
be.

If one general-purpose tool to handle this rises to the top and is
usable by many people, it would be a good candidate for addition to
devscripts.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: RFS: uncrustify

[Joey Hess]

Daniel Baumann wrote:
>   * ${misc:Depends} is useless here

Please don't ask people to remove "useless" misc:Depends lines. At any
time a new version of a debhelper command could need to add a new
dependency to misc:Depends, and this only works if you keep it in your
depends line.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: debconf: asking several questions more than once

[Joey Hess]

Patrick Schönfeld wrote:
> Hi people,
> 
> as i just finished a current version of mantis got it uploaded by Daniel
> (thanks for that!) i have re-started working on smstools. Because the
> upstream author and me detected that installation can lead into a
> defunct state (because smsd is started, even though maybe there is no
> appropriate config), i thought about implementing a series of debconf
> questions to preconfigure smsd if the user wants to do so.
> Thats no problem so far.
> But there is one thing I'm not sure how to implement. Users can use up
> to 32 modems with smstools. Even though i don't think that is a common
> setup i would like to give them a chance to configure more than one
> modem. But i am a bit unsure how to do this.
> Off course i know that i can loop in my config script, but how to ask
> several questions again and again and store the answers so i can process
> them in the postinst? I heard about the db_register command, but i
> haven't seen a concrete example so far and so i am a bit curious about
> how to do this.

for x in $(seq 1 32); do
db_register my/template my/question/$x
db_input high my/question/$x
db_go
done

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Tone-of-voice used by sponsors

[Joey Hess]

Thomas Goirand wrote:
> Daniel many times told me that for example, I shouldn't use 2 blank
> lines on my debian/rules, don't have empty space a end of line in my
> copyright, and things like that.
> 
> I agree it doesn't mater MUCH, but it's still better the way he advise
> me to correct.

I would much rather see new packages getting a basic security review
than having that time spent perfecting whitespace.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Copyright issues GPL-PHP license

[Joey Hess]

David Paleino wrote:
> Why?
> And a web server written in awk, then? Is that of any real-world use?
> I've seen implementations of that on the Internet. I admit that this
> is not enough reason to package it though.

d-i contains a web server written in shell, fwiw.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: RFS: alienarena2007

[Joey Hess]

Andres Mejia wrote:
> License: The game client and dedicated server are under GPL
>  The game data files are under a CCPL, specifically, the
> Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported
> License .

Therefore the data packages have to go in non-free, and the game at best
in contrib (if packaged as a separate source package). Your control file
needs to be changed to specify non-free/games etc as the section.

These two lines from the copyright file seem potentially problimatic:
| The source code is released under the GPL license and can be used or modified 
for any purpose, provided it too is released under the GPL license.
| 
| Under no circumstances can ALIEN ARENA 2007 be sold or used for profit, 
without express consent from COR Entertainment.  ALIEN ARENA 2007 may be 
included in free compilation CD's and similar packages without consent, 
provided the archives remain unmodified.

Is the GPLed source code supposed to also be covered by this not-for-profit
clause? It is not very clear.

Also, there seem to be exe and dll files in the svn repository, which is
a bit questionable, especially if these happen to statically link in any
proprietary MS stuff.

> For convenience, I wrote a script  to make building
> the packages from SVN easier. Running 
> from the top directory builds all packages. The packaging.README in
> the debian folder explains the other options available for the
> build-package.sh script and on building these packages using
> dpkg-buildpackage and pbuilder.

The way you've made debian/rules require BUILD_PACKAGE be set is not
good, because you can't rely on such an environment variable being set
when a package is built on the autobuilders. You either need one rules
file that builds everything each time (possibly with binary-
sub-rules that can be called to build only one package if desired), or
you need to split the upstream source into multiple independant source
packages which can then be built independently in the usual way.

Before I could sponsor this I'd also need to know where the tarball is
I'm supposed to be building against, and would prefer if you pointed me
at a debian source package, not a svn repo. Other sponsors might vary.

Deleting things out of $HOME as the postrm tries to do is sure to net
you some bug reports sooner or later, and that line of code is best
removed. 

Also, the various tests you have in the postinst and postrm to see if
the package is still installed are not the right way to do this. See
"6.5. Summary of ways maintainer scripts are called" in debian-policy.
Here's a more reasonable postrm:

#! /bin/sh -e
#DEBELPER#
if [ "$1" = remove ]; then
rm -f /usr/share/games/alienarena2007/arena/game.so
rm -f /usr/share/games/alienarena2007/data1/game.so
fi

Note that I added #DEBHELPER# markers too, which your maintainer scripts
seem to be lacking. Better yet, the postinst and postrm could be removed
entirely, and the symlinks they manage simply included in the deb.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: repository signing and apt-get authentication

[Joey Hess]

Neil Williams wrote:
> Seems to me you have two choices: Use what you had without SecureApt.
> Use the directory layout and tools that support SecureApt.

There is nothing in apt's security checking code that requires any
particular repository structure.

Example of apt repository that uses a flat directory structure, created
by mini-dinstall, including fully automated creation of signed Release
files usable by apt: http://kitenet.net/~joey/debian/unstable/

-- 
see shy jo


signature.asc
Description: Digital signature

Re: busybox

[Joey Hess]

K. Richard Pixley wrote:
>Ok, sure.  But that seems like a hack to me so that busybox can be
>installed on regular desktop systems which presumably want coreutils, (and
>friends), to be installed as the primary "ls" command.  In this context,
>busybox is more of a toy, or an evaluation install than a useful tool.

Most systems that have busybox installed use it to boot, since
initramfs-tools puts it on the initramfs by default. That's not very
toy-like.

>For busybox to be a useful tool, it would need to supplant coreutils, (and
>friends).  And my question is to why this hasn't been done.

Several reasons, including that it would break large quantities of software
that expects to be able to use various command line options that are not
present in the busybox utilities.

http://kitenet.net/~joey/blog/entry/replacing_stuff_with_busybox.html

-- 
see shy jo


signature.asc
Description: Digital signature

Re: vanity packages (was: mentors.debian.net reloading)

[Joey Hess]

Neil Williams wrote:
> > I would consider its popularity low (187 popcon installs with 46
> > votes).
> 
> It's not that low. It looks like quite a few people find it useful, so
> that's good.

Using absolute popcon numbers as indications of a package's popularity
isn't the best idea anyway, since we don't know what percentage of users
use popcon. Comparing popcon stats for two packages is more useful.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: automatically parseable debian/copyright

[Joey Hess]

Bart Martens wrote:
> On Wed, 2007-11-28 at 17:44 +0930, Paul Wise wrote:
> > I'd suggest that the copyright file
> > should be redone and done so it can be parsed automatically:
> > 
> > http://wiki.debian.org/Proposals/CopyrightFormat
> 
> Hi Paul,
> 
> As far as I know, it has not yet been decided that the debian/copyright
> files must be formatted as described on the wiki page quoted above.  Or
> did I miss some decision ?

Don't confuse it being mandatory with it being allowed. The format
described there is a perfectly valid format under the current rules and
best practices for copyright files. I'm using it on all my new packages,
including quite a few already in the archive.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: dh 7 broken by design?

[Joey Hess]

Helmut Grohne wrote:
> I recently tried converting my packages to dh 7 and ... failed.
> 
> The simple rule
> %:
>   dh $@
> will fail miserably if there is any file named like a target. Try `touch
> build' in your favourite dh-7-package to see it break.
> 
> GNU make users probably know that this is why there is a .PHONY: ...
> rule. However that one does not work with implicit dependencies and
> results in make thinking there is nothing to be done.

I was not aware of this behavior of make and had assumed .PHONY could be used
as usual in this case. But I see that bug #509756 was recently opened on make
about it.

> Another idea was to supply the -B switch to make:
>   -B, --always-make   Unconditionally make all targets.
> 
> However `make -Bf ./debian/rules clean' does not seem to work since make
> executes `dh ./debian/rules'. I did not find out why.

Apparently make always tries to run a target with the name of the 
Makefile. So this causes it to try to build the Makefile
even though it's up-to-date.

I will make dh handle this case in the next release, by doing the equivilant
of:

debian/rules:
# no-op

-- 
see shy jo


signature.asc
Description: Digital signature

Re: dh 7 broken by design?

[Joey Hess]

Helmut Grohne wrote:
> So will the new minimal example look like the following then?
> 
> #/usr/bin/make -Bf
> %:
>   dh $@

Yes, that's how it's looking now.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: dh 7 broken by design?

[Joey Hess]

Russ Allbery wrote:
> I really think this is a bug in make.

Probably, but who knows. It could just be a misfeature on which ghod
knows what somehow depends.

.PHONY: precompiled-binary-we-cannot-regenerate-with-gcc.o
 
> We can change Policy if we have to.  Arguably that line complies with
> Policy, but it feels icky to me; Policy's requirement that debian/rules be
> a makefile to me means that you should be able to use it as a makefile,
> which means not requiring special make flags.

I don't remember all the examples of ways to use debian/rules as a
makefile that tend to come up whenever someone suggests that that 
(IMHO restrictive and counter-innovative) requirement be dropped. (And
would prefer recapitulating that thread..)

But I had rather thought that they all tended to involve either:

- Testing if a target exists. Ie, something like
  `make -nf debian/rules get-orig-source`
  (close to equivilant: `debian/rules -n get-orig-source`)
- Being able to rely on various make features when running debian/rules.
  Ie: `debian/rules clean build FOO=1`

Both sorts of things continue to work with rules files that pass
additional options to make. I'm having a hard time imagining a
rationalle for building a package by running
`make -f debian/rules binary`

-- 
see shy jo


signature.asc
Description: Digital signature

Re: DEP5 and multiple copyrights for same file

[Joey Hess]

Siegfried-Angel Gevatter Pujals (RainCT) wrote:
> Hi Jean,
> 
> Something likes this should do:

> --
> Files: gtk/core_math2.cc
> Copyright: 2004-2010, Thomas Okken
> License: GPL-2
> 
> Files: gtk/core_math2.cc
> Copyright: 1993, Sun Microsystems, Inc.
> License: other
>  Permission to use, copy, modify, and distribute this
>  software is freely granted, provided that this notice
>  is preserved.
> --

DEP5 says "The last paragraph that matches a particular file
applies to it." So here you have a first para that does not apply
to the only file it lists.

I think that the way to handle this case is:

Files: gtk/core_math2.cc
Copyright: 2004-2010, Thomas Okken
   1993, Sun Microsystems, Inc.
License: GPL-2 and other
Comment: Mostly GPL-2, but one function is licensed differently.

License: other
 Permission to use, copy, modify, and distribute this
 software is freely granted, provided that this notice
 is preserved.

License: GPL-2
 See /usr/share/common-licenses/GPL-2.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Init scripts as conffiles

[Joey Hess]

Matt Zagrabelny wrote:
> Sure. That doesn't make it correct, optimal, or the best option, just
> how things have always been done.
> 
> I understand the difference between remove and purge and the reason to
> use both, but removing unmodified conf files seems like a win to me.
> Keeps the clutter down.

You'll stop thinking this when apt decides to do an upgrade as follows:

1. remove foo (and its conffiles)
2. install bar
3. install foo

That is one of the reasons for the current behavior, and temporarily
removing a package is how apt deals with certian dependency issues. 
Renaming a package is another similar reason for the current behavior.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: RFS: parallel

[Joey Hess]

George Zarkadas wrote:
> It builds these binary packages:
> parallel   - Execute jobs in parallel locally or using remote computers

I have not figured out what to do about moreutils containing a
/usr/bin/parallel that is not entirely command-line compatable with this
one. #597050

-- 
see shy jo


signature.asc
Description: Digital signature

Re: RFS: parallel

[Joey Hess]

George Zarkadas wrote:
> -- In addition, the "alternatives" mechanism does not force any user to
> make any changes to his/her scripts (as a choice to rename one of the
> binaries would for the respective user group); they just set their
> preference and use their scripts as before.

There are already packages in debian (well, in incoming) that use the
moreutils parallel and would be broken by this other package being
installed, unless its alternatives were lower priority. 

Anyhway, alternatives are not a viable solution to a problem of two
incompatable command-line utilities with the same name.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Git and tarballs

[Joey Hess]

Andrey Rahmatullin wrote:
> On Wed, Jul 06, 2011 at 03:12:41PM +0200, Thomas Preud'homme wrote:
> > Does pristine-tar work if the upstream branch contains files which have 
> > been 
> > removed during repack?
> Unfortunately the directory and the tarball must have identical contents.

That's not true, but the larger the difference the larger the delta file
will be.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Git and tarballs

[Joey Hess]

Andrey Rahmatullin wrote:
> How can I create this delta? The man page says only about creating a delta
> for a tarball without a directory.

The delta is created for you when you run pristine-tar commit.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Nitpicking: you are doing it wrong

[Joey Hess]

Scott Howard wrote:
> From the debhelper manpage
> 
> "Unless otherwise indicated, all debhelper documentation assumes that
> you are using the most recent compatibility level, and in most cases
> does not indicate if the behavior is different in an earlier
> compatibility level, so if you are not using the most recent
> compatibility level, you're advised to read below for notes about what
> is different in earlier compatibility levels."

This is overstated; while it's quite likely the documentation for a
particular command will fail to mention some change made in a recent
compat level, the compat level is always mentioned when some
incompatible change or new feature is actually properly documented. :P

> and
> "v8  This is the recommended mode of operation."

This qualification is there mostly to avoid people using v9 before it's
complete; the only non-recommended compat levels are v4 and below,
which are deprecated.

As a point of comparison, the compat histogram for packages I
co-maintain is:

124 7
  6 5
  3 8
  2 4
  1 9
  1 6

Thomas Goirand wrote:
> I believe that CDBS/dh is hiding what's necessary to
> do a good packaging, and is calling too many unnecessary helpers,
> which slows down the build process.

Bear in mind that CPUs have doubled in speed something like 7 times
since debhelper was originally written -- and it was written from the
beginning to be not annoyingly slow when every command was put in the
rules file. There have also been some siginficant speed improvements
made for the dh case. A rules file for a multiarch packages using dh
is likely to be faster than one hand-written. I suspect this may come
down to phycology at this point; we see a lot of commands running and
feel the build took longer. Of course there is still room for
improvement -- it's been suggested that dh could run many commands
in parallel..

> Also, with dh_override_*, if you
> have a lot of them, it soon becomes unreadable. That's only my opinion

To the contrary, I find that it exposes the essence of what makes a package
different, and even an example such as the following does not seem hard to
read, because there are no complex interrelationships between the override
targets.

override_dh_auto_install:
$(MAKE) prefix=`pwd`/debian/debconf-utils install-utils
$(MAKE) prefix=`pwd`/debian/debconf-i18n install-i18n
$(MAKE) prefix=`pwd`/debian/debconf install-rest

# Run dh_link earlier so that it has an opportunity to link documentation
# directories.
override_dh_installdocs:
dh_link
dh_installdocs

override_dh_installdebconf:
# Don't modify postrm, I purge differently than normal packages
# using me
dh_installdebconf -n

override_dh_install:
dh_install
cp debian/apt.conf debian/debconf/etc/apt/apt.conf.d/70debconf
cp bash_completion debian/debconf/etc/bash_completion.d/debconf

override_dh_installchangelogs:
# Changelog reduction hack for debconf. Only include top 100 entries.
perl -ne '$$c++ if /^debconf /; last if $$c > 100 ; print $$_' \
< debian/changelog > debian/debconf.changelog
dh_installchangelogs

override_dh_compress:
dh_compress -X demo.templates -X tutorial.templates

-- 
see shy jo


signature.asc
Description: Digital signature

Re: dh --parallel (was: Re: RFS: lebiniou)

[Joey Hess]

Paul Wise wrote:
> Completely agreed, please file two bugs against debhelper about this.

Only after reading debhelper's bug logs where the decision was
researched and made to not --parallel by default, please.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Lintian says "package-contains-ancient-file"

[Joey Hess]

Olе Streicher wrote:
> Therefore, the package contains a couple of files which are quite old --
> some help files, sources, documentation etc. date 1983 and 1984. This
> leads to the Lintian *error* shown in the subject. Although I think it
> is reasonable to overwrite this tag (the files actually *are* that old,
> and they are still part of the package), I am a bit concerned by the
> Lintian explanation "Your package will be rejected by the Debian archive
> scripts if it contains a file with such a timestamp".
> 
> Searching the policy, I could not find a point that would speak against
> using old time stamps. Even more, the policy asks me to *keep* the time
> stamps:
> 
> | 4.7 Time Stamps
> | Maintainers should preserve the modification times of the upstream
> | source files in a package, as far as is reasonably possible.

> I would also feel a bit bad with just "touch"ing these files, since the
> age may be an indicator to evaluate the contained information.
> 
> So, is it reasonable just to overwrite this tag, or will I then face to
> a package reject? What is the reason for this tag?

This check is intended to guard against package being built
with a broken clock, or even a buggy version of /usr/bin/install
which set the time stamp of all files to epoch. See bug #218304.
Oddly, the cut-off date is the year 1984, not "more than 20 years ago"
as described by lintian-info.

I think the DAK rejects are based on lintian checks now, but am not 100%
sure. An ovrride would probably work.

I think it would be reasonable to file a bug on lintian that this check
should not be applied to documentation.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Managing Debian packages with Subversion

[Joey Hess]

Jamin W. Collins wrote:
> I prefer an alternate structure where you start with the project as a
> top level.  This keeps all project (package) related files under one
> directory in the project:
>
>project/
>   trunk/
>   branches/
>   tags/
>   vendor/

The only problem with this is that if you maintain N packages, and you
presumably set up svn:externals pulling in all N, so you can update your
whole source tree with one svn up, then subversion will currently open n
connections to your server. Due to some bugs it will keep all N
connections open until it's done with the whole update. If you use
subversion over ssh, this is pretty bad. I have successfully fork bombed
my server with subversion. (N was 40 or so.)

Not to mention all the other limitations of svn:externals. It's fine if
you're only maintaining a few packages I guess.

> Either way, I suggest the addition of a vendor/ directory to track
> differences in upstream versions.  The reason for this will be clear
> (see below).

Vendor is just a branch so I don't understand why it should be kept
separate. I use branches/package/upstream for this, and put vendor tags
in tags/package/upstream_revision_x.y. I am considering changing the
latter, which is derived from what cvs2svn does to old cvs-buildpackage
managed repositories, to something like tags/package/upstream/x.y

-- 
see shy jo


pgpLtPInbASYC.pgp
Description: PGP signature

Re: Managing Debian packages with Subversion

[Joey Hess]

Fabian Fagerholm wrote:
> Thanks to [EMAIL PROTECTED] and [EMAIL PROTECTED] for their
> insight into this issue. I will try to summarize everything in this
> reply to myself.

Nice job writing this up, here are some corrections.

> The repository will have the following structure:
> 
> trunk/
>projectA/
>projectB/
>...
> branches/
>projectA/
>projectB/
>...
> tags/
>projectA/
>projectB/
>...
> vendor/
>projectA/
>projectB/
>...
> 
> The advantage of this might be that the svn:externals property might
> work better. (TODO: verify, why)

The reason I prefer this layout is I can check out the whole trunk/
directory here, and get a nice directory with all my debian packages
(projectA, projectB, projectC..) in it. No need for svn:externals at
all.

> Option B.A.: Per-project trunk/, branches/ and tags/
> 
> The repository will have the following structure:
> 
> projectA/
>trunk/
>branches/
>tags/
> projectB/
>trunk/
>branches/
>tags/
> ...

Compare with a layout like this one. If I want a directory with all my
projects, I must either check out the whole repository (likely not an
option due to disk spack), or set up a directory with a svn:externals
propery like this:

projectAsvn://wherever/projectA
projectBsvn://wherever/projectB
projectCsvn://wherever/projectC

And maintain this. The maintenance burden, coupled with the limitations
of svn:externals (which some subversion developers don't like and would
prefer to just remove), make me prefer to avoid svn:externals when
possible.

Of course, there are advantages to the toplevel project layouts too. For
one thing, the tags and branches directories are closer to the trunk
directory, which can make it be less typing to tag projects, work with
branches, and so on. Just do a svn info, and paste the repo url,
changing the last word of it from trunk to tags. 

I've lately been working on tools to automate this kind of thing, for
example I have a svnpath tool that I use to get directories for tags and
branches. It works with either repo layout, like this:

svn cp `svnpath` `svnpath tags`/new-tag

Will make a new tag of the project I'm cd'd to. This is in my subversion
repository in the bin directory along with other tools to do automated
committing and tagging based on the debian/changelog.

>  * B.B. svn_load_dirs -t tags/projectX/upstream/
>url://host/repos/ branches/projectX/upstream
>/path/to/new/version

I've only ever had to do this once, and I tried a svn_load_dirs command
like that and watched it try to check out the root of my repository. 10+
gb of files (hundreds of versions of most packages) over dialup. The thing
is very badly documented, but I eventually worked out that I could run
it like this:

svn_load_dirs url://host/repos/branches/projectX upstream /dir

This leaves me doing the tag myself of course. Even when run this way
it apparently checked out all of url://host/repos/branches/projectX/,
which could be quite painful if you have a lot of branches. I hope this
tool gets improved.

> Then export (svn export) the current tag and build the package. You also
> need to export the upstream source and turn it into an .orig.tar.gz.

Please don't do that. Keep an archive of your .orig.tar.gz's and copy
the tarball into place before doing the build so we can have pristine
source. I personally use a local mini-dinstall repository that I upload
all my packages too, that way I have all the released packages handy,
along with their sources. Another approach is the check the orig
tarballs into svn, if you're optimistic about the ever-falling price of
disk space. :-)

-- 
see shy jo


pgp4mysTLgNXu.pgp
Description: PGP signature

Re: Managing Debian packages with Subversion

[Joey Hess]

Jamin W. Collins wrote:
> I was with you up to this point.  I don't normally name my working copy
> in the form project- as that form is needed for actually making
> hte package and for that we need an exported copy of the working copy.

Actually, dpkg-buildpackage does not care what you name the build
directory of a package.

Persaonally, I use just packagename for the directory names and build
directly from them, using a collection of ugly hacks to ignore the .svn
directories[1]. I don't really recommend that, but it works.

-- 
see shy jo

[1] DH_ALWAYS_EXCLUDE=CVS:.svn dpkg-buildpackage 
-i'(?:^|/).*~$|(?:^|/)\..*\.swp|DEADJOE|(?:/CVS|/.svn|/RCS|/.deps)(?:$|/.*$)' 
-ICVS -I.svn


pgpMNShdDGAS1.pgp
Description: PGP signature

Re: Managing Debian packages with Subversion

[Joey Hess]

Eduard Bloch wrote:
> However, a possible implementation failed completely because of
> stupideness of "svn merge". So we have to find an alternative solution
> with diff&patch&cp. OTOH it is not possible to keep the version history of
> every file.

I think you're looking for svn_load_dirs.

-- 
see shy jo


pgp34nF8CjzDg.pgp
Description: PGP signature

Re: Some debconf questions

[Joey Hess]

Frank Küster wrote:
> - If a debconf question is manipulated by db_set, does that affect its
>   "seen" flag? And if it does, does it take effect immediately (i.e.,
>   also for a following db_inut ...), or only in the next run of the
>   config file?

No, you would have to use FSET to manipulate a flag. And all changes
take effect immediatly.

> - If I set a debconf question's seen flag to "false" with db_fset, it
>   will still be set to "true" again if the question is then asked to the
>   user - no need to revert manually? I would be very surprised if this
>   wasn't so, but someone else was in doubt.

That's correct.

> - What do I have to do to set up a test environment? I have created a
>   ~/.debconfrc and defined my testing database there, I have copied part
>   of the main database to it (as root), using debconf-copydb. However,
>   the templates file hasn't been copied, and I get an error message:
> 
> alhambra:~# debconf-copydb configdb frankdb --pattern='^tetex' \
>  --config=Name:frankdb --config=Driver:File \
>  --config=Filename:/home/frank/.debconf/config.dat
> alhambra:~# chown frank:frank /home/frank/.debconf/config.dat 
> 
> [EMAIL PROTECTED]:~$ egrep -v '^#|^$' .debconfrc | head -7
> Config: frankdb
> Templates: frankdb
> Name: config
> Driver: File
> Mode: 644
> Reject-Type: password
> Filename: ~/.debconf/config.dat
> [EMAIL PROTECTED]:~$ debconf-show tetex-base
> debconf: DbDriver "config": could not open ~/.debconf/config.dat
> [EMAIL PROTECTED]:~$ 

Debconf does not understand ~ for home in .debconfrc. Try using
environment variable expansions: ${HOME}

-- 
see shy jo


pgpNTG0fgQc6Q.pgp
Description: PGP signature

Re: Some debconf questions

[Joey Hess]

Frank Küster wrote:
> [EMAIL PROTECTED]:~$ debconf-show tetex
> Configuration database "frankdb" was not initialized.
> 
> Probably it would be better if you point me to some documentation so
> that I don't have to bother the list. There no occurence of "init" in
> debconf(7), debconf-devel(7) or debconf-show(1).

debconf.conf(5)

Your file is also messed up in that it seems to refer to a *single*
database, "frankdb" for both config and templates. They must be separate
databases. Moreover, it does not even define a frankdb database, but
only one named "config", which is probably why you get that error
message.

-- 
see shy jo


pgpCMv5LM5cQx.pgp
Description: PGP signature

Re: Debconf problem: Question asked twice

[Joey Hess]

Frank Küster wrote:
> + db_fset tetex-bin/hyphen seen false
> + db_input medium tetex-bin/hyphen || true
> +#db_fset tetex-bin/hyphen seen true

Please reconsider playing with the seen flag, unless you know *exactly*
what you're doing. Since you see the question twice, you don't.
debconf-devel(5) for details.

-- 
see shy jo


pgpLVDwIj56pS.pgp
Description: PGP signature

Re: Some debconf questions

[Joey Hess]

Frank Küster wrote:
> It isn't, or rather Joey has misunderstood me - he probably knows every
> piece of code by heart.

Hardly, and obviously not. I'd forgotten about the seen flag cache used
in making it easier to do scripts that back up. Besides, it's 30kloc.. ;-)

> Seen (after seeing in fact): false
> Seen (after setting): true
> [EMAIL PROTECTED]:~$ 
> 
> i.e after manipulating the seen flag to false, it is _not_ changed by
> debconf when it in fact shows the questions - the script has to manually
> revert its manipulation.

As soon as the script exits (or you call STOP), debconf will roll the
changes to the seen flag that are cached when questions are displayed.
Manually modifying seen flags after a question is seen will invalidate
the entry in the seen cache for that question, so your changes will
stick.

It could be considered a bug that debconf does not pull values out of
the seen cache when you ask for them with fget..

-- 
see shy jo


pgpsCyvmeqTFx.pgp
Description: PGP signature

Re: Debconf problem: Question asked twice

[Joey Hess]

Frank Küster wrote:
> It wasn't me ;-) One of the maintainers of tetex brought up a
> modification to fix a bug which altered the seen flag, and I wanted to
> suggest a somewhat different approach. I agree, however, with Atsuhito
> that the question has to be shown again to anybody who has answered it
> before, because there were some non-debconf'ed defaults we now
> integrated _and_ changed. 
> 
> > unless you know *exactly*
> > what you're doing. Since you see the question twice, you don't.
> > debconf-devel(5) for details.
> 
> I had only faintly in mind that the config script is run twice... I've
> had a look at other config scripts that use the fset ... seen command,
> but they all do this "internally", i.e. only in internal checking loops
> etc. 
> 
> For tetex-bin, however, we need to set the flag for every user. I think
> the only solution is to create an additional question that's only used
> internally to store the information wether the setting of the flag has
> been done yet.

I'm sorry I was short with you earlier. I try to be more helpful on
-memtors.

Really the only sane way to use the seen flag is if there is a peice of
external state that you can check before setting the flag. Some good
candidates are:

 - some program is failing, so you know it's ok to set the seen flag and
   display an error (note)
 - a file has a particular value, and you always modify this file to
   have some other value after setting the flag

I'd be leery of using a debconf question as your semaphore, but I
suppose it might work. If you're going this route you could just make
up your own flag and add it to the question whose seen flag you are
modfying.

-- 
see shy jo


pgp9EZ9SD9f1u.pgp
Description: PGP signature

Re: RFS: APT-Fu - source building tool for APT

[Joey Hess]

Eric Wong wrote:
> Hello, I wrote a new source-building tool for APT and am looking for
> somebody to sponsor it.  
> 
> Here's an excerpt I wrote for the README file:
> 
> Why APT-Fu?  Why not use an existing source-building tool in Debian?

I think it's a bad idea to add yet another duplicate tool to debian when
you could easily add every listed feature to apt-src and perhaps help
turn it into something really useful.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: config.sub and config.guess | .diff.gz bloat

[Joey Hess]

Zenaan Harkness wrote:
> > > debhelper puts the following into the "clean" rule in debian/rules:

No it didn't.

> Should I email this to the debhelper script maintainer?

Only if you want me to bounce it to the maintainer of the package that
actually put those lines there.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: When to unregister unused debconf templates?

[Joey Hess]

Frank Küster wrote:
> after changing the configuration scheme considerably, I have a couple of
> unused debconf templates left. I guess it's a good idea to unregister
> them from the database to keep it as small as possible.
> 
> Where should I do this? Not before the new package is unpacked, but also
> better not wait until the next upgrade: So postinst is best? Or are
> there other criteria?

I've always done that in the postinst, no problems.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: docs for debconf:db_*

[Joey Hess]

martin f krafft wrote:
> I know that debconf-devel(7) lists the debconf protocol and that the
> shell and Perl wrappers are basically 1:1. Still, I wonder if there
> is any documentation about these (which may be a little more
> accessible to new users). Could someone please take a clue stick and
> whack it over my head iff you also point me in the right direction
> afterwards?

Maybe you're looking for Debconf::Client::ConfModule(3)?

-- 
see shy jo


signature.asc
Description: Digital signature

Re: wmbatteries

[Joey Hess]

Roberto Cioffi wrote:
> I've just uploaded a new package: wmbatterie.
> It's a dockapp for windowmaker that shows acpi information read from
> proc filesystem.
> 
> It can be reached at:
> 
> http://mentors.debian.net/debian/dists/unstable/
> 
> or at:
> 
> http://utenti.lycos.it/bigjacob/debian/
> 
> I'm looking for a sponsor, if someone is interested, please contact me.

As the author of wmbattery, and a debian developer, I wish you could
find a new name for your program. I think that having two programs that
do the own thing have names differing only by pluralisation will be
very confusing to users.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: wmbatteries

[Joey Hess]

Roberto Cioffi wrote:
> Joey Hess wrote:
> 
> > As the author of wmbattery, and a debian developer, I wish you
> > could find a new name for your program. I think that having two
> > programs that do the own thing have names differing only by
> > pluralisation will be very confusing to users.
> >
> I'm not the author, I mean the name was not chosen by me.

Ok, sorry for my confusion.

Do you think you could convince its author to choose a less confusing
name?

-- 
see shy jo


signature.asc
Description: Digital signature

Re: po2debconf errors

[Joey Hess]

Stephen Gran wrote:
> I am working on a package that uses po files, inherited from the
> previous maintainer, and I am getting this during build:
> 
> po2debconf  debian/clamav-daemon.templates > 
> debian/clamav-daemon/DEBIAN/templates
> Warning:Outdated PO file: debian/po/fr.po, running
>   debconf-updatepo --podir=debian/po
> WARNING: It seems that none of the files in POTFILES.in contain marked strings
> 
> What is a 'marked string' and how do I dig about to fix this?  I am new
> to po, so I'm sorry for asking, but I'm not sure where to start digging
> for this error message.
> 
> I have looked through the /usr/share/doc stuff and info files, but I'm
> just not seeing it.  Cluebat?

See po-debconf(7). In summary, po-debconf uses templates files in which
the translatable fields have been marked with a leading underscore. If
it's no so marked, it's assumed not to be a translatable field.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Multiple binary source & per-package dh_ options?

[Joey Hess]

Stephen Gran wrote:
> dh_installinit -p foo -n
> dh_installinit -a

dh_installinit -p foo -n
dh_installinit -a -N foo

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Multi-person sponsorship

[Joey Hess]

Matthew Palmer wrote:
> So, comments, brickbats, acclaim, whatever.  Throw it at me.

Well I don't think that this system as described would be of any use to
me. I want to maintain a close relationship with the people whose
package I sponsor. I want to know if they are not able to send me a
package that will build properly. I want to work with them and be
familiar with the overall work they are doing on Debian, so I want to
always sponsor their package except when I'm unavailable (or too slow).

Evenually, and most importantly, if they turn out to be doing a good
job, I want to get them into Debian as a proper DD, and that is why I
require the numerous bits of information I gather in passing while
sponsoring them, so I can know if I want to advocate them or not. 

(I'd also like to see AM's making more use of this information. If I've
advocated someone, I can tell you what parts of T&S they have already,
IMHO, passed.)

Also, if things should go wrong, and my sponsee turns out to not have
the skills, interest, or time, I consider it my responsibility as the
sponsor to do any cleanup that might be required, orphaning or
temporarily maintaining packages, etc.

I don't see that your system helps with any of these things. I can see
it being possibly useful in the case where I am temporarily unavailable
and my sponsee needs to make an upload, but I cannot imagine myself
using it to randomly request to perform such a sponsorship for someone I
don't know and don't have a working relationship with, for a package
with which I am unfamiliar.

Just me, perhaps.

(I also hope that nobody roots your autobuilder.)

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Multi-person sponsorship

[Joey Hess]

Matthew Palmer wrote:
> > package I sponsor. I want to know if they are not able to send me a
> > package that will build properly. I want to work with them and be
> 
> Since you only get packages for sponsorship which have built in a clean sid
> chroot out of my system, you can be fairly sure of that.

As you've described the system, it sounds like my sponsee could make
several iterations with bad unbuildable packages before it is ever made
aailable to me to look at. This is what I want to avoid; if they are not
competant to upload a buildable package the first time, I want to know
that.

> I'm interested in how many of your sponsees do you know are/aren't doing,
> say, QA work quietly, or working on d-i, or doing bug triage?  I know that
> at least one person I'm sponsoring isn't doing anything on anything else,
> because I used to work with him, but apart from that, the people whose
> packages I've sponsored could be working towards becoming DPL and I'd hardly
> know.  Should I know these things?  Do you think that a good sponsor should
> be doing these things, or that it's useful in the general case for a sponsor
> to know all of a sponsees other activities?

I use filtering and scoring to keep track of such things reasonably
well. Unless they're sending patches to maintainers via private email or
something, I am likely to see anything they do in debian.

> > Evenually, and most importantly, if they turn out to be doing a good
> > job, I want to get them into Debian as a proper DD, and that is why I
> > require the numerous bits of information I gather in passing while
> > sponsoring them, so I can know if I want to advocate them or not. 
> 
> If you don't mind me asking, what sort of information do you ask for from
> potential sponsees?  (Warning: your answer may become FAQ fodder ).  Info
> similar to what gets asked for in the "background" section of NM?

I don't ask a set series of questions, I simply get to know the person
by working with them, same as I'd get to know any other DD, and reach my
own conclusions from that.

> > (I'd also like to see AM's making more use of this information. If I've
> > advocated someone, I can tell you what parts of T&S they have already,
> > IMHO, passed.)
> 
> If you put that information into an advocacy report, does the AM ignore it,
> or are they not supposed to take other people's experiences into account? 
> (That seems odd, considering that some NMs get their AMs switched on them).

I didn't know we had avocacy reports, doesn't the current system only
let you enter their email address?

> > (I also hope that nobody roots your autobuilder.)
> 
> I'm not keen on ever providing the .debs that come out of the autobuilder. 

Beside the point. Inside the autobuilder, you are running possibly
untrusted code. It's only a local exploit away from running as root, at
which time it can easily break out of any chroot you have it in. If it's
in an UML jail it also has to exploit a hole in the linux kernel, but we
have no shortage of those. :-/

-- 
see shy jo


signature.asc
Description: Digital signature

Re: RFS: New version of cvs-autoreleasedeb

[Joey Hess]

Eike zyro Sauer wrote:
> Raphael Goulais schrieb:
> >  - Why do you remove /var/log/cvs-autoreleasedeb.log at postrm, since
> >the log files are in /var/log/cvs-autoreleasedeb/ ? Also, I don't
> >think you should remove the log files anyway, even on a purge.
> 
> Is this consensus?
> I thought I'd get rid of everything a package made when purging.

I'm not familiar with this package, but policy is quite clear:

 Log files should be removed when the package is purged (but not when
 it is only removed).  This should be done by the `postrm' script when
 it is called with the argument `purge' (see Section 6.7, `Details of
 removal and/or configuration purging').

-- 
see shy jo


signature.asc
Description: Digital signature

Re: dh_installman

[Joey Hess]

Matthew Palmer wrote:
> I was under the impression that dh_installman renamed the file appropriately
> according to the .TH line -- at least, that's what the manpage suggests.

It uses the .TH line to get the section, but AFAIK there is nothing
similar in the content of the man page to work out the language, so it
uses filename extensions for that. 

See bug #193221 for some details. I'd prefer to add something to the
content of the man page and teach dh_installman about that, rather than
messing with file renames or other things.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: mysteries of /etc/default/*

[Joey Hess]

Adrian 'Dagurashibanipal' von Bidder wrote:
> On Thursday 15 July 2004 15.15, Martin Dickopp wrote:
> > Sebastian Henschel <[EMAIL PROTECTED]> writes:
> [/etc/default]
> > See Policy 9.3.2.  (Disclaimer: IANADD.)
> 
> Which does only say:
> | To ensure that vital configurable values are always available, the
> | init.d script should set default values for each of the shell
> | variables it uses, either before sourcing the /etc/default/ file or
> | afterwards using something like the : ${VAR:=default} syntax.
> which isn't much.

A few bits that you missed:

 Often there are some variables in the `init.d' scripts whose values
 control the behaviour of the scripts, and which a system administrator
 is likely to want to change.  As the scripts themselves are frequently
 `conffile's, modifying them requires that the administrator merge in
 their changes each time the package is upgraded and the `conffile'
 changes.  To ease the burden on the system administrator, such
 configurable values should not be placed directly in the script.
 Instead, they should be placed in a file in `/etc/default', which
 typically will have the same base name as the `init.d' script.  This
 extra file should be sourced by the script when the script runs.  It
 must contain only variable settings and comments in POSIX `sh' format.
 It may either be a `conffile' or a configuration file maintained by
 the package maintainer scripts.  See Section 10.7, `Configuration
 files' for more details.

9.3.5. Example
--

 The `bind' DNS (nameserver) package wants to make sure that the
 nameserver is running in multiuser runlevels, and is properly shut
 down with the system.  It puts a script in `/etc/init.d', naming the
 script appropriately `bind'.  As you can see, the script interprets
 the argument `reload' to send the nameserver a `HUP' signal (causing
 it to reload its configuration); this way the system administrator can
 say `/etc/init.d/bind reload' to reload the name server.  The script
 has one configurable value, which can be used to pass parameters to
 the named program at startup; this value is read from
 `/etc/default/bind' (see below).

...

 Complementing the above init script is a configuration file
 `/etc/default/bind', which contains configurable parameters used by
 the script.  This would be created by the `postinst' script if it was
 not already present, and removed on purge by the `postrm' script.
  # Specified parameters to pass to named. See named(8).
  # You may uncomment the following line, and edit to taste.
  #PARAMS="-u nobody"

It's really not that hard to run less on policy and type /etc\/default

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Debian vs RedHat init script

[Joey Hess]

Adrian 'Dagurashibanipal' von Bidder wrote:
> > Thanks for the url. I'm not sure how that solves my problem. As I
> > understand you, I need to convince the upstream maintainer to switch
> > to LSB style initscript. I can try doing that. The initscript has
> 
> Yes, that was my idea - so everybody can use the same init script.

To use lsb init scripts in Debian, you need to have the lsb package
installed. I don't think that we want to have debian packages depending
on lsb, for one thing it pulls in lots of other stuff.

I've also discovered that supposedly lsb compliant distributions violate
its init script policy in various ways which can be quite hard to work
around in an lsb init script, but YMMV there.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Simple Debian Package Creation?

[Joey Hess]

Rene Engelhard wrote:
> > any debian rules.
> 
> the foo-0.1 is a convention. if your stuff doesn't follow it it is broken.

No, there is no convention and it doesn't matter at all what you name
the package's source directory. This has been completly unnecessary for
years.

> And: You *could* use a random directory name later after dh_install 
> (dh_install needs to get the info it puts into the template from somehwre). 

You seem to be confused about what dh_install is.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Advice on debconf - locales settings

[Joey Hess]

Brian Sutherland wrote:
> I have quite a difficult config file problem to debconfify, and would
> like to ask advice.
> 
> The config file can contain a number of lang $locale settings, of which
> the first is the requested translation and the rest are backups.
> 
> How best to keep the ordering. Multiple select questions in series as a
> multiselect doesn't provide ordering?

I'd suggest keeping in mind that debconf is intended to be used to ask
the questions that a user needs to answer to get a package installed and
focus on those questions, not on turning debconf into some kind of
generic config file editor that it was never intended to be used for.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: buildinfo.debian mit debhelper ?

[Joey Hess]

Adam P. Harris wrote:
> I have.  Some packages require specific versions of supporting
> packages.  Since we don't have source depends,
> /usr/doc//buildinfo.Debian files are a useful thing.

Buildinfo files are in binaryt packages. What does that have to do with
source packages?

-- 
see shy jo


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

Re: my first package... loads of questions :)

[Joey Hess]

Martin Schulze wrote:
> the maintainer.  Well, there's just right another, using debhelper
> partially prevents the package from being compiled on other
> architectures.[1]
> 
> [1] We had this problem with binary-sparc where no new perl package
> existed so all packages using debhelper couldn't be re-packaged
> for the Sparc archtitecture.

Woah, woah, woah.. if perl is broken and won't build on the target arch,
that is hardly debhelper's fault. Debhelper depends on a version of perl
that has been available for debian (i386) since May _1997_.

Also, in about 90% of packages that use debhelper, you can force an install
of debhelper and the package will build ok without perl. The remaining 10%
can probably be worked around by installing perl 5.003 and grabbing
/usr/lib/perl/Getopt/Long.pm from perl 5.004 on an i386. If that helps you
any on your porting efforts.. 

-- 
see shy jo


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

Re: buildinfo.debian mit debhelper ?

[Joey Hess]

Matthias Klose  Perhaps not everybody wants to rebuild from the debian source package,
> but compile a newer upstream version for personal use or installation
> into /usr/local. Then the buildinfo in /usr/doc/ would be useful.

Why? 

-- 
see shy jo


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

Re: 2 packages using same conffile

[Joey Hess]

Joseph Carter wrote:
> What does one do in a situation where two packages both provide the same
> conffile?  Currently they use different names for the file, but both
> packages can (and probably should) use the same file.  How should this be
> handled, both from a policy and from an implementation standpoint?
> 
> I could create the file in postinst if it doesn't exist, but this seems like
> a Bad Idea for many reasons.  Is there really no Right Way to do this
> except to leave them as two seperate files and have the user deal with it
> however they will?

I'm not sure how dpkg handles conffiles plus diversions, but that seems like
the logical way to do it - both packages contain the file, and one of them
diverts the other package's file out of the way.

-- 
see shy jo


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

Re: moving confflie to another location

[Joey Hess]

Martin Bialasinski wrote:
> I am squashing the bugs in the xisp package. Report 12773 asks to move a
> conffile from /etc/options.xisp to /etc/ppp/options.xisp.
> 
> This sounds reasonable. To handle upgrading from an old version, is it enough
> to move the file in preinst?

Here's what I put in the preinst of xaw-wrappers to move a conffile. I'm not
sure if the use of cat is required, but I have gotten no reports of this not
working.

if [ ! -e /etc/X11/xaw-wrappers.conf -a -e /etc/xaw-wrappers.conf ]; then
# Move conffile. I think it's safest to use cat here, becuase 
# the user may have done something funky like made it be a sumlink.
cat /etc/xaw-wrappers.conf > /etc/X11/xaw-wrappers.conf
fi
rm -f /etc/xaw-wrappers.conf

-- 
see shy jo


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

Re: debstd trouble with multi-binary package

[Joey Hess]

Adam P. Harris wrote:
> Joey Hess, as the maintainer of debhelper, do you see this as a
> situation that should change?  I think we should eliminate any manuals
> suggesting debstd (or put it under a "historic" section), and try to
> get someone working on a debhelper equivalent.  Perhaps a discussion
> of the pros and cons of debhelper, hand-roll (a la Manoj), and
> cvs-buildpackage and the like could be discussed also.

I certianly have no problwm with documents directing new maintainers to
debhelper. I think a discussion of other options would be good too.

-- 
see shy jo


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

Re: moving confflie to another location

[Joey Hess]

Dan Jacobowitz wrote:
> Except, if the user has decided to make it a symlink, wouldn't it make
> more sense to just rename the symlink?  Otherwise, I'd get really
> confused if my /export/configs/X11/xaw-wrappers.conf for example
> suddenly got disconnected from /etc/{X11/,}xaw-wrappers.conf .

It's be better, but I was worrying about relative symlinks.

-- 
see shy jo


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

Re: debstd trouble with multi-binary package

[Joey Hess]

Jaldhar H. Vyas wrote:
> As the author of one of those documents, (Will Lowe is the other but I
> don't know if he is still working on it.) I agree completely.  I no longer
> use debstd in my own packages and don't recommend it to others.
> 
> Since around February off and on, I've been working on a revised edition
> which would be debhelper based and much more ambitious in scope. 
> Unfortunately I didn't reckon with the hell which is Y2K taking over all
> my spare time at work.  When I did get a little time to work on debian
> stuff, I unwisely let my self get sidetracked into debianizing TWIN. 
> 
> But really really soon now, there will be an update.  I promise :-)

Great. If you have techical (or philosophical) questions about debhelper, ask
me.

-- 
see shy jo, debhelper author


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

Re: tempfile <-> IO::Handle::new_tmpfile?

[Joey Hess]

Marcelo E. Magallon wrote:
> Hi,
> 
>can I use IO::Handle::new_tmpfile in an Perl script that's run on
>  postinst? The package has to Predepend on perl, right? 

Why not just depend on debianutils (>= 1.6) and use the tempfile command?

>  I'll use this
>  tempfile to modify a conffile (it *has* to be modified, it's not an
>  option)...

If it has to be modified, policy says it cannot be a conffile. Postinst
could create it instead.

-- 
see shy jo


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

Re: tempfile <-> IO::Handle::new_tmpfile?

[Joey Hess]

Marcelo E. Magallon wrote:
>  There's nothing wrong with debianutils... this is more a meta
>  question, I was just wondering if I could use the Perl provided
>  method... and debianutils is part of the base system, and it's
>  requiered, so there's no need to depend on it, is there?

You have to depend on it to make sure some old version that lacks tempfile
isn't installed.
 
>  Well, I didn't explain myself. In the particular case I'm dealing
>  with, the file is already there, and it has to be fixed because the
>  program (wmaker) won't even start with the old data. There are
>  several keys .*Fiend.* that have to be changed to .*Clip.*; if the
>  change is not made, wmaker won't start (the general feeling among
>  developers is "this is still under development, use at your own
>  risk"... I'm just trying to cope with that)

Ah. Fair enough.

-- 
see shy jo


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

Re: circular depends: problem

[Joey Hess]

Shaleh wrote:
> E-themes does not have a Changelog or a Copyright --> it is just pics,
> wavs and a text file or three.  The docs from E explain what they are

If you really don't have a copyright, it cannot go in debian.

-- 
see shy jo


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

Re: How to make only the binary parts

[Joey Hess]

Shaleh wrote:
> Now that I have a few packages split into arch-dep and arch-indep, how
> do I only build one or the other?  If all that changed is the arch-dep
> packages, I do not need to re-upload the arch-indep and vice versa.

If you changed the version number, you really need to upload the arch-indep
packages as well, even if there are no changes in them. At least the
changelog is likely to change, after all.

With that said, dpkg-buildpackage -B will do something like what you want
but it's really intended for porters.

-- 
see shy jo


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

Re: debhelper error -- bug?

[Joey Hess]

Brian Almeida wrote:
> The latest release of debhelper(0.99.2) broke my packages.  
> Is it a bug in it, or my packages? I think it the recent change
> to dh_movefiles (see the changelog) did it.  Unfortunately I don't
> know enough bash to fix it myself. Thanks.
> 
> Here is the error:
> 
> --- Building: emusic-docs
> mkdir -p /tmp/emusic/emusic-0.6.1/debian/build/emusic-docs/usr/doc
> dh_installdocs   -pemusic-docs 
> -P/tmp/emusic/emusic-0.6.1/debian/build/emusic-docs README AUTHORS 
> dh_installchangelogs -pemusic-docs 
> -P/tmp/emusic/emusic-0.6.1/debian/build/emusic-docs ChangeLog
> dh_movefiles -pemusic-docs 
> -P/tmp/emusic/emusic-0.6.1/debian/build/emusic-docs
> dh_movefiles: I was asked to move files from debian/tmp to debian/tmp.
> make: *** [emusic-docs] Error 1

Yes it's a bug. Fixed in version 0.99.3.

-- 
see shy jo


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

Re: libmsgcat and sympa : my first packages

[Joey Hess]

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]

Re: New maintainer's packaging - bewildering variety of information

[Joey Hess]

Matthias Klose wrote:
> try to run the helper programs with -v. You get a pretty good insight
> what's happening (although this may change, when Joey is switching the 
> current sh implementation to perl).

This will not change. I use perl for the backend now, but it just runs shell
commands to do everything that touches debian/, and -v still shows those
commands.

> True, although you can save much using the debhelper options -a and -i
> to act on all packages.
> 
> >   iii) Bugs in helper packages affect ones package, and one has little
> >control over the time for the fx (Joey has been wonderful so
> >far) 
> 
> Yes, I have to repeat this!

Thanks, both. :-)

-- 
see shy jo

Re: debhelper

[Joey Hess]

Darren Benham wrote:
> To date, I've been using the deb-make packages to handle my packages... After
> following a recent conversation, I figured I'd give debhelper a try but I'm
> having trouble finding a suitable "Starting place" to aquaint myself with it. 
> Anybody point me in the right direction for learning debhelper?

Have you tried /usr/doc/debhelper/README? And /usr/doc/debhelper/from-debstd
will be useful since you have used debstd in the past. (If you're using a
recent (>= 1.1.0) version of debhelper, refer to debhelper(1) as well, the
NOTES section has some useful info. That used to be in the README)

-- 
see shy jo

Re: what are the latest debian packaging tools.

[Joey Hess]

Manoj Srivastava wrote:
> Hi,
> >>"Stephane" == Stephane Bortzmeyer <[EMAIL PROTECTED]> writes:
> 
>  Stephane> Just do it... I considered adopting the Packaging HOWTO
>  Stephane> which seems orphan but it is work and I'm lazy :-}
> 
>   The packaging HOWTO is a part of the core Policy documents,
>  and is no longer orphaned. 

However, it's not the place to document debhelper or anything like that.
Actually I've always been a little annoyed it even mentions debmake. I'd
rather see it be completly impartial about this contentious issue.

If a newbie (the best person for the job, IMHO) wants to work on writing an
introduction to debhelper, I will give them my full support with any
questions they might have.

-- 
see shy jo, debhelper maintainer

Re: changing location of .conf files

[Joey Hess]

tony mancill wrote:
> preinst checks to see if it was called with either "install "
> or "upgrade ", which case it will copy whatever the user had
> for these conffiles into the new locations (and then remove the old
> conffiles?  Or let dpkg handle this?)

I've done this a couple of times, but I can never remember exactly what to
do. Anyhow, I think this is the right solution, and that you do have to
delete the old conffiles. I don't think dpkg automatically removes them.

-- 
see shy jo

Re: Packages with shared libraries

[Joey Hess]

Samuel Tardieu wrote:
> 1) Man pages and info files
> - ---
> It looks like the man page is being included in the three
> distribution. How can I prevent this?

Are you using debhelper and dh_installmanpages to install the man pages
automatically? dh_installmanpages has some brain-dead behavior (even I think
this, and I wrote it), that it defaults to installing all man pages into all
binary packages, which is almost never what you really want. Use -p to work
around it (ie, "dh_installmanpages -pxdelta" to only install the manpages
into the xdelta package).

I plan to correct this at some point, probably by writing a new version of
dh_installmanpages.

> Is there a way to let xdelta know that it depends onto libxdelta1
> because of the shared library dependency, maybe using a shared library 
> mapping file?

Maybe try a debian/shlibs.local file?

> 3) Shared dependency again
> - --
> Since I have a debian/libxdelta1.files file, at the time of ldd on
> xdelta, the libxdelta1.so library cannot be found and I had to add a
> LD_LIBRARY_PATH=debian/libxdelta1/usr/lib before dh_shlibdeps. Is
> there another way to do this? Shouldn't it add this automatically,
> getting this information from the debian/control file?

I can't think of any general way to make debhelper look at the control file
and know it needs to set a LD_LIBRARY_PATH.

I typically hardcode this dependancy info into the control file when I'm in
this siutation. Anyone else have a better way to handle it?

> 4) Links to shared libraries in *deb file
> - -
> Lintian reports:
> W: libxdelta1: non-dev-pkg-with-shlib-symlink usr/lib/libxdelta.so.1.0.0 
> usr/lib/libxdelta.so
> What should I do about this?

W: libxdelta1: non-dev-pkg-with-shlib-symlink usr/lib/libxdelta.so.1.0.0 
usr/lib/libxdelta.so
N:
N:   Though this package is not a -dev' package, it installs a symbolic
N:   link referencing the corresponding shared library, where the link name
N:   does not include the version number of the shared library.
N:   
N:   If there is also a -dev' package for this shared library, this is
N:   most likely a bug. If this is a small package which includes the
N:   runtime and the development libraries, this is not a bug. In the
N:   latter case, please contact [EMAIL PROTECTED] about this so
N:   that this error gets included in the overrides file for Lintian. (With
N:   that, Lintian will ignore this bug in the future.)
N:

Don't install that symlink in the xdelta1 package, put it in xdelta1-dev.

-- 
see shy jo