Re: How can I modify /etc/inittab?
Henrique de Moraes Holschuh wrote: > Then tell the user that, and DO NOT TOUCH /etc/inittab. > ... > Yes. But AFAIK there are absolutely no plans to provide an interface for > ANY package to touch /etc/inittab. Screwing it up is so utterly callous, > that one would have to be out of his mind to encourage any package to > attempt to "auto configure" anything inside /etc/inittab. I don't disagree. Perhaps you would like to peek at the 'secvpn' package. It could use some improvement in this area. Bob signature.asc Description: Digital signature
Depends: awk -- Is that required?
I need a clarification because I am confused. If I have a script that uses awk do I need the package to "Depends: awk"? Or is awk like basename where we are able to assume it is on the system without any explicit dependencies? I see that many packages do "Depends: awk". But awk is an alternative and mawk is "Priority: required" so I would not think so. But gawk provides awk and is "Priority: optional" but with a higher alternative priority too and so that "required" mawk is almost never used. (I always install gawk as awk for its better features.) If the package used gawk specific features then the decision would be easy. It would need to depend upon gawk. But it only uses basic awk features and so any of the alternatives is sufficient. Thanks for you knowledge in this. Bob signature.asc Description: Digital signature
Re: Depends: awk -- Is that required?
Recai Oktas wrote: > Steve Langasek wrote: > > awk is "virtually essential": it can't be Essential: yes because > > that would prevent removing mawk in favor of gawk, but awk is a > > dependency of another essential package to ensure that you can use > > basic awk functionality without having to depend on it. > > Just to make things a little clearer, the above is the excerpt from the > changelog of 'base-files' (an essential package): > * Added "Depends: awk", so that awk is a "virtual essential package". A good explanation. That clears up my confusion. I was pretty sure it was something like that but just could not find it. Thanks! Bob signature.asc Description: Digital signature
Bug#677013: RFS: time/1.7-24 -- The GNU time program for measuring cpu resource usage
Sandro Tosi wrote: > Bart Martens wrote: > > Package: sponsorship-requests > > Owner: Bob Proulx > > > > I'm opening this RFS on behalf of Bob Proulx who owns ITA 652670. > > > > Bob Proulx wrote: > >> Hi Bart, > >> > >> > How is progress on this ITA ? > >> > >> Can I admit that it is a little frustrating? I am not a DD and > >> therefore the package needs to be sponsored. I have had various DDs > >> sponsor packages before. But I have been striking out going through > >> my list. The ones I have contacted have all become busy with life and > >> have fallen out of contact. > > That's interesting: I sent a review of "time" on "Sat, Jun 9, 2012 at > 5:09 PM CET" while Bob wrote his complains to Bart on June 10th. Mostly due to being busy this weekend and not being able to read through 100% of the incoming email. I still have a few hundred emails piled up that I have not read yet. I might be able to catch up by tomorrow. I had emailed you (Sandro) asking for help on Sunday 3 Jun 2012. By this weekend it had already been a week without having heard any response. I didn't know if any response was coming. Bart updated Bug#652670 asking me about the status. The message sorted higher in my read priority due to it being attached to a bug. I read it earlier. Seeing the interest I jumped at the opportunity and responded to that request! At that time I had not known there had been a response from Sandro. Sorry. Sandro thank you for reviewing the new package. I will review the feedback and respond to it. However I am flying today and will be unable to give it much time until I return late tonight. Today will mostly be a completely lost day. Bob signature.asc Description: Digital signature
Bug#677013: Debian time package sponsor?
Sandro Tosi wrote:
> Hello Bob,
> here's a brief review of the package.
Thank you for reviewing the package!
> debian/changelog
> - don't rewrite history, so please restore the old changelog entries,
> even if they have a weird "Closes=xxx" in the first entry line
The two entries are:
time (1.7-4) unstable; urgency=low, Closes=31767
* debian/{rules,postinst,postrm}: Removed support for html documentation
through menu as it is already provided by doc-base (fixes #31767)
-- Dirk Eddelbuettel Thu, 14 Jan 1999 20:42:16 -0500
time (1.7-3) unstable; urgency=low, Closes=31164
* Upgraded to Debian Policy 2.5.0.0 (no change)
* Added doc-base support (fixes #31164)
-- Dirk Eddelbuettel Tue, 5 Jan 1999 20:43:41 -0500
I fixed those entries because otherwise lintian complains with these
warnings:
W: time: syntax-error-in-debian-changelog line 175 "unknown key-value key
Closes - copying to XS-Closes"
W: time: syntax-error-in-debian-changelog line 182 "unknown key-value key
Closes - copying to XS-Closes"
Plus the changelog entries for each of them already mention that they
fix those particular bugs so no historical information is lost by
updating the syntax. Also there is a long history in Debian of
correcting changelog entries when appropriate and this certainly seems
like an appropriate instance if any.
I think these should be fixed. However I will reintroduce those
lintian warnings since you feel strongly about it.
> debian/control
> - why didn't you bump debhelper to 9, which is the latest version?
> just to undestand if there was some reason
Because 8 was the latest version when I built the package. Version 9
was uploaded subsequently on 2012-01-15. I will rebuild it with
version 9 now that it is the latest. The compat level of the
previous package was 4.
> - I personally would have left 'GNU time' in the short description line
I changed the line due to input from other people concerning the
"correct" format for the short description. Plus it gave me this
lintian warning so I needed to change it.
W: time: description-synopsis-starts-with-article
But I am happy to modify it again. I don't feel strongly about it.
I would have left "cpu" lower case too. It has long ago moved from
being an acronym to being an accepted word of its own. Just like
"email" and others. But there was Bug#492669 from Filipus Klutiero
who is a good soul. It seemed magnanimous to simply make the change
than to argue such a minor point.
> debian/copyright
> - you misses to state the previous maintainer(s) copyright. While this
> is non necessary for teh upload, is kinda rude ;) please add at least
> the entry for Tollef (easily gettable from the start to the end of his
> maintainership of the package).
If you noticed the changelog entry then you know that I was not being
rude to Tollef or any of the other contributors.
Also I think you meant Dirk Eddelbuettel not Tollef. Tollef didn't
list himself as owning copyright for any of the files in the package.
His name did not appear in the previous copyright file at all. It was
Dirk Eddelbuettel who is credited with having created the package
originally. Although the name of Peter Tobias appears earlier in the
changelog file.
I believe the copyright file should list the _current_ status of the
files of the package. The changelog is the appropriate place for
historical information. So on a technical point: How would Tollef be
credited in the new DEP5 copyright format? I am not yet comfortable
with the new format even after studying the documentation on it in
great detail. Is there a section for listing emeritus maintainers?
However because of looking into this now I do see that the time.1 file
is copyright by Dirk Eddelbuettel. Missing that file for the
copyright listing was definitely an oversight on my part. If I had
caught that I would defintely have listed it. Note that it was not
listed as such in the previous version of the copyright file.
I will update the copyright file for the new version to note that
file's copyright status. Which uncomfortably does not use a standard
license. It says only:
Copyright (C) Dirk Eddelbuettel but freely redistributable
And therefore I can only infer the following for the new DEP5
copyright file format:
Files: debian/time.1
Copyright: Copyright 1996 Dirk Eddelbuettel
License: freely redistributable
Copyright Dirk Eddelbuettel but freely redistributable
The one thing that I really wish people would learn would be to avoid
creating new and unique licenses. It is almost always better to use
one of the standard existing licenses than to create a new one.
However this was from 1996 more than 16 years ago. We learn things as
time goes by.
Also I see that the doc-base file was created by Dirk Eddelbuettel but
has no license associated with it. It is a small file with only six
lines of unique content and I think safe to assume that he intended to
apply the same
Bug#677013: Debian time package sponsor?
Ferenc Wagner wrote: > Bob Proulx writes: > > Yes. But note that those had been made before too. I only updated > > the autotools files (again) because the current ones were quite aged > > and dearly in need of being updated. Those were not "patched" in the > > sense of editing the file with changes but updated whole by using the > > current autotools to create new versions of those files from the > > included source files. (The source being the configure.ac and > > Makefile.am files.) > > Did you consider using dh-autoreconf or dh --with autotools_dev? As far as I know from reading the documentation using dh-autoreconf and dh --with autotools_dev update only the config.sub and config.guess files if they exist. The 'time' package does not use either of the config.sub or config.guess files and neither exist in the package. Therefore AFAIK calling dh_autotools_dev would be a noop. I was basically following Option 1 from the autotools-dev README file. I would have used dh_autoreconf but I didn't know how to force it to be run in the dh system. But digging more into it and searching the web I now find that there is a 'dh $@ --with autoreconf' option. Maybe that was the option you were thinking of but your fingers typed in the other one by mistake? Probably. In any case if that works then that is most desirable. I will explore that technique. (Time passes...) That seems to work. Adding the build dependencies needed for it and converting to using that recipe. > >> Addenda, taken from lintian output after build: > >> > >> I: time source: debian-watch-file-is-missing > >> is it possible to add it? does it make sense for a GNU project? > > > > Up to date lintian does not give me that message. > > You need to add the --info option to get Info level messages. Ah! Thank you for that hint. > >> W: time: hardening-no-fortify-functions usr/bin/time > >> did you consider enable the hardening flags? > > > > That is a brand new lintian warning and did not exist when I built the > > package. So the answer is no that I did not consider it. It wasn't > > an item to be considered at that time. I am skeptical that time would > > gain value by using them. But I am not opposed to adding them. > > > > However I am using the debhelper build system. Shouldn't it be doing > > this automatically there? Isn't that the purpose of using such a > > build system so that standardized behaviors are implemented uniformly > > across everything all at once? > > > > How does one enable hardening flags when using the dh build system? > > Debhelper compat level 9 makes this automatic with a recent dpkg-dev. > (If I'm not mistaken.) If that is true then nothing more needs to be done. > >> P: time: no-homepage-field > >> can you please add it? > > > > Up to date lintian does not give me that message. > > This is a Pedantic message, use the --pedantic option to enable these. Ah, again! That is a good hint. Thanks! Bob -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120618082531.ga5...@hysteria.proulx.com
Bug#677013: Debian time package sponsor?
The latest 'time' package release candidate is here: http://www.proulx.com/~bob/debian/pool/sid/main/time/2012-06-21/ -rw-r--r-- 1 16649 Jun 21 13:38 time_1.7-24.debian.tar.gz -rw-rw-r-- 1 1038 Jun 21 13:48 time_1.7-24.dsc -rw-r--r-- 1 12317 Jun 21 13:39 time_1.7-24_amd64.build -rw-rw-r-- 1 2468 Jun 21 13:48 time_1.7-24_amd64.changes -rw-r--r-- 1 32786 Jun 21 13:39 time_1.7-24_amd64.deb -rw-rw-r-- 1 103066 Aug 9 1997 time_1.7.orig.tar.gz I believe I have addresssed all of the concerns that were previously raised with the previous release candidate. Notably it has been converted to quilt and builds correctly using it. I sorted through the patches and split them out into individual patch files tagged using the new DEP3 tag format. The debhelper build system now builds using 'dh $@ --with autoreconf' and so those files are updated automatically at build time and are no longer part of the patch diffs. Thanks! Bob signature.asc Description: Digital signature
Bug#677013: RFS: time
Hi Bart, Bart Martens wrote: > The file debian/copyright "should name the original authors", and > David Keppel is such an author. Thank you for taking the time to look at the copyright file in detail. I admit the new DEP5 format confuses me. I need to find some actual examples in the field of more than the very simple examples listed in the documentation. I am working from this document: http://dep.debian.net/deps/dep5/ Where would I find such a statement in the documentation? How would this be defined in the file? How would we comply with that statement within the restrictions of the above documentation? The copyright holder is of course the FSF. That is the copyright statement listed in each of the files. Should I list the original authors in a Comment: field? I see no other way. Help! > The previous package maintainers are also copyright holders of debian/* so > debian/copyright needs an update for that. Please talk to the previous > maintainers if there is doubt on the license(s) for debian/*. I walked through the Debian changelog and compiled a list of contributors and years from it. > The years in the main copyright notice are not correct. For example, time.c > additionally has "1990, 91, 92". Good catch. I definitely missed that. And not sure where I pulled that line from. And getopt.c goes back to 1987. I walked through every source file and compiled a list of copyright years from each file. It seems that I can also collapse the license definition somewhat too. Working through the above this is the next release candidate version. How does this look? Any additional comments concerning this? Such as how to "name the original authors"? >snip< Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: time Source: http://ftp.gnu.org/pub/gnu/time/time-1.7.tar.gz Files: * Copyright: Copyright 1987-1996 Free Software Foundation, Inc. License: GPL-2+ Files: debian/* Copyright: Copyright 1995 Peter Tobias Copyright 1995-2004 Dirk Eddelbuettel Copyright 2005, 2008 Tollef Fog Heen Copyright 2010 Salvatore Bonaccorso Copyright 2012 Bob Proulx License: GPL-2+ Files: debian/time.1 Copyright: Copyright 1996 Dirk Eddelbuettel License: freely redistributable Copyright Dirk Eddelbuettel but freely redistributable License: GPL-2+ This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. . This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. . You should have received a copy of the GNU General Public License along with this package; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA . On Debian systems, the full text of the GNU General Public License version 2 can be found in the file `/usr/share/common-licenses/GPL-2'. >snip< > The package uses source format "3.0 (quilt)" but does not really use > quilt, so debian/README.source can be removed. I was working from the Debian quilt howto here which said it was required. Of course that is explicitly for Perl but for this aspect it shouldn't matter. http://pkg-perl.alioth.debian.org/howto/quilt.html#readme_source I find it annoying so am happy to remove it. But I find your statement that the quilt format doesn't use quilt surprising! And in fact it was required specifically that I convert the package to use the quilt format. Pending review of the above (or any other comment) here is the next release candidate in full: http://www.proulx.com/~bob/debian/pool/sid/main/time/2012-06-22/ -rw-r--r-- 1 16639 Jun 22 17:35 time_1.7-24.debian.tar.gz -rw-rw-r-- 1 1038 Jun 22 17:39 time_1.7-24.dsc -rw-r--r-- 1 12317 Jun 22 17:36 time_1.7-24_amd64.build -rw-rw-r-- 1 2468 Jun 22 17:39 time_1.7-24_amd64.changes -rw-r--r-- 1 32904 Jun 22 17:36 time_1.7-24_amd64.deb -rw-rw-r-- 1 103066 Aug 9 1997 time_1.7.orig.tar.gz However note the above request for help in the item "should name the original authors". Bob signature.asc Description: Digital signature
Bug#677013: RFS: time
Bart Martens wrote: > Bob Proulx wrote: > > Bart Martens wrote: > > > The file debian/copyright "should name the original authors", and > > > David Keppel is such an author. I have looked through many copyright files and do not see one that does this. See for example this one along with many others: /usr/share/doc/gawk/copyright Of course that doesn't mean there aren't others that do. I would welcome an example to follow. I just haven't found any. Nor does it mean that it isn't the right thing to do. Although philosophically I am not sure of the need for it since anyone looking for authors would look in the AUTHORS file which is the canonical location for that information, at least for GNU programs. > > Thank you for taking the time to look at the copyright file in detail. > > I admit the new DEP5 format confuses me. > > Me too. :-) > > Where would I find such a statement in the documentation? To answer my own question it is stated here: http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile In addition, the copyright file must say where the upstream sources (if any) were obtained, and should name the original authors. So definitely stated by Policy the original authors must be named. > > How would this be defined in the file? How would we comply with > > that statement within the restrictions of the above documentation? > > No idea. After doing more research and without any other input I think the only thing that makes sense is to include the information in the free-form Comment: block. I don't find any other packages doing this (would welcome an example) but it would definitely seem to be required by the spirit of Policy 12.5 and there doesn't seem to be any other place to put it in the DEP5 format. > > The copyright holder is of course the FSF. That is the copyright > > statement listed in each of the files. > > > > Should I list the original authors in a Comment: field? I see no > > other way. Help! > > No idea. I think putting this in a Comment: field about the only acceptable solution that I can see that meets all of the (conflicting) requirements. > Note that DEP5 is not mandatory. Plain text is OK for policy. What motivated > you to switch to DEP5 ? There are several facets. First is that since the package needs to be sponsored it means that every sponsor will have their own pet peeves and requests. Generally this means that everything must be of the newest features. You never know what a sponsor will ask for. (Or sometimes it must be of an older feature!) DEP5 is one of Debian's new features and therefore to get a package through sponsorship it pretty much needs to have it. See for example the request to move to quilt instead of using the previous diff.gz format. Also the request to use the newest compat level which arrived during the updating of this package. Before Sandro offerred to help I had started conversations with two other DDs for this package. Since I am completely at the mercy of a sponsor when they say jump I can only ask how high and try my best to comply. Although there was no specific request for DEP5 there were requests to update the copyright file. And secondly in the maintainers guide it specifically calls out DEP5 format. http://www.debian.org/doc/manuals/maint-guide/dreq.en.html 4.2. copyright This file contains information about the copyright and license of the upstream sources. Debian Policy Manual, 12.5 "Copyright information" dictates its content and DEP-5: Machine-parseable debian/copyright provides guidelines for its format. I didn't read "Policy 12.5.1 Machine-readable copyright information" which states that the format is optional until just now. I didn't realize it was optional. And therefore I was and have been giving it my best shot. Note that the previous copyright file did not address the issues that have been raised about the updated version of the file. The new file corrects some mistakes there. Such as the previous attribution that the program was written by David MacKenzie when the AUTHORS file specifies the original author as David Keppel. The new version is definitely an improvement. > I presume that the issue with the original authors is not yet solved in your > package of "Jun 22 17:39". I posted the file in the email between the "===>snip<===" lines to make it easier to find. The package didn't need to be pulled and unpacked to see the file contents. I posted it in the email for easy reference. (At least I was trying to make it easy. :-) And here is the latest candidate copyright file between "snip" lines again. I am rebuilding with the copyright file shown here. I updated and corrected the comments from the previous copy
Bug#677013: RFS: time
Russ Allbery wrote: > * The formatting of the man page isn't great. There are a few places that > seem to have spurious line breaks (the --append documentation, for > example), That appears to have been some spurious spaces in bad places in the man page. Fixed. > and it's traditional to have a blank line between each option > documented in OPTIONS. The second problem at least can be fixed by just > deleting the .PD 0 command (or at least moving it down to the formatting > section, if it's still desireable for the resource specifiers. Nice! Agreed. Fixed. I moved it down so that the resource specifiers are still compactly listed. I think it is still useful and better that way there. (Now wondering about using that modification on the 'date' man page for its format section. ) > Also, I realize this is a matter of taste, but personally I always use: > > .\" For nroff, turn off justification. Always turn off hyphenation; it makes > .\" way too many mistakes in technical documents. > .if n .ad l > .nh I am often annoyed by poor hyphenation in man pages! When I am quoting man pages in email I always fix up the hyphenation manually. So I very much think this is a good improvement. > for all manual pages, for the entire file (not just for SYNOPSIS). Try > this patch and see what you think: I like it! That should definitely go in. Bob signature.asc Description: Digital signature
Bug#677013: RFS: time
Russ Allbery wrote: > * There seems to be something odd about the time info file. If I run info > time, and then press space, rather than proceeding to the next child > node the way that info normally does, info just reports "no more nodes > in this file." The same is true at a few points in the child node tree. > Is the *.texinfo file possibly missing metadata or proper section links? TL;DR: I figured it out and have fixed it. Details: I have looked into the texinfo problem and have figured out the problem. At one level the problem is the way 'makeinfo' and 'info' deal with the document structure. Using Emacs to navigate through the info page works fine for example. Also the structure of the time.texi file corresponds to a previous generation texinfo template. See for example an older GNU hello-2.1.x version and the two styles line up very closely. That version of GNU hello behaves exactly the same with the same problem. So it appears that time.texi was following the best practices known at the time it was written. However the current GNU hello version has significant changes and behaves differently. It now behaves as you desire. So this was probably a systematic problem that was fixed. To fix this I very slightly restructured the nodes so as to work with 'makeinfo' and 'info' programs by adding an additional index section. So a good all around since having an index section, even if sparse, is a good thing. I also reworked the previously unused index entries. I will be posting a new candidate package with this latest change as soon as I finish tidying up these latest changes. Bob signature.asc Description: Digital signature
Bug#677013: RFS: time
Bart Martens wrote:
> Back to the "time" package itself. Is this your newest version of "time" you
> are requesting sponsorship for ? Or do you want to update it first ?
> http://www.proulx.com/~bob/debian/pool/sid/main/time/2012-06-22/time_1.7-24.dsc
It was. But then Russ Allbery noted some oddities! :-) I have
addressed those issues with a new package turn. Here is the latest
and greatest:
http://www.proulx.com/~bob/debian/pool/sid/main/time/2012-06-24/time_1.7-24.dsc
http://www.proulx.com/~bob/debian/pool/sid/main/time/2012-06-24/time_1.7-24_amd64.changes
I think it is ready to go.
To make the review easier I am attaching the diff with the incremental
changes between the 2012-06-22 and 2012-06-24 versions.
Thanks!
Bob
diff -ru 2012-06-22/debian/changelog 2012-06-24/debian/changelog
--- 2012-06-22/debian/changelog 2012-06-18 16:54:59.0 -0600
+++ 2012-06-24/debian/changelog 2012-06-24 20:36:53.0 -0600
@@ -6,20 +6,24 @@
Bonaccorso. (Closes: #592620)
* Update to new standards version 3.9.3.
* Update to new compat level 9.
- * Use new DEP5 copyright file format.
- * Convert package build system to debhelper dh.
- * Convert package build to quilt 3.0. Use DEP3 format for patch tagging.
+ * Use new machine readable copyright file format.
+ * Convert package build system to debhelper dh build system.
+ * Convert package build to "3.0 quilt". Unwind diff.gz patches. Use
+DEP3 format for patch tagging.
* Use dh_installinfo instead of install-info from postinst scripts.
Thanks Riku Saikkonen, Hans Spaans. (Closes: #617935, #598099)
* ru_maxrss is reported in KBytes not pages. Thanks Richard Kettlewell,
Sven Hartrumpf, Miles Bader. (Closes: #649402)
- * Update bug report email address in README and info. Thanks Faheem
-Mitha. (Closes: #542469)
+ * Update bug report email addresses. Thanks Faheem Mitha. (Closes: #542469)
* Improve capitalization in short description. Thanks Filipus
Klutiero. (Closes: #492669)
* Fix man page roff formatting. Thanks Bjarni Ingi Gislason.
(Closes: #663260)
-
+ * Fix man page formatting oddities. Thanks Russ Allbery for the nice patch.
+See Bug#677013#68 for the discussion.
+ * Fix texinfo standalone info program navigation oddity. Reported by
+Russ Allbery. See Bug#677013#63.
+
-- Bob Proulx Mon, 23 Feb 2012 12:55:30 -0700
time (1.7-23.1) unstable; urgency=low
@@ -174,6 +178,8 @@
-- Dirk Eddelbuettel Sat, 2 Oct 1999 16:00:28 -0400
+Old Changelog:
+
time (1.7-4) unstable; urgency=low, Closes=31767
* debian/{rules,postinst,postrm}: Removed support for html documentation
diff -ru 2012-06-22/debian/patches/series 2012-06-24/debian/patches/series
--- 2012-06-22/debian/patches/series 2012-06-18 16:34:59.0 -0600
+++ 2012-06-24/debian/patches/series 2012-06-24 20:12:36.0 -0600
@@ -1,7 +1,8 @@
-info-direntry.patch
non-normal-exit.patch
-quiet.patch
-rusage-portability.patch
ru_maxrss.patch
+rusage-portability.patch
+quiet.patch
bug-address.patch
configure.patch
+info-direntry.patch
+info-nav.patch
diff -ru 2012-06-22/debian/time.1 2012-06-24/debian/time.1
--- 2012-06-22/debian/time.1 2012-06-17 22:45:39.0 -0600
+++ 2012-06-24/debian/time.1 2012-06-23 16:37:03.0 -0600
@@ -2,10 +2,12 @@
.\" Thanks to Herbert Thielen for a patch
.\" Copyright (C) Dirk Eddelbuettel but freely redistributable
.TH TIME 1 "Debian GNU/Linux"
+.\" Always turn off hyphenation; it makes way too many mistakes in
+.\" technical documents.
+.nh
.SH NAME
time \- run programs and summarize system resource usage
.SH SYNOPSIS
-.hy 0
.na
.TP
.B time
@@ -42,8 +44,9 @@
[
.I ARGS
]
-.hy 1
.ad b
+.\" For nroff, turn off justification.
+.if n .ad l
.SH DESCRIPTION
.B time
run the program
@@ -84,7 +87,6 @@
.IR COMMAND .
.SH OPTIONS
-.PD 0
.TP
.BI \-o " FILE, " \-\-output= "FILE "
Write the resource use statistics to
@@ -96,7 +98,7 @@
.TP
.BR \-a ", " \-\-append ""
Append the resource use information to the output file instead of overwriting
- it. This option is only useful with the `\-o' or `\-\-output' option.
+it. This option is only useful with the `\-o' or `\-\-output' option.
.TP
.BI \-f " FORMAT, " \-\-format " FORMAT "
Use
@@ -168,6 +170,9 @@
followed by that character, to indicate that an invalid resource
specifier was given.
+.\" No blank line between the resource specifiers below so that they
+.\" are more compactly listed.
+.PD 0
The resource specifiers, which are a superset of those recognized by the
.BR tcsh (1)
builtin `time' command, are:
--- 2012-06-22/time.texi
+++ 2012-06-24/time.texi
@@ -70,7 +70,10 @@
by the Foundation.
@end titlepage
-@node Top, , (dir), (dir)
+@contents
+
+@node Top
+@top The GNU @code{time} Command
@ifinfo
Thi
Bug#677013: RFS: time
Hi Sandro! How are things going with you? You were the first person to offer to sponsor this package and gave much help to get it going. Thank you very much for all of your help. But I know that real life intrudes often, as it should, and it has been some days since we have heard from you. What is your desire? I am getting a little nervous about getting the current update uploaded before the freeze. I would like to be ahead of the wave and get through the autobuilders. Thanks! Bob Russ Allbery wrote: > Bob Proulx writes: > > It was. But then Russ Allbery noted some oddities! :-) I have > > addressed those issues with a new package turn. Here is the latest > > and greatest: > > > > > http://www.proulx.com/~bob/debian/pool/sid/main/time/2012-06-24/time_1.7-24.dsc > > > > http://www.proulx.com/~bob/debian/pool/sid/main/time/2012-06-24/time_1.7-24_amd64.changes > > > I think it is ready to go. > > This looks great to me. Both the info page nagivation and the man page > formatting look much better. > > I'm happy to sponsor or leave it to someone else, whatever people would > prefer. signature.asc Description: Digital signature
Bug#677013: RFS: time
Russ Allbery wrote: > Bob, I've uploaded the latest version. Thank you for your work! Thanks! Bob signature.asc Description: Digital signature
Re: deploying package with NFS
Ben Finney wrote: > Richard Hector writes: > > We've run into an issue here, when we deploy a package (created > > in-house) on a system that uses NFS for some filesystems. Due to > > root-squashing, the postinst can't create or chmod/chown the files it > > needs to. > ... > * You're root-squashing filesystems that need root access. I think trying to use a package manager without root access to set ownership and permission is asking too much. In the past when I have done similar things I always had one machine that was an admin host machine for the NFS cluster. That machine was designated to be used for administrative purposes only and it had root_squash disabled just for it so that it had root access over NFS to the cluster. Then all packaging operations were run on that machine. It had full root access over NFS and so there were no problems with setting ownership and permissions. Secondly I didn't mix the databases between these "userland" installs and the OS installed packages. It was for a completely different purpose and it didn't make sense to me to mix them in the operating system's package database. It was conceptually located in NFS space it didn't really belong to any one machine. Therefore I declared my own directory for holding the "userland" database and created script wrappers to ensure that all of the options were set correctly and not forgotten. In my case this was for a different operating system than Debian and using a different package manager. (HP-UX with an rpm port.) I don't know what knobs would need to be turned to do the above with dpkg although I am confident that it would similarly be possible. Bob signature.asc Description: Digital signature
Re: How to add dependencies that exist in another repository
PJ Weisberg wrote: > Ben Hutchings wrote: > > Don't even think of doing this in a package uploaded to Debian. > > Right. I mentioned it mostly for completness, since it's the answer > to the question that was actually asked. I almost added, "I don't > think any Debian packages actually do this," but I've never looked at > most of the packages in Debian. :-) Not part of Debian but packaged for it is the KDE 3.x Trinity project. http://trinity.pearsoncomputing.net/ The packages for Debian there add a source.list.d file as you describe. (And it really confused me until I figured out what it had done. And once I realized that it did that I resolved not to use such packages. If they would do that then what other nasty business would they include that I didn't find?) Bob signature.asc Description: Digital signature
dpkg status Conffiles obsolete flag?
I am hoping to understand the "obsolete" flag on conffiles in the dpkg status file. There are many packages that include this flag at the end of the line. For example: Package: file Conffiles: /etc/magic.mime 272913026300e7ae9b5e2d51f138e674 obsolete /etc/magic 272913026300e7ae9b5e2d51f138e674 obsolete And there many more examples such as in apache2.2-common and gsfonts. These conffiles that are marked obsolete do exist on the system. I could not find where this was documented. The man page or dpkg says: /var/lib/dpkg/status Statuses of available packages. This file contains information about whether a package is marked for removing or not, whether it is installed or not, etc. See section INFORMATION ABOUT PACKAGES for more info. But the section "INFORMATION ABOUT PACKAGES" does not say anything about this field that I could find. I downloaded the source to several packages having obsolete conffiles marked and I could not find any reference in the package that would cause those files to be marked as obsolete. The reason I am looking at this is because I am trying to automate system upgrades from Lenny to Squeeze and some packages have init.d scripts that are marked obsolete and I am trying to understand why. Could some kind soul enlighten me on how conffiles are marked obsolete? Thanks! Bob signature.asc Description: Digital signature
Re: dpkg status Conffiles obsolete flag?
Ansgar Burchardt wrote: > Sven Joachim wrote: > > Bob Proulx wrote: > >> I am hoping to understand the "obsolete" flag on conffiles in the dpkg > >> status file. There are many packages that include this flag at the > >> end of the line. For example: > [...] > > > > They are obsolete because they no longer exist in the package. It is > > the package maintainer's task to deal with them (e.g. remove them if > > they are unmodified and no longer needed). Unfortunately, this is often > > not done. Ah... This makes things clear. I had missed it. > > When they are no longer shipped in the package that used to contain > > them; dpkg does not currently remove obsolete conffiles unless that > > package is purged, see #330256¹. > > dpkg-maintscript-helper(1) also has a good explanation what happens and > why. It also makes dealing with them (in maintainer scripts) easier. Also very useful information. It would seem that packages that have left unmodified obsolete conffiles behind as lint, especially in init.d, are worth a bug report about them. This gets in the way of upgrades such as moving to dependency based booting and from my perspective one of the strongest strengths of Debian is the ability to upgrade. Thanks! Bob signature.asc Description: Digital signature
Removing init.d stop scripts best practice?
What is the best procedure to use for removing a stop script from a package? Moving from: # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 dh_installinit To: # Default-Start: 2 3 4 5 # Default-Stop: dh_installinit --update-rcd-params="start 99 2 3 4 5 ." If nothing more than the above is done then insserv complains with: insserv: warning: current stop runlevel(s) (0 1 6) of script `foo' overwrites defaults (empty). But removing the links unconditionally in the postinst would fail to preserve local changes, if perhaps all of the start links were already removed by the local sysadmin then this would leave none behind to indicate this. Perhaps that is worrying too much about a corner case? rm -f /etc/rc[016].d/K??foo I am sure that others have thought this through in detail. Is there a best practice for it? Or should the stop scripts just be left behind doing nothing to avoid the issue? Thanks, Bob signature.asc Description: Digital signature
Cleaning up obsolete conffiles
I have many obsolete conffiles on my system. It has been upgraded
through many releases.
dpkg-query -W -f='${Conffiles}\n' | grep obsolete
Picking a simple one as an example:
/etc/skel/.bash_profile d1a8c44e7dd1bed2f3e75d1343b6e4e1 obsolete
If I purge the package and install it fresh then that file will not be
there and it will not be listed as an obsolete conffile. But of
course many packages are difficult to purge.
How can I as a system administrator clean that obsolete conffile up?
I can certainly rm -f the file. But afterward it is still listed in
dpkg as an obsolete conffile even though the file was removed.
Is there a method to clean these up, remove them from the disk, and
tell dpkg that they are no longer there? I have searched but I have
not found a way to do this.
Thanks,
Bob
signature.asc
Description: Digital signature
Re: Cleaning up obsolete conffiles
Paul Wise wrote:
> Bob Proulx wrote:
> > How can I as a system administrator clean that obsolete conffile up?
>
> rm -f /etc/some-obsolete-conffile
> apt-get --reinstall install package-that-provided-the-obsolete-conffile
Ah! Thanks. That works.
> > I have many obsolete conffiles on my system.
>
> Please file bugs about obsolete conffiles when you find new ones. The
> packages themselves should clean up their obsolete conffiles.
I am cleaning up Squeeze systems before upgrading. But even Wheezy
and Sid have many. This is on my updated Sid system.
$ dpkg-query -W -f='${Conffiles}\n' | awk '$NF=="obsolete"{print$1}' | xargs
-L1 dlocate | awk -F: '{print$1}' | sort -u | wc -l
26
But it has been upgraded through many releases.. I don't know if
these are still a problem in recent versions or if these have been
hanging around since previous releases. I will clean up my Squeeze
machines and upgrade them to Wheezy. Then any obsolete conffiles left
will be current issues and can be filed.
> To help with this task, you can install the package called
> 'adequate' and enable the post-install debconf prompt.
Thanks for that pointer. I will try it.
> > But of course many packages are difficult to purge.
>
> Every package must be possible to purge, if it is not possible then it
> is a release-critical issue and you should file a severity serious bug
> against the package.
I didn't say impossible. I said difficult. There are dependencies
that cause a large cone to be removed. And then there are essential
packages. I am still trying to use the system at the same time.
$ sudo apt-get purge bash
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
bash-static
The following packages will be REMOVED:
bash* bash-completion* bashdb* common-lisp-controller* devscripts-el*
dpatch* emacs-goodies-el* foomatic-db-engine* foomatic-filters* lsb*
lsb-printing*
python-foomatic*
The following NEW packages will be installed:
bash-static
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
bash
0 upgraded, 1 newly installed, 12 to remove and 203 not upgraded.
Need to get 937 kB of archives.
After this operation, 9,134 kB disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
?]
Thanks!
Bob
P.S. Here is my list on my Sid machine.
$ dpkg-query -W -f='${Conffiles}\n' | awk '$NF=="obsolete"{print$1}' | xargs
-L1 dlocate | awk -F: '{print$1}' |
sort -u
asciidoc
base-files
bash-completion
bashdb
chromium-browser
cvs
epiphany-browser-data
firebird2.5-common
gimp-data
gnome-panel-data
gsfonts
iceweasel
lightdm
lsb-core
mailgraph
setserial
shorewall
shorewall6
smartmontools
source-highlight
stunnel4
subversion-tools
ttf-arphic-uming
vlc-data
w3c-markup-validator
xserver-xorg-video-intel
signature.asc
Description: Digital signature
Re: Cleaning up obsolete conffiles
Paul Wise wrote:
> Please file bugs about obsolete conffiles when you find new ones. The
> packages themselves should clean up their obsolete conffiles.
Is there a bug example or two you could point me to so that I can
follow the standard template of reporting these problems? It appears
I have some bug reports to file against packages in Wheezy.
Bob
dpkg-query -W -f='${Conffiles}\n' | awk '$NF=="obsolete"{print$1}' | xargs -L1
dlocate | awk -F: '{print$1}' | sort -u
bind9
grub-pc
hdparm
initscripts
libgtk2.0-0
munin
mysql-server-5.1
netbase
resolvconf
rubygems1.8
shorewall
signature.asc
Description: Digital signature
Re: tagging bugs "woody"?
Andreas Metzler wrote: > Frank Kuster wrote: > >users working with Debian woody often do not look at archived bugs when > >reporting bugs on a package. Therefore it is likely that bugs that have > >long been fixed in unstable, but will never be in woody will be reported > >multiple times again. I have been a victim of this problem myself. > Imvvvho this a matter of personal taste, and the manual (the part I > snipped) can be taken as guideline instead of as bible. Personaly I'd > keep only these bugs open which _really_ get reported at least twice, > otherwise the BTS is to messy for me to work with. I believe there are many people that look for bugs, won't find them, but won't report them either. Even if people do not report a bug it benefits from from being able to see the bug in the BTS. In this way the BTS acts as a knowledge database. Therefore I would like to see bugs in stable kept open until the next stable fixes them. I realize there are technical issues to be resolved in the BTS in this area. Bob pgpNM2Lb6tWoX.pgp Description: PGP signature
Re: newbie packaging question
Eric Winger wrote: > would it be sacreligious to ask why sources are kept in non-free? You are asking an obvious question and the answer is the obvious one. The sources are in non-free because they are not free. Look at the copyrights of any of the packages in non-free and you will see that they all have some type of restriction. Bob pgpWMrXBEvl9y.pgp Description: PGP signature
Re: gcc versions and c++ packages
David Meggy wrote: > Searching the mailing lists, oddly shows up nothing. I think the debian > mailing list search page needs some fixing. I think this was in debian-devel. Since I had the page up in my browser when I read your message here it is. http://people.debian.org/~rmurray/c++transition.html I tried the Debian search engine http://lists.debian.org/search.html but it returned no hits. So I might have to agree with your statement. But I usually use google.com for my searching. You can restrict the matches to just the site you are looking for. This works for more than just the debian lists and is a generally useful thing to know about the search engine. Using this search string finds the plan as the first match. site:debian.org gcc transition plan Personally I will be happy two years from now when we have the transition completely behind us instead of mostly in front of us. HTH, Bob pgpfkiA6qXn1x.pgp Description: PGP signature
Re: backing up/replacing files from another package
Eric Winger wrote: > Can't I even "Depend" on a package and then fine tune its configuration > though? I don't think you can depend upon a package and tweak its conffiles. It would be interesting to be able to do that and it certainly makes sense from an object oriented inherit and modify viewpoint. Frank suggested building your own package which completely replaced the original package and naming it autofs-$erico or something similar and if you are up for it that would work very well. I do that in a couple of places, but not for autofs. Some packages can be renamed and tweaked with little effort. Others require more effort. But I realize that recompiling the package can make you nervous for critical and obtuse applications like NFS. I have the same problem as you and have solved it but unfortunately my solution is probably a little heavy for your needs. I install system configuration scripts which I call a 'sysconf' package. These scripts run both at system boot time and by cron. The first thing they do is rsync a new copy of themselves from our "gold" servers ensuring that they are the latest available. Then they run to configure all of the little bits of the system like /etc/auto.master which locally we need configured in a particular way. As packages are normally upgraded through the life of a system I train people to always say 'Y' to the replace a conffile question. Sure this may leave the system in a generic and locally unworkable state. But the file is updated to follow the package to the latest version. After any particular update that a question like that is asked I train people to always run our 'sysconf' script which configures all of the little bits of the system, including conffiles, which need to be tweaked up. This leaves the system in a locally configured good state and we are done. The sysconf scripts must be smart enough to handle reconfiguring these files and the *running* system in place. Because it runs by cron this will fix any host that gets accidentally left in a partially configured state. Or one that the user left in a broken state. By running at boot time it means that a host that is powered off for a long time will be brought up to the latest local configuration when it is powered back on. Bob pgpIALaUOmNM5.pgp Description: PGP signature
Re: fvwm-themes gets better
Andrei Mitrofanow wrote: > nobody interestet to fvwm-themes? > http://smilebef.homelinux.org/~smilebef/ [Reading my note before sending it I see it sounds harsh. I don't mean it that way. I mean it constructively so that you will know why I personally have not tried any of your packages. Please take this constructively.] I use FVWM. I am interested in themes. But I don't read German and could not make any headway on your web page. So I am left out. Which is fine. But I am also less likely to try your packages if I don't have clues as to what is in them. Of the three screenshots present on your web page, two have almost identical purple-grey themes and seem identical to me. The other one has the same theme but with a different color. Taken together it does not look like very much. Therefore it is not interesting enough to sell me enough to download a set of unknown deb files and try to inspect them carefully because they are not from a previously trusted source and to test them on my machine. Those themes look too bland to be interesting, sorry. Compare this to: http://fvwm-themes.sourceforge.net/screenshots/ There are many more interesting themes there. It would be interesting to have someone package those for Debian. Perhaps that is even what you are trying to do. But again, I can't tell that. Bob pgps0qSnvuSTn.pgp Description: PGP signature
Re: backing up/replacing files from another package
Matthias Urlichs wrote: > > As packages are normally upgraded through the life of a system I train > > people to always say 'Y' to the replace a conffile question. Sure > > this may leave the system in a generic and locally unworkable state. > > So why not "N"? That may leave the package, at worst, in a "I can't find > a necessary setting and am going to crash" state, but the following call > to your sysconf program will wake it up right away. Most of the time that would be completely true. Especially for tiny files like /etc/auto.master. But for other files with more documentation in them I prefer to get the new file with the new comments in them. Thinking of files for apache, postfix, bind, and other packages with complex conffiles. But you are right that if my script is written well it would work either way. If my script is not well enough written then I might have a bug. :-) > On the other hand, "Y" will replace that file with a generic version. At > best the package does nothing, but at worst it'll have inconsistent > configuration and do some random things which aren't expected. The package should not do anything unexpected. It should work as if you had just installed the package on a new machine and had not yet done any configuration to it. Debian packages should "just work" out of the box. If a package needs some configuration then it should behave reasonably until further configured. Since my system configuration scripts will be launched and run after the update things will be configured again in just a moment. Mail is the only package which I think has any time where it won't work right on my site with the default configuration. But it should be back working again right away after our scripts run. Other things may be confused for a while but for the time we are talking about it is not significant. Basically I can't give good arguments strongly for either Y or N once we have a script in place to automatically set the package configuration for our site. You have asked a good question and I could see people debating it either way. I just prefer to have the latest commentary in the files. That way new machines and old machines both look very similar. Then by looking at the conffiles you won't be able to tell that it was a potato machine updated to woody updated to sarge. It will just look like a sarge machine. When I write a script to configure a package I normally have two choices. 1) I can replace the entire file with my own configured copy of the file. 2) I can read-modify-write the file to only change what I need to change. This preserves other changes that may have been made in the file. For the /etc/auto.master case I just replace the file whole. For the case of /etc/postfix/main.cf I only modify things like the transport map, which we use on our site, and leave other things alone since there are many options that could be host locally configured there. Getting back on topic for d-m let me suggest that package authors try to set up files such that they can be mechanically updated whenever possible without the need to read-modify-write. Directories of configuration files are great because then a single file can be copied into place and everything else left untouched around it. And this can be undone with a simple removal of that file. Of course /etc/cron.d/* is a classic example of directories of files. And /etc/apt/apt.conf.d/* is another. I can place a file with our web proxy configuration there easily. And /etc/spamassassin/*.cf also allows easy, automated configuration. But ssh is the opposite case. It has only a single file /etc/ssh/sshd_config and so that is a read-modify-write case. Most of these issues are forced upon the maintainer by the upstream architecture. But sometimes you can make it work. The latest bind9 I see uses 'include /etc/bind/named.conf.local' which simplifies the local configuration section. The main file I can leave unchanged and just completely replace the local section. This is a nice way to organize the files. Bob pgpcUjNkIDhDG.pgp Description: PGP signature
--force-confdef? When is it different?
I am setting up a scripted update for a pool of machines and trying to understand the ramifications. In the dpkg man page: confnew: If a conffile has been modified always install the new version without prompting, unless the --force-confdef is also specified, in which case the default action is preferred. confold: If a conffile has been modified always keep the old version without prompting, unless the --force-confdef is also specified, in which case the default action is preferred. confdef: If a conffile has been modified always choose the default action. If there is no default action it will stop to ask the user unless --force- confnew or --force-confold is also been given, in which case it will use that to decide the final action. When would confdef ever not be the same as confold? How is the default action determined? I thought the default action was always simply 'N'. No? I am thinking that --force-confmiss --force-confold are the appropriate options for my case. But if there is a time when the default is determined to be different then should I specify --force-confdef as well? Thanks Bob pgpWFEsjsI6m9.pgp Description: PGP signature
Re: Problem with dependency declaration
Andreas Metzler wrote: > Frank Küster wrote: > > in a package that I maintain (sponsored by a DD), I use a call to > > stat. In sarge, /usr/bin/stat is in coreutils - of course I don't need a > > dependency on that. However, in woody stat was in a separate > > package. Usually packages keep really old versioned dependencies - this > > might be important for upgrades, and it's friendly for backporters. I just ran into almost the same case with a local meta package that I maintain. So this has suddenly become pertinent for me as well. > > If coreutils wouldn't be of priority required, I would just add > > "coreutils | stat" to the dependencies. What should I do in this case? > > Stat was in coreutils from the first time it appeared in Debian, so a > > versioned Depends: wouldn't make any sense (except that it makes lintian > > and linda be quiet...) > > I don't have a sid system at hand, but doesn't coreutils > Provides/Replaces stat? Is there any reason that stat was removed from sarge? Since coreutils has subsumed 'stat' shouldn't 'coreutils' create an empty package 'stat' for the transition? This would be the same as with shellutils, fileutils, textutils. It can then be removed at the next release along with those other three. How I 'stat' different than the other three? As an alternative could a standalone stat package could be created which depends upon coreutils and conflicts with older stat packages? Bob pgpvwn1KZspxn.pgp Description: PGP signature
Re: Special requirements for scripts in /etc/rcS.d?
Frank Küster wrote:
> stat is called to get uid and exact permissions of a temporary
> configuration file which has just been created.
Perl is standard on systems. I hesitate to put more use of it in init
scripts but... Perhaps this would be of use instead of stat just to
work around this problem?
perl -e 'printf("%d\n",(stat($ARGV[0]))[4]);' /tmp # print uid in decimal
0
perl -e 'printf("%o\n",(stat($ARGV[0]))[2]);' /tmp # print mode in octal
41777
My only question now is where did that '4' come from in the mode? But
the last four digits always seem to be correct.
Bob
pgpbtajUHGvHH.pgp
Description: PGP signature
Re: Special requirements for scripts in /etc/rcS.d?
Christoph Berg wrote:
> Re: Bob Proulx in <[EMAIL PROTECTED]>
> > perl -e 'printf("%o\n",(stat($ARGV[0]))[2]);' /tmp # print mode in octal
> > 41777
> >
> > My only question now is where did that '4' come from in the mode? But
> > the last four digits always seem to be correct.
>
> stat(2):
>S_IFDIR004 directory
Aha! (smacking forehead) I should have known that. Thanks for
pointing me to it.
Also the second aha! of the day was when Eric Schwartz kindly pointed
out to me that if stat was not available because /usr was not mounted
then using perl would not help the situation. I was still fixated
upon the 'coreutils | stat' issue of the previous thread. :-)
Bob
pgpXjT2MAJxiS.pgp
Description: PGP signature
Re: Need a mentor with a !x86 machine
John Lightsey wrote: > I'm trying to adopt xmms-goom which has a release critical bug related to > !x86 architectures. I believe the version I've packaged fixes the problem, > but I don't have access to a !x86 machine running unstable to test it on. If > someone could download, build, and test this package I'd be very gratefull. > > http://www.nixnuts.net/xmms-goom.tar.gz > > All of the necessary files are included. If it gives you any errors during > the build process please send me a copy of the build log. One thing I see in the upstream source which will likely cause trouble is the following. File ./src/Makefile.am: CFLAGS = -O9 -g -DDATADIR=\"@[EMAIL PROTECTED]" @XMMS_CFLAGS@ `sdl-config --cflags` And then later on in the file: zoom_filter_mmx.lo:zoom_filter_mmx.c gcc -O9 -c -funroll-all-loops -fno-schedule-insns zoom_filter_mmx.c -o z oom_filter_mmx.lo -DHAVE_MMX Those hard coded CFLAGS can't be disabled at configure time. On any architecture with optimizer sensitivities such as is often the case on less mature ports this can cause trouble. As help to convince upstream this is bad, refer them to the automake documentation. Variables reserved for the user === Some `Makefile' variables are reserved by the GNU Coding Standards for the use of the "user" - the person building the package. For instance, `CFLAGS' is one such variable. Sometimes package developers are tempted to set user variables such as `CFLAGS' because it appears to make their job easier - they don't have to introduce a second variable into every target. However, the package itself should never set a user variable, particularly not to include switches which are required for proper compilation of the package. Since these variables are documented as being for the package builder, that person rightfully expects to be able to override any of these variables at build time. To get around this problem, automake introduces an automake-specific shadow variable for each user flag variable. (Shadow variables are not introduced for variables like `CC', where they would make no sense.) The shadow variable is named by prepending `AM_' to the user variable's name. For instance, the shadow variable for `YFLAGS' is `AM_YFLAGS'. Which would just cause them to want to put AM_CFLAGS = -O9 in their Makefile.am which is just as bad. Instead they should not set it at all. Comments from the list as to how to handle this problem? Bob pgpfi4W2mxS5I.pgp Description: PGP signature
Re: Need a mentor with a !x86 machine
John Lightsey wrote: > If anyone with a non-x86 machine would like to take a look again and give > feedback on wheter or not it compiles properly, I'd really appreciate it. > The build logs that I recieved were very helpfull. I grabbed that and gave it another run. There are still -O9 references in the Makefile.in. The Makefile.am was cleaned up and so if the Makefile.in was regenerated or patched then that problem would be resolved. Those caused gcc to SIGSEGV during the compile. I am running a slightly old gcc-3.3 at the moment and that might be fixed already. But I believe you need to either regenerate the Makefile or force a distclean at the start. Removing those -O9's from the Makefile and without that everything compiled. There were however a number of pointer / integer which need to be looked at. I will send the trace to you directly. Bob pgpSRuryBD83h.pgp Description: PGP signature
pbuilder ${shlibs:Depends} yields libc6-2.2.4-4 ???
I just recently started using pbuilder. Previously I have been
maintaining my own chroots as required. I can see why people
recommend pbuilder. It is very nice! But things do not seem to be
operating as I believe they should and I have been unable to figure
this out. Let me set the stage.
sudo apt-get install pbuilder
echo 'MIRRORSITE=' > ~/.pbuilderrc # MIRRORSITE= my apt-proxy cache
sudo pbuilder create
cd # some package directory which uses ${shlibs:Depends} in control
grep ^Depends: debian/control
Depends: ${shlibs:Depends}
pdebuild
dpkg-deb --info /var/cache/pbuilder/result/*.deb |grep Depends:
Depends: libc6 (>= 2.2.4-4)
So then in an attempt to resolve this I add DISTRIBUTION=woody to my
$HOME/.pbuilderrc file but I receive the same result. Why doesn't the
depends show up as 2.2.5-11.5? So I login to the chroot area to check.
sudo pbuilder login
dpkg --status libc6 |grep ^Version:
Version: 2.2.5-11.5
Really and truly 2.2.5 is installed in the changeroot. But 2.2.4 is
getting listed as the Depends: for the package getting built. I
manually built a package in the pbuilder chroot with the same result.
So the problem would seem to me to be in dpkg-shlibdeps in the chroot.
No debian/shlibs.local exists. The /etc/dpkg/shlibs.default only
contains comments.
My system is mainly woody but does have a variety of backports.
Thinking this might be something related to the version of pbuilder or
debootstrap I updated to the latest pbuilder from unstable (version
0.96) which required a newer debootstrap which I pulled (version
0.2.9.backports.org.1) but with the same result. And that is when I
decided that someone must have debugged this already and that I would
ask for help.
Why does building a package with pbuilder generate the seemingly wrong
version for Depends: of 2.2.4-4 regarldless that 2.2.5-11.5 is the
installed library? What am I doing wrong?
Thanks
Bob
pgp2DyYGeGfsL.pgp
Description: PGP signature
Re: pbuilder ${shlibs:Depends} yields libc6-2.2.4-4 ???
Rene Engelhard wrote: > Bob Proulx wrote: > > Why does building a package with pbuilder generate the seemingly wrong > > version for Depends: of 2.2.4-4 regarldless that 2.2.5-11.5 is the > > installed library? What am I doing wrong? > > Nothing. > > [EMAIL PROTECTED]:~$ sudo chroot chroots/stable cat > /var/lib/dpkg/info/libc6.shlibs > libc 6 libc6 (>= 2.2.4-4) Thanks for taking the time to answer. I am not unappreciative but unfortunately I did not find this very informative to me. Even that reference to the libc6.shlibs file, while correct, was obtuse to me. So before the mailling list archive gets split into the new month I decided I would get another in with an update with an expansion of this topic. Digging through the dpkg-shlibdeps perl script and I can see where it is reading the file you referenced. Therefore it appears that shared library packages can specify an ABI version separate from their installed package version. The glibc package specifies 2.2.4-4 as the ABI so that even though version 2.2.5-11.5 is installed. The installed value is overridden with the libc6 package specified version from the shlibs file. Digging into the glibc package I see that they manually set the ABI version to 2.2.4-4 in the debian/rules.d/shlibs.mk file. Now knowing a little more about what to look for I was able to locate documentation on the process. Here is the pointer. http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps Thanks again, Bob pgps4sIwm0slr.pgp Description: PGP signature
Re: Should I always clean in debian/rules before making binary?
Frank Küster wrote: > Colin Watson <[EMAIL PROTECTED]> schrieb: > > It's easier to use DESTDIR=$(CURDIR)/debian/tmp if DESTDIR support is > > available; that way you get less confused by /etc. > [..] > Hm, how do I know (other by trial and error) whether a package supports > this? autoconf'iscated ones do not use it generally, do they? Older automake generated Makefiles do not support DESTDIR. But newer automake generated Makefiles do support it. I don't know at what version that support was enabled. But if the tool uses a new automake to generate the files or if you happen to regenerate them then you should have DESTDIR support. There appear to be three cases. 1. The developer wrote the Makefiles by hand and did not supply any support for DESTDIR natively. 2. The developer used automake and therefore supports DESTDIR by default. 3. The developer used automake but also supplied additional Makefile sections by hand and those additional sections do not support DESTDIR. So it is partially there but not fully functional now. That last one happens every so often. I found and reported one in gettext just recently (which was promptly fixed by upstream). But those are the hardest to detect without actually trying. Trial and error is probably the easiest method. Bob pgpOFWFs3v7EH.pgp Description: PGP signature
Re: What format package for debian test phase?
Halim Boukaram wrote: > I've finished making the rpm for my package. > > Should i convert it to a 'deb' file (using alien) > before trying to get it uploaded to debian test folder > or should it be rpm or tarred. The 'alien' program is really good. But it is not perfect. And we would like Debian packages to be perfect! :-) So for a package which is going to get wide exposure it is not good enough to do the job completely. Also the version from woody stable has some known flaws. The sid version of alien is required at the moment to avoid them. If you have a package and you would like someone to package it then you can post a RFP (request for packaging) and try to get someone to sponser the package for you. That is really the best case because then you get someone who is expert in the native packaging to handle the details. If you are wishing to learn how to package for Debian yourself then both 'alien' and 'dh_make' are useful in different ways to get a head start. With 'alien' use the --keep and --generate options. It will create directories for you to edit and change to later build the deb. The 'dh_make' works similarly but from your source tar.gz to create a debian directory template to build your package from scratch. The packaging documentation on www.debian.org is very useful. And of course if you have packaging questions this mailing list can help. Bob pgp0wyHChMZaN.pgp Description: PGP signature
Re: setgid-wrapper
Steven Augart wrote:
> First, a retraction:
>
> James Damour wrote:
> >On Tue, 2004-05-18 at 09:03, Steven Augart wrote:
> >>As you probably know, when a shell sees that it is running a setuid or
> >>setgid shell script, it detects this because the euid and ruid or egid
> >>and rgid are different. It "fixes" this by setting the euid to be the
> >>same as the ruid, and/or egid the same as the rgid, effectively
> >>turning off the setuid/setgid bit.
> >
> >Actually, I didn't know that. Thanks for the info!
You will only see this on systems which allow set-uid shell scripts.
Here is an example from HP-UX.
#!/bin/sh -p
id
Setuid outputs:
uid=1423(rwp) gid=2000(esl) euid=0(root) ... long list of groups deleted...
> Jeroen van Wolffear wrote:
> > Huh? This is wrong. It is the kernel who refuses to set the UID or GID
> > on execution of setuid/gid shell scripts.
On Linux. But not on the classic UNIX kernels.
> > Where did you read that?
>
> It probably started from programming on 2.9 BSD and 4.2 BSD
> and 4.3 BSD Unix systems, where (if I recall correctly) setuid
> shell scripts worked.
Yes. Set-uid shell scripts work on HP-UX, for example, the kernel of
which is a derivative of 4.2 BSD. ("Work" used loosely here, because
it is a bad thing.)
However, setuid shell scripts are such a security hole that they
should never exist. Much of the time spent by the security scanners
for unix scan for just such problems.
> I have spent the past four years confused on this issue, mislead by the
> discussion of the -p flag on the Bash 2.05b manual page:
>
> Turning this option off causes the effective user and group ids
> to be set to the real user and group ids.
>
> Now I know why I had such trouble getting setuid programs to work
> on Linux.
Remember that bash runs on many systems such as Solaris, AIX, HP-UX,
etc. and not just on Linux. Therefore there is a lot of baggage to
work around classic bugs that modern systems have corrected. If those
systems would update they would fix this too. But they are even more
stable that Debian stable! :-)
Bob
pgpCORE3EcJgn.pgp
Description: PGP signature
Re: release as a package or add to APT's file list?
Jarno Elonen wrote:
> ..and the said utility script looks like this:
>
>
> source /etc/upgrade-system.conf
>
> echo "Updating available package lists..."
> apt-get -q=2 update
Are you randomizing your start time? Look at cron-apt for an example.
Otherwise there is a high potential to cause a load spike and trigger
failures. [Note that $RANDOM is a bash'ism.]
> echo -e "\nUpgrading installed packages..."
> apt-get $UPGRADEOPTS
Is UPGRADEOPTS upgrade? Or dist-upgrade? For 'testing' it would need
to be dist-upgrade, of course.
To make this script run the same when run interactively as well as run
from cron the following may be beneficial. Or perhaps redirect the
input 'exec echo -e "\nCleaning APT cache..."
> apt-get clean
>
> if [ -f /usr/bin/deborphan ]
> then
> echo -e "\nChecking for orphan files..."
> if [ `deborphan $ORPHANOPTS | wc -l | tr -d " "` = 0 ];
> then
> echo "No orphan file to be purged."
> else
> echo "Purging orphan files..."
> deborphan $ORPHANOPTS | xargs dpkg --purge
The --purge would make me nervous. But I guess I should just file a
bug against gphoto2 since it always shows up in deborphan's output on
my system. Something is strange about it. But one can always hold
it to avoid that.
> fi
> fi
>
> if [ -f /usr/bin/update-menus ]
> then
> echo -e "\nUpdating menus..."
> update-menus
> fi
>
> echo -e "\nSystem upgrade completed."
>
Some more random thoughts without much thinking...
In my own scripts I always set these options:
APT::Get::Remove "false";
But by the use of deborphan above I know you don't want to disable
removing packages. But I do and it makes the process much safer. But
this next one you might want, at least the --force-confold part. The
replace missing config file one has raised a lot of debate in the
past.
DPkg::Options {"--force-confmiss";"--force-confold"};
Bob
pgpXCz5CjQvjj.pgp
Description: PGP signature
Re: Best way to maintain a package for multiple Debian releases?
Jarle Aase wrote: > I'm about to make some .deb packages. Some will hopefully be accepted as > official packages, while others will be built for my own convenience (to > ease installation and upgrades on Debian servers I maintain). > > The packages includes shared C++ libraries, binaries, databases (MySQL) > and some Java programs. > > I have set up a machine with Debian "unstable" to work on the packages I > hope to get into the Debian distribution. I will however need all of the > packages in a "stable" repository (for my own use) and some even > backported to "Woody". > > How is the best way to maintain debianized packages that are bulit for > several Debian releases? Should I use the approach described in "Debian > New Maintainer's Guide", or some other tols like Yada? For your own purposes I would just maintain the packages on the oldest of the tracks that you need to support. That is, if sarge is the oldest that you need to support then just use a sarge build for your own use on sarge, etch, and sid. Because the system is backward compatible you can run programs compiled on the older system on the newer system. You don't need to compile your program for your own use against every release. If your oldest system that you need is woody then compile on woody and run on sarge, etch, and sid. The pbuilder package is useful to set up a chroot and build against woody on sarge and other combinations. If this is a package that you are trying to get sponsored or otherwise into Debian then it should be built against the current sid at the time of upload. This is because policy changes will dictate certain behaviorss such as the previous transition from /usr/doc to /usr/share/doc and things like that. Also it links against the current libraries and avoids dependencies against the older libraries so that they may be retired in future releases. Maintaining your own "backport" package to woody while trying to put that same package into sid can mean confusion with the package version number. If you use the same version number for both then the md5sums for the resulting official debian package in the depot will be different than the one in your backport. This can confuse both apt and yourself. In that case I would give the version to be uploaded to Debian the real version number and give your backport a backport number. That is, decrement the release number by one, append a unique identifier to denote that this is your personal backport, add a revision. For example 1.1-1 becomes 1.1-0.jarle.1. Then your machine will naturally upgrade to the official package when an upgrade is presented to it. As for maintaining your own apt depot look into using debarchiver. It works quite well for maintaining a small depot. See also mini-dinstall for another alternative. These both automate the running of apt-ftparchive to build a depot automatically. For easy uploading into your archive see dupload or dput, depending on whether you prefer perl or python respectively. Bob signature.asc Description: Digital signature
Re: LessTif conflicts with Motif, doesn't provide Motif, and is required???
John Hendrickson wrote: > Why in the world did DMs compile KDE to say: You must use LessTif and > uninstall Motif??? What kde package requires lesstif? I was unable to locate one using 'apt-cache showpkg lesstif1' and 'apt-cache showpkg lesstif2'. Note that lesstif1 and lesstif2 implement versions 1 and 2 of the ABI respectively. But libmotif is up to version 3 at this time. That is probably the source of your problem. There is no equivalent to the version 3 ABI available from lesstif at the moment. > Motif was "here first" and has every right to use "motif" as it's library > name! If lesstif doesn't like motif it can change LessTif's lib names to > lesstif. The Motif library is not free and does not meet the DSFG (Debian Free Software Guidelines). Therefore Debian cannot distribute it in the main Debian archive. Because non-free is not part of Debian the Motif library is also not part of Debian. There can be no Debian software in main that depends upon that library. However the library is available to users in the non-free section of the depot. The Lesstif library was written from scratch with the goal to produce a free software replacement for the Motif library which is not free. This is not Debian specific. This was developed to meet the general need for a free Motif compatible library outside of Debian. But Debian does package and distributes it. It is really that one or none because there is no other alternative that is free software. This has nothing to do about the name of the library. Clearly Motif was there first. Lesstif is a joke on that name. The goal was to produce a free version of the library and through versions 1 and 2 this works. But they are lagging behind with version 3. Such is the nature of volunteer projects. > As far as Debian trying to force Motif out of the market and prop up > LessTif in it's place by making it disfunctional? It's an insult to all > unix users. I think most unix users understand that any group that has "open" in their name is rarely really open. The OpenGroup controls the Motif copyright and has been slow and opening up the source to it. If you feel so motivated you might contact them and check on the status of freeing up the copyright on the the Motif library. > I see clear patterns of favoritism developing and I dont' like it. There is a clear pattern of favoritism for free software. So much so that Debian voted to change the Social Contract to say "Debian will remain 100% free". Because Motif is not free software it cannot be part of Debian under the current DSFG. The Social Contract also says "We will not object to non-free works that are intended to be used on Debian systems". Bob signature.asc Description: Digital signature
Re: Emacs mode package problem
Rakotomandimby Mihamina wrote: > I want to make a rpm-spec-mode package in order to create RPM specfiles > under Debian. Unfortunately I don't know anything about your problem building your package. But I just wanted to note that emacs already comes with a mode for dealing with rpm spec files. It is a standard part of emacs and is a minor mode of sh-mode. Bob signature.asc Description: Digital signature
Re: separate binary and sources
gregor herrmann wrote: > On Thu, Jul 07, 2005 at 08:15:06PM +0200, Rakotomandimby Mihamina wrote: > > But what and how should I separate the created files? > > Should I put them into the same directory? orig, diff, dsc,.. in a flat > > way? I guess yes > > Yup. > > Maybe you'd like to take a look at mini-dinstall and dput - very > handy tools an the server resp. client side for managing small > repositories. Also look at debarchiver. I found that to be easier and more featured than mini-dinstall. Bob signature.asc Description: Digital signature
Re: separate binary and sources
John Skaller wrote: > (a) it does not provide binary packages > (b) apt tools can't build from source > > The latter is exceptionally annoying (which I consider > a very polite form of what I'd like to actually say ;) > > Is there a tool which does that? > > I use Synaptic GUI tool, it would be nice if a tool > like that could build from source transparently. Have a look at apt-src. apt-cache show apt-src apt-src is a command line interface for downloading, installing, upgrading, and tracking Debian source packages. It makes source package management feel a lot like using apt to manage binary packages, and is being used as a testbed to work on adding source dependencies to Debian. It can be run as a normal user, or as root. If you want a convenient way to track updates to packages while preserving your local modifications, this is a way to do that. Note that I have not actually looked at it myself yet. It is on my todo list. Bob signature.asc Description: Digital signature
Re: uploading packages built on an amd64 box inside ia32 chroot
Stefano Zacchiroli wrote: > Are there any problem in uploading packages built inside that chroot? It should be fine. In fact that is a recommended practice. It prevents flavor from the developer's machine leaking into the build. The 'pbuilder' package is very nice for managing these types of chroots. If this is the first time you have been through this then you are doing good by looking at things closely. But things look normal to me when I build in a 32-bit chroot. > The only strange thing I notice on binaries built there is that ldd > reports a dynamic dependency on "linux-gate.so.1" which is not there for > binaries build elsewhere. Interesting I don't see that on my amd64 machine building in a sarge chroot. But I don't have an updated sid chroot at the moment and am too lazy to wait for it to build so this may have been introduced post sarge. But I have heard from others on the lists that the linux-gate is a virtual library provided by the linux 2.6 kernel. I don't know if that is accurate. And that is about all I know. Bob signature.asc Description: Digital signature
Re: What format package for debian test phase?
Halim Boukaram wrote: > I've finished making the rpm for my package. > > Should i convert it to a 'deb' file (using alien) > before trying to get it uploaded to debian test folder > or should it be rpm or tarred. The 'alien' program is really good. But it is not perfect. And we would like Debian packages to be perfect! :-) So for a package which is going to get wide exposure it is not good enough to do the job completely. Also the version from woody stable has some known flaws. The sid version of alien is required at the moment to avoid them. If you have a package and you would like someone to package it then you can post a RFP (request for packaging) and try to get someone to sponser the package for you. That is really the best case because then you get someone who is expert in the native packaging to handle the details. If you are wishing to learn how to package for Debian yourself then both 'alien' and 'dh_make' are useful in different ways to get a head start. With 'alien' use the --keep and --generate options. It will create directories for you to edit and change to later build the deb. The 'dh_make' works similarly but from your source tar.gz to create a debian directory template to build your package from scratch. The packaging documentation on www.debian.org is very useful. And of course if you have packaging questions this mailing list can help. Bob pgpxKSHmhL395.pgp Description: PGP signature
Re: setgid-wrapper
Steven Augart wrote:
> First, a retraction:
>
> James Damour wrote:
> >On Tue, 2004-05-18 at 09:03, Steven Augart wrote:
> >>As you probably know, when a shell sees that it is running a setuid or
> >>setgid shell script, it detects this because the euid and ruid or egid
> >>and rgid are different. It "fixes" this by setting the euid to be the
> >>same as the ruid, and/or egid the same as the rgid, effectively
> >>turning off the setuid/setgid bit.
> >
> >Actually, I didn't know that. Thanks for the info!
You will only see this on systems which allow set-uid shell scripts.
Here is an example from HP-UX.
#!/bin/sh -p
id
Setuid outputs:
uid=1423(rwp) gid=2000(esl) euid=0(root) ... long list of groups deleted...
> Jeroen van Wolffear wrote:
> > Huh? This is wrong. It is the kernel who refuses to set the UID or GID
> > on execution of setuid/gid shell scripts.
On Linux. But not on the classic UNIX kernels.
> > Where did you read that?
>
> It probably started from programming on 2.9 BSD and 4.2 BSD
> and 4.3 BSD Unix systems, where (if I recall correctly) setuid
> shell scripts worked.
Yes. Set-uid shell scripts work on HP-UX, for example, the kernel of
which is a derivative of 4.2 BSD. ("Work" used loosely here, because
it is a bad thing.)
However, setuid shell scripts are such a security hole that they
should never exist. Much of the time spent by the security scanners
for unix scan for just such problems.
> I have spent the past four years confused on this issue, mislead by the
> discussion of the -p flag on the Bash 2.05b manual page:
>
> Turning this option off causes the effective user and group ids
> to be set to the real user and group ids.
>
> Now I know why I had such trouble getting setuid programs to work
> on Linux.
Remember that bash runs on many systems such as Solaris, AIX, HP-UX,
etc. and not just on Linux. Therefore there is a lot of baggage to
work around classic bugs that modern systems have corrected. If those
systems would update they would fix this too. But they are even more
stable that Debian stable! :-)
Bob
pgpxxtYtjlp8e.pgp
Description: PGP signature
Re: release as a package or add to APT's file list?
Jarno Elonen wrote:
> ..and the said utility script looks like this:
>
>
> source /etc/upgrade-system.conf
>
> echo "Updating available package lists..."
> apt-get -q=2 update
Are you randomizing your start time? Look at cron-apt for an example.
Otherwise there is a high potential to cause a load spike and trigger
failures. [Note that $RANDOM is a bash'ism.]
> echo -e "\nUpgrading installed packages..."
> apt-get $UPGRADEOPTS
Is UPGRADEOPTS upgrade? Or dist-upgrade? For 'testing' it would need
to be dist-upgrade, of course.
To make this script run the same when run interactively as well as run
from cron the following may be beneficial. Or perhaps redirect the
input 'exec echo -e "\nCleaning APT cache..."
> apt-get clean
>
> if [ -f /usr/bin/deborphan ]
> then
> echo -e "\nChecking for orphan files..."
> if [ `deborphan $ORPHANOPTS | wc -l | tr -d " "` = 0 ];
> then
> echo "No orphan file to be purged."
> else
> echo "Purging orphan files..."
> deborphan $ORPHANOPTS | xargs dpkg --purge
The --purge would make me nervous. But I guess I should just file a
bug against gphoto2 since it always shows up in deborphan's output on
my system. Something is strange about it. But one can always hold
it to avoid that.
> fi
> fi
>
> if [ -f /usr/bin/update-menus ]
> then
> echo -e "\nUpdating menus..."
> update-menus
> fi
>
> echo -e "\nSystem upgrade completed."
>
Some more random thoughts without much thinking...
In my own scripts I always set these options:
APT::Get::Remove "false";
But by the use of deborphan above I know you don't want to disable
removing packages. But I do and it makes the process much safer. But
this next one you might want, at least the --force-confold part. The
replace missing config file one has raised a lot of debate in the
past.
DPkg::Options {"--force-confmiss";"--force-confold"};
Bob
pgpCi25PrDr9f.pgp
Description: PGP signature
Re: namespace conflict != package Conflict?
Anthony Towns wrote: > GNU Interactive Tools hasn't seen an upstream update at all since 2001, > and looking at the diffs since .18, doesn't seem to have had any > significant changes since 1999. The Debian updates seem mostly to be > updating the build system, rather than user-visible changes. I am not sure upstream inactivity by itself is a good measure. For example compare this to GNU rcs. GNU rcs has not had an upstream modification since 1995. I would hate to see this argument applied there that we should remove or rename RCS commands. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multiple Binary and man pages
Marco Presi <[EMAIL PROTECTED]> [2002-09-08 22:45:23 +0200]:
> I am packaging a multiple binary from a single sources. The two
> binaries provides the same server functionality and differs just for
> compilation options, let's say:
>
> "server" and "server-enhanced".
Are they overlapping packages, that is shipping the same files?
> My problem is this: for the two packeges I want to have two
> different man pages (in fact "server-enhanced" has more config
> options that "server") but it would nice if the man pages could have
> the same name ("server.conf.5")
>
> I don't know how to resolve this, because in the /debian dir I can
> put just one file named "server.conf.5"
It sounds like one package should "conflict" with the other. That way
when one is installed it will remove the other.
Bob
msg07110/pgp0.pgp
Description: PGP signature
Re: Handling application private libs
Devin Carraway <[EMAIL PROTECTED]> [2002-09-22 01:35:32 -0700]: > I'm working on a package containing several executables, whose common > functionality lives in a few shared libraries. They're linked in the > usual way at compile time. Policy says they should live in > /usr/lib/packagename/, but I need to make them available for the runtime > linker. Is there a dependency that you continue to provide the shared libraries? If so then they should be in /usr/lib and should be public shared libraries. Private shared libraries really don't make much sense to me. There are specific uses but not typically. If they are truly local to the package then I personally would convert them from being a shared library to being an archive library. Then you remove all of the shared library issues you are facing right now. The changes would all be local in the build environment, i.e. the Makefiles, and you can manage that easily for the build. Your executables would then only need the normal shared libraries of the system and you would be on easy street. Bob msg07247/pgp0.pgp Description: PGP signature
Re: Handling application private libs
Devin Carraway <[EMAIL PROTECTED]> [2002-09-22 01:35:32 -0700]: BTW, I wanted to also say... > I know of three ways to deal with this one -- add a new path to > ld.so.conf (yuck), Blech! Very yucky taste in mouth. ;-) > link with -rpath, or wrap the apps in a script which alters > $LD_LIBRARY_PATH. None of these are thrilling; I gather that rpath > is verboten, but haven't found any mention of it in the policy > manual. Undesireable for many reasons. For example I can't use the same binary for two different installations. > The wrapper script approach seems the least problematic, but since the > libs are in the package and the script would hardcode the path it > doesn't seem inherently any better than -rpath. The wrapper script is the most palatable of the yucky tasting solutions. It allows a postinst script to customize the paths in the wrapper script without needing to recompile the binary. Which allows installation in non-expected locations such as /install_root/usr/ and things like that. It also allows some non-compile solutions such as manual hacking of the script to make problem installations work. You should be thinking about non-traditional installations of your package. If you can avoid those shared libraries it would be best. Libraries should be either shared in /usr/lib or not shared at all. The halfway between place is not a mature methodology at this time and contains many problems. Bob msg07248/pgp0.pgp Description: PGP signature
Re: Handling application private libs
Junichi Uekawa <[EMAIL PROTECTED]> [2002-09-22 20:54:19 +0900]: > What would be the point of restricting the shared libraries to > within the software ? The traditional argument is usually that shared libraries save disk space. If your have a large amount of code that is completely shared between N programs then you have N copies of that code on disk. By using a shared library private to your application you can reduce your disk space consumption needs to only one copy of that shared library code shared between the various executables of your project. But making a public shared library creates a public API which you are now responsible for maintaining _forever_. Anyone else that you do not know about might be depending upon your shared library in their program. This restricts the things you can do. If you are developing and wishing to change even a minor thing such as a parameter type to a function then you will need to make a major revision to your shared library API otherwise you will break those other programs which are using your shared library. Public shared libraries are therefore a public contract that you always have to think about when doing changes to the library. Entering into those contracts should not be made lightly. Keeping them private avoids the contract and you now can develop and change your library as you see fit and as long as your program is internally consistent you are good to go and still save the N copies of disk space. Or so the theory goes. But is your program so large that disk space for your executables is really a concern? Has anyone filed any bugs against your project that you are using an unreasonable amount of disk space? If no bugs have been filed because of that then I would reject the use of shared libs to save disk space. Bob msg07249/pgp0.pgp Description: PGP signature
Re: stripping binaries...must we?
Drew Parsons <[EMAIL PROTECTED]> [2002-10-14 00:41:49 +1000]: > OK, I'll try to remember to restrip for sarge :) Perhaps the BTS could be a help in remembering this? Bob msg07487/pgp0.pgp Description: PGP signature
Re: dpkg-buildpackage problem
Jay Graves <[EMAIL PROTECTED]> [2002-10-10 16:39:18 -0600]:
> > debian/rules should have something like this:
> > make install DESTDIR=$(CURDIR)/debian/tmp
>
> well my debian rules looks like this
> ./configure (lots of stuff here) --datadir=/etc/X11
This implies that the application is using data itself in order to
find configuration files. This will push down into the generated
'Makefile's. If you look at the top of one of those you will see the
section where prefix and other variables are set. Looking there will
probably explain what is happening better than I can here.
> ./configure (lots of stuff here) --datadir=/etc/X11
That probably says things like this for "(lots of stuff here)"
--infodir=\$${prefix}/share/info
By using prefix in this way when prefix is overridden at install time
everything is handled. But by using a hard /etc path without an
override then you are also must handle that in the install target
later. In a nutshell, you did one but not the other.
> and the install block has this line
> $(MAKE) install prefix=$(CURDIR)/deban/packageName/usr
I hope it spelled 'debian' right in the real thing.
> everything installs into debian/packageName fine if I don't specify
> the --datadir in the configure, but once I do it tries to install files
> to /etc/X11
Because you set datadir in your configure then you need to override it
in your make install target. Probably something like this.
$(MAKE) install prefix=$(CURDIR)/debian/packageName/usr
datadir=$(CURDIR)/debian/packageName/etc/X11
Where packageName, your convention, is the name of your package. Or
'tmp' in some cases.
HTH
Bob
msg07566/pgp0.pgp
Description: PGP signature
Re: Advice about cfengine2 package
Andrew Stribblehill <[EMAIL PROTECTED]> [2002-11-08 15:49:27 +]: > I can see a number of ways out of it, but have no clear idea which is > best: > > * Split the package into its component parts, such that each daemon > is in a separate package. Have an init script for each. The admin > chooses which daemons run by adding and removing packages. This seems simple for the end user of the system. It seems hard to think of ways to complicate it. Note that a previous thread had a discussion of this of daemon start up scripts. You might want to browse the thread, I suggest starting here. Although you are probably already well versed there. http://lists.debian.org/debian-devel/2002/debian-devel-200209/msg01791.html > * Put a debconf message into the package warning that the behaviour > has changed. Write one init script. Allow the user to configure > which daemons start at boot-time by editing /etc/default/cfengine2 > which contains RUN_CFEXECD=0; RUN_CFENVD=1; ... May I voice an opinion against a gratuitous message saying that the behavior has changed but without real useful value? Those darn "click-throughs" are a large part of the complaints against debian packages during an install. May I suggest that if at all possible avoid needing user input during the installation. Especially for a program such as cfengine which gains usefulness on larger sites with many hosts. Trying to install something with a "press enter to continue" on a thousand hosts such as a large cfengine user might need to do would be extremely tedious. If at all possible please allow the package to be installed non-interactively. > * As above, but manage /etc/default/cfengine2 by debconf. If I do > this, must this file not be a conffile? As a system user when I have had to tinker with files in /etc/default I have always hated not having a backup of the file. If I break it how can I restore it to a package default? apt-get --purge remove and then install? Yuck! Even apt-get --reinstall install is not the most pleasant way to deal with this since then AIDE/Tripwire alarms will be triggered for the non-configuration files changed. May I suggest keeping a clean copy of any file that the user might modify in /usr/share/doc beside the package documentation? That way I can always diff between my local customizations and the package version and it gives me an easy way to see what I have changed. > * Write three init scripts and keep them in the same single package. > Has this got a precedent? This seems functionally to be no different than your suggestion to have one init script which decides which of the three to start. But it suffers from being more complicated. Just my two cents... Bob msg07786/pgp0.pgp Description: PGP signature
Re: new system uid/gid
Chad Miller wrote: > On Sun, Jan 26, 2003 at 09:12:21AM +0100, Szilveszter Farkas wrote: > > i would like to create a package which needs a system user and a group > > to be added. which uid/gid shall i use? leave it over 1000 (default), > > or should i set it under 1000? > > There's policy already set up for this, and "adduser --system" does the > right thing. You nnedn't worry about choosing a UID. See the Policy manual section 10.2.1 for the details. As noted you should be using the 'adduser' command to dynamically create uids when created within your package. http://www.debian.org/doc/debian-policy/ch-opersys.html#s10.2 Bob msg08378/pgp0.pgp Description: PGP signature
virtual-package-depends-without-real-package-depends rsh-client
I am unable to determine why I am getting this message from lintian. Help? My control file seems normal to me with this header. I am attempting to build a meta package that contains nothing but depends so that I can pull in various packages easily by installing my metapackage. I have reduced the problem to this small example which illustrates the problem I am having. Package: myserverbundle Architecture: all Section: admin Priority: optional Depends: rsh-client Description: My server package bundle Running lintian on the resulting .deb results in the following output. I know this is coming from the fields module of lintian. But I got lost in the perl. W: myserverbundle: virtual-package-depends-without-real-package-depends rsh-client Why does it think rsh-client is a virtual package? This happens even with the sid version 1.22.6 lintian. Other dependencies that I have listed do not trigger this behavior. But either rsh-client or rsh-server do and so this seems somehow specific to those packages. Thanks Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: virtual-package-depends-without-real-package-depends rsh-client
Matt Zimmerman wrote: > > Why does it think rsh-client is a virtual package? > > It is a mixed virtual package. There is a real package rsh-client, but also > several other packages provide rsh-client (apt-cache showpkg rsh-client). Aha! Interesting. Since I *knew* that rsh-client was a real package I never even considered that other packages would provide it as a virtual package. I never even looked. > This may be a false positive, since you should not need an alternative for > mixed virtual packages. Policy Manual section "2.3.5 Virtual packages" says nothing about mixed virtual packages. Googling around I find reference to the Debian Packaging Manual http://www.debian.org/doc/devel-manuals#devref which is no longer available as such. Is there any place in particular I could learn more about the details of mixed virtual packages? Having both real and virtual packages seems to create a dilemma for the tools. How common is this? How accepted are mixed virtual packages? They appear to be an alternative with an infinitely high priority. In this case I want the "real" rsh-client package and not one of the virtuals such as ssh. I also have ssh installed. Therefore I do not want to list this as "ssh | rsh-client" because that would not be the right thing. Therefore I will declare this to be a false positive since there is a real package rsh-client it should not create a warning. Thanks! Bob msg08565/pgp0.pgp Description: PGP signature
Re: virtual-package-depends-without-real-package-depends rsh-client
Colin Watson wrote: > It's a false positive, yes. Please file it as a bug against lintian > (also compare #179614). Bug 179614! It appears to me that this is a similar but not quite identical problem. In that bug the packages were all real packages and none of them were virtual. I could not deduce that any of them were virtual. So I will file this as a seperate bug and reference the above as additional information. But since I have been hassling over this for a few weeks it gives me a convenient excuse for not having seen that report. It was only filed only 9 days ago and was not there when I started seeing this problem initially. (Actually, yes, I did search first! :-) Matt Zimmerman wrote: Thanks for your information as well. It was very helpful. > Is it certain that none of the rsh-like alternatives will work here? Why? This is a legacy corporate environment on a private network without Internet access. (Does a socks server count as Internet access? Let's not discuss that!) And there is a lot of legacy. It will take a while to get all of the people educated about SSH. SSH in this environment is one of those "new fangled thangs" and it is not so much that not everything is converted over but more that the few that have converted over to ssh are the exception. The majority of the people and applications are still using rsh. Like backup. Something that if I interfered with I would get run out'a Dodge on a rail. And Debian is the newcomer to the network. Mostly it has been commercial vendor systems. Politically I need Debian to play nicely with the other less capable children. > If you are absolutely certain that ssh (for example) will not work at all, > then you can guarantee that you will get the real package by specifying a > versioned dependency, though this is not terribly elegant and may break in > the future if versioned Provides are implemented. Use versioned depends to trick lintian not to see this as a virtual package. Interesting! Yes, I tried that and it did silence that warning. Thank you for suggesting that. Since this meta package is for my own internal use only and I can change it on demand as needed I can react to any future change in versioned Provides. Thanks for the help! Bob msg08570/pgp0.pgp Description: PGP signature
Re: virtual-package-depends-without-real-package-depends rsh-client
Aaron Haviland wrote: > Bob Proulx cursed the gypsies with this chant: > > Bug 179614! It appears to me that this is a similar but not quite > > identical problem. In that bug the packages were all real packages > > and none of them were virtual. I could not deduce that any of them > > were virtual. So I will file this as a seperate bug and reference the > > above as additional information. > > It would appear to me that they are the same bug. If you look closely at > the bug, you'll notice that pump Provides: dhcp-client In what version? I looked at pump-0.8.11-5 and it did not provide dhcp-client. There it is! pump-0.8.14-1 in unstable provides pump. The changelog says this: * Provide dhcp-client (closes: #178961). So they are almost certainly the same bug. I will update the report. Thanks Bob msg08578/pgp0.pgp Description: PGP signature
Re: Unofficial package tips
Bastian Kleineidam wrote:
> On Fri, Feb 28, 2003 at 08:19:51PM +0100, Henning Moll wrote:
> > In addition i have some questions to the Depends section in
> > debian/control: ${shlibs:Depends} is a nice feature, but i think
> > for many packages/libraries it is way to strict, because it's
> > always using the versions of installed packages which may not be
> > necessary. So what's the best/common way to handle this?
>
> The library version number is there for some reason: binary compatibility.
> If you drop the version number from library depends, your package may
> break when a new library is there.
I think you meant when an old library is there, not an new one. Since
libraries are not meant to be forward compatible moving code compiled
with a newer library to an older one might not work. The older one
did not know about the newer one. They are designed to be backward
compatible in that moving to a newer library should work. The newer
one knows about the older one. Assuming that is what you meant or
please correct me.
Bob
pgp0.pgp
Description: PGP signature
Re: Really strange : my package doesn't compile from source.
Neil L. Roeth wrote: > Examining the buildd logs showed it tried to run automake to build > [...] > But, *why* did this happen? I had created Makefile.in in the source > tree after aclocal.m4, so it was a *newer* file there and did not > trigger a call to automake on my build machine. You asked the question. But then you supplied this answer. > Perhaps the problem is that both aclocal.m4 and Makefile.in are > unpacked from the source package in the order that they appear in > the .diff.gz file; Makefile.in is in the .diff.gz first, followed by > aclocal.m4. So the time ordering was reversed after the files were > created by patching .orig.tar.gz with .diff.gz, and automake got > invoked needlessly. That's my theory, feel free to point out any > stunningly obvious facts that I overlooked which make it invalid :-) Why do you think that you have not answered your own question? :-) I don't really know 100% but I am convinced within the limits of available data. I have created similar problems for myself because of the patch files. > What this does not explain is why it did not FTBFS on all > architectures. A guess. More likely is that perhaps those other architectures patch the files so fast that the resulting timestamp is all within the same second. Which make will accept as up to date. A race condition. If you try the same build enough times all would fail and pass at different times. It all depends on if it can complete within the same second or not if it crosses seconds. > I searched through one or two other logs of successful builds and > did not see any calls to automake, so somehow the dependency did not > trigger. Also, a build with pbuilder on my machine, i.e., a clean > environment, had no problem. If it is a race condition, all sources local to your machine, and you have a fast machine, then the odds are good the timestamp will be in the same second. It may be hard to generate a case which crosses the second boundary. I noticed that the machines that failed your build in the buildd logs were slower machines. If you were to build your own repository, 'apt-get source -b package' would you get the same problem? I always test that no since I added a configure script to a package which did not have one and the configure mode in my development directory was a+x but when created by patch it is not executable. I would never have caught that in my development area but only by fresh source build. > Unless you or someone else can tell me what is going on, and a better way to > fix it, I am inclined to go ahead and include automake in the build > dependencies. Put me in the camp that does not like AM_MAINTAINER_MODE. I would make the timestamps work correctly in the debian/rules file. That limits the ramifications. There are none outside of the debian build. My rules files have build: depend upon build-stamp: depend upon configure-stamp: and there I would touch the generated files in the right order. Or force them to be the same as a reference file timestamp. touch aclocal.m4 Makefile.in configure, I think. Since the patch process is changing the timestamps from what are in your sources it is necessary to force the timestamps back into the order they are in on the system when the patch was created. The actual values are not important but only the order. You may want to read some discussion on the subject of automake and timestamps here. http://mail.gnu.org/archive/html/automake/2003-02/msg00036.html Bob pgp0.pgp Description: PGP signature
Closing bugs in unreleased packages?
The released version of Debian is 'stable. Why are bug reports closed
against 'sid'? Shouldn't bug reports be closed only in released
versions of Debian? What am I missing? Requesting education.
http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-bug-handling
5.8.4 When bugs are closed by new uploads
... you should not close the bug until the package which fixes the
bug has been accepted into the Debian archive. Therefore, once
you get notification that your updated package has been installed
into the archive, you can and should close the bug in the BTS.
...alternately... list the fixed bugs in your debian/changelog
file ...
I am assuming here that "accepted into the Debian archive" refers to
'sid' in this case. Therefore all bugs are closed when the package is
in 'sid' even though this fix may never reach 'stable'. A user of the
released Debian may never see the fix.
Here is the documented user interface:
http://www.debian.org/Bugs/
Viewing bug reports on the WWW
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data={ex}&archive=no
[Where {ex} in the URL is any example package name, changed not to
pick on any one particular package.]
If you find a bug not listed here, please report it.
This documentation leads one to believe that if they see a bug in
'stable' that they should report it, no?
A package maintainer who is following the rules, will fix the bug,
update the package in sid, close the bug. The bug, now closed will
disappear from the BTS (being moved to the archive of closed bugs,
requiring archive=yes to view). Users using released Debian 'stable'
observing the bug who are following the rules will not see the closed
report, will report the bug again. The maintainer will see the
duplicate bug report and close it. Repeat. Repeat. Repeat. The
time period during which this may continue could be the two years it
took to release 'woody'.
The maintainer is frustrated by seeing the same bug reports for things
they have fixed and are in the pipeline to stable but not there yet.
Again and again. The user is frustrated because they are not seeing
any of those bug reports. They are going through effort to create a
good bug report, only to be told it is a duplicate. Then they are
told to go away, and in some cases griped at for filing a duplicate
bug.
Shouldn't bugs be "not-closed" until the package moves into 'stable'?
(I did not say "open". After a fix perhaps "fixed", or "resolved" to
show that it has been addressed in a package that has not yet made it
to 'stable'?)
Please educate me. What should a user be doing? What should a
maintainer be doing? What am I missing?
Thanks
Bob
pgp0.pgp
Description: PGP signature
Re: tagging bugs "woody"?
Andreas Metzler wrote: > Frank Kuster wrote: > >users working with Debian woody often do not look at archived bugs when > >reporting bugs on a package. Therefore it is likely that bugs that have > >long been fixed in unstable, but will never be in woody will be reported > >multiple times again. I have been a victim of this problem myself. > Imvvvho this a matter of personal taste, and the manual (the part I > snipped) can be taken as guideline instead of as bible. Personaly I'd > keep only these bugs open which _really_ get reported at least twice, > otherwise the BTS is to messy for me to work with. I believe there are many people that look for bugs, won't find them, but won't report them either. Even if people do not report a bug it benefits from from being able to see the bug in the BTS. In this way the BTS acts as a knowledge database. Therefore I would like to see bugs in stable kept open until the next stable fixes them. I realize there are technical issues to be resolved in the BTS in this area. Bob pgp0.pgp Description: PGP signature
Re: newbie packaging question
Eric Winger wrote: > would it be sacreligious to ask why sources are kept in non-free? You are asking an obvious question and the answer is the obvious one. The sources are in non-free because they are not free. Look at the copyrights of any of the packages in non-free and you will see that they all have some type of restriction. Bob pgp0.pgp Description: PGP signature
Re: gcc versions and c++ packages
David Meggy wrote: > Searching the mailing lists, oddly shows up nothing. I think the debian > mailing list search page needs some fixing. I think this was in debian-devel. Since I had the page up in my browser when I read your message here it is. http://people.debian.org/~rmurray/c++transition.html I tried the Debian search engine http://lists.debian.org/search.html but it returned no hits. So I might have to agree with your statement. But I usually use google.com for my searching. You can restrict the matches to just the site you are looking for. This works for more than just the debian lists and is a generally useful thing to know about the search engine. Using this search string finds the plan as the first match. site:debian.org gcc transition plan Personally I will be happy two years from now when we have the transition completely behind us instead of mostly in front of us. HTH, Bob pgp0.pgp Description: PGP signature
Re: backing up/replacing files from another package
Eric Winger wrote: > Can't I even "Depend" on a package and then fine tune its configuration > though? I don't think you can depend upon a package and tweak its conffiles. It would be interesting to be able to do that and it certainly makes sense from an object oriented inherit and modify viewpoint. Frank suggested building your own package which completely replaced the original package and naming it autofs-$erico or something similar and if you are up for it that would work very well. I do that in a couple of places, but not for autofs. Some packages can be renamed and tweaked with little effort. Others require more effort. But I realize that recompiling the package can make you nervous for critical and obtuse applications like NFS. I have the same problem as you and have solved it but unfortunately my solution is probably a little heavy for your needs. I install system configuration scripts which I call a 'sysconf' package. These scripts run both at system boot time and by cron. The first thing they do is rsync a new copy of themselves from our "gold" servers ensuring that they are the latest available. Then they run to configure all of the little bits of the system like /etc/auto.master which locally we need configured in a particular way. As packages are normally upgraded through the life of a system I train people to always say 'Y' to the replace a conffile question. Sure this may leave the system in a generic and locally unworkable state. But the file is updated to follow the package to the latest version. After any particular update that a question like that is asked I train people to always run our 'sysconf' script which configures all of the little bits of the system, including conffiles, which need to be tweaked up. This leaves the system in a locally configured good state and we are done. The sysconf scripts must be smart enough to handle reconfiguring these files and the *running* system in place. Because it runs by cron this will fix any host that gets accidentally left in a partially configured state. Or one that the user left in a broken state. By running at boot time it means that a host that is powered off for a long time will be brought up to the latest local configuration when it is powered back on. Bob pgp0.pgp Description: PGP signature
Re: fvwm-themes gets better
Andrei Mitrofanow wrote: > nobody interestet to fvwm-themes? > http://smilebef.homelinux.org/~smilebef/ [Reading my note before sending it I see it sounds harsh. I don't mean it that way. I mean it constructively so that you will know why I personally have not tried any of your packages. Please take this constructively.] I use FVWM. I am interested in themes. But I don't read German and could not make any headway on your web page. So I am left out. Which is fine. But I am also less likely to try your packages if I don't have clues as to what is in them. Of the three screenshots present on your web page, two have almost identical purple-grey themes and seem identical to me. The other one has the same theme but with a different color. Taken together it does not look like very much. Therefore it is not interesting enough to sell me enough to download a set of unknown deb files and try to inspect them carefully because they are not from a previously trusted source and to test them on my machine. Those themes look too bland to be interesting, sorry. Compare this to: http://fvwm-themes.sourceforge.net/screenshots/ There are many more interesting themes there. It would be interesting to have someone package those for Debian. Perhaps that is even what you are trying to do. But again, I can't tell that. Bob pgp0.pgp Description: PGP signature
Re: backing up/replacing files from another package
Matthias Urlichs wrote: > > As packages are normally upgraded through the life of a system I train > > people to always say 'Y' to the replace a conffile question. Sure > > this may leave the system in a generic and locally unworkable state. > > So why not "N"? That may leave the package, at worst, in a "I can't find > a necessary setting and am going to crash" state, but the following call > to your sysconf program will wake it up right away. Most of the time that would be completely true. Especially for tiny files like /etc/auto.master. But for other files with more documentation in them I prefer to get the new file with the new comments in them. Thinking of files for apache, postfix, bind, and other packages with complex conffiles. But you are right that if my script is written well it would work either way. If my script is not well enough written then I might have a bug. :-) > On the other hand, "Y" will replace that file with a generic version. At > best the package does nothing, but at worst it'll have inconsistent > configuration and do some random things which aren't expected. The package should not do anything unexpected. It should work as if you had just installed the package on a new machine and had not yet done any configuration to it. Debian packages should "just work" out of the box. If a package needs some configuration then it should behave reasonably until further configured. Since my system configuration scripts will be launched and run after the update things will be configured again in just a moment. Mail is the only package which I think has any time where it won't work right on my site with the default configuration. But it should be back working again right away after our scripts run. Other things may be confused for a while but for the time we are talking about it is not significant. Basically I can't give good arguments strongly for either Y or N once we have a script in place to automatically set the package configuration for our site. You have asked a good question and I could see people debating it either way. I just prefer to have the latest commentary in the files. That way new machines and old machines both look very similar. Then by looking at the conffiles you won't be able to tell that it was a potato machine updated to woody updated to sarge. It will just look like a sarge machine. When I write a script to configure a package I normally have two choices. 1) I can replace the entire file with my own configured copy of the file. 2) I can read-modify-write the file to only change what I need to change. This preserves other changes that may have been made in the file. For the /etc/auto.master case I just replace the file whole. For the case of /etc/postfix/main.cf I only modify things like the transport map, which we use on our site, and leave other things alone since there are many options that could be host locally configured there. Getting back on topic for d-m let me suggest that package authors try to set up files such that they can be mechanically updated whenever possible without the need to read-modify-write. Directories of configuration files are great because then a single file can be copied into place and everything else left untouched around it. And this can be undone with a simple removal of that file. Of course /etc/cron.d/* is a classic example of directories of files. And /etc/apt/apt.conf.d/* is another. I can place a file with our web proxy configuration there easily. And /etc/spamassassin/*.cf also allows easy, automated configuration. But ssh is the opposite case. It has only a single file /etc/ssh/sshd_config and so that is a read-modify-write case. Most of these issues are forced upon the maintainer by the upstream architecture. But sometimes you can make it work. The latest bind9 I see uses 'include /etc/bind/named.conf.local' which simplifies the local configuration section. The main file I can leave unchanged and just completely replace the local section. This is a nice way to organize the files. Bob pgp0.pgp Description: PGP signature
--force-confdef? When is it different?
I am setting up a scripted update for a pool of machines and trying to understand the ramifications. In the dpkg man page: confnew: If a conffile has been modified always install the new version without prompting, unless the --force-confdef is also specified, in which case the default action is preferred. confold: If a conffile has been modified always keep the old version without prompting, unless the --force-confdef is also specified, in which case the default action is preferred. confdef: If a conffile has been modified always choose the default action. If there is no default action it will stop to ask the user unless --force- confnew or --force-confold is also been given, in which case it will use that to decide the final action. When would confdef ever not be the same as confold? How is the default action determined? I thought the default action was always simply 'N'. No? I am thinking that --force-confmiss --force-confold are the appropriate options for my case. But if there is a time when the default is determined to be different then should I specify --force-confdef as well? Thanks Bob pgp0.pgp Description: PGP signature
Re: Problem with dependency declaration
Andreas Metzler wrote: > Frank Küster wrote: > > in a package that I maintain (sponsored by a DD), I use a call to > > stat. In sarge, /usr/bin/stat is in coreutils - of course I don't need a > > dependency on that. However, in woody stat was in a separate > > package. Usually packages keep really old versioned dependencies - this > > might be important for upgrades, and it's friendly for backporters. I just ran into almost the same case with a local meta package that I maintain. So this has suddenly become pertinent for me as well. > > If coreutils wouldn't be of priority required, I would just add > > "coreutils | stat" to the dependencies. What should I do in this case? > > Stat was in coreutils from the first time it appeared in Debian, so a > > versioned Depends: wouldn't make any sense (except that it makes lintian > > and linda be quiet...) > > I don't have a sid system at hand, but doesn't coreutils > Provides/Replaces stat? Is there any reason that stat was removed from sarge? Since coreutils has subsumed 'stat' shouldn't 'coreutils' create an empty package 'stat' for the transition? This would be the same as with shellutils, fileutils, textutils. It can then be removed at the next release along with those other three. How I 'stat' different than the other three? As an alternative could a standalone stat package could be created which depends upon coreutils and conflicts with older stat packages? Bob pgp0.pgp Description: PGP signature
Re: Special requirements for scripts in /etc/rcS.d?
Frank Küster wrote:
> stat is called to get uid and exact permissions of a temporary
> configuration file which has just been created.
Perl is standard on systems. I hesitate to put more use of it in init
scripts but... Perhaps this would be of use instead of stat just to
work around this problem?
perl -e 'printf("%d\n",(stat($ARGV[0]))[4]);' /tmp # print uid in decimal
0
perl -e 'printf("%o\n",(stat($ARGV[0]))[2]);' /tmp # print mode in octal
41777
My only question now is where did that '4' come from in the mode? But
the last four digits always seem to be correct.
Bob
pgp0.pgp
Description: PGP signature
Re: Special requirements for scripts in /etc/rcS.d?
Christoph Berg wrote:
> Re: Bob Proulx in <[EMAIL PROTECTED]>
> > perl -e 'printf("%o\n",(stat($ARGV[0]))[2]);' /tmp # print mode in octal
> > 41777
> >
> > My only question now is where did that '4' come from in the mode? But
> > the last four digits always seem to be correct.
>
> stat(2):
>S_IFDIR004 directory
Aha! (smacking forehead) I should have known that. Thanks for
pointing me to it.
Also the second aha! of the day was when Eric Schwartz kindly pointed
out to me that if stat was not available because /usr was not mounted
then using perl would not help the situation. I was still fixated
upon the 'coreutils | stat' issue of the previous thread. :-)
Bob
pgp0.pgp
Description: PGP signature
Re: Need a mentor with a !x86 machine
John Lightsey wrote: > I'm trying to adopt xmms-goom which has a release critical bug related to > !x86 architectures. I believe the version I've packaged fixes the problem, > but I don't have access to a !x86 machine running unstable to test it on. If > someone could download, build, and test this package I'd be very gratefull. > > http://www.nixnuts.net/xmms-goom.tar.gz > > All of the necessary files are included. If it gives you any errors during > the build process please send me a copy of the build log. One thing I see in the upstream source which will likely cause trouble is the following. File ./src/Makefile.am: CFLAGS = -O9 -g -DDATADIR=\"@[EMAIL PROTECTED]" @XMMS_CFLAGS@ `sdl-config --cflags` And then later on in the file: zoom_filter_mmx.lo:zoom_filter_mmx.c gcc -O9 -c -funroll-all-loops -fno-schedule-insns zoom_filter_mmx.c -o z oom_filter_mmx.lo -DHAVE_MMX Those hard coded CFLAGS can't be disabled at configure time. On any architecture with optimizer sensitivities such as is often the case on less mature ports this can cause trouble. As help to convince upstream this is bad, refer them to the automake documentation. Variables reserved for the user === Some `Makefile' variables are reserved by the GNU Coding Standards for the use of the "user" - the person building the package. For instance, `CFLAGS' is one such variable. Sometimes package developers are tempted to set user variables such as `CFLAGS' because it appears to make their job easier - they don't have to introduce a second variable into every target. However, the package itself should never set a user variable, particularly not to include switches which are required for proper compilation of the package. Since these variables are documented as being for the package builder, that person rightfully expects to be able to override any of these variables at build time. To get around this problem, automake introduces an automake-specific shadow variable for each user flag variable. (Shadow variables are not introduced for variables like `CC', where they would make no sense.) The shadow variable is named by prepending `AM_' to the user variable's name. For instance, the shadow variable for `YFLAGS' is `AM_YFLAGS'. Which would just cause them to want to put AM_CFLAGS = -O9 in their Makefile.am which is just as bad. Instead they should not set it at all. Comments from the list as to how to handle this problem? Bob pgp0.pgp Description: PGP signature
Re: Need a mentor with a !x86 machine
John Lightsey wrote: > If anyone with a non-x86 machine would like to take a look again and give > feedback on wheter or not it compiles properly, I'd really appreciate it. > The build logs that I recieved were very helpfull. I grabbed that and gave it another run. There are still -O9 references in the Makefile.in. The Makefile.am was cleaned up and so if the Makefile.in was regenerated or patched then that problem would be resolved. Those caused gcc to SIGSEGV during the compile. I am running a slightly old gcc-3.3 at the moment and that might be fixed already. But I believe you need to either regenerate the Makefile or force a distclean at the start. Removing those -O9's from the Makefile and without that everything compiled. There were however a number of pointer / integer which need to be looked at. I will send the trace to you directly. Bob pgp0.pgp Description: PGP signature
pbuilder ${shlibs:Depends} yields libc6-2.2.4-4 ???
I just recently started using pbuilder. Previously I have been
maintaining my own chroots as required. I can see why people
recommend pbuilder. It is very nice! But things do not seem to be
operating as I believe they should and I have been unable to figure
this out. Let me set the stage.
sudo apt-get install pbuilder
echo 'MIRRORSITE=' > ~/.pbuilderrc # MIRRORSITE= my apt-proxy cache
sudo pbuilder create
cd # some package directory which uses ${shlibs:Depends} in control
grep ^Depends: debian/control
Depends: ${shlibs:Depends}
pdebuild
dpkg-deb --info /var/cache/pbuilder/result/*.deb |grep Depends:
Depends: libc6 (>= 2.2.4-4)
So then in an attempt to resolve this I add DISTRIBUTION=woody to my
$HOME/.pbuilderrc file but I receive the same result. Why doesn't the
depends show up as 2.2.5-11.5? So I login to the chroot area to check.
sudo pbuilder login
dpkg --status libc6 |grep ^Version:
Version: 2.2.5-11.5
Really and truly 2.2.5 is installed in the changeroot. But 2.2.4 is
getting listed as the Depends: for the package getting built. I
manually built a package in the pbuilder chroot with the same result.
So the problem would seem to me to be in dpkg-shlibdeps in the chroot.
No debian/shlibs.local exists. The /etc/dpkg/shlibs.default only
contains comments.
My system is mainly woody but does have a variety of backports.
Thinking this might be something related to the version of pbuilder or
debootstrap I updated to the latest pbuilder from unstable (version
0.96) which required a newer debootstrap which I pulled (version
0.2.9.backports.org.1) but with the same result. And that is when I
decided that someone must have debugged this already and that I would
ask for help.
Why does building a package with pbuilder generate the seemingly wrong
version for Depends: of 2.2.4-4 regarldless that 2.2.5-11.5 is the
installed library? What am I doing wrong?
Thanks
Bob
pgp0.pgp
Description: PGP signature
Re: pbuilder ${shlibs:Depends} yields libc6-2.2.4-4 ???
Rene Engelhard wrote: > Bob Proulx wrote: > > Why does building a package with pbuilder generate the seemingly wrong > > version for Depends: of 2.2.4-4 regarldless that 2.2.5-11.5 is the > > installed library? What am I doing wrong? > > Nothing. > > [EMAIL PROTECTED]:~$ sudo chroot chroots/stable cat /var/lib/dpkg/info/libc6.shlibs > libc 6 libc6 (>= 2.2.4-4) Thanks for taking the time to answer. I am not unappreciative but unfortunately I did not find this very informative to me. Even that reference to the libc6.shlibs file, while correct, was obtuse to me. So before the mailling list archive gets split into the new month I decided I would get another in with an update with an expansion of this topic. Digging through the dpkg-shlibdeps perl script and I can see where it is reading the file you referenced. Therefore it appears that shared library packages can specify an ABI version separate from their installed package version. The glibc package specifies 2.2.4-4 as the ABI so that even though version 2.2.5-11.5 is installed. The installed value is overridden with the libc6 package specified version from the shlibs file. Digging into the glibc package I see that they manually set the ABI version to 2.2.4-4 in the debian/rules.d/shlibs.mk file. Now knowing a little more about what to look for I was able to locate documentation on the process. Here is the pointer. http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps Thanks again, Bob pgp0.pgp Description: PGP signature
Re: Should I always clean in debian/rules before making binary?
Frank Küster wrote: > Colin Watson <[EMAIL PROTECTED]> schrieb: > > It's easier to use DESTDIR=$(CURDIR)/debian/tmp if DESTDIR support is > > available; that way you get less confused by /etc. > [..] > Hm, how do I know (other by trial and error) whether a package supports > this? autoconf'iscated ones do not use it generally, do they? Older automake generated Makefiles do not support DESTDIR. But newer automake generated Makefiles do support it. I don't know at what version that support was enabled. But if the tool uses a new automake to generate the files or if you happen to regenerate them then you should have DESTDIR support. There appear to be three cases. 1. The developer wrote the Makefiles by hand and did not supply any support for DESTDIR natively. 2. The developer used automake and therefore supports DESTDIR by default. 3. The developer used automake but also supplied additional Makefile sections by hand and those additional sections do not support DESTDIR. So it is partially there but not fully functional now. That last one happens every so often. I found and reported one in gettext just recently (which was promptly fixed by upstream). But those are the hardest to detect without actually trying. Trial and error is probably the easiest method. Bob pgp0.pgp Description: PGP signature
Re: Multiple Binary and man pages
Marco Presi <[EMAIL PROTECTED]> [2002-09-08 22:45:23 +0200]:
> I am packaging a multiple binary from a single sources. The two
> binaries provides the same server functionality and differs just for
> compilation options, let's say:
>
> "server" and "server-enhanced".
Are they overlapping packages, that is shipping the same files?
> My problem is this: for the two packeges I want to have two
> different man pages (in fact "server-enhanced" has more config
> options that "server") but it would nice if the man pages could have
> the same name ("server.conf.5")
>
> I don't know how to resolve this, because in the /debian dir I can
> put just one file named "server.conf.5"
It sounds like one package should "conflict" with the other. That way
when one is installed it will remove the other.
Bob
pgp5LNoyJuMR1.pgp
Description: PGP signature
Re: Handling application private libs
Devin Carraway <[EMAIL PROTECTED]> [2002-09-22 01:35:32 -0700]: > I'm working on a package containing several executables, whose common > functionality lives in a few shared libraries. They're linked in the > usual way at compile time. Policy says they should live in > /usr/lib/packagename/, but I need to make them available for the runtime > linker. Is there a dependency that you continue to provide the shared libraries? If so then they should be in /usr/lib and should be public shared libraries. Private shared libraries really don't make much sense to me. There are specific uses but not typically. If they are truly local to the package then I personally would convert them from being a shared library to being an archive library. Then you remove all of the shared library issues you are facing right now. The changes would all be local in the build environment, i.e. the Makefiles, and you can manage that easily for the build. Your executables would then only need the normal shared libraries of the system and you would be on easy street. Bob pgp3QzUGhoLDc.pgp Description: PGP signature
Re: Handling application private libs
Devin Carraway <[EMAIL PROTECTED]> [2002-09-22 01:35:32 -0700]: BTW, I wanted to also say... > I know of three ways to deal with this one -- add a new path to > ld.so.conf (yuck), Blech! Very yucky taste in mouth. ;-) > link with -rpath, or wrap the apps in a script which alters > $LD_LIBRARY_PATH. None of these are thrilling; I gather that rpath > is verboten, but haven't found any mention of it in the policy > manual. Undesireable for many reasons. For example I can't use the same binary for two different installations. > The wrapper script approach seems the least problematic, but since the > libs are in the package and the script would hardcode the path it > doesn't seem inherently any better than -rpath. The wrapper script is the most palatable of the yucky tasting solutions. It allows a postinst script to customize the paths in the wrapper script without needing to recompile the binary. Which allows installation in non-expected locations such as /install_root/usr/ and things like that. It also allows some non-compile solutions such as manual hacking of the script to make problem installations work. You should be thinking about non-traditional installations of your package. If you can avoid those shared libraries it would be best. Libraries should be either shared in /usr/lib or not shared at all. The halfway between place is not a mature methodology at this time and contains many problems. Bob pgplH6FAYVR3c.pgp Description: PGP signature
Re: Handling application private libs
Junichi Uekawa <[EMAIL PROTECTED]> [2002-09-22 20:54:19 +0900]: > What would be the point of restricting the shared libraries to > within the software ? The traditional argument is usually that shared libraries save disk space. If your have a large amount of code that is completely shared between N programs then you have N copies of that code on disk. By using a shared library private to your application you can reduce your disk space consumption needs to only one copy of that shared library code shared between the various executables of your project. But making a public shared library creates a public API which you are now responsible for maintaining _forever_. Anyone else that you do not know about might be depending upon your shared library in their program. This restricts the things you can do. If you are developing and wishing to change even a minor thing such as a parameter type to a function then you will need to make a major revision to your shared library API otherwise you will break those other programs which are using your shared library. Public shared libraries are therefore a public contract that you always have to think about when doing changes to the library. Entering into those contracts should not be made lightly. Keeping them private avoids the contract and you now can develop and change your library as you see fit and as long as your program is internally consistent you are good to go and still save the N copies of disk space. Or so the theory goes. But is your program so large that disk space for your executables is really a concern? Has anyone filed any bugs against your project that you are using an unreasonable amount of disk space? If no bugs have been filed because of that then I would reject the use of shared libs to save disk space. Bob pgpSMSmNSaBSA.pgp Description: PGP signature
Re: dpkg-buildpackage problem
Jay Graves <[EMAIL PROTECTED]> [2002-10-10 16:39:18 -0600]:
> > debian/rules should have something like this:
> > make install DESTDIR=$(CURDIR)/debian/tmp
>
> well my debian rules looks like this
> ./configure (lots of stuff here) --datadir=/etc/X11
This implies that the application is using data itself in order to
find configuration files. This will push down into the generated
'Makefile's. If you look at the top of one of those you will see the
section where prefix and other variables are set. Looking there will
probably explain what is happening better than I can here.
> ./configure (lots of stuff here) --datadir=/etc/X11
That probably says things like this for "(lots of stuff here)"
--infodir=\$${prefix}/share/info
By using prefix in this way when prefix is overridden at install time
everything is handled. But by using a hard /etc path without an
override then you are also must handle that in the install target
later. In a nutshell, you did one but not the other.
> and the install block has this line
> $(MAKE) install prefix=$(CURDIR)/deban/packageName/usr
I hope it spelled 'debian' right in the real thing.
> everything installs into debian/packageName fine if I don't specify
> the --datadir in the configure, but once I do it tries to install files
> to /etc/X11
Because you set datadir in your configure then you need to override it
in your make install target. Probably something like this.
$(MAKE) install prefix=$(CURDIR)/debian/packageName/usr
datadir=$(CURDIR)/debian/packageName/etc/X11
Where packageName, your convention, is the name of your package. Or
'tmp' in some cases.
HTH
Bob
pgp8gJsYnqNfY.pgp
Description: PGP signature
Re: stripping binaries...must we?
Drew Parsons <[EMAIL PROTECTED]> [2002-10-14 00:41:49 +1000]: > OK, I'll try to remember to restrip for sarge :) Perhaps the BTS could be a help in remembering this? Bob pgpoGeZUVTmOR.pgp Description: PGP signature
Re: Advice about cfengine2 package
Andrew Stribblehill <[EMAIL PROTECTED]> [2002-11-08 15:49:27 +]: > I can see a number of ways out of it, but have no clear idea which is > best: > > * Split the package into its component parts, such that each daemon > is in a separate package. Have an init script for each. The admin > chooses which daemons run by adding and removing packages. This seems simple for the end user of the system. It seems hard to think of ways to complicate it. Note that a previous thread had a discussion of this of daemon start up scripts. You might want to browse the thread, I suggest starting here. Although you are probably already well versed there. http://lists.debian.org/debian-devel/2002/debian-devel-200209/msg01791.html > * Put a debconf message into the package warning that the behaviour > has changed. Write one init script. Allow the user to configure > which daemons start at boot-time by editing /etc/default/cfengine2 > which contains RUN_CFEXECD=0; RUN_CFENVD=1; ... May I voice an opinion against a gratuitous message saying that the behavior has changed but without real useful value? Those darn "click-throughs" are a large part of the complaints against debian packages during an install. May I suggest that if at all possible avoid needing user input during the installation. Especially for a program such as cfengine which gains usefulness on larger sites with many hosts. Trying to install something with a "press enter to continue" on a thousand hosts such as a large cfengine user might need to do would be extremely tedious. If at all possible please allow the package to be installed non-interactively. > * As above, but manage /etc/default/cfengine2 by debconf. If I do > this, must this file not be a conffile? As a system user when I have had to tinker with files in /etc/default I have always hated not having a backup of the file. If I break it how can I restore it to a package default? apt-get --purge remove and then install? Yuck! Even apt-get --reinstall install is not the most pleasant way to deal with this since then AIDE/Tripwire alarms will be triggered for the non-configuration files changed. May I suggest keeping a clean copy of any file that the user might modify in /usr/share/doc beside the package documentation? That way I can always diff between my local customizations and the package version and it gives me an easy way to see what I have changed. > * Write three init scripts and keep them in the same single package. > Has this got a precedent? This seems functionally to be no different than your suggestion to have one init script which decides which of the three to start. But it suffers from being more complicated. Just my two cents... Bob pgp9wS3mDcxFu.pgp Description: PGP signature
Re: new system uid/gid
Chad Miller wrote: > On Sun, Jan 26, 2003 at 09:12:21AM +0100, Szilveszter Farkas wrote: > > i would like to create a package which needs a system user and a group > > to be added. which uid/gid shall i use? leave it over 1000 (default), > > or should i set it under 1000? > > There's policy already set up for this, and "adduser --system" does the > right thing. You nnedn't worry about choosing a UID. See the Policy manual section 10.2.1 for the details. As noted you should be using the 'adduser' command to dynamically create uids when created within your package. http://www.debian.org/doc/debian-policy/ch-opersys.html#s10.2 Bob pgpCHadaV3m6h.pgp Description: PGP signature
virtual-package-depends-without-real-package-depends rsh-client
I am unable to determine why I am getting this message from lintian. Help? My control file seems normal to me with this header. I am attempting to build a meta package that contains nothing but depends so that I can pull in various packages easily by installing my metapackage. I have reduced the problem to this small example which illustrates the problem I am having. Package: myserverbundle Architecture: all Section: admin Priority: optional Depends: rsh-client Description: My server package bundle Running lintian on the resulting .deb results in the following output. I know this is coming from the fields module of lintian. But I got lost in the perl. W: myserverbundle: virtual-package-depends-without-real-package-depends rsh-client Why does it think rsh-client is a virtual package? This happens even with the sid version 1.22.6 lintian. Other dependencies that I have listed do not trigger this behavior. But either rsh-client or rsh-server do and so this seems somehow specific to those packages. Thanks Bob
Re: virtual-package-depends-without-real-package-depends rsh-client
Matt Zimmerman wrote: > > Why does it think rsh-client is a virtual package? > > It is a mixed virtual package. There is a real package rsh-client, but also > several other packages provide rsh-client (apt-cache showpkg rsh-client). Aha! Interesting. Since I *knew* that rsh-client was a real package I never even considered that other packages would provide it as a virtual package. I never even looked. > This may be a false positive, since you should not need an alternative for > mixed virtual packages. Policy Manual section "2.3.5 Virtual packages" says nothing about mixed virtual packages. Googling around I find reference to the Debian Packaging Manual http://www.debian.org/doc/devel-manuals#devref which is no longer available as such. Is there any place in particular I could learn more about the details of mixed virtual packages? Having both real and virtual packages seems to create a dilemma for the tools. How common is this? How accepted are mixed virtual packages? They appear to be an alternative with an infinitely high priority. In this case I want the "real" rsh-client package and not one of the virtuals such as ssh. I also have ssh installed. Therefore I do not want to list this as "ssh | rsh-client" because that would not be the right thing. Therefore I will declare this to be a false positive since there is a real package rsh-client it should not create a warning. Thanks! Bob pgp5aX1gYq5n1.pgp Description: PGP signature
Re: virtual-package-depends-without-real-package-depends rsh-client
Colin Watson wrote: > It's a false positive, yes. Please file it as a bug against lintian > (also compare #179614). Bug 179614! It appears to me that this is a similar but not quite identical problem. In that bug the packages were all real packages and none of them were virtual. I could not deduce that any of them were virtual. So I will file this as a seperate bug and reference the above as additional information. But since I have been hassling over this for a few weeks it gives me a convenient excuse for not having seen that report. It was only filed only 9 days ago and was not there when I started seeing this problem initially. (Actually, yes, I did search first! :-) Matt Zimmerman wrote: Thanks for your information as well. It was very helpful. > Is it certain that none of the rsh-like alternatives will work here? Why? This is a legacy corporate environment on a private network without Internet access. (Does a socks server count as Internet access? Let's not discuss that!) And there is a lot of legacy. It will take a while to get all of the people educated about SSH. SSH in this environment is one of those "new fangled thangs" and it is not so much that not everything is converted over but more that the few that have converted over to ssh are the exception. The majority of the people and applications are still using rsh. Like backup. Something that if I interfered with I would get run out'a Dodge on a rail. And Debian is the newcomer to the network. Mostly it has been commercial vendor systems. Politically I need Debian to play nicely with the other less capable children. > If you are absolutely certain that ssh (for example) will not work at all, > then you can guarantee that you will get the real package by specifying a > versioned dependency, though this is not terribly elegant and may break in > the future if versioned Provides are implemented. Use versioned depends to trick lintian not to see this as a virtual package. Interesting! Yes, I tried that and it did silence that warning. Thank you for suggesting that. Since this meta package is for my own internal use only and I can change it on demand as needed I can react to any future change in versioned Provides. Thanks for the help! Bob pgpcacyqcdSzZ.pgp Description: PGP signature
Re: virtual-package-depends-without-real-package-depends rsh-client
Aaron Haviland wrote: > Bob Proulx cursed the gypsies with this chant: > > Bug 179614! It appears to me that this is a similar but not quite > > identical problem. In that bug the packages were all real packages > > and none of them were virtual. I could not deduce that any of them > > were virtual. So I will file this as a seperate bug and reference the > > above as additional information. > > It would appear to me that they are the same bug. If you look closely at > the bug, you'll notice that pump Provides: dhcp-client In what version? I looked at pump-0.8.11-5 and it did not provide dhcp-client. There it is! pump-0.8.14-1 in unstable provides pump. The changelog says this: * Provide dhcp-client (closes: #178961). So they are almost certainly the same bug. I will update the report. Thanks Bob pgpredH9HPLCZ.pgp Description: PGP signature
Re: Unofficial package tips
Bastian Kleineidam wrote:
> On Fri, Feb 28, 2003 at 08:19:51PM +0100, Henning Moll wrote:
> > In addition i have some questions to the Depends section in
> > debian/control: ${shlibs:Depends} is a nice feature, but i think
> > for many packages/libraries it is way to strict, because it's
> > always using the versions of installed packages which may not be
> > necessary. So what's the best/common way to handle this?
>
> The library version number is there for some reason: binary compatibility.
> If you drop the version number from library depends, your package may
> break when a new library is there.
I think you meant when an old library is there, not an new one. Since
libraries are not meant to be forward compatible moving code compiled
with a newer library to an older one might not work. The older one
did not know about the newer one. They are designed to be backward
compatible in that moving to a newer library should work. The newer
one knows about the older one. Assuming that is what you meant or
please correct me.
Bob
pgpNhXG9ks4T3.pgp
Description: PGP signature
Re: Really strange : my package doesn't compile from source.
Neil L. Roeth wrote: > Examining the buildd logs showed it tried to run automake to build > [...] > But, *why* did this happen? I had created Makefile.in in the source > tree after aclocal.m4, so it was a *newer* file there and did not > trigger a call to automake on my build machine. You asked the question. But then you supplied this answer. > Perhaps the problem is that both aclocal.m4 and Makefile.in are > unpacked from the source package in the order that they appear in > the .diff.gz file; Makefile.in is in the .diff.gz first, followed by > aclocal.m4. So the time ordering was reversed after the files were > created by patching .orig.tar.gz with .diff.gz, and automake got > invoked needlessly. That's my theory, feel free to point out any > stunningly obvious facts that I overlooked which make it invalid :-) Why do you think that you have not answered your own question? :-) I don't really know 100% but I am convinced within the limits of available data. I have created similar problems for myself because of the patch files. > What this does not explain is why it did not FTBFS on all > architectures. A guess. More likely is that perhaps those other architectures patch the files so fast that the resulting timestamp is all within the same second. Which make will accept as up to date. A race condition. If you try the same build enough times all would fail and pass at different times. It all depends on if it can complete within the same second or not if it crosses seconds. > I searched through one or two other logs of successful builds and > did not see any calls to automake, so somehow the dependency did not > trigger. Also, a build with pbuilder on my machine, i.e., a clean > environment, had no problem. If it is a race condition, all sources local to your machine, and you have a fast machine, then the odds are good the timestamp will be in the same second. It may be hard to generate a case which crosses the second boundary. I noticed that the machines that failed your build in the buildd logs were slower machines. If you were to build your own repository, 'apt-get source -b package' would you get the same problem? I always test that no since I added a configure script to a package which did not have one and the configure mode in my development directory was a+x but when created by patch it is not executable. I would never have caught that in my development area but only by fresh source build. > Unless you or someone else can tell me what is going on, and a better way to > fix it, I am inclined to go ahead and include automake in the build > dependencies. Put me in the camp that does not like AM_MAINTAINER_MODE. I would make the timestamps work correctly in the debian/rules file. That limits the ramifications. There are none outside of the debian build. My rules files have build: depend upon build-stamp: depend upon configure-stamp: and there I would touch the generated files in the right order. Or force them to be the same as a reference file timestamp. touch aclocal.m4 Makefile.in configure, I think. Since the patch process is changing the timestamps from what are in your sources it is necessary to force the timestamps back into the order they are in on the system when the patch was created. The actual values are not important but only the order. You may want to read some discussion on the subject of automake and timestamps here. http://mail.gnu.org/archive/html/automake/2003-02/msg00036.html Bob pgpSWm7qMFafO.pgp Description: PGP signature
Closing bugs in unreleased packages?
The released version of Debian is 'stable. Why are bug reports closed
against 'sid'? Shouldn't bug reports be closed only in released
versions of Debian? What am I missing? Requesting education.
http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-bug-handling
5.8.4 When bugs are closed by new uploads
... you should not close the bug until the package which fixes the
bug has been accepted into the Debian archive. Therefore, once
you get notification that your updated package has been installed
into the archive, you can and should close the bug in the BTS.
...alternately... list the fixed bugs in your debian/changelog
file ...
I am assuming here that "accepted into the Debian archive" refers to
'sid' in this case. Therefore all bugs are closed when the package is
in 'sid' even though this fix may never reach 'stable'. A user of the
released Debian may never see the fix.
Here is the documented user interface:
http://www.debian.org/Bugs/
Viewing bug reports on the WWW
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data={ex}&archive=no
[Where {ex} in the URL is any example package name, changed not to
pick on any one particular package.]
If you find a bug not listed here, please report it.
This documentation leads one to believe that if they see a bug in
'stable' that they should report it, no?
A package maintainer who is following the rules, will fix the bug,
update the package in sid, close the bug. The bug, now closed will
disappear from the BTS (being moved to the archive of closed bugs,
requiring archive=yes to view). Users using released Debian 'stable'
observing the bug who are following the rules will not see the closed
report, will report the bug again. The maintainer will see the
duplicate bug report and close it. Repeat. Repeat. Repeat. The
time period during which this may continue could be the two years it
took to release 'woody'.
The maintainer is frustrated by seeing the same bug reports for things
they have fixed and are in the pipeline to stable but not there yet.
Again and again. The user is frustrated because they are not seeing
any of those bug reports. They are going through effort to create a
good bug report, only to be told it is a duplicate. Then they are
told to go away, and in some cases griped at for filing a duplicate
bug.
Shouldn't bugs be "not-closed" until the package moves into 'stable'?
(I did not say "open". After a fix perhaps "fixed", or "resolved" to
show that it has been addressed in a package that has not yet made it
to 'stable'?)
Please educate me. What should a user be doing? What should a
maintainer be doing? What am I missing?
Thanks
Bob
pgpZePZzTgj36.pgp
Description: PGP signature
Re: First steps in packaging
Tony Maro wrote: > Why do I feel like I opened a can of worms? It is that squirmy feeling in the gut. Like just before the alien claws its way out. Bob pgpClP4tDDzjT.pgp Description: PGP signature
Re: First steps in packaging
Matthew Palmer wrote: > Out of interest, are there any MUAs which have a separate "reply to list" > function? KDE's 'kmail' for those into GUIs to read text. But you have to configure the list address on a per folder basis. Bob pgpKg8pXDLrj4.pgp Description: PGP signature
Re: How do you upload/build sponsored packages?
Colin Watson wrote: > I actually don't see how dpkg-buildpackage's > sign-immediately-after-build defaults ever make sense (except when > dpkg-buildpackage was originally written, when debsign didn't yet > exist). Why would you want to waste time signing a package you haven't > tested yet? Surely the order should be build, test, sign. > > Accordingly, I have DEBUILD_DPKG_BUILDPACKAGE_OPTS="-uc -us", together > with a bunch of other options that don't matter here, in ~/.devscripts. > I've never yet found that I want the other behaviour. Would it be somehow possible to change the default behavior? Using 'debuild' it makes it relatively easy for people to build packages. Even those not familiar with Debian's build systems can make small tweaks to the source files and then say 'debuild' and everything magically works for them. But just saying 'debuild' does not _really_ work because of the signing steps unless they are all set up for that too. When I tell them to use 'debuild -uc -us' suddenly the eyes glaze over and this nice simple build approach becomes completely incomprehensible. It is almost enough to create 'dbuild' which would supply those options automatically. I think after this discussion I am leaning more toward automatically seting up /etc/devscripts.conf with these options for my users. Unfortunately the downside is that the behavior does not transfer exactly from the systems I administer to other stock systems. Bob pgpbx6BiI86w7.pgp Description: PGP signature
Re: How do you upload/build sponsored packages?
Brian Nelson wrote: > > Would it be somehow possible to change the default behavior? > > [of debuild to be debuild -uc -us] > Uh, have you filed a wishlist bug? Good idea! Just did that. Bug#194678 Bob pgpfOUP2e7fXk.pgp Description: PGP signature
