Re: RFS: qttube
Siegfried-Angel <[EMAIL PROTECTED]> wrote:
> Sorry, the files had wrong versioning (-0ubuntu1) and I corrected
> that. You can dget it from here now:
> http://mentors.debian.net/debian/pool/main/q/qttube/qttube_0.2~pre1-1.dsc
OK.
> 2007/8/8, Florent Rougon <[EMAIL PROTECTED]>:
>> Maybe your qttube.post{inst,rm} are missing the #DEBHELPER# line?
>
> If it isn't clear in my last message, it's debhelper who generates
> that files during the build.
No, I wrote qttube.post{inst,rm}, not qttube.post{inst,rm}.debhelper,
and I meant it.
You're missing these files in the .deb. Check with mc (simply hit Enter
on the .deb and have a look at what is shipped there). The reason is
most probably because you're not using dh_installdeb.
Apart from that, your packaging looks quite broken to me (sorry for
being blunt, don't take it bad---everyone has to learn one day or the
other).
The most broken thing is that your binary package is arch: any, whereas
it should be "arch: all" since Python code runs on all platforms and
doesn't need to be compiled specifically for each platform.
Next, I'd say the way you call the main python module is wrong:
,[ /usr/bin/qttube ]
| #! /bin/sh
|
| cd /usr/share/qttube/src
| python ./qttube.py "$*"
`
IMHO, /usr/bin/qttube should be something like that:
,
| #! /usr/bin/python
|
| # Maybe fiddle here with sys.path to have your private python modules
| # available to "import".
|
| import
|
| .run()
`
I see you're calling dh_pysupport in binary-indep, but AFAICS, this
currently does absolutely nothing to your .deb file. I think you're
misusing dh_pysupport ATM.
Also, your rules file contains way too much stuff from the dh_make
template, such as the useless configure* targets. You should understand
it fully and only let what is useful.
I suggest to:
- read documentation on dh_pysupport;
- look at other packages in the archive that are using it;
- and then kindly ask on debian-python for someone to check your
packaging (I personally have not yet packaged anything in Python
with the "new" Python Policy, so I couldn't help much here).
HTH.
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: qttube
Hi,
Siegfried-Angel <[EMAIL PROTECTED]> wrote:
> The package appears to be lintian clean, except for this messages
> (checking the .deb):
> - E: qttube: postinst-does-not-call-updatemenus usr/share/menu/qttube
> - E: qttube: postrm-does-not-call-updatemenus usr/share/menu/qttube
> However, qttube.postinst.debhelper and qttube.postrm.debhelper files
> are generated during build and both call update-menus, so I don't know
> what the problem is.
Maybe your qttube.post{inst,rm} are missing the #DEBHELPER# line?
> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/q/qttube
> - Source repository: deb-src http://mentors.debian.net/debian unstable
> main contrib non-free
> - dget
> http://mentors.debian.net/debian/pool/main/q/qttube/qttube_0.2~pre1-0ubuntu1.dsc
% dget -x
http://mentors.debian.net/debian/pool/main/q/qttube/qttube_0.2~pre1-0ubuntu1.dsc
dget: retrieving
http://mentors.debian.net/debian/pool/main/q/qttube/qttube_0.2~pre1-0ubuntu1.dsc
--18:10:02--
http://mentors.debian.net/debian/pool/main/q/qttube/qttube_0.2~pre1-0ubuntu1.dsc
=> `qttube_0.2~pre1-0ubuntu1.dsc'
Resolving mentors.debian.net... 85.214.70.36
Connecting to mentors.debian.net|85.214.70.36|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
18:10:02 ERROR 404: Not Found.
dget: wget qttube_0.2~pre1-0ubuntu1.dsc
http://mentors.debian.net/debian/pool/main/q/qttube/qttube_0.2~pre1-0ubuntu1.dsc
failed
/tmp %
Hmmm.
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mini-dinstall, repository signing and apt-get authentication
Hi, Long before I heard about reprepro, I also wrote my own Python script to manage my local and remote Debian repositories (and I'm still using it): http://people.debian.org/~frn/fmdr documented at: http://people.debian.org/~frn/fmdr.txt To follow the pattern on http://wiki.debian.org/HowToSetupADebianRepository, it has these features: Automatic repositories: Yes Incoming mechanism: not sure what this means; to upload a package, you need to pass a .changes file to the --add option. Pools: Yes GPG signing: Yes HTH. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hfsprogs - mkfs and fsck for HFS and HFS+ file systems
Warren Turkal <[EMAIL PROTECTED]> wrote: > Why does this matter? I don't see every other package specifically > mentioning who made it or what OS it was originally developed for. Of course it matters. I don't know whether there is an official (i.e., from Apple) public full specification for HFS+, but I suspect it is not the case. Which means that Apple developers are obviously in a better position than most other people to write tools dealing with HFS+. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/control - Build-Depends vs. Build-Depends-Indep for newbies (+solution)
Joachim Reichel <[EMAIL PROTECTED]> wrote: >> Now here's the part that I forgot: debian/rules usually has a binary-arch and >> binary-indep target. Run "debian/rules clean binary-arch" and now you can >> check whether the package will also run fine on a Debian autobuilder. > > The problem is that sbuild invokes the build target (which also depends > on build-indep), but does not pay attention to Build-Depends-Indep. There is a thread about this mess currently running on debian-devel. It was started with the following message: http://lists.debian.org/debian-devel/2007/06/msg00923.html -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: staying in stable but compiling for sid
Hi, Romain Beauxis <[EMAIL PROTECTED]> wrote: > Well, if it's only meant for using the application in your current X server, > you simply have to bind mount the /tmp directory in the chroot: > mount -t none -o bind /tmp /path/to/chroot/tmp > > I think it's enough to get the chroot to use the X server with UNIX sockets.. > > Of course if you don't have the same users in the chroot, you may also > xhost + > to allow other users.. > Et voila ! Even with the same user, it's not enough. You need to import the MIT-MAGIC-COOKIES in the chroot if you want to avoid the 'xhost +' security hole. The advantage of this solution is that it's probably faster than TCP connections to localhost. The main disadvantage is that /tmp isn't anymore isolated in the chroot. Programs in the chroot are fiddling with your normal /tmp. To avoid that, it's problably enough to mount --bind only /tmp/.X11-unix, instead of the whole /tmp. I didn't try it, though. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: staying in stable but compiling for sid
[Running X apps in a chroot] Székelyi Szabolcs <[EMAIL PROTECTED]> wrote: > You can. Just run an sshd inside the chroot and enable X forwarding on > the ssh server sitting inside and the ssh client connecting from outside > (from an xterm, of course). There is another way, which I've been using for years: - in the chroot, arrange to have 'DISPLAY=localhost:0.0'; - out of the chroot, run your X server in a way that it does listen to TCP connections (for me, this means ommitting the '-nolisten tcp' arguments that are by default appended to the /usr/bin/X call in /etc/X11/xdm/Xservers). Of course, if you do this, I strongly suggest to configure your firewall so that the TCP ports X is listening on are only accessible from 127.0.0.1, not from your network interfaces connected to the wild world (the ports used for this start at 6000; every display takes up one port). - arrange to have a script transfer the MIT-MAGIC-COOKIES (with xauth) from the user running the X session out of the chroot to the user running the X apps in the chroot, so that X connections to your normal X server are authorized for the apps you run in the chroot. This is a bit of a hack, but it does work. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make or $(MAKE) ?
Charles Plessy <[EMAIL PROTECTED]> wrote: > As one of the program I package was recently automakified, I had to > change debian/rules to deal with this. While comparing with other > packages, I realised that often $(MAKE) is used instead of make in > debian/rules. In case of trivial packages which do not seem to expect > something fancy from the enviroment, are both commands equivalent ? I think $(MAKE) is useful when your make binary is called "gmake", for instance. This shouldn't be the case on Debian, but I think it's a good habit to take. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Claiming a binary name used in Sarge but not in Etch.
Charles Plessy <[EMAIL PROTECTED]> wrote: > #!/bin/sh > echo -e "AMAP is now available under /usr/bin/amap.\nThis wrapper > (/usr/bin/amap-align) will be removed in the future." > exec /usr/bin/amap "$@" 'echo -e' is not specified by POSIX. If you want to use escapes such as \n, you'd better use printf instead of echo. > I am just wondering if the quotes around $@ are necessary... Yes. The quotes are necessary so that arguments containing spaces aren't mangled (yes, this is a weird syntax, but it's supposed to be used this way). -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where to mention, when several tarballs are merged into one .orig.tar.gz
Russ Allbery <[EMAIL PROTECTED]> wrote: > I still think that debian/copyright is a more natural location for this > information. debian/copyright is where we're required to specify the > source of the upstream tarball. Any customizations to the upstream > tarball seem to me to be part and parcel with specifying its source. > Plus, usually describing the repackaging only takes a sentence or maybe a > paragraph, which is a bit short to warrant a separate file. Makes sense. OTOH, using a separate well-known file makes it easy to see at first glance that the upstream tarball has been repackaged. I'd say that, if you're using README.Debian-source, you should mention the repackaging in debian/copyright along with a pointer to README.Debian-source for the details. > I'll open a wishlist bug against developers-reference. Okay. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where to mention, when several tarballs are merged into one .orig.tar.gz
Hi, Daniel Leidert <[EMAIL PROTECTED]> wrote: >> Definitely README.Debian; probably a good idea in "copyright", where you >> mention the download location. The Developers Reference gives several useful hints for this situation and suggests[1] to use a more specific file: README.Debian-source. [1] http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html (§ 6.7.8.2, "Repackaged upstream source") > Do I understand it correctly, that it is only invoked, if run > > fakeroot debian/rules get-orig-source I fail to see why fakeroot should be needed here. > Or is it also invoked in a different case (if e.g. the .orig.tar.gz is > missing)? I don't think so. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Legends The Game, new debian package
olaf <[EMAIL PROTECTED]> wrote: > I havnt uploaded anything yet and I doubt that I am able to upload the files > with suse-linux at my school (no dput?). What shall I do? :( Presumably, putting all the following files: /usr/bin/dput /usr/bin/dcut [not sure if this one is actually needed] /usr/share/dput/helper/dputhelper.py /usr/share/dput/ftp.py /usr/share/dput/http.py /usr/share/dput/https.py /usr/share/dput/scp.py /usr/share/dput/local.py /usr/share/dput/rsync.py in the same directory would be enough, provided there is Python installed and you have a correct ~/.dput.cf. *But* you shouldn't sign the .dsc and .changes files at your school, because you don't want to type your GnuPG passphrase on an untrusted system (malicious users could be sniffing keystrokes)... -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: softbeep (updated package)
Damyan Ivanov <[EMAIL PROTECTED]> wrote: > 3.7.2.2Oct 2006 > * Maintainer scripts must not be world writeable (up from a > should to a must) [6.1] > > IMHO, this is something that makes 3.7.2.0 and 3.7.2.2 two non-equal > Policy versions. I wonder why wasn't this 3.7.3.0 instead? Hmmm... maybe because the "should" in 3.7.2.0 was actually obviously a "must" for security reasons? -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed configuration files?
Marc Haber <[EMAIL PROTECTED]> wrote: > I doubt this. The code is definitely not what I call complex. The tetex-bin package is, but not that particular piece of code, once isolated. > Additionally, this is a huge waste of maintainer time. Code like this > _BELONGS_ into a standardized tool. Following your course of > argumentation, why not have debhelper removed from the archive? You're resorting to hyperbole and putting words in my mouth (sorry, don't know how to express that well in english). Of course a standard tool for doing that would be nice, but there is no such tool now, as it seems. Now, ask yourself: when debhelper didn't exist, did people refuse to make packages because "there ought to be a standard easy-to-use tool for doing all these little things"? As Manoj explained you, a standard tool won't magically pop up if everyone is passively waiting for it. > I still feel that the right place to do this is the tool that claims > to be able to replace dpkg conffile (sic!) handling, ucf. This "sic" has nothing to do here. ucf indeed performs a comparable task as dpkg's conffile handling. Remember: dpkg does _nothing_ particular for configuration files that are not conffiles. The particular handling that ucf is trying to replace is therefore aptly named "dpkg's conffile handling". -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SVN snapshot versioning
Russ Allbery <[EMAIL PROTECTED]> wrote: > In other words, use + if you're packaging > that version plus some additional upstream modifications, and use > + if you're packaging an alpha or beta arelease ^ I hope you meant '~' here. > of . Well, you're free to do what you want with that. I gave my opinion, no need to repeat it. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed configuration files?
Marc Haber <[EMAIL PROTECTED]> wrote: >> I didn't know you were alone maintaining a hundred of packages that need >> this particular removal code. Interesting. > > You seem to be deliberately misunderstanding me. I'll stop wasting my > time. I meant that when a maintainer copies code in its maintainer scripts, he *must* read the code carefully and understand it. Therefore, if a hundred maintainers do that as you suggest, there is a very high probability that most, if not all, bugs are found during the process. You know, the eyeball theory. But here, it really should work, as maintainers are *really* expected to carefully check what they put in their maintainer scripts (contrary to the general flaw in the eyeball theory, where the actual eyeballs scrutinizing the code are not that numerous for most projects IMHO). And finally, please accept my apologies for having wasted your precious time correcting your question (where the use of "conffile" was wrong, and that of ucf not even mentioned), your algorithm (which was missing 'ucf --purge') and extracting the relevant portion of code from tetex-bin that does what you want. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed configuration files?
Marc Haber <[EMAIL PROTECTED]> wrote: > These are 23 lines of code which have the potential for a lot of bugs. > I do not think it is a good idea to cut&paste this code into a hundred > packages. I didn't know you were alone maintaining a hundred of packages that need this particular removal code. Interesting. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SVN snapshot versioning
Manoj Srivastava <[EMAIL PROTECTED]> wrote: >> Ah, so now that we have this '~' allowed by dpkg, we have to use it >> everywhere? > > No, but we should use it in situations for which is was > specifically designed for, no? Precisely. And it was *not* designed for CVS/SVN/whatever RCS snapshots. AFAIK, it was designed for Release Candidates, which are well-known for exhibiting this problem: 1.0 < 1.0rc1 > This is massively confused. Sorry, not at all. Besides what Martin explained, using 2.1 in your version number without knowing for sure that 2.1 is going to be the next release is ugly, even if it were harmless (which is not the case). Better use something you do know: if this SVN snapshot is based on 2.0, then use 2.0. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SVN snapshot versioning
"Andrew Donnellan" <[EMAIL PROTECTED]> wrote: > So for a snapshot of revision 91 between stable version 2.0 and future > version 2.1, would something like: >2.1~20070123svn.r91 > > be OK? Ah, so now that we have this '~' allowed by dpkg, we have to use it everywhere? You cannot predict the future. It might me that next version is not 2.1 as you expected, but, e.g., 3.0. Why not base your version number on things you *know* for sure: that the last released version was 2.0? Therefore, I'd suggest something like 2.0+20070123svn.r91 (or without the date, for those who don't like it---personally, I find it useful, even if not atomic-precise; OK, since some of you want to nitpick with timezones here, the correct solution while keeping the date would be more like 2.0+svn.r91.20070123, to ensure that package versions are sorted based on the SVN revision and not the date). This has two more advantages: - '+' has a somewhat intuitive meaning here (which '~' definitely doesn't have): what you're packaging is version 2.0 "plus" (enhanced with) some more changes that are found in SVN revision 91, which was commited about 2007-01-23. - works with older dpkg. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed configuration files?
"Margarita Manterola" <[EMAIL PROTECTED]> wrote: > The subject still says "configuration file" and not "conffile". > There's a difference between them, and you should know it. The subject here says "configuration file" because I fixed it. It seems you are the one who doesn't know the difference between a "configuration file" and a "conffile". I repeat: Marc said his file was *not* managed by dpkg. As a consequence, it is not a conffile. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed configuration files?
Marc Haber <[EMAIL PROTECTED]> wrote:
> The file is under ucf control (I omitted that to lessen complexity),
Hey! We are doctors. You have to tell us _everything_. :-)
> but ucf does not know about the file any more if it is not in the new
> package and will therefore not handle it.
Uh, if you don't 'ucf --purge' it, I fear it will remain in the ucf
cache. There is code doing what you want in tetex-bin (not written by
me). For instance, in debian/common.functions.in, you can find:
ucf_md5sum(){
file=$1
md5sum=$(grep "$file$" /var/lib/ucf/hashfile | cut -f 1 -d ' ')
if [ -z "$md5sum" ]; then
get_sarge_md5sum_from_list $file
fi
echo $md5sum
}
[...]
preinst_remove_or_move_ucf(){
file=/etc/texmf/$1
newname=$(get_newfilename $1)
debug $file
test -f "$file" || return 0
debug "handled\n"
oldmd5sum=$(ucf_md5sum $file)
currmd5sum=$(md5sum $file | cut -d ' ' -f 1)
if [ "$oldmd5sum" != "$currmd5sum" ]; then
mv $file $oldstuff_dir/$(basename $file).$PREINST_MOVE_EXT
else
rm $file
if [ -x /usr/bin/ucf ]; then ucf --purge $file; fi
fi
}
HTH.
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed conffiles?
Santiago Vila <[EMAIL PROTECTED]> wrote: > Instead of 1,2,3 you could do 1,2,3 only when upgrading from a version > previous than the one not having a.conf anymore Sure. > and in case that (3) happens, keep a.conf untouched, instead of > renaming it (assuming the program will not read a.conf anymore). Hmm, I don't like this much, because it contributes to /etc pollution. There are so many things in that directory that it's often difficult to know when you can safely remove something that looks like cruft (especially after dpkg's messages "Non-empty directory 'foo' coudn't be removed" or so). So, IMHO, it's much better when the maintainer scripts of the Package Who Knows tell you that $file can be safely removed (and even better, give it a name ending in .package-old, as Marc suggested). -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed configuration files?
Hi, Marc Haber <[EMAIL PROTECTED]> wrote: > I have a package with a bunch of configuration files that are managed > by my maintainer scripts and not by dpkg. Therefore, these configuration files are *not* conffiles. Your Subject line was misleading (especially considering we are on -mentors). > (1) Let the new package version know about the md5sum of the last > version(s) of a.conf that were in the package. > (2) If one of the md5sums matches, the file has not been changed, > remove it. > (3) If none of the md5sums matches, the file has locally been changed, > rename it to a.conf.package-old With a little message in (3) to let the admin know that he can safely remove a.conf.package-old. > Is that acceptable? Or is there anything easier, more elegant, more > policy compliant? I think it's the usual, and correct way (sometimes actually performed by ucf, but since you're getting rid of the file, there is no point in putting it under ucf control). -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: fspanel -- minimalist panel for X
Daniel Baumann <[EMAIL PROTECTED]> wrote:
> * $(MAKE) install DESTDIR=`pwd`/debian/fspanel
>
> -> do *not* use `pwd`, but $(CURDIR).
And when using $(CURDIR), please enclose the path in double quotes (""),
because $(CURDIR) may well contain spaces. There are so many packages
that get this wrong...
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Permissions for kernel device and /proc/
Hi,
I'm not expert in these matters, but since nobody answered, I'll give it
a try.
Hynek Hanke <[EMAIL PROTECTED]> wrote:
> I have no direct controll over /dev/softsynth and /proc/speakup as
> they are not created by my package.
Sounds like the crucial point to me. As for /proc/speakup, I think the
owner and permissions should be set in the kernel patch that creates
this file. As for /dev/softsynth, I believe you have to make sure the
owner/perms are set correctly in those two places:
- MAKEDEV
- udev
The former should be done in package 'makedev'. Concerning the latter,
probably the package shipping the kernel patch you mentioned should
provide something under /etc/udev ("udev rules") to ensure proper owner
and perms.
I don't think these jobs should be done in the package shipping the
userspace app, especially if the kernel interfaces you mentioned are of
more general use than this only userspace app.
> I could just write it in the README that my package expects such and
> such permissions on the devices, but this will confuse many users (the
> application won't work just after it is installed).
Documenting, if done properly, cannot harm. But if the owner/perms are
set correctly in the right place (the package providing the interface
files in /proc and /dev), I think all you'll have to document in the end
is that users have to be in $group in order to use the userspace app.
> I can change the ownership of /dev/softsynth from the package install
> scripts, but this is of little help if /dev/softsynth is dynamically
> created. How to do it properly?
I believe the answer is writing appropriate udev rules. But making sure
MAKEDEV Does The Right Thing is probably a good idea too.
HTH,
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Recurring "please do" patterns in debian-mentors
"Paul Cager" <[EMAIL PROTECTED]> wrote:
> The policy *does* distinguish between lines starting with one space
> (paragraphs with word-wrapping) and lines starting with two or more spaces
> (non-wrapped if panning is possible, otherwise hard-wrapped), so I think
> there is a strong policy basis for the "Homepage" comment. Apart from
> anything else, it makes cutting and pasting URLs easier.
I wouldn't be so sure.
If len("Homepage: " + URL) <= screen_width, then both cases lead to the
same result[1]. But if this is not true, what do you expect from the
frontend when a single leading space was used? Word-wrapping will cause
something like that:
Case 1 (single leading space)
~
Homepage:
http://very-lng-URL
which means you can copy and paste URLs in *one* step that are much
longer than in the case of two leading spaces:
Case 2a (two leading spaces, panning enabled)
~
Homepage: http://very-loo
-> you have to pan the screen to access the second part of the URL
-> copy/paste needs *two* steps
Case 2b (two leading spaces, hard wrapping instead of panning)
~~
Homepage: http://very-loo
oong-URL
-> copy/paste is likely to need two steps, but not necessarily
And even then, I am being too kind to the two-leading-spaces cases,
because in both 2a and 2b, the front-end should use the last character
of the first line to indicate that the line is incomplete. Otherwise, in
case 2a, you cannot know that you have to pan in order to see the full
URL, and in case 2b, you cannot know (without resorting to the context)
that the second line is actually the continuation of the first line. And
that special "continuation character" would presumably kill the
possibility of copy-pasting the URL in one step in case 2b.
OK, there remains an obscure point in case 1, when the URL is longer
than a screen line. Should it be hyphenated? And if so, how, where? But
it isn't really worse than what happens in case 2, and is only triggered
with very long URLs (you start having problems in case 2 with shorter
ones).
Anyway, the URL should be a control field; then, we wouldn't be having
this rather pointless discussion.
[1] Well, not quite: the single-leading-space case wins because Policy
says that the leading space "will usually be stripped off", whereas
in the case of two leading spaces, "None, one or two initial spaces
may be deleted". As a consequence, the usable length of a line is
"usually" greater or equal in the one-leading-space case than in
the two-leading-spaces case. But that's a detail.
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: core++
Daniel Baumann <[EMAIL PROTECTED]> wrote: > * a build-depends on gawk | awk doesn't make sense. either you use > specifically features of gawk, and then you only depend on gawk, or > your depends is fulfilled by any awk implementations, which means, > you don't need to list it Err, no. Virtual packages aren't supposed to be used this way. Whenever one depends or build-depends on a virtual package, it should be done just like Joachim did: 'gawk | awk', where gawk is a real package Providing the virtual package awk; this allows to control which package is installed when doing non-interactive installations (such as happens on buildds). It also allows apt frontends to select the default choice when something depends on awk (but in this case, the user can choose to install another implentation of awk to satisfy the dependency). -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages (using C++) for two different distributions
Asheesh Laroia <[EMAIL PROTECTED]> wrote: > I'm not a Debian developer, but I would think the easiest thing to do is to > install pbuilder and create a chroot for Debian. Since the source package > will be the same (libgmp-dev, I'd guess) for both, you can use pbuilder to > generate the Debian package in a chroot. This is a possibility. You can also use debootstrap directly to generate a chroot environment and work there whenever you need (no need to compact the filesystem). There are packages in Debian that are supposed to ease the creation of such chroots, but I didn't try them. And there is also cdebootstrap, as an alternative to debootstrap (didn't try it either). -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Alternative TeX Live build-dependency [was: Build-Depends-Indep and build target]
While we're at it, you should also consider adding the appropriate texlive packages to your B-D as an alternative to the tetex packages. Sooner or later (may well happen for lenny), the tetex packages will be removed, so you'll have to do that anyway. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Build-Depends-Indep and build target
Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > The underlying problem is that build-arch/indep are not mandatory and > thus building must call the "build" target. This makes sense, thanks for pointing it out. > If build-indep does take a considerable time then you can use the > following hack: Indeed, it should work, but is rather ugly; I'd rather see Policy amended to make build-arch and build-indep mandatory. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Build-Depends-Indep and build target
Hi, Joachim Reichel <[EMAIL PROTECTED]> wrote: > Hi, > > section 7.6 of the policy states that Build-Depends-Indep must be > satisfied if the build target is invoked. [...] > Now, if my sponsor uploads this package, it will still fail, right? If > Build-Depends-Indep is not satisfied by accident, the build will fail > again ... Your analysis looks correct to me. It is a known fact that the buildds don't conform to Policy as far as Build-Depends and Build-Depends-Indep are concerned. > So what should I do? I suggest you read the following post: http://lists.debian.org/debian-mentors/2006/09/msg00229.html The first paragraph by Wouter Verhelst (longtime buildd admin) tells you what buildds from real life expect, which explains why your build failed: because your Build-Depends line didn't contain "all packages that are required for a 'dpkg-buildpackage -B' run to complete successfully" (since, as you noticed, 'dpkg-buildpackage -B' does call 'debian/rules build' and your 'build' target requires tetex-bin, which is not in your Build-Depends). The last paragraph, by Scott James Remnant, confirms this and tells you in a more straightforward way what you should do to have the package build successfully on the buildds: include tetex-bin in your Build-Depends, since it's needed in the 'build' target. But again, you're right on this: according to Policy, your package build should not fail due to latex being unavailable. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
Warren Turkal <[EMAIL PROTECTED]> wrote: > Okay, the build deps now look like: > Build-Depends: cdbs, debhelper (>= 5), autotools-dev, gfortran, tex, texi2dvi Ugh, what's this 'tex' package? Before blindly doing what others tell you, you'd better think a little bit (I'm sure Patrick didn't want to deceive you; just to make you think about which package(s) to Build-Depend on in order to get your texi2dvi call running properly). -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gcin
Hi, Ben Hutchings <[EMAIL PROTECTED]> wrote: > The requirement for "#! /" was documented in 4.1BSD but the > implementation never really required it - compare > http://www.in-ulm.de/~mascheck/various/shebang/exec.2.html and > http://www.in-ulm.de/~mascheck/various/shebang/sys1.c.html > > (Found via http://en.wikipedia.org/wiki/Shebang_(Unix) ) Thanks to you and Russ for the details on that portability question. Regards, -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gcin
Daniel Baumann <[EMAIL PROTECTED]> wrote: > * this is ugly: > > ---snip--- > #! /bin/sh /usr/share/dpatch/dpatch-run > ---snapp--- > > and this is beautiful: > > ---snipp--- > #!/bin/sh /usr/share/dpatch/dpatch-run > ---snapp--- How so? There are two reasons why I always use the first style: - it is surely easier to read, the interpreter name being separated by spaces from the rest; - I was told it is more portable (I once looked for confirmation with a little Google search but that was a while ago and I forgot the exact reasons that were mentioned). What are your arguments for advocating the second style? -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: RFS: renrot - a program to rename and rotate files according to EXIF tags [EMAIL PROTECTED]
Mike Hommey <[EMAIL PROTECTED]> wrote: > If you mean rotation of pictures depending on the orientation tag in > the exif data, jhead already does that, lossless, with jpegtran (which > is in libjpeg-progs) Since we are talking about this, I'd like to mention exifautotran(1), which also does that, and is my preferred one (maybe because I didn't use jhead/jpegtran in the best way). For me, a simple 'exifautotran *' in a directory containing (only) JPEG images with the right Exif orientation tag Does The Right Thing. % dpkg -S exifautotran libjpeg-progs: /usr/bin/exifautotran libjpeg-progs: /usr/share/man/man1/exifautotran.1.gz % -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Depending on an essential package
Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > Reduces the memory wasted and speeds up processing in dpkg, dselect, > apt, aptitude, britney, ... It's also useful for simple humans looking at the dependencies of a package: having all dependencies, including those on essential packages, would clutter the Depends line without adding much value in most cases. For instance, I would not be very interested to learn that $PACKAGE depends on debianutils for the only reason that it uses /usr/bin/which or /bin/mktemp in a script. But several such explicit dependencies would really clutter the Depends line, and /that/ would be annoying. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: naming and relationships of development packages
Székelyi Szabolcs <[EMAIL PROTECTED]> wrote: > That's right. But why is Replaces needed in the case of an MTA? If a > package Providing mail-transport-agent is installed, and the user is > about to explicitly install another package which also Provides and > Conflicts with mail-transport-agent, then the currently installed > package will be removed anyway before the new one is installed. I do not > see the need for Replaces. I didn't say it's needed. I even posted an experiment showing that with the tools from unstable, it makes no difference in: apt-get -s install > But that's not right. With this, what you've tested is installing the > virtual package installs the real package instead. That's the way it > should be. It shows that, even when not using Replaces, things do work in this situation. > But the question is: is Replaces needed to get the previous version > removed upon installation of the new package? What previous version are you talking about? Which "new package"? > What if the user forces the installation of the new package by > overriding the conflict (dpkg --force-conflicts)? Then Replaces can be > used to take over the files contained in both packages, so dpkg won't > complain about overwriting files which are contained in another package, > resulting in a somewhat more consistent installation. So, it's right because dpkg doesn't complain when the user it shooting itself in the foot? If the user uses --force-conflicts, he is on its own. > I disagree. Provides is used for that. It has nothing to do with Replaces. Fine. I tried to explain how the use of Replaces in the MTA example could be justified with the information given in Policy. If that is not enough for you, go argue with the Policy maintainers. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: naming and relationships of development packages
Hi, Székelyi Szabolcs <[EMAIL PROTECTED]> wrote: > The soversion is usually added to the -dev package name to be able to > support multiple versions of a library off-line, which means all > versions can be found in the archive, but only one can be installed on > the user's machine. The question is, which mechanism should be used to > accomplish this? Do we need Replaces:? I think Provides and Conflicts is > enough. I think it's an analogous case to that of the MTA in Policy, and therefore, that Replaces should be used. However, I'm not sure whether any of our current tools (apt, dpkg, etc.) makes any difference if it is used or not, in this context. Actually, I tested one case with the apt from unstable: apt-get -s install Having the Replaces in addition to the Provides and Conflicts made no difference: foo 1.0-4 ~ Provides: foo-pkg Conflicts: foo-pkg # apt-get -s install foo-pkg Reading package lists... Done Building dependency tree... Done Note, selecting foo instead of foo-pkg The following NEW packages will be installed: foo 0 upgraded, 1 newly installed, 0 to remove and 240 not upgraded. Inst foo (1.0-4 Florent Rougon's packages for experiments:unstable) Conf foo (1.0-4 Florent Rougon's packages for experiments:unstable) foo 1.0-5 ~ Provides: foo-pkg Conflicts: foo-pkg Replaces: foo-pkg # apt-get -s install foo-pkg Reading package lists... Done Building dependency tree... Done Note, selecting foo instead of foo-pkg The following NEW packages will be installed: foo 0 upgraded, 1 newly installed, 0 to remove and 240 not upgraded. Inst foo (1.0-5 Florent Rougon's packages for experiments:unstable) Conf foo (1.0-5 Florent Rougon's packages for experiments:unstable) You can check how this situation is handled in the archive with the following command: grep-available -F Provides -s Package,Provides,Replaces,Conflicts \ -e ".*-dev" | less You'll see that many packages use the Replaces, and many don't. Some even Replace and Conflict with the various -dev packages, but I don't think it's a good idea (Replacing and Conflicting with the virtual package should be enough): Package: libcupsys2-dev Provides: libcupsys-dev Replaces: libcupsys1-dev, libcupsys-dev, cupsys (<< 1.1.22-3) Conflicts: libcupsys1-dev, libcupsys-dev, cupsys (<< 1.1.22-3) > I'm not sure I understand the example about MTAs in Policy 7.5.2. Why is > Replaces needed at all in this particular case? Is this also valid in > the case of development packages? Why aren't Conflicts + Provides enough? Quoting § 7.5.2: Secondly, Replaces allows the packaging system to resolve which package should be removed when there is a conflict Based on that, I'd argue that the meaning of the Replaces in the MTA example is: Any real package providing mail-transport-agent should be favored upon the virtual package mail-transport-agent. i.e., if something pulls in mail-transport-agent for whatever reason (e.g., a dependency or 'apt-get install '), then in no case should the virtual package mail-transport-agent be installed; all other packages Replacing it are preferred to resolve the situation (which is fortunate, since of course, you cannot install a virtual package). At least, that's the way I understand it. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: swish++: A Simple Web Indexing System for Humans --- C++ version
Kapil Hari Paranjape <[EMAIL PROTECTED]> wrote: > As far as I understand it the DFSG does not apply to Copyright license > documents. For example the GNU "COPYING" document contains exactly > the same sentence. That's right. > The file "copying.dj" is DJ Delorie's copyright license document so it > *can* insist that it be distributed verbatim. Yes. Although we prefer license texts that are DFSG-free, this has never been enforced in Debian AFAIK and is not about to change. > I would rather not repack the tarball unless it is absolutely > necessary. At least, repacking in order to remove a license text that is not DFSG-free is certainly not an option! -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What to do with word documents ?
gregor herrmann <[EMAIL PROTECTED]> wrote: > TTBOMK MS Office files don't contain any fonts (that's why they often look > suboptimal if used on a machine where the referenced fonts are > missing). I believe there is[1] an option in MSWord to embed the fonts in a document. But since it's an option, it's not always in use, which can lead to the experience you're reporting. [1] Or at least, was---last time I used MSWord was *long* ago. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What to do with word documents ?
Hi, Charles Plessy <[EMAIL PROTECTED]> wrote: > 1) How can I know if they are redistributable at all, for instance if > they contain non-free fonts? In the worst case, do I have to repackage > the sources as well? I'll leave that to the real experts on the matter. > 2) There are simple text versions of those documents, but they have many > pages, so I was considering to convert them to PDF or HTML. However, the > converter which gives the nicest results in my hands is openoffice. Is > ther a way to run it from the command line? I suppose this is doable with PyUNO (Debian package python-uno) or another language binding for OOo. But I've never used these beasts; just giving a pointer in case you didn't know about these. > Would it be considered as buildd sabotage ? Good question. :-P > 3) In general, is there a policy about MSWord documents? Never heard about that... -- Florent (sorry for not being able to help much, but...) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: flexbackup 'grave' Bug Resolved
"Kurt B. Kaiser" <[EMAIL PROTECTED]> wrote: > The QA upload switched from Build-Depends-Indep to Build-Depends and > I left that alone. Maybe both of these (identical) should exist? > Build-Depends: debhelper is necessary because dh_clean is in the clean > target, and Build-Depends-Indep might be needed since binary-indep > calls dh_* commands. It's not clear to me; enlightenment would be > appreciated! Here are a few messages on the matter that I found helpful, and thus kept for reference. HTH. http://lists.debian.org/debian-policy/2003/debian-policy-200309/msg00067.html , | Something like... | | `` 'Build-Depends' should contain all packages that are required for a | 'dpkg-buildpackage -B' run to complete successfully. Any packages | that are not requird for a 'dpkg-buildpackage -B' run, but that are | required for a plain 'dpkg-buildpackage' run should be put in | 'Build-Depends-Indep'. For reference, 'dpkg-buildpackage -B' calls the | 'foo', 'bar', and 'baz' targets of the 'debian/rules' file, whereas | 'dpkg-buildpackage' calls the 'foobar', 'quux', and 'quuux' targets.'' | | (dpkg-buildpackage's manpage doesn't tell which targets exactly are | called. If people accept the above, I'll make sure I find out, but I was | too lazy to read the code right now) | | -- | Wouter Verhelst | Debian GNU/Linux -- http://www.debian.org | Nederlandstalige Linux-documentatie -- http://nl.linux.org | "Stop breathing down my neck." "My breathing is merely a simulation." | "So is my neck, stop it anyway!" | -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. ` http://lists.debian.org/debian-devel/2003/debian-devel-200310/msg01460.html , | Scott James Remnant <[EMAIL PROTECTED]> wrote: | > On Sun, 2003-10-19 at 09:51, Adam Conrad wrote: | [...] | >> libtool fails to build from source on all the buildds[1] due to a missing | >> build-dep on texi2html. | | [...] | | > My reading of policy suggests that this is correct: | | > 8<8<8<8<8<8<8< | > `Build-Depends-Indep', `Build-Conflicts-Indep' | > The `Build-Depends-Indep' and `Build-Conflicts-Indep' fields must | > be satisfied when any of the following targets is invoked: | > `build', `build-indep', `binary' and `binary-indep'. | > | | [Flo] The following footnote is *not* part of the Debian Policy (see | above for the footnote mark). | | > [1] If you make "build-arch" or "binary-arch", you need Build-Depends. If | > you make "build-indep" or "binary-indep", you need Build-Depends and | > Build-Depends-Indep. If you make "build" or "binary", you need both. | > >8>8>8>8>8>8>8 | | > texinfo and texi2html are used in the "build" target. As far as I can | > tell this means that the buildd should be ensuring both Build-Depends | > and Build-Depends-Indep are installed before running it. | | > Have I read policy wrong, or is policy not entirely in accord with | > reality? | | [...] | | Afaik the latter, the buildds don't build the binary-all target and | won't install Build-Depends-Indep. | | This works: | * If your package only builds arch-dependent packages, don't use | Build-Depends-Indep | | * If your package only builds binary-all packages, you can choose | whether to use Build-Depends-Indep or Build-Depends. However many | packages need Build-Dependencies for the clean target (dh_clean), if | this applies you must use "Build-Depends". | | * If your package builds both binary-arch and binary-all packages, | list anything needed for build, clean, build-arch and binary-arch in | "Build-Depends" and anything _additionally_ needed for binary-indep | in "Build-Depends-Indep". ` -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problem building a package in buildd
[EMAIL PROTECTED] (Francesco Namuri) wrote: > I think this is the problem... It's a packaging problem? Doesn't look so. Maybe ask the buildd admins... -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging automation - separation of 'debian/' directory
Bas Wijnen <[EMAIL PROTECTED]> wrote: > Also, someone noted that this script is vulnerable to a symlink attack in > /tmp. I haven't found a good solution for that though, because I want to have > a reachable build tree under a "normal" name, where I can see what all the > files look like. If you *create* a *directory* in /tmp, it should be safe, because mkdir will fail if a symlink with the same name already exists. And when the temporary directory is created with the appropriate permissions[1], noone can fiddle with it. If you are in this case, please quote the relevant piece of code and the objection that "someone" made about this code. [1] mkdir(1) supports --mode, as does the mkdir(2) system call with its second argument, to avoid a race condition. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xmmsctrl
"Andrew Donnellan" <[EMAIL PROTECTED]> wrote: >> What does this do that python-xmms/pyxmms does not do? > > Maybe this might just be a *standalone application* rather than a library? The standalone application corresponding to (and relying on) PyXMMS is PyXMMS-remote (found in the pyxmms-remote Debian package). -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: urw-garamond -- scalable PostScript font from the Garamond family
Hi, Rogério Brito <[EMAIL PROTECTED]> wrote: > I just read the copyright file and I thought that it would be > distributable. Are there any conflicts in what is written there? I pointed out the problems I saw in the initial thread about this RFS. Please check the debian-mentors archives. > Please educate me regarding this. Wouldn't it be distributable even in > non-free? Not in non-free, not on mentors.debian.net, nowhere. Basically, IIRC, the license requires prominent notice in every file when changes are made to the fonts[1] stating at least the date and author of the changes. This clause of the license was not respected in the last package I reviewed. This must be fixed upstream. Upstream is alive, Debian-aware and friendly (hi, Ralf!)[2], so this should be doable. [1] Well, the license was not developed with fonts in mind, as it seems... [2] Walter Schmidt's cooperation is also probably needed for a new release, but I don't think it's a problem either. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: urw-garamond -- scalable PostScript font from the Garamond family
Rogério Brito <[EMAIL PROTECTED]> wrote: > I have been using your package for some time right now and it seems to > work fine. > > I would love to see your package uploaded to Debian and I have seen that > the latest version you published is both lintian and linda clean. This is all very nice, but last time I checked, it was undistributable (legally). -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request-For-Sponsorship (xfardic)
Often, changelog entries explain why certain technical packaging decisions were made (for instance, Build-Depend on "foo >= $version" because of $reason). These entries are definitely useful, even if they happened before the first release uploaded to the Debian archive. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] qterm: BBS client for X Window System written in Qt
"LI Daobing" <[EMAIL PROTECTED]> wrote: > These two files were not added by me. they are in the original > source[1]. so I think I have to repackage the source if I want to clear > the warnings. > > [1] > $ tar tzvf qterm_0.4.0pre4.orig.tar.gz | grep ex$ > -rw-r--r-- nichloas/nichloas1877 2003-04-29 15:46:07 > qterm-0.4.0pre4.orig/debian/manpage.1.ex > -rw-r--r-- nichloas/nichloas4547 2003-04-29 15:46:07 > qterm-0.4.0pre4.orig/debian/manpage.sgml.ex Another case demonstrating why upstream tarballs should not contain a top-level debian directory... -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to correctly patch without cdbs?
Olly Betts <[EMAIL PROTECTED]> wrote: > The autoconf manual, section 10.10 "Limitations of Shell Builtins" (in > the CVS HEAD version at least) says: > > `!' > The Unix version 7 shell did not support negating the exit status > of commands with `!', and this feature is still absent from more > modern shells (e.g., Solaris `/bin/sh'). [...] OK, thanks for the reference (yes, I am surprised). It doesn't say, though, whether legacy systems such as Solaris have a 'test' builtin that supports negation. ;-P Regards, -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to correctly patch without cdbs?
Grrmpfff... Florent Rougon <[EMAIL PROTECTED]> wrote: > I would be very surprised to know why. ^ interested (of course) And yes, surprised if that was true. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to correctly patch without cdbs?
Justin Pryzby <[EMAIL PROTECTED]> wrote: > It's my understanding that test ! is more portable than ! test (same > for [ !). I would be very surprised to know why. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: urw-garamond-no8
Kevin Bube <[EMAIL PROTECTED]> wrote: > Hi all, > > I uploaded a new package version to mentors.debian.net. The changelog > file lists all changes done. I think I addressed all problems which > still remained. http://mentors.debian.net/debian/pool/non-free/u/ is currently empty. Huh? > A slight catch: I did not Inherit FontName in defoma.hints, as I > understand the defoma documentation this is not necessary as I declare > FontNameN for each entry. Please correct me if I am wrong. I think you're right here. Good point. > I corrsponded with Walter Schmitd and Ralf Stubner about the license > problem concerning the missing modification notice in the modified > files. They will do a new corrected upstream release. OK. We'll have to wait for this to happen. > About Florent's suggestion to change the path names from garamond to > garamond-no8 Walter's opinion is clearly against this. His reasons are > not the 8.3 limits, but he thinks that if one insists on doing things > right one also would have to change the fonts' registration from urw* to > ueg*. This would cause (too) much trouble and as only some experts > notice the incorrectness, it is better to leave things as they are. Ahem, well... right... Regards, -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about linux-wlan-ng-firmware in main
Bas Wijnen <[EMAIL PROTECTED]> wrote: > Not at all, I am entirely looking at it from a user's perspective, in > particular a user which doesn't want non-free software (those people are the > reason contrib and non-free exist, so it seems appropriate to look especially > at them). No, there is a much more important reason why non-free exists: some of its contents cannot be legally distributed on CDs (and sold with magazines, etc.). -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Avoiding the Linux version of "DLL Hell"...
"Redefined Horizons" <[EMAIL PROTECTED]> wrote: > Here is my question. Can I create a custom Debian package for Library A that > satisfies the dependency requirements of Package A, but still keep the older > version of Library A required by my other programs? Of course. Look for example at the GTK+ library. In both sarge and sid, you'll find GTK+ 1.2 and GTK+ 2 (packages libgtk*), as well as packages using GTK+ 1.2, and packages using GTK+ 2. > In essence, I want to create my own custom Debian Packages to avoid > conflicts in package dependencies. Is this plausible? Yes, dpkg allows you to express dependencies in a comfortable way. Besides the New Maintainer's Guide, which you've already found, you should really read the Debian Policy to get a better understanding of these things. HTH, -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC/RFS: bfilter, aspell-hr, myspell-hr
Vedran Furaè <[EMAIL PROTECTED]> wrote: > Thanks for uploading. I see that parser at NEW didn't catch the "Closes:" > line. I will close that bug once it's accepted. If you used the right syntax, that probably happened because it wasn't part of the last changelog entry, in which case dpkg-buildpackage's -v option should have been used for the upload. Otherwise, it's a bug and should be reported. > What if I receive a bugreport which I don't know how to solve? For > example, a FTBFS on some "exotic architecture"? For this specific example, you should look for appropriate mailing-lists (the porters for that architecture / buildd admins, or a list for Debian users of that architecture). You should be able to find these lists on http://www.debian.org/ports/ (otherwise, Google and file a bug report to get www.debian.org updated). More generally, if there is a bug you really don't know how to solve, you can file an RFH bug on wnpp (Request For Help) to tell the world about it. See: http://lists.debian.org/debian-devel-announce/2004/08/msg0.html -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: optional building of a package
Charles Plessy <[EMAIL PROTECTED]> wrote: > I have made /usr/share/doc/probcons-extra a symlink to > /usr/share/doc/probcons (probcons-extra depends on probcons). Is it OK > to do such things? ^^ this is important Yes, this is written in Policy. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: urw-garamond-no8
Charles Plessy <[EMAIL PROTECTED]> wrote: > Le Fri, Jun 02, 2006 at 04:10:29PM +0200, Florent Rougon a écrit : >> The files pertaining to the Debian packaging are >> (c) 2006 Kevin Bube. >> > Maybe one could suggest a replacement for the word "pertaining", which > may be a bit complex for average non-native speakers? I'm all open for suggestions since... I am a non-native speaker. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Jython and its dependency on python2.1 (#362292)
Nicolas Duboc <[EMAIL PROTECTED]> wrote: > About the second issue, the current state of my work includes the > modules in the diff.gz file. This file is then 531K. Do you think it is > acceptable ? Maybe you'd be better off with something like quilt, dpatch or cdbs, that would allow clean separation of the various patches. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: urw-garamond-no8
Hi,
Kevin Bube <[EMAIL PROTECTED]> wrote:
> After reading bug #366234 I set debhelper requirement to >=5.0.35. See
Fine. That's also what I had done with lmodern in the meantime.
>> 3. I'm not a native english speaker, but I would modify the Description
>>field this way:
>
> [snip]
>
>>
>
> Okay, I applied your suggestion.
You forgot to add the "s" to "font" in the short description. Your
package is not shipping one font, but several fonts from the same
family.
> Okay, I chose a bit different style, but I hope to have reproduced all
> necessary information.
Yes, that looks good. You could change:
The files in the debian/ directory are
(c) 2006 Kevin Bube.
to
The files pertaining to the Debian packaging are
(c) 2006 Kevin Bube.
which is a bit broader (covers .diff.gz) and easier to understand for
people who don't know about the source package...
>> 8. There are many problems in your urw-garamond.defoma-hints file.
>>At first glance:
>>
>> - confusion in the Weight attributes;
Still wrong. You declare ugm Medium as Medium-weighted and ugm Regular
as Bold-weighted. This is the other way around.
>> - X-FontName not in accordance with your urw-garamond.scale;
This is fixed, but please use lowercase for these names.
>> - you should be using FaceNum and Inherit since you declare
>> multiple charsets in the .scale file;
Your Inherit has a Typo ("Priorty" instead of "Priority"). And why don't
you include 'FontName' and 'AFM' therein? For lmodern, I use:
Inherit = FontName Family GeneralFamily Weight Width Shape Direction Priority
AFM
> Okay, I rewrote the defoma-hints file. I hope I have it now, although I
> have to admit, I did not completely understand the charset stuff. I
> ommited many of the fonts mkfontscale found and only kept
> iso8859-{1,15} as these are the ones I am used to and know they
> work. How can one determine reliably which charsets a .pfb file
> contains?
I don't know of any other way than manually checking each character
defined in the charset... which is obviously a PITA.
As for the charsets, I am not opposed to declaring those that
mkfontscale found in your previous package:
iso8859-1
iso8859-15
-> probably OK
microsoft-cp1252
-> may be OK (I believe it is close to iso8859-1)
iso10646-1
-> of course, the whole charset is not covered in urw-garamond-no8,
but I don't think many fonts do cover it in its entirety... so,
I'm not sure about when it is appropriate to declare this
charset.
But there is a problem: you declare FontName1, Charset1 and X-FontName1
twice instead of using FontName2, etc. the second time.
> I used your sed script from lmodern (0.99.3-2) to generate the .scale
> file.
Well, the whole point is to use it at package build time...
Also, I wrote a sed script for lmodern but this awful language is hardly
readable; if you want to write a similar script in Python for your
package, that's perfectly fine with me.
> This omits the *-unregistered-font_specific entries. Is this on
> purpose?
Yes, I think it's useless to declare such a charset (in fact, the script
doesn't omit this charset specifically, but only extracts what is
declared in attributes matching the pattern 'X-FontName[0-9]'). OTOH, in
your case, the fonts are in Adobe StandardEncoding. This one could be
declared, as mkfontscale found out.
>> 14. The "dh_installdirs $(X11DST)" is feeling lonely. Merge it with the
>> first dh_installdirs call to save one Perl process per build. Same
>> thing with "dh_installdirs etc/X11/fonts/X11R7/Type1".
>
> Okay. I also dropped the X11R7 from the path.
Fine.
>> 15. The build will fail whenever the expansion of "$(CURDIR)" contains
>> spaces. You should use double quotes at several places.
>
> Hopefully done. I quoted all $FOOSRC variables, where the problem could
> occur.
Doesn't work. Try it.
> W: urw-garamond-no8 source: build-depends-without-arch-dep defoma
> W: urw-garamond-no8 source: build-depends-without-arch-dep tex-common
>
> Can they be ignored? The binary package depends on both.
As Frank wrote, they can be ignored. OTOH, it is easy to make them
disappear.
> Next week I will be on a conference where I won't be mailable. I guess I
> will be back online on Monday, June 12th.
OK, no problem.
I noticed a slight problem in your new debian/rules file: the following
comment:
# normally at build time nothing has to be done
is misplaced (the build target is several lines above).
And last but not least, the following clause of the license:
,[ PUBLIC ]
|If you have modified the Program, you must cause the Work
|to carry prominent notices stating that you have modified
|the Program's files and the date of any change. In each
|
Re: RFS: urw-garamond -- scalable PostScript font from the Garamond family
Hi, Kevin Bube <[EMAIL PROTECTED]> wrote: > The defoma-hints and scale files are indeed quite tricky. I modified the > scales file by hand as the font itself declares all shapes as medium, so > fontscale duplictes all fonts. I will reread the docs and rework the > defoma-hints. OK. BTW, since the defoma hints file contains the XLFD names of the fonts (those known to X11), I generate the .scale file from the defoma hints file in lmodern, using a sed script run at package build time. Maybe you'd like to do the same. > Do you think the name 'urw-garamond' should be changed at all, since > Ralf pointed out that 'URW Garamond' is not usually connected with > urw garamond No. 8? Maybe the package should be named 'urw-garamond-no8' > then? Yes, after rereading Ralf's comment, I think 'urw-garamond-no8' would be a better name. PS: your forgot to Cc Ralf; he is in the Mail-Followup-To header... Regards, -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] wormux - A funny fight game on 2D maps
Jean Parpaillon <[EMAIL PROTECTED]> wrote: > It's because someone suggested me to have the manpage in xml format so > that I could get it in pdf or dvi or I don't know... Well, XML isn't necessary for that. You can get DVI from *roff with 'man -Tdvi' and PDF with dvipdfm(x)... > ...Of course *roff format is enough for a game. Sure. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] wormux - A funny fight game on 2D maps
Jean Parpaillon <[EMAIL PROTECTED]> wrote: > - Manpage is in upstream. But manpage is in nroff format as I don't know > autotools enough to handle manpage transformation with it... What do you mean by manpage transformation? Transformation to .dvi? It's not unusual to have manpages in *roff format... -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: urw-garamond -- scalable PostScript font from the Garamond family
Hi, Ralf Stubner <[EMAIL PROTECTED]> wrote: > I have valid E-Mail addresses that do not contain my surname. ;-) Sure, but the license says you have to indicate your name *and* email address. You can't hide. :) > However, it was indeed an oversight to not mark the changed file > properly as required by the license. I will try to build a new version > soon, and since I by now know more about the internals of Type1 fonts, I > might even be able to build a better version. Great, thanks. > Note that my bug fix did not alter the metrics, hence tha .afm and > .pfm files are unchanged. OK. My reasoning about the .pfm was a bit confused, because for a moment I forgot that PFM stands for Printer Font *Metrics*. > One comment that might be usefull for the type aficionados: There are > many versions of 'Garamond', including several from URW. URW Garamond [...] > The URW Garamond No. 8 font family is URW's digitization of the Garamond > version introduced by the Stempel foundry. ... Many thanks for your expert's comments on this matter! >> 6.2. AFAICT, Ralf Stubner is one of the copyright holders, but is not >> listed in the relevant section. > > I am not sure if I can claim any rights on the rather trivial patch that > I applied. Yeah, I don't know where the limit of triviality is reached... and I don't know precisely how you altered the fonts, so I am not in a position to assert whether your are or are not a copyright holder. But if you don't want to claim copyright, I think that's fine: whenever you submit a change to a work, you can choose to give away the copyright (I believe that is what happens with GNU projects, where the copyright is assigned to the FSF). This will only make any later relicensing easier, since you won't have to agree with such relicensing. > Defoma and especially fontconfig integration are really tricky for this > font since the 'bold' weight is called 'medium'. Yes, I noticed that. I just wanted Kevin to find the problem himself. He's the prospective maintainer, after all. :) I'd try declaring the Medium fonts as Bold-weighted to defoma and the Regular ones as Medium-weighted and see what it gives... >> thing with "dh_installdirs etc/X11/fonts/X11R7/Type1". > ^ > > Note: > > debhelper (5.0.35) unstable; urgency=low > [...] > * dh_installxfonts: /etc/X11/fonts/X11R7 is deprecated, back to looking in > old location, and not passing --x11r7-layout to update-fonts-alias and > update-fonts-scale (but still to update-fonts-dir). Closes: #366234 Argh!!! So, I suppose we have to use /etc/X11/fonts/Type1 again. lmodern needs an update, then. And do we need to depend on debhelper (>= 5.0.35) instead of (>= 5.0.31)? lintian probably needs an update too in this case, unless of course this has already been implemented (I didn't upgrade my sid chroot very recently). Thanks for your comments! -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: urw-garamond -- scalable PostScript font from the Garamond family
Hi, Kevin Bube <[EMAIL PROTECTED]> wrote: > Hi mentors, > > I am looking for a sponsor for the urw-garamond package (ITP #367223). > It builds cleanly with debuild and installs and works with > unstable. This is my first attempt for a Debian package so comments are > very welcome. Your package is generally correct on the technical side, but there are some problems to solve with upstream before it can be legally distributed. Quoting the license of the upstream work (that of (URW)++ Design & Development, found in the PUBLIC file from ftp://mirror.cs.wisc.edu/pub/mirrors/ghost/AFPL/GhostPCL/urwfonts_t1-1.40.tar.bz2): ,[ PUBLIC ] | 1. Licenses. | |Licensor hereby grants you the following rights, provided that you |comply with all of the restrictions set forth in this License and |provided, further, that you distribute an unmodified copy of this |License with the Program: | |[...] | |(b) | You may modify the Program, create works based on the Program | and distribute copies of such throughout the world, in any | medium. ` The current distribution of the fonts on CTAN, as well as your package on mentors.debian.net, are in violation of this clause: a URL is clearly not "an unmodified copy of this License". ,[ PUBLIC ] |If you have modified the Program, you must cause the Work |to carry prominent notices stating that you have modified |the Program's files and the date of any change. In each |source file that you have modified, you must include a |prominent notice that you have modified the file, |including your name, your e-mail address (if any), and the |date and purpose of the change; ` AFAICT from Walter Schmidt's README.garamond, one should find Ralf Stubner's traces in some .pfb files (and I think also in the .pfm and *maybe* also in some .afm files). I cannot find such traces. But: % for f in *.pfb; do t1disasm "$f" | grep -i stubner; done % And now, for some other comments (those that are not legally binding). 1. You should Build-Depend on debhelper (>= 5.0.31), defoma (>= 0.7.0) and tex-common (>= 0.16) (have a look at the changelog files for these packages if you want to know why these versions are needed). 2. You're missing a dependency on defoma (>= 0.5.0) (have a look at your postinst script). 3. I'm not a native english speaker, but I would modify the Description field this way: --- /tmp/a 2006-05-26 15:50:56.0 +0200 +++ /tmp/b 2006-05-26 15:55:55.0 +0200 @@ -1,6 +1,8 @@ -Description: scalable PostScript font from the Garamond family +Description: scalable PostScript fonts from the Garamond family The URW Garamond No. 8 font family is URW's version of the Garamond - typeface. It consists of scalable PostScript Type 1 and comes in normal - and bold series. Both series are available in upright and italic - shapes. . The fonts are setup for use with the TeX typesetting system. - They are also integrated into X11. + typeface. These scalable fonts are shipped in the PostScript Type 1 format + and feature normal and bold series. Both series are available in upright and + italic shapes. + . + The fonts are setup for use with the TeX typesetting system. They are also + integrated into X11. 4. I believe you should put the full upstream URL in debian/copyright, just as you did in README.Debian. 5. debian/copyright: Note: the files in the ugm.zip archive are located in the directories ^^^ from the upstreamthose doc/, dvips/, fonts/ and tex/. ^ in the .orig.tar.gz file. Also, what does "e.a." mean? 6. The full texts of the Aladdin Free Public License and the LaTeX Project Public License must be quoted in debian/copyright (Policy § 12.5). 6.2. AFAICT, Ralf Stubner is one of the copyright holders, but is not listed in the relevant section. 6.3. Well, please revamp this file: This package was debianized by ... It was downloaded from . Work #1 --- The full text of $license is included at the end of this file (appendix $i). Work #2 --- The full text of $license is included at the end of this file (appendix $i). etc. Appendix A -- Aladdin Free Public License - Appendix B -- LaTeX Project Public License -- I identify the following works: - the font files (copyright holders: (URW)++ Design & Development and Ralf Stubner, AFAICT); - the TeX support files (copyright holder: Walter Schmidt); - the debian packaging (copyright holder: at leas
Re: RFS: FSlint - File System lint
Pádraig Brady <[EMAIL PROTECTED]> wrote: > Done. The following "source package" was built with: > dpkg-source -b fslint-2.15 fslint_2.15.orig.tar.gz [...] > I'm confused as to why it didn't ask me to sign it. I don't know if that's expected (I usually use 'debuild' to build my source packages), but you can always sign the .dsc and .changes files afterwards with 'debsign'. Actually, this is generally better because then, you only type your GPG passphrase when the packages are really ready, *after* doing all your tests (which usually causes several package builds for the incremental fixes, and therefore several times where you would type you GPG passphrase for no good reason in the end, if not building with a "don't sign" setting). NB : to tell debuild not to sign by default, I have: DEBUILD_DPKG_BUILDPACKAGE_OPTS="-us -uc" in ~/.devscripts. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: urw-garamond -- scalable PostScript font from the Garamond family
Kevin Bube <[EMAIL PROTECTED]> wrote: > Yes, the package is done for unstable. Is X.org 7 expected to go into > etch? Or is it better to use the X11R6 locations for now? No, packaging for X.org was the right decision. I'll try to have a look at your package one of these days, but probably not this week... -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PDF files and dh_compress
Hi, Yaroslav Halchenko <[EMAIL PROTECTED]> wrote: > .pdf.gz versions. And at least I would expect all -doc packages to have > uncompressed .pdfs since neither of the pdf viewers to me experience > handle transparent decompression of pdf.gz I know it doesn't really answer your question, but a simple way for viewing .pdf.gz files is: see file.pdf.gz [ cf. see(1) ] -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lopster
Franz Pletz <[EMAIL PROTECTED]> wrote: > W: lopster; A binary links against a library it does not use symbols from > This package contains a binary that links against a library that is > not in the Depends line. This may also be a bug in the library which > does not have a shlibs file. > > I've doublechecked the output of both ldd and objdump -p for > /usr/bin/lopster but was not able to identify a library in a package > which isn't in Depends. The program works without any problems, though. > Any advice? See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=360391 This may be a false positive by linda. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/rules::dh_* comments as rejection criteria
Simon Richter <[EMAIL PROTECTED]> wrote: > Exactly. So in order to understand my own packages better I leave the > dh_* calls in, commented out so I can grep for them and see that they > are disabled. Well, I never felt this need. > Being a DD, I think I should be able to make that judgement for > myself. Don't take it bad. I gave you my opinion and my arguments, but you're free to think differently... -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/rules::dh_* comments as rejection criteria
Romain Beauxis <[EMAIL PROTECTED]> wrote: > Would you argue that you are not skilled if you comment your dh_* calls? No, rather that if you're skilled, you don't need to comment them. > You could simply not want to loose time to find back the good order... I'd say that if you're ready to sacrifice understanding of your package in order to spare 15 seconds, you should probably spend your time on something else than official Debian packages... > BTW, what are the *real* arguments for removing those commented calls. They've been given already. No need to repeat them ad nauseum. Maybe you weren't convinced, which explains why you're asking for *real* arguments. That's possible; I wouldn't pretend they are very cogent. But from my point of view, the arguments for keeping the comments are even weaker. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A list of common gotchas in Debian packaging
Jari Aalto <[EMAIL PROTECTED]> wrote: > I disagree with comments about removing the lines from from > debian/rules (debhelper calls that are unused). This file is used by > the maintainer of the package and he knows best what is the most > effective way to organize his works. IME, it is not very frequent to add dh_lines to a working rules file. And it takes just a few seconds to figure out where to put them, assuming you know what you are doing. I think these seconds are worth spending: 1. They give you the occasion to actually *think* about what you are doing, instead of blindly following a recipe. 2. They make the rules file much more readable : it shows what is being done; no more, no less. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A list of common gotchas in Debian packaging
Panu Kalliokoski <[EMAIL PROTECTED]> wrote: > Well, I must add that I don't find the recommendation very smart either, > but probably there's somebody out there that has terrible difficulties > in not reading commented-out lines or something like that. I personally The threshold where commented lines get unacceptable is IMHO way before they cause "terrible difficulties". You *could* read a newspaper article in which every other line is an ad written in red ink, but given the choice between that and a normal article, what would you choose? -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/rules::dh_* comments as rejection criteria
Bart Martens <[EMAIL PROTECTED]> wrote: > Anyway, I don't see a problem with the readability of debian/rules with > the commented dh_ lines, and I agree with Jari Aalto that leaving the > commented dh_ lines can be useful, so I would vote "allow" if a > discussion would be held for this. I disagree. If you aren't able to figure out a sane order for the dh_ calls by yourself, you shouldn't be maintaining the package IMO (of course, you could maintain a private package for yourself and your friends, but we are talking here about packages that are uploaded to the Debian archive). -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A list of common gotchas in Debian packaging
Justin Pryzby <[EMAIL PROTECTED]> wrote: > Agreed; my motivation for leaving commented lines around is that it is > arguably easier to merge with newer dh_make template files (if one > were to do that ..). The reason to not leave them around is that not > doing so indicates some level of familiarity and understanding, and > the ability to fix stuff if it breaks or needs improving. More importantly, it makes the rules file actually readable! -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: HowTo upgrade to a newer Debian Policy version
"Sandro Tosi" <[EMAIL PROTECTED]> wrote: > No, I'm not sure at all! :) I suppose that field should tell the > package builder "Ehi, use debian policy version XXX while building > this package" and so every script involved will use this information > to validate the package against the d-p specified. No. There is only one version of Policy that should (in an ideal world) be implemented in the packages from sid: the latest one. The field says that you, as the maintainer, assert that the package conforms to that particular version of the Debian Policy, to the best of your knowledge (not mentioning open bugs, of course). -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: thailatex (orphaned package for babel-based Thai latex support)
Norbert Preining <[EMAIL PROTECTED]> wrote: > that it can be backported to woody (sarge already has tetex3). ... on http://www.backports.org/! -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC/RFS: rhinote -- virtual sticky-notes for your desktop
Andrea Bolognani <[EMAIL PROTECTED]> wrote: > Rhinote is designed to be "keyboard friendly", that is, every single action > is bount to a specific keystroke. ^ bound -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC/RFS: rhinote -- virtual sticky-notes for your desktop
Andrea Bolognani <[EMAIL PROTECTED]> wrote: > Rhinote is designed to be "keyboard friendly", that is, every single action > is binded to a specific keystroke. ^^ bound (I'm not a native English speaker, though) -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /etc/conf not installed
Gerber van der Graaf <[EMAIL PROTECTED]> wrote: > I am trying to repair the libgpiv package I've build. The > libgpiv_0.3.2-1_i386.deb contains a configuration file /etc/gpiv.conf, > as reported by dpkg -c. Extracting the .deb to tmpdir/ (with dpkg -x) This shows it is a conffile. This is more precise than "configuration file". > gives tmpdir/etc/gpiv.conf, as expected. However, dpkg --install .deb or > installing with: "apt-get install libgpiv" (after uploading in a local > repository) does not install this file. On the other > side, /usr/lib/libgpiv.so is perfectly installed. The gpiv.conf file is > pointed by debian/libgpiv.files. I also tried to include it in > debian/conffiles, in order to warn in case of an upgrade. Can somebody You should be using a debhelper level where any file shipped in the .deb under /etc is automatically a conffile. > give me a hint where I have to look at or to search for in order to > repair this bug? Thanks, Gerber Did you try purging the package (dpkg -P ) before installing it? Did you try the --force-confmiss option of dpkg? -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Program for creating and managing APT repositories
Hello, I am not quite sure it is the best place to post this, but anyway. I wrote a Python script to create and manage APT repositories which has the following features: - supports repositories with a structure almost identical to that of the Debian archive, with distributions, the main/contrib/non-free sections and package pools (the only difference being that I thought the structure pool/p/packagename/ was overkill for reasonably-sized distributions, and therefore used pool/packagename/ instead); - can create and sign the master Release file for a distribution, which allows APT 0.6 and later to trust (authenticate) the repository after checking the GnuPG signature of the master Release file; - rudimentary command-line interface to remove packages from the Sources[.gz,.bz2] and Packages[.gz,.bz2] files; - can automatically replicate the repositories to one or several local or remote locations (for the remote case: with scp and ssh[1]). That's it. It is adequate to my way of working, and I'd be happy if it could be useful to someone else. The program is documented at http://people.debian.org/~frn/fmdr.txt and can be downloaded at http://people.debian.org/~frn/fmdr Happy hacking. [1] ssh is needed because scp blindly follows symbolic links. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: library files are not included in the .deb files
kamaraju kusumanchi <[EMAIL PROTECTED]> wrote: > $tree fortranposix-0.1/debian/tmp/ > fortranposix-0.1/debian/tmp/ > `-- usr > `-- lib > |-- libfortranposix.a > `-- libfortranposix.so.0.0.0 > > 2 directories, 2 files It seems you are using a debhelper compatibility level (see debhelper(1)) strictly greater than 1, which is good. In this case, you should install your stuff into debian/ instead of debian/tmp if you want it to end up in a package. Didn't you wonder why your .deb file contained quite a few files that your build procedure does *not* put in debian/tmp? -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compilation maybe-successful
Bas Wijnen <[EMAIL PROTECTED]> wrote: > For all platforms, it says that the compilation was "maybe-successful". > That sounds like it could be better. Now I haven't seen anything > "successful" for other packages either, so perhaps it is simply impossible. > > Is there anything I can (and should) do to get rid of the "maybe"? No. The message means that the build didn't fail in an obvious way for build daemon program (such as dpkg-buildpackage exiting with a non-zero status). To be absolutely sure, a human would have to check the log and (since the log doesn't necessarily tell everything) the generated .debs. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS:qterm
Li Daobing <[EMAIL PROTECTED]> wrote: > If I want to modify the source tarball, for example, I want to delete > the admin/CVS and debian/*.ex in the source, should I modify the version > number, for example, called it 0.4.0pre2.dfsg.1-1 or some other name? The version number consists of two parts for non-native packages (by far the majority). cf. Debian Policy. The upstream part should reflect which upstream source your package is based on (released version, release candidate or in some cases, CVS-or-whatever snapshot). If this doesn't change, you should only increment the Debian part of the version number. The .dfsg thing means that the upstream source has been changed in a substantial way in order to comply with the Debian Free Software Guidelines; important enough that users should know they are not getting what is shipped by upstream---and why. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Stupid shebang tricks
Ben Finney <[EMAIL PROTECTED]> wrote: > Is '/usr/bin/env' part of the POSIX spec? Is its behaviour with regard > to command arguments defined? Where would I find out? It is part of POSIX: http://www.opengroup.org/onlinepubs/009695399/utilities/env.html The problem is not with env, but with shebang lines. I believe that #! program argument works on most systems but using more arguments only works on some of them. Therefore, even without env, you wouldn't be able to call perl in a shebang line with more arguments than -w in a portable way. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: splat package
David Clarke <[EMAIL PROTECTED]> wrote: > Why is it better to have the debian directory separate to the main > tarball? I had a read of the thread a little while ago about the > developers including a debian directory, and am still unsure why this is > neccessarily a bad thing if the person producing the debs is the > developer. For instance, someone might want to produce different Debian packages than yours. If you ship the debian subdir in the upstream tarball, this will make it a real pain. Moreover, this will probably require to repackage the upstream source to remove the debian subdir, and therefore considerably weaken the trust path to your code (how do you check that the upstream source is really what upstream distributes, if it has been repackaged?). Another reason: what about other distributions? Would you be happy if, when unpacking an upstream tarball, you got a hundred of useless top-level directories with some crap for every distribution around? Yet another one: you *will*, no matter how perfect you are, have to make modifications to the Debian packaging. Releasing a new upstream version for changes that are specific to the Debian packaging is stupid, wastes bandwith and confuses your users. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: noob needs a little help making a package.
Justin Pryzby <[EMAIL PROTECTED]> wrote: > You list the build-dependencies as best you know them, and then build > in pbuilder. If it does not build, then you look at the last line, > and figure out what it needs that it didn't have, and add the > appropriate thing. If it does build, then you remove the build-deps > one by one to make sure that each one is, in fact, necessary. Well, in general, the goal is not to find a minimal set of build-dependencies that allows building, but to find /the/ minimal set of build-dependencies that allows building the package /in the desired configuation/. I mean, suppose a package can optionally use, e.g., FreeType, and detects the library with its configure script (which is run at build time). If you remove libfreetype6-dev (or whatever you are build-depending on when you want to link your program to FreeType), the package *will* build successfully. But it will not have FreeType support. So, in general, you should only keep the build-dependencies that: - are not build-essential (nor essential, since this implies build-essential); - are necessary to build the package in the configuration you think is best for Our Users (often, this means linking to every library that the package can make use of, and is in Debian---except maybe for very experimental stuff). [ I suppose this is what Justin meant, but I am not sure it was obvious to the OP. ] -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: --purge and log/spool files
Michelle Konzack <[EMAIL PROTECTED]> wrote: > I asume, that > > rm -f /var/log/tddyndns/-??.log > > should work in all shells, because the logs are -MM.log. It should work in /bin/sh. http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_13 -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: --purge and log/spool files
Justin Pryzby <[EMAIL PROTECTED]> wrote:
> Note that there was a relevant thread on -devel around about last
> October. Someone complained that their thesis was in /var/log/apache/
> and was deleted when they purged the package. As such, you might
> consider something like rm -f /var/log/apache/{access,error}.log*;
Warning: this type of globbing is not supported by the POSIX shell.
Therefore, it is not suitable for /bin/sh. You can write a for loop, or
use "#! /bin/bash".
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A couple of questions
Shachar Shemesh <[EMAIL PROTECTED]> wrote: > The slight dilemma is whether /var/cache or /var/spool would be a > better choice. I'm leaning towards spool, as they tend to be big, and > it would really be better not to erase them. Well, if you ask me, I think /var/cache doesn't look that bad for this purpose. I would say that when an admin starts deleting stuff in /var/cache, it means he *really* needs to free some space; so, if the data can be regenerated automatically, why not let him this choice? -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A couple of questions
Shachar Shemesh <[EMAIL PROTECTED]> wrote: > After your explanation, the only thing I still have doubts over is > whether the files should not go into /var/cache instead. Erm, which files? -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A couple of questions
In case Justin's mail didn't answer all your questions... Shachar Shemesh <[EMAIL PROTECTED]> wrote: > Well, you would need a helper program to actually change it, as the > password is encrypted. Otherwise, yes it's a configuration file. Well, the line is a bit blurry here, I admit. Note that passwords in /etc/shadow are encrypted, but the admin can still modify the (encrypted) passwords by hand in that file. This is not an argument against placing the file under /etc. IMHO, whether /etc or /var is more appropriate depends on whether you consider the file as configuration data for the program, or not. Specifically, do you expect an admin to simply copy that file to another system if he wants the same passwords in the other system? If yes---and, I am tempted to say, if the file is in text format, because seeing binary stuff under /etc kinda hurts my eyes---, then I'd choose /etc. If not (i.e., if you consider the file as simply storing a "state" for your program), /var sounds more appropriate. > Debhelper(1) says: > >> V3 This mode works like V2, with the following additions: >> - Every file in etc/ is automatically flagged as a conffile by >> dh_installdeb. > > You are right, I am thoroughly confused. It seems to me that if I > follow the policy version 3 or above (and we all agree that I should), > then every configuration file (that must be placed under /etc > according to 10.7.2) will also be a conffile, contradicting 10.7.1. I see your reasoning. They key to avoid the confusion here is to understand the meaning of "Every file in etc/" in debhelper(1). It means "Every file *shipped in a binary package* (.deb) under etc/". Note: the fact that "etc/" is used instead of "/etc/" is a slight indication---the directory is relative... to the package build directory. debhelper really doesn't know what you can do in your maintainer scripts (preinst, postinst, prerm...) since they are shell scripts with full-blown syntax. It cannot (reliably) know by inspecting them whether they create something under /etc or not. It can only look at what is going to end up in the .deb files you are creating and act based on these observations. conffiles are the ones that cause all the dpkg prompts on upgrade: "File modified by you or a script, do you want to install the new package maintainer's version, to keep the file as is, to see a diff, to background the process and examine the situation? etc." When you ship a file under etc/ in a .deb (in debhelper compat levels >= 3), you are saying: "This is a reasonable default configuration file for my package, and I wish it to be installed automatically in /etc when installing the package from "purge" state, and to cause the aforementioned conffile prompt to appear on upgrades if it was modified by the admin." > While I am confused, I have to say your explanation did not help me. > The way I see it, a password file is a configuration file, but not a > conffile. All Right (I suppose there is no "default password file" that the user would be likely to accept on upgrades). > configuration files, be them conffiles or not, should go into /etc, > but debhelper compatibility version 3 (and, by induction, version 4) > does not allow me to place a file there that is not a conffile. It does. Just don't ship it in the .deb, but as Justin said, have it created by postinst, or by one of the programs shipped in the package, for instance. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A couple of questions
Shachar Shemesh <[EMAIL PROTECTED]> wrote: > two questions: > 1. My package has a password file. Where is the best place to store it? > /etc/name/password? /var/lib/name/password? If the password file is a system configuration file (i.e., a file that can be customized by the admin to modify the behavior of the program), it belongs to /etc. Otherwise, it should be placed elsewhere. See the FHS. > 2. I have placed some file names into debian/conffiles. It seems, however, > that all files under /etc are logically added to it as well. This is a feature of dh_installdeb in debhelper compatibility levels 3 and above. cf. debhelper(1). > Files under /etc > that I explicitly list as conffiles are listed twice on > /var/lib/dpkg/info/name.conffiles after installation. This is not good, > especially if option #1 above is taken. Can anyone explain why/how to stop the > scripts from marking all files under /etc as configuration files? 1. You are confusing conffiles and configuration files. These notions are explained in the Debian Policy Manual. 2. This is probably a bad idea, but I suppose that setting DH_COMPAT to 2 or below just for the dh_installdeb invocation would do the trick. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using symlinks for manpages
Justin Pryzby <[EMAIL PROTECTED]> wrote: > In fact, I believe all symlinks should be relative, except top-level > symlinks. And packages probably shouldn't ship any of those:) Not exactly. cf. Policy § 10.5: , | In general, symbolic links within a top-level directory should be | relative, and symbolic links pointing from one top-level directory into | another should be absolute. (A top-level directory is a sub-directory of | the root directory /.) | | In addition, symbolic links should be specified as short as possible, | i.e., link targets like foo/../bar are deprecated. ` dh_link does the right thing. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: albumshaper - a drag and drop photo album manager
jano kupec <[EMAIL PROTECTED]> wrote: >> 3) I think you should build-depends on qt3-dev-tools and not only on >>the libs (as you need qmake from the former). > > i added it there, but i thought it shouldn't be necessary since the > libqt3-mt-dev already depends on qt3-dev-tools, according to apt-cache > show libqt3-mt-dev You shouldn't care about what libqt3-mt-dev depends on. This is not your business, and could very well change over time, breaking albumshaper's build process. If you directly use qmake in your build process, you must build-depend on the package that provides it, qt3-dev-tools. Same thing for depends: they must reflect exactly what the package directly needs to work properly, not rely on its dependencies pulling other dependencies. >> 4) You may set DH_COMPAT to 4. DH_COMPAT Temporarily specifies what compatibility level debhelper should run at, overriding any value in debian/compat. I would rather: echo 4 > debian/compat as suggested in debhelper(7). -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS(2): autoreply - A safe, rate-limited auto-responder
Foreword: you're lucky I happened to relate your mail to mine. Please do the necessary so that your future messages actually appear as replies to the messages you are replying to (hint: the "References" field does the job). "Richard A. Hecker" <[EMAIL PROTECTED]> wrote: > You used a judgement to say judgements are not acceptable. Last time I > checked, I didn't say that "judgements are not acceptable". Please don't misquote me. I said that I found a *particular* judgement not acceptable on public mailing lists. I believe I am still entitled to have opinions. > Debian did not have any opennings in the PC police department ;-) Well, if the PC police department is the one preventing me from expressing my views, you may already be working there... One learns every day, you know. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS(2): autoreply - A safe, rate-limited auto-responder
Don Armstrong <[EMAIL PROTECTED]> wrote: > The author(s) can spend free time in any way the author(s) wish to. I'm glad to learn that. > Likewise, Blars and myself are free to tell authors that what they > have written appears to be a waste of their time when Free alternative > "foo" exists. Just like you are free to tell me that responding to > your message is a waste of my time, and others can tell us that > reading this thread is a waste of their time. I was reacting to the "yet another vaction clone by someone who didn't bother to read the vacation man page" part of Blars' message, which seems to be overly harsh (and maybe untrue) if it is only meant to say "a free program with mostly the same features already exists". > Furthermore, the message above isn't written in the context of telling > the authors that they should never have written said software, only > that said software should probably not be included in the archive > because other tools already frobnicate better (or as well.) I don't think this was the only message carried by Blars' words, but I may have misunderstood him... -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS(2): autoreply - A safe, rate-limited auto-responder
Blars Blarson <[EMAIL PROTECTED]> wrote: > In other words, this looks like yet another vaction clone by someone who > didn't bother to read the vacation man page. IMO, such judgments are not acceptable on public mailing-lists[1]. If the upstream author felt like writing a program similar to vacation, hell, who am *I* (and, for that matter, you) to say he should do something better with *his* free time? Free software works because people have fun developing it. If the guy is having fun rewriting something that for some parts already exists, well, so be it. Sometimes, rewrites/clones happen to be a good thing, also. Whether the program is a useful addition to Debian---considering that vacation is already there---is an entirely different matter, on which I won't comment (because I have no opinion about it, using neither of the programs, and not even considering doing so). [1] You may want to try to convince the upstream author privately if you really feel so sad about the "waste of resources" for the free software community (*cough*). -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package split/merge advice
Frank Küster <[EMAIL PROTECTED]> wrote: > Yes, technically this works. But then the version numbers do not > correspond at all to the version numbers used by upstream. And you get > in trouble if upstream changes his packaging and distributes all data in > a single tar.gz: > > dpkg --compare-versions 2004-12-07 lt 3.0; echo $? You can still use a version like 0.0.0.20041207 (hoping the first upstream release with a real version number will have less than 3 leading zeros...). -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to use reportbug from inside a chroot?
Hi, Anibal Monsalve Salazar <[EMAIL PROTECTED]> wrote: > Install ssmtp in the chroot. Or nullmailer. Also, I have created the attached file in the normal system (not in the chroot) to start the daemon in the chroot when the system is booted. local-sid-root-nullmailer Description: Bourne shell script Bye, -- Florent
