debian packages: single diff vs multiple patches (as in rpm)
Although philosophically more aligned with Debian, I had been a RedHat user for almost 8 years largely pragmatic reasons that aren't relevant. As such, I have developed a large rpm-based infrastructure for releasing my company's own software to our production facilities and have become quite familiar with RedHat's rpm system from the developer's perspective. Now I'm strongly considering making the switch to Debian and am evaluating moving my whole installation system over to dpkg. dpkg seems superior to rpm in almost all respects (richer dependencies, better documentation, more robustness, apt, etc.), but there's one thing that bothers me. When building an rpm, multiple source files and multiple patch files can be specified, and arbitrary commands can be used to extract sources and apply patches. This makes it easy to build an rpm of a standard package with a handful of separately maintained patches applied. As far as I can tell, a Debian package consists of a single source tarball and a single diff. Is this right, or have I missed something? Coming from an rpm perspective, it seems to me that this would make it much more difficult to manage locally modified versions of packages. I'd appreciate if someone could either explain to me that I've got it all wrong give me a pointer for what to look like, or confirm that my understanding is correct but explain why this isn't really a problem. I'm especially interested in hearing thoughts from other people who have converted an rpm-based infrastructure to a dpkg-based infrastructure. Lastly, please feel free to correct my terminology if I'm using it incorrectly. For example, is it correct to say dpkg-based rather than deb-based? Thanks! -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
RFS: xerces -- or -- request for NMU
I am interested in possibly co-maintaining the xerces packages or in taking them over. Ivo Timmermans, the current maintainer of the xerces packages, indicated on [1]debian-devel that he is "looking for people interested in working on the xerces packages, as a comaintainer or maybe to take it over entirely." 1. http://lists.debian.org/debian-devel/2004/debian-devel-200402/msg01047.html There hasn't been any activity relating to that post on the debian-devel list. (There are no other messages in the February or March archives with the word "xerces" in their subject lines.) In [2]Bug 225305, I submitted a patch for libxml-xerces-perl to bring it up to the latest upstream version. In response to my comments to this bug report (prior to submitting the patch), Ivo Timmermans replied, "Go ahead and do an NMU." Of course, I can't do that because I'm not (yet, I hope) a DD. 2. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=225305 My patch in Bug 225305 requires a change to the xerces23 package as well. In [3]Bug 234230, I have submitted a patch to the xerces23 source package that would allow the config.status file leftover from building xerces to be installed in /usr/lib/xerces23. The config.status file is needed in order to build libxml-xerces-perl which needs to know how xerces was configured. The config.status file, though text, is definitely architecture-dependent since it encapsulates the output of running "configure", which is why I figured it would go in /usr/lib/xerces23 rather than /usr/share/xerces23. I discuss this in the bug report. 3. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=234230 Both patches are suitable for NMUs. They follow the policy of not making any gratuitous changes. In other words, the packages built by applying my patch and following the procedure outlined in the bug report do have one lintian warning (an executable header file), but so do the existing packages. I explicitly did not fix the problem (though it is easy to fix) because I was considering this to be fodder for an NMU rather than a new packaging job. If I were to assist with maintenance or take over as maintainer of the xerces packages, I would plan to fix this problem and also to create a xerces24 package for the latest upstream Xerces-C package. (At present, the latest version of Xerces perl is not compatible with the latest version of Xerces-C. There's no reason, however, that one can't have more than one version of the runtime libraries installed even though only one version of the Xerces-C development packages can be installed.) I am definitely interested in becoming a Debian developer and getting onto the new maintainer track. I have not yet gotten by GPG key signed by a developer, but I have made contact and intend to pursue the key signing a bit more aggressively. I am relatively new to Debian, but I have been running Linux since 1992 and have been reasonably active in the Open Source community since the late 80's, submitting small to medium patches to a wide range of packages. I am also capable of [4]following the convention of embedding references in my email, which indicates that I am able to observe and mimic prevailing habits. :-) I have read the policy, social contract, developer's reference, and various other materials, and I have close to 20 years of programming and system administration experience under my belt. Luckily, I'm also very patient and don't expect any special treatment on the basis of these stated qualifications. :-) 4. This message I've been lurking on this list long enough to realize that requesting a sponsor for an NMU is somewhat unusual, so I'd welcome advice about how to proceed. Although I have not spoken with Ivo Timmermans about this in the last couple of weeks, I did discuss this some with him including stating my intentions to post here. See [5]Bug 232474 (defunct, superseded by Bug 234230) for details, though keep in mind that this message includes some rambling as I come to the conclusions asserted in Bug 234230. I believe that my patches here are sufficiently simple that someone with the inclination should be able to decide to do an NMU with very little time or effort. If you're willing to sponsor me as a comaintainer of the packages, I'd like to know that too. We would, of course, have to coordinate with Ivo. Thanks for your time. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Re: RFS: xerces -- or -- request for NMU
> Jay Berkenbilt <[EMAIL PROTECTED]> writes: > > I am interested in possibly co-maintaining the xerces packages or in > > taking them over. Ivo Timmermans, the current maintainer of the > > xerces packages, indicated on [1]debian-devel that he is "looking for > > people interested in working on the xerces packages, as a comaintainer > > or maybe to take it over entirely." > [...] > > OK, please send me an URI to your packages (i'd prefer that, but you can > also mail them to me directly). I've put all the packages at: http://www.tux.org/~ejb/debian/xerces/ They are divided into libxml-xerces-perl and xerces23. I copied all the files that I believe would be uploaded. This would include all binary packages as well as diff.gz dsc, and orig.tar.gz for libxml-xerces-perl and all the binary packages as well as diff.gz, dsc, and changes for xerces23. (libxml-xerces-perl has been moved to a new upstream version; xerces23 has just had a minor change.) Here is a complete list of files under the above URL. libxml-xerces-perl/libxml-xerces-perl_2.3.0-4-1.diff.gz libxml-xerces-perl/libxml-xerces-perl_2.3.0-4-1.dsc libxml-xerces-perl/libxml-xerces-perl_2.3.0-4-1_i386.changes libxml-xerces-perl/libxml-xerces-perl_2.3.0-4-1_i386.deb libxml-xerces-perl/libxml-xerces-perl_2.3.0-4.orig.tar.gz xerces23/libxerces23-dev_2.3.0-2_i386.deb xerces23/libxerces23-doc_2.3.0-2_all.deb xerces23/libxerces23_2.3.0-2_i386.deb xerces23/libxercesicu23_2.3.0-2_i386.deb xerces23/xerces23_2.3.0-2.diff.gz xerces23/xerces23_2.3.0-2.dsc xerces23/xerces23_2.3.0-2_i386.changes Thanks for taking a look at this. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Re: RFS: xerces -- or -- request for NMU
> In a private email to Ivo I offered to co-maintain them under the > umbrella of the Debian XML/SGML group (see my signature for more > info). Ivo told me that xerces already its own project on Alioth > but that it might be better to move it over to the Debian XML/SGML > group. > > If you want your welcome to join the group. Thanks. I'll definitely check this out. Someone kindly volunteered to look over my packages. Should I still move forward with the NMU? I just need to redo the packages following the proper policy for NMU which I didn't do exactly right. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
wvdial prompts "by hand"... is that release critical?
See bug 219151. The wvdial package prompts the user by hand during installation instead of using debconf. Isn't this against the policy? If so, shouldn't that bug be release critical instead of important? Is it worth trying to change that so that this gets fixed for Sarge? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=219151 -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
RFS: patmv -- a bulk renaming tool
I'd like to request a sponsor for my "patmv" package. patmv is a Perl
script that can be used to do bulk renames on files based on a Perl
expression ("pattern"). I've been using this script for about 10
years, and it has a small following among current and former
co-workers. The idea was inspired by a short example that was
included with perl 5.000 or one of its betas, but my script is an
expansion on the original concept.
You can retrieve the package from mentors.debian.net. They are
lintian and linda clean and they build in pbuilder. I have read the
policy, social, contract, etc. and have had my key signed by Debian
developers. I've also completed more substantive and complex
packaging tasks and have read Matthew Palmer's sponsorship FAQ at
http://people.debian.org/~mpalmer/sponsorship.html. I have not
created an ITP though since, prior to this weekend, this script was
not packaged and pretty much only existed on machines that I could log
into.
The patmv program is most useful to people who have to deal with
sanitizing names on large groups of files. It's one of our must-have
tools when dealing with receipt of batches of data from our clients.
It helps to have some Perl knowledge, but anyone who can use sed can
use patmv, and the manual page gives plenty of examples that people
can modify.
The idea is simple: patmv takes an expression that operates on $_ as a
command-line argument. For each file, it evals the expression with
the last component or whole filename (depending on options) set to
$_. If the operation changes the name, a rename is done. patmv is
intelligent about keeping track of intermediate steps, making it safe
to use in cases where directories get renamed before their contents.
It can take lists of file names on the command line or read them from
stdin, one file per line.
Here are a few quick examples:
To change all spaces to underscores recursively in "Some Directory":
find "Some Directory" -print | patmv 's/ /_/g'
To change the names of all the files in the current directory to lower
case:
patmv tr/A-Z/a-z/ *
To forcibly overwrite all files named whatever with any files named
whatever.new:
patmv -f 's/\.new$//' *.new
and so forth.
The version I uploaded is version 1.0. Although the code is very
thoroughly tested (both by the included automated test suite and by
years of daily use), this is the first time I've made a public
release.
I'd be eager for your consideration and any comments.
Oh, one note: there are no differences at all between the upstream
version and the Debian version: the debian files (and an rpm .spec
file) are both included in the upstream sources. Based on a
discussion on debian-devel, however, I've decided to not package this
as native. Therefore, there is a .orig.tar.gz and a .diff.gz, even
though the .diff.gz is empty (well, actually the result of running
gzip on an empty file), and the Debian revision is 1. I thought I'd
mention this so that it was clear that I did it this way on purpose.
--
Jay Berkenbilt <[EMAIL PROTECTED]>
http://www.ql.org/q/
Re: RFS: patmv -- a bulk renaming tool
> > I'd like to request a sponsor for my "patmv" package. patmv is a Perl
> > script that can be used to do bulk renames on files based on a Perl
> > expression ("pattern"). I've been using this script for about 10
> > years, and it has a small following among current and former
> > co-workers. The idea was inspired by a short example that was
> > included with perl 5.000 or one of its betas, but my script is an
> > expansion on the original concept.
>
> Can you clarify what the difference is between this script and the
> 'rename' script currently including in the Debian perl package?
> All of the examples you gave, as far as I can tell, would work
> just as well with the 'rename' that is already in Debian.
Hmm. Looks like rename and patmv have the same common ancestor. I
didn't realize this already existed, though I tried digging for it in
the perl sources. (I didn't know what it was called, and I didn't
think to look in the debian/ directory which is where rename is in the
Debian perl distribution.)
There are several differences, though: patmv has logic to handle
recursive renames in an intelligent way and has options for
manipulating the whole path or the last component as an option. In my
opinion, it also handles file existence cases more robustly and
generates more useful output.
% mkdir -p z
% cd z
With rename:
% mkdir WORK; touch WORK/{1,2,3}.TXT
% rename -v tr/A-Z/a-z/ `find WORK -print`
WORK renamed as work
Can't rename WORK/1.TXT work/1.txt: No such file or directory
Can't rename WORK/2.TXT work/2.txt: No such file or directory
Can't rename WORK/3.TXT work/3.txt: No such file or directory
With patmv:
% rm -rf work
% mkdir WORK; touch WORK/{1,2,3}.TXT
% patmv tr/A-Z/a-z/ `find WORK -print`
mv WORK work
mv work/1.TXT work/1.txt
mv work/2.TXT work/2.txt
mv work/3.TXT work/3.txt
patmv generates output that could be re-executed if needed (though
I've seldom used this feature) and that handles the need for quoting
intelligently:
% touch "Someone's Goofy Filename"
% patmv "tr/A-Z '/a-z_-/" S*
mv 'Someone'\''s Goofy Filename' someone-s_goofy_filename
patmv handles existing file names by prompt the user unless it can't
(in which case it fails without overwriting) or --force is given (in
which case it just renames the file):
% touch 1 2
% rename s/1/2/ 1
1 not renamed: 2 already exists
% patmv s/1/2/ 1
2 exists. Overwrite? y
mv 1 2
patmv can read files from stdin as well as taking files on the
command-line. For example, one could convert a large RCS-based source
tree to a CVS repository with something like (untested):
% find . -type f -name '*,v' | grep RCS/ > /tmp/1
% tar -c --files-from /tmp/1 -f - | (cd /my/cvs-repo; tar xf -)
% cd /mn/cvs-repo
% find . -type f -print | patmv -w s,RCS/,,
My copyright says that the software can be redistributed and used for
any purpose, which is less restrictive than the Aristic license. At
the time I wrote my version of the script, I wrote it from scratch
without using any of the original example code which was only a few
lines long anyway. I could probably be convinced to use the Artistic
license, though for something so short, I see no need to maintain any
kind of artistic control. (I don't view myself as having violated the
original copyright since I didn't use any of the code and since the
idea was so simple, but if you disagree, by all means let me know.)
--Jay
Re: RFS: patmv -- a bulk renaming tool
> > There are several differences, though: patmv has logic to handle > > recursive renames in an intelligent way and has options for > > manipulating the whole path or the last component as an option. In my > > opinion, it also handles file existence cases more robustly and > > generates more useful output. > > Your examples are persuasive that patmv has some advantages over Perl's > rename. I wonder whether it might be worthwhile to see if patmv could > replace rename in the perl package, though, since it appears to be > intended for an identical purpose. > > I suppose on the other hand people might be more aware that the program > exists at all by virtue of a separate package. I would prefer it to be a separate package. I've released it from my personal software website and have also made a Red Hat package (for my less enlightened friends have haven't switched yet ;-]). Also, "rename" isn't actually part of the upstream Perl package -- it's added in Debian by the patch. In fact, Red Hat distributions also have a "rename" command that does something different. There's no real reason why patmv should be part of Perl either. Although it was definitely inspired by a Perl example, it has, in my opinion, enough functionality to be a separate package in its own right (in addition to the good point you make about awareness). Also, by having it be a separate package, enhancements or bug fixes can be made without having to re-release Perl. (I have every intention of becoming a DD, though I know this takes some time.) Although I failed to mention this in my initial post, the thing that pushed me over the edge and made me decide to submit this package for sponsorship was the recent inclusion of the "renameutils" package, which I learned about in the Debian Weekly News[1] new package list. 1. http://www.debian.org/News/weekly/2004/16/ I feel that patmv is no more special-purpose than renameutils (which is in its own package) and serves a different cross section of the Debian user community. > I might be willing to sponsor it; let me think about it a bit. I appreciate your consideration. So that I don't have to come across as nagging, can you give me some kind of timeframe within which you expect to respond? If I don't hear anything within that timeframe, I'll post a second RFS request. :-) Thanks! -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Re: RFS: patmv -- a bulk renaming tool
> Jay Berkenbilt wrote: > > Although I failed to mention this in my initial post, the thing that > > pushed me over the edge and made me decide to submit this package for > > sponsorship was the recent inclusion of the "renameutils" package, > > which I learned about in the Debian Weekly News[1] new package list. > Ah. The only thing that kept me from suggesting the same for patmv as > for pdfmerge was that I didn't know which package is would well fit in. > Thanks for taking care of that. > So: I suggest you submit it for addition to renameutils. > As a side effect, renameutils and your package get a comaintainer. Thanks for the suggestion. My preference would still be to have patmv as its own package as I think patmv and renameutils have different audiences. Also, patmv has its own life outside of perl or renameutils. My point about renameutils was only that the fact that this package was recently included into Debian convinced me that there was a place for something small and special-purpose like my patmv command. As for comaintainership, that's always a good idea, but I've changed patmv about four times in 10 years, so I don't think it will generate too much activity. :-) --Jay
Re: RFS: patmv -- a bulk renaming tool
strength of my conviction on this point. I truly appreciate the suggestions and the implication of interest that they imply. Thanks again for listening. Please let me know if I you are still planning on looking at patmv and considering sponsoring it. Thanks. --Jay -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
withdrawing RFS for patmv (was RFS: patmv -- a bulk renaming tool)
> Tiny packages are generally frowned upon in Debian since they > unnecessarily bloat the Packages file. So, small scripts like yours > tend to be collected into a single package with other related scripts. > > If everyone packaged their pet scripts into separate packages, the > already very large number of packages in Debian would grow enormously. Your arguments and those of others have persuaded me to withdraw my RFS for patmv. For now, I'll just put the Debian package for patmv on my personal site along with a handful of other small tools that are useful enough to share with a wider audience than their current user base. If someone else decides that it's worth including in renameutils, I have no objection. I'll likel contact the remameutils maintainers and let them know about it, at least as a more advanced alternative to the rename program that is packaged with Perl. Please understand that I'm not withdrawing this because I feel bitter or disappointed, but because I genuinely agree with the arguments. My thinking prior to submitting my RFS was that, if a reasonable package had been debianized, it made sense to submit it for inclusion in the distribution where it would be easy to find and install. I now feel that it's better to wait until the package has a wider user base or serves some important purpose not served by other packages. (This seems obvious in retrospect.) I'm sure I'm not alone, especially among relative newcomers to Debian, in not even having read the names of all the available packages, let alone knowing what they all do. Although it's great to be able to install just about anything I know about with apt-get install (rather than search all over the place for, say, an rpm that may or may not coexist peacefully with other packages), I completely acknowledge that patmv is not something anyone will come looking for. Thanks again for the responses and interest! -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
testing config/preinst mods
Is there a preferred or easy way to test proposed modifications to maintainer scripts, particularly config and preinst scripts which are run before the package is installed, on existing built packages at the time of installation? There is a small handful of config/preinst bugs that I'd like to try to fix and that would require modifying config or preinst scripts. For config scripts, in the absence of something pre-existing, one approach that looks like it would work pretty easily would be to replace apt-extracttemplates (which is called by dpkg-preconfigure) with something that would check a magic directory for replacement scripts for a package and use those instead of the real ones if they exist. Then if I wanted to mess around with editing config scripts, I could run apt-extracttemplates by hand, copy the resulting files into this directory, and edit them freely. Then the next time I install the package (after dpkg --purge) I'll see the modified scripts instead. Something similar could probably be done for preinst though I haven't looked at exactly where in the process this happens. For what it's worth, I've also looked at running scripts by hand with /usr/bin/debconf, but that doesn't solve the whole problem. For example, debconf-devel(7) discusses using debconf-loadtemplate and running scripts by hand with debconf(1), but this addresses only debconf issues, not other issues with config or preinst scripts. Gratuitous comments: I'm posting this question to debian-mentors because I think it's too far toward development to post to debian-users, and too much of a newbie question for debian-devel. It seems like this is something that most developers who maintain packages with configure scripts would probably have to do from time to time, so it seems worth asking before reinventing the wheel. If you think I've misjudged where to ask this question, I'd like to know. Also, I've looked in various documents for an answer to this question and haven't found anything. If this issue is spelled out somewhere, a pointer would be appreciated. The apt.conf and debconf-devel documentation have lots of hints, but nothing that looks easier than the approach I'm planning on trying. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Re: testing config/preinst mods
> > For config scripts, in the absence of something pre-existing, one > > approach that looks like it would work pretty easily would be to > > replace apt-extracttemplates (which is called by dpkg-preconfigure) > > with something that would check a magic directory for replacement > > scripts for a package and use those instead of the real ones if they > > exist. > > I have never heard of something like this - but it would be simply > great! Not only that it would make testing easier, but also because if > some strange bug is reported, one could put debugging code at the right > places of the script, send it to the bug submitter and ask him to make > dpkg use it. I had a couple of hours over the weekend to implement and test this. I used it today to create patches for two outstanding bugs including three merged release-critical bugs against console-common. I'll post my solution to debian-devel today with the subject "testing config/preinst mods: one approach". -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Re: Upload of a new package
> Hi, > I'm the mantainer of phpldapadmin, a web-based tool for managing ldap > servers. I'm not (yet!) an official Debian developer, so I asked for a > sponsor. He checked my package and uploaded in the unstable debian > archive about ten days ago... > > Here my questions: > - how long takes the verification process and when will be the package > available in unstable? How can I monitor the state of the package? > > - A new minor upstream version is available for the package, my sponsor > told me it is better to wait the package enters in unstable before > send the new version, because every upload before this happens "reset > the timer" and I have to wait more time to see my package in unstable. > > I'm not in this list, so if you answer please CC me. > > Thanks a lot, > Fabio. As a point of comparison, I'm helping with maintenance of the xerces packages and had xerces25 (new) uploaded by a sponsor. The package was initially uploaded on May 4 and appeared in unstable on May 18. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Re: /etc/init.d/ script policy violation?
> > One question I have however, is should it be a policy violation if a > > script hangs waiting for user input? Perhaps the policy document > > should be updated to explicitly deal with this case? > > If it does wait on input (or might) it should start afte, ssh, pcmcia, > hotplug and networking. Thus allowing acces to the "hanging" machine > even with pcmcia network cards. This is true only as long as DELAYLOGIN=no in /etc/default/rcS or rmnologin is moved earlier as well. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Re: setgid-wrapper
> My understanding of the position of Bob and Mike can be summed up as,
> "in general, shell script's can't be made to use setuid/setgid
> securely". Basically, the problem comes down that a user can manipulate
> their PATH to redefining basic commands that are used by the shell
> scripts (like "ls") in order to elevate their privileges.
>
> I'm not willing to give up on the basic idea yet, however, as I still
> need to run a Java program setgid to "games" to handle a score history
> file. Similarly, I hope to one day run a Java application server (e.g.
> Tomcat, JBoss, or Geronimo) setuid to some system id. Therefore I
> humbly request your comments on how to salvage this idea. Please keep
> in mind that "/usr/bin/java" is, itself, almost certainly a script.
I missed the original discussion, so I risk saying something someone
has already said. My strategy for dealing with setuid/setgid shell
scripts in general is always to use sudo (which mdz mentioned as an
example of controlling elevation of privileges). I abandoned wrappers
in favor of this long ago. sudo is easy to set up, and it explicitly
moves responsibility to the local administrator. My standard approach
is to name my script whatever.real and have a wrapper that runs sudo.
For example, I allow certain users on some of my systems to create
accounts with adduser. I have renamed adduser to adduser.real and
created the following adduser script:
#!/bin/sh
echo "If prompted, enter your password to enter user creation program."
exec sudo $0.real ${1+"$@"}
Use of $0.real here is okay because the sudoers file has the full path
to the program that the user is authorized to run. (Anyway, the user
can always run sudo by hand.) I also set the permissions on the
whatever.real script to 0750 or 0700. Now if I want to control this
with a group or just a list of authorized users, I can do that in
sudoers. Although my home-written adduser script could certainly be
exploited by a knowledgeable user, I trust the people who are
authorized to create accounts on my systems, so I'm willing to accept
that risk in this instance.
As for the specific example of writing to a high scores file, I would
assert that this functionality is not essential to the proper
functioning of the game, and you should make the game work with or
without this functionality. That way, if whatever strategy you choose
for updating the high scores file is overridden by the local
administrator, the game will still work. I wouldn't make the whole
game setgid just so it can write to its high score file. I would do
one of two things instead: make the high score file world-writable and
put it in a non-world-writable directory (some may object to
world-writable files on a system partition), or create a separate
program that your main program communicates to whose sole purpose in
life is to update the high scoring program. This can be a normal
compiled C or C++ program. You can create a debconf question that
explains to the installer that this component of the application needs
to be installed setgid games to update its high scoring file and ask
the user whether to do this, explaining the potential security risks,
and have the default be "no". You can look at man-db
(dpkg-reconfigure man-db) for example of how you might want to word
this.
--
Jay Berkenbilt <[EMAIL PROTECTED]>
http://www.ql.org/q/
Re: Feedback wanted: audacity 1.2.1-3
> I have recently reworked some of the packaging scripts for "audacity". > The package now uses CDBS and debhelper more extensively. I would > appreciate it if anyone can take a look at the package and provide > suggestions or feedback. This package installs its help file, audacity-1.2-help.htb, in /usr/share/doc/audacity. Since this isn't a human-readable file (or, more accurately, a file intended to be read manually by the user), I wonder whether that's really the right place for it. I see it's put in that location explicitly by the Makefile, so it would be there on any system, even one which doesn't follow Debian's conventions on use of /usr/share/doc. I would think /usr/share/audacity would be a better location for the help file, but I could be off base here. (For this reason, I cc my reply to debian-mentors, giving someone else the chance to contradict me.) Otherwise, this looks like a nice cbds example. :-) I'm not a DD (yet?), but that's my $0.01. (I didn't say enough to be worth $0.02 ;-]). That's for helping to create audacity. I've been a light audacity user since before 1.0. It just keeps getting better. It also was the tool that introduced me to wxWidgets (f.k.a. wxWindows) which I use for my own GUI development now. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Re: packages.qa.d.o bug?
>I maintain cvs2svn, and my sponsor uploaded a new version of the > package four days ago. Still, "Testing Status" shows the previous > package: "* 21 days old (needed 10 days); * Valid candidate" etc. > Is this known, or should I file a bugreport? Skimming over 'general' > bugs in BTS does not show anything relevant. In your package status package: http://packages.qa.debian.org/c/cvs2svn.html You'll see, under "Problems", that the package has not entered testing even though the 10-day delay is over. Click on "Check why" there to see the reasons. http://bjorn.haxx.se/debian/testing.pl?package=cvs2svn You'll see that this is blocked by subversion which in turn is blocked by perl. Lots of things are blocked by perl, but there appears to be active effort in resolving that issue. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
two new packages, one depends upon the other
Suppose I have two packages: A and B where B depends and build depends upon A. Neither package has been uploaded before. I can easily build A in pbuilder using pdebuild, but I can't do the same with B because B build depends upon A and A is not in the archive (thereby causing pbuilder-satisfydepends to fail). I have gotten around this by using pbuilder login, installing A's debs manually, running pbuilder-satisfydepends, and then run dpkg-buildpackage, but I'm wondering whether there is a better/usual way to do this. Any suggestions would be welcome. Also, when A and B are ready to be uploaded into unstable, I am assuming that, as long as A is uploaded first, there's no reason not to upload them together. Of course, B won't be able to built from source until its build dependencies can be satisfied, which won't happen until A is built. Would it be useful to wait a few days between uploading A and B? If B fails to build from source, is it the case that manual intervention is then required to get it to retry, or does this happen automatically? Thanks again for any clarification. The actual situation is a set of development libraries and command-line tools in one source package that creates four binary packages (runtime, dev, doc, and tools) and then a separate graphical front end that depends on the runtime and build-depends on the dev. I'll be posting an RFS for these packages probably within the next day or so. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Re: two new packages, one depends upon the other
> > Suppose I have two packages: A and B where B depends and build depends > > upon A. Neither package has been uploaded before. I can easily build > > A in pbuilder using pdebuild, but I can't do the same with B because B > > build depends upon A and A is not in the archive (thereby causing > > pbuilder-satisfydepends to fail). I have gotten around this by using > > pbuilder login, installing A's debs manually, running > > pbuilder-satisfydepends, and then run dpkg-buildpackage, but I'm > > wondering whether there is a better/usual way to do this. Any > > suggestions would be welcome. > > You can always add your own repository to the /etc/pbuilderrc. > If you don't have time to create your own, you can use mentors.debian.net, > that's what I do usually. That's so obvious I completely overlooked it. :-) Thanks! It worked perfectly. I already have a local repository, so I just copied these packages into it, reran dpkg-scanpackages, and added it to /etc/pbuilderrc in OTHERMIRROR. It worked perfectly (after I ran pbuilder update --config-override). > > If B fails to build from source, is it > > the case that manual intervention is then required to get it to retry, > > or does this happen automatically? Thanks again for any > > clarification. > > That depends on the reason of not-building. What reasons do you expect? Only not waiting long enough between uploading A and B. Probably nothing to worry about. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
RFS: vips and nip
I have packaged [1] vips and nip. The packages can be found on mentors.debian.net (details follow). All packages are lintian clean and were built in an up-to-date pbuilder environment. I have locally installed and tested the packages. 1. http://www.vips.ecs.soton.ac.uk The following introductory text, largely lifted from the vips web site, briefly describes the software: VIPS is a free image processing system. It is good with large images (images larger than the amount of RAM in your machine), and for working with colour. VIPS consists of two main components: an image processing library, and a spreadsheet-like graphical user interface, available in the nip package. The nip program is really quite remarkable, and has functionality unlike what I've seen any other packages. This is most certainly not just another image viewer or manipulation program. With this program, you can form complex pipelines of image operations using a spreadsheet-like user interface. The resulting images are updated dynamically as parameters are changed. One of the more interesting features here is mosaic assembly. I have used this successfully to create "seamless" scanned images out of parts scanned on my 8.5x11 flatbed scanner. Also, nip can work on very large images and is quite efficient. I was able to do manipulations on 9 300-dpi 24-bit color 8.5 x 11 images simultaneously without any observable lag. I have discussed my interest in packaging vips and nip for Debian with the upstream maintainers, who are enthusiastic about this possibility. There are packages for vips and nip for some other distributions including gentoo. An [2] RFS for this package already existed. I retitled the RFS to an ITP and posted a little bit of additional information. 2. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=188478 There are two source packages: vips7.8 and nip. The vips7.8 package creates four binary packages (shown here with their i386 names): libvips7.8-dev_7.8.14-1_i386.deb libvips7.8-doc_7.8.14-1_all.deb libvips7.8-tools_7.8.14-1_i386.deb libvips7.8_7.8.14-1_i386.deb The nip package creates a single binary package: nip_7.8.14-1_i386.deb The vips package has the version number built into the package name because it creates and installs a shared library. Unfortunately, the library version is 0.0.0, but the upstream maintainers have fixed this and are now using sensible shared library naming conventions. To my knowledge, they are not using versioned symbols, though I may take this issue up with them (particularly after this whole tiff fiasco). vips 7.10.0 is out, but it is considered a beta release. The upstream maintainers expressed a preference for having 7.8.14 packaged for Debian for now rather than 7.10.0. The new version of nip is now called nip2. It uses gtk2.0 instead of gtk+. I will package those in a few months when they are considered stable by upstream and have documentation. Clearly they will not be ready in time for sarge. I'm hoping someone will sponsor these packages and upload them soon. They need to be uploaded fairly quickly to make it into sarge. Any feedback on the packaging is, of course, appreciated so that if I need to make changes, there is still time. Since nip build depends upon libvips7.8-dev (which depends upon libvips7.8), a gap of a day or two should be left between uploading vips and uploading nip. A few final notes: I am on the [3] NM queue but have not yet been assigned an AM, so I have some time to go yet. I am currently maintaining the xerces packages (xerces23, xerces24, xerces25, and libxml-xerces-perl) as a member of the debian-sgml-xml group on alioth. I am listed as a co-maintainer of those packages, though I am presently the only person actively working on them. As for vips and nip, I am not associated with the packages in any way other than being a user. 3. http://nm.debian.org/nmstatus.php?email=ejb%40ql.org Thanks for your support. If no one steps up to sponsor these packages within a couple of days, I will ask two people who have sponsored uploads for me before, but I'm hoping someone who is interested in image manipulation software will take a look at these. I don't want to seem impatient, which is why I mention this up front. I'm only trying to act quickly because of the looming sarge freeze. :-) -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
RFS: vips/nip: quick demo so you'll see how good it is
her than 7.10.0. The new version of nip is now called nip2. It uses gtk2.0 instead of gtk+. I will package those in a few months when they are considered stable by upstream and have documentation. Clearly they will not be ready in time for sarge. I'm hoping someone will sponsor these packages and upload them soon. They need to be uploaded fairly quickly to make it into sarge. Any feedback on the packaging is, of course, appreciated so that if I need to make changes, there is still time. Since nip build depends upon libvips7.8-dev (which depends upon libvips7.8), a gap of a day or two should be left between uploading vips and uploading nip. A few final notes: I am on the [3] NM queue but have not yet been assigned an AM, so I have some time to go yet. I am currently maintaining the xerces packages (xerces23, xerces24, xerces25, and libxml-xerces-perl) as a member of the debian-sgml-xml group on alioth. I am listed as a co-maintainer of those packages, though I am presently the only person actively working on them. As for vips and nip, I am not associated with the packages in any way other than being a user. 3. http://nm.debian.org/nmstatus.php?email=ejb%40ql.org Thanks for your support. If no one steps up to sponsor these packages within a couple of days, I will ask two people who have sponsored uploads for me before, but I'm hoping someone who is interested in image manipulation software will take a look at these. I don't want to seem impatient, which is why I mention this up front. I'm only trying to act quickly because of the looming sarge freeze. :-) -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ 1.tif Description: TIFF image 2.png Description: PNG image Run nip & Insert -> Image From File Change file type from "VIPS image files" to "TIFF image files" select "1.tif" Insert -> Image From File Change file type from "VIPS image files" to "PNG image files" select "2.png" Double click the image portion of A2 to open the A2 image window CTRL-left click near the upper-left corner but stil in the gray drag all the way to the lower-right corner This creates A3 Close the A2 image window (File -> Quit, or use the window manager) Hold the mouse over A2. Notice A3 turns medium blue, showing child relationship Click on A3. Notice A2 turns dark blue, showing parent relationship Double-click on image portion of A1 to open A1 window Double-click on image portion of A3 to open A3 window In A1, CTRL-left click on some point that is common to the two images, for example somewhere on the "a". This creates point A4. In A3, CTRL-left click on APPROXIMATELY the same point. It doesn't need to be super-exact, so eyeballing it is okay. This creates point A5. Close A1 and A3. Now left click on the label "A4" and CTRL-left click on "A5" so that both labels are green. This is selecting these points as arguments. In the right-side menu, select Mosaic -> Mosaic_Translate -> Left_Right This creates image A6: a "stitched" version of the image. Double click A6 to open the A6 window CTRL-left click near the upper-left corner in the gray and drag to near the lower-right corner within the gray so the entire selected region is in the gray. This creates region A7. Close A6. Single click A7 so the label turns green. On the right-side menu, select Colour -> RGB_to -> Mono Click A8. In right menu, select Filter -> Emboss Right click A9, select Save..., type final.jpg Main menu -> File -> Save workspace: enter "potato", click "save" Exit (File -> Quit) Now look at final.jpg in your favorite viewer. Restart nip: nip potato.ws & There's your whole workspace again Double click A6 and A9. Move or the A7 region in A6. Watch A9 update dynamically!
getting packages to rebuild
This is a variant of a commonly asked question, but I'm still not able to find a clearly stated answer. three of my packages: http://packages.qa.debian.org/x/xerces23.html http://packages.qa.debian.org/x/xerces24.html http://packages.qa.debian.org/x/xerces25.html have all not entered testing because of being out of date on some architectures. In the case of xerces25, only arm is shown as out of date. In the case of xerces23 and xerces24, multiple architectures out of date. I have two questions: * On all three packages, the arm build failed because of an unsatisfiable build dependency that was the result of a timing problem. These should succeed now as the problem with the dependent package has been cleared. I emailed [EMAIL PROTECTED] to request these to be rebuilt. Is there anything else I have to do? Should I see out a DD to manually build these on arm and upload them before the freeze? * In xerces23 and xerces24, other architectures out of date, but their buildd logs show success. Why would they be out of date if they were built successfully? What can I do to resolve this? Thanks for any clarification. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Re: getting packages to rebuild
> > * On all three packages, the arm build failed because of an > >unsatisfiable build dependency that was the result of a timing > >problem. These should succeed now as the problem with the > >dependent package has been cleared. I emailed > >[EMAIL PROTECTED] to request these to be rebuilt. Is there > > In this case you don't have to do anything about arm for your package: > > http://www.buildd.net/cgi/package_status?all_pkg=xerces25&searchtype=go > > arm: libs/xerces25_2.5.0-2: Dep-Wait by buildd_arm-europa > [extra:out-of-date] > Dependencies: libicu28-dev > Previous state was Building until 2004 Jun 17 20:04:28 Okay, thanks. I had been looking at build logs and saw the maybe-failed but I didn't check the status. (I didn't know about this, though I had a bookmark to buildd.debian.net. Oops.) > BUT: > > arm: libs/icu28_2.8-3: Building by buildd_arm-netwinder > [optional:uncompiled] > Previous state was Needs-Build until 2004 Jun 13 02:33:44 > > You might want to check this out. It certainly isn't still > building. Did it fail? Should it be retried? Does it need bugsfixes? > Check for buildd logs and bugreports. Yes, it seems the most recent arm build failed, but yet the current icu28 (2.8-3) is in testing. Perhaps someone built it manually. There are no bugs posted again icu28. > Check buildd.net: > > arm: libs/xerces23_2.3.0-3: Dep-Wait by buildd_arm-europa > [extra:out-of-date] > > mips: libs/xerces23_2.3.0-3: Not-For-Us [extra:out-of-date] > mipsel: libs/xerces23_2.3.0-3: Installed by rmurray-repeat > [extra:out-of-date] > Those two puzzle me. Why does mipsel build on mipsel and every other > arch but is not-for-us on mips? Unless you have a good reason not to > support mips please mention that to our leader too. Hmm what does Not-For-Us mean? My packages all had either Architecture: any or Architecture: all, so I don't see why this would happen. > alpha: libs/xerces24_2.4.0-2: Needs-Build [extra:out-of-date] > > Not a big surprise there, just wait or fiond someone with an alpha to > build it manually. Is this just not a big surprise because of the much-discussed long backlog? > mips, mipsel, powerpc: libs/xerces24_2.4.0-2: Not-For-Us [extra:out-of-date] > > Why do you support even less archs? I'd like to know that too. I don't think it's anything I did. How would I find out? Thanks for your helpful and thorough response. --Jay
Re: getting packages to rebuild
> > Yes, it seems the most recent arm build failed, but yet the current > > icu28 (2.8-3) is in testing. Perhaps someone built it manually. > > There are no bugs posted again icu28. > > In testing but not in unstable for arm? Or in testing without arm > support? Hmm. In testing and unstable without arm support. How does this happen? The debian/control says Architecture: all for relevant packages. I don't see any mention of xerces or icu in http://www.buildd.net/buildd/Packages-arch-specific. > > Hmm what does Not-For-Us mean? My packages all had either > > Architecture: any or Architecture: all, so I don't see why this would > > happen. > > http://people.debian.org/~wouter/wanna-build-states There's a lot of information hidden beneath the surface, it seems. Is there a place through which I could have discovered this, other than asking on debian-mentors? :-) > http://www.buildd.net/buildd/Packages-arch-specific is a global list > for such packages while buildd admins can put packages into the > not-for-us state for a single arch which seems to be your case. > > You need to talk to the mips buildd admin to revert that. I'm not seeing xerces or icu packages in these lists. Am I missing something? yes. > >> mips, mipsel, powerpc: libs/xerces24_2.4.0-2: Not-For-Us > [extra:out-of-date] > >> > >> Why do you support even less archs? > > > > I'd like to know that too. I don't think it's anything I did. How > > would I find out? > > Ask the buildd admins since its not on the global list. And how would I go about asking the buildd admins? Is there a list for this? Are there specific people whose email addresses I should use? Sorry if I'm being thick-headed about this, but this seems to be one area where documentation is (uncharacteristically) sparse. --Jay
Re: getting packages to rebuild
> > http://people.debian.org/~wouter/wanna-build-states
>
> There's a lot of information hidden beneath the surface, it seems. Is
> there a place through which I could have discovered this, other than
> asking on debian-mentors? :-)
Answering my own question, I see a link to this in buildd.net.
> > Ask the buildd admins since its not on the global list.
>
> And how would I go about asking the buildd admins? Is there a list
> for this? Are there specific people whose email addresses I should
> use? Sorry if I'm being thick-headed about this, but this seems to be
> one area where documentation is (uncharacteristically) sparse.
I sent email to {mips,mipsel,[EMAIL PROTECTED] Is this
correct?
--Jay
Re: RFD: take over packages
>I was writing to Ivo Timmermans[1] that I would like to continue with some > of his packages, as he has not updated them for a while. They are music > players (mean: binary, libs) for C64 music formats, ie: SID emulator. > He said it is OK for him, but when I have updated the packages, fixed bugs, > uploaded to mentors.debian.net, I have lost contact with him. In this > scenario, given the facts that Sarge is coming, and I have fixed FTBFS > bugs with gcc 3.4, would it be a good reason to ask an other DD to > upload the packages? I do not want to hijack them, but I don't want to > sit tight and just see that the packages are not fixed for Sarge. :( > What do mentors think about this? > > Thanks, > Laszlo/GCS > [1] [EMAIL PROTECTED] If Ivo gave you explicit permission to do this and isn't responding, you are within your right to ask someone else to sponsor the uploads, but you should keep Ivo in the loop. If something is about to happen that he objects to, he can take some action. I think this is a good general rule, but I have done this specifically with packages maintained by Ivo and in my experience, although unresponsive at times, he is supportive and good to work with. --Jay
request removal of vips7.8 and nip from mentors.debian.net
I tried sending a request for the removal of vips7.8 and nip from mentors.debian.net by sending mail to [EMAIL PROTECTED] However, it appears that mail to the mentors.debian.net domain is not working and hasn't been for at least a few days: % host -t mx mentors.debian.net mentors.debian.net is an alias for mentors.workaround.org. mentors.workaround.org isn't answering on the smtp port though it is answering on http and ssh. Is sending mail to [EMAIL PROTECTED] still the preferred way to request removal of packages from mentors.debian.net? I'm requesting removal of these packages because someone has agreed to sponsor them for upload into the archive, and I want to tweak the description from what's there on mentors. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
advice about splitting a package (libtiff-tools)
The libtiff package (upstream) includes one program, tiffgt, that requires opengl. The current version of libtiff in debian installs tiffgt's manual page but does not install tiffgt. (This is bug 219456.) I have built new libtiff packages that create tiffgt, which seems like a reasonable program to include. I have two packaging choices, both of which I have successfully implemented, but I wanted some opinions on which way was better. 1. Just add the necessary libraries to Build-Depends so that tiffgt gets built. This is the easiest solution, but it has the disadvantage of having libtiff-tools get a bunch of extra dependencies (X and opengl libraries) just to support one program. 2. Split libtiff-tools into libtiff-tools and libtiff-opengl, where the latter contains only tiffgt and its manual page. This is also really easy, but there's one catch: older versions of libtiff-tools already include the manual page for tiffgt, which means libtiff-opengl must conflict with versions of libtiff-tools that are older than this new version. This means that someone installing libtiff-opengl without first upgrading libtiff-tools will have libtiff-tools REMOVED. To work around this, I could make libtiff-opengl require libtiff-tools >= the minimum version instead of making it conflict with the old version, but I don't want to do this because libtiff-opengl doesn't actually depend upon libtiff-tools. So, should I include tiffgt in libtiff-tools and just not worry about all the new dependencies, or should I deal with this short-lived but annoying problem of people possibly installing libtiff-opengl without first upgrading libtiff-tools and losing libtiff-tools as a result? Most people will have all those libraries on their systems anyway, and I suspect not many people running systems without X will bother with libtiff-tools. Thanks for any advice. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Re: advice about splitting a package (libtiff-tools)
I think I'll reply to my own post. I brought this up on IRC and was pointed to a better solution. > The libtiff package (upstream) includes one program, tiffgt, that > requires opengl. The current version of libtiff in debian installs > tiffgt's manual page but does not install tiffgt. (This is bug > 219456.) I have built new libtiff packages that create tiffgt, which > seems like a reasonable program to include. I have two packaging > choices, both of which I have successfully implemented, but I wanted > some opinions on which way was better. > >1. Just add the necessary libraries to Build-Depends so that tiffgt >gets built. This is the easiest solution, but it has the >disadvantage of having libtiff-tools get a bunch of extra >dependencies (X and opengl libraries) just to support one >program. > >2. Split libtiff-tools into libtiff-tools and libtiff-opengl, where >the latter contains only tiffgt and its manual page. This is >also really easy, but there's one catch: older versions of >libtiff-tools already include the manual page for tiffgt, which >means libtiff-opengl must conflict with versions of libtiff-tools >that are older than this new version. This means that someone >installing libtiff-opengl without first upgrading libtiff-tools >will have libtiff-tools REMOVED. To work around this, I could >make libtiff-opengl require libtiff-tools >= the minimum version >instead of making it conflict with the old version, but I don't >want to do this because libtiff-opengl doesn't actually depend >upon libtiff-tools. > > So, should I include tiffgt in libtiff-tools and just not worry about > all the new dependencies, or should I deal with this short-lived but > annoying problem of people possibly installing libtiff-opengl without > first upgrading libtiff-tools and losing libtiff-tools as a result? > Most people will have all those libraries on their systems anyway, and > I suspect not many people running systems without X will bother with > libtiff-tools. Use Replaces instead of Conflicts. This will enable the new libtiff-opengl to overwrite and claim ownership of tiffgt.1.gz. Since Replaces will appear without Conflicts, libtiff-tools won't get removed. When it gets upgraded, tiffgt.1.gz will not be removed. Once libtiff-opengl is installed, it will no longer be possible to install an older version of libtiff-tools, but I don't consider that to be important. > Thanks for any advice. You're welcome. Actually, thank doogie on IRC. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Re: testing config/preinst mods
> > For config scripts, in the absence of something pre-existing, one > > approach that looks like it would work pretty easily would be to > > replace apt-extracttemplates (which is called by dpkg-preconfigure) > > with something that would check a magic directory for replacement > > scripts for a package and use those instead of the real ones if they > > exist. > > I have never heard of something like this - but it would be simply > great! Not only that it would make testing easier, but also because if > some strange bug is reported, one could put debugging code at the right > places of the script, send it to the bug submitter and ask him to make > dpkg use it. I had a couple of hours over the weekend to implement and test this. I used it today to create patches for two outstanding bugs including three merged release-critical bugs against console-common. I'll post my solution to debian-devel today with the subject "testing config/preinst mods: one approach". -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
testing config/preinst mods
Is there a preferred or easy way to test proposed modifications to maintainer scripts, particularly config and preinst scripts which are run before the package is installed, on existing built packages at the time of installation? There is a small handful of config/preinst bugs that I'd like to try to fix and that would require modifying config or preinst scripts. For config scripts, in the absence of something pre-existing, one approach that looks like it would work pretty easily would be to replace apt-extracttemplates (which is called by dpkg-preconfigure) with something that would check a magic directory for replacement scripts for a package and use those instead of the real ones if they exist. Then if I wanted to mess around with editing config scripts, I could run apt-extracttemplates by hand, copy the resulting files into this directory, and edit them freely. Then the next time I install the package (after dpkg --purge) I'll see the modified scripts instead. Something similar could probably be done for preinst though I haven't looked at exactly where in the process this happens. For what it's worth, I've also looked at running scripts by hand with /usr/bin/debconf, but that doesn't solve the whole problem. For example, debconf-devel(7) discusses using debconf-loadtemplate and running scripts by hand with debconf(1), but this addresses only debconf issues, not other issues with config or preinst scripts. Gratuitous comments: I'm posting this question to debian-mentors because I think it's too far toward development to post to debian-users, and too much of a newbie question for debian-devel. It seems like this is something that most developers who maintain packages with configure scripts would probably have to do from time to time, so it seems worth asking before reinventing the wheel. If you think I've misjudged where to ask this question, I'd like to know. Also, I've looked in various documents for an answer to this question and haven't found anything. If this issue is spelled out somewhere, a pointer would be appreciated. The apt.conf and debconf-devel documentation have lots of hints, but nothing that looks easier than the approach I'm planning on trying. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: patmv -- a bulk renaming tool
I'd like to request a sponsor for my "patmv" package. patmv is a Perl
script that can be used to do bulk renames on files based on a Perl
expression ("pattern"). I've been using this script for about 10
years, and it has a small following among current and former
co-workers. The idea was inspired by a short example that was
included with perl 5.000 or one of its betas, but my script is an
expansion on the original concept.
You can retrieve the package from mentors.debian.net. They are
lintian and linda clean and they build in pbuilder. I have read the
policy, social, contract, etc. and have had my key signed by Debian
developers. I've also completed more substantive and complex
packaging tasks and have read Matthew Palmer's sponsorship FAQ at
http://people.debian.org/~mpalmer/sponsorship.html. I have not
created an ITP though since, prior to this weekend, this script was
not packaged and pretty much only existed on machines that I could log
into.
The patmv program is most useful to people who have to deal with
sanitizing names on large groups of files. It's one of our must-have
tools when dealing with receipt of batches of data from our clients.
It helps to have some Perl knowledge, but anyone who can use sed can
use patmv, and the manual page gives plenty of examples that people
can modify.
The idea is simple: patmv takes an expression that operates on $_ as a
command-line argument. For each file, it evals the expression with
the last component or whole filename (depending on options) set to
$_. If the operation changes the name, a rename is done. patmv is
intelligent about keeping track of intermediate steps, making it safe
to use in cases where directories get renamed before their contents.
It can take lists of file names on the command line or read them from
stdin, one file per line.
Here are a few quick examples:
To change all spaces to underscores recursively in "Some Directory":
find "Some Directory" -print | patmv 's/ /_/g'
To change the names of all the files in the current directory to lower
case:
patmv tr/A-Z/a-z/ *
To forcibly overwrite all files named whatever with any files named
whatever.new:
patmv -f 's/\.new$//' *.new
and so forth.
The version I uploaded is version 1.0. Although the code is very
thoroughly tested (both by the included automated test suite and by
years of daily use), this is the first time I've made a public
release.
I'd be eager for your consideration and any comments.
Oh, one note: there are no differences at all between the upstream
version and the Debian version: the debian files (and an rpm .spec
file) are both included in the upstream sources. Based on a
discussion on debian-devel, however, I've decided to not package this
as native. Therefore, there is a .orig.tar.gz and a .diff.gz, even
though the .diff.gz is empty (well, actually the result of running
gzip on an empty file), and the Debian revision is 1. I thought I'd
mention this so that it was clear that I did it this way on purpose.
--
Jay Berkenbilt <[EMAIL PROTECTED]>
http://www.ql.org/q/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: patmv -- a bulk renaming tool
> > I'd like to request a sponsor for my "patmv" package. patmv is a Perl
> > script that can be used to do bulk renames on files based on a Perl
> > expression ("pattern"). I've been using this script for about 10
> > years, and it has a small following among current and former
> > co-workers. The idea was inspired by a short example that was
> > included with perl 5.000 or one of its betas, but my script is an
> > expansion on the original concept.
>
> Can you clarify what the difference is between this script and the
> 'rename' script currently including in the Debian perl package?
> All of the examples you gave, as far as I can tell, would work
> just as well with the 'rename' that is already in Debian.
Hmm. Looks like rename and patmv have the same common ancestor. I
didn't realize this already existed, though I tried digging for it in
the perl sources. (I didn't know what it was called, and I didn't
think to look in the debian/ directory which is where rename is in the
Debian perl distribution.)
There are several differences, though: patmv has logic to handle
recursive renames in an intelligent way and has options for
manipulating the whole path or the last component as an option. In my
opinion, it also handles file existence cases more robustly and
generates more useful output.
% mkdir -p z
% cd z
With rename:
% mkdir WORK; touch WORK/{1,2,3}.TXT
% rename -v tr/A-Z/a-z/ `find WORK -print`
WORK renamed as work
Can't rename WORK/1.TXT work/1.txt: No such file or directory
Can't rename WORK/2.TXT work/2.txt: No such file or directory
Can't rename WORK/3.TXT work/3.txt: No such file or directory
With patmv:
% rm -rf work
% mkdir WORK; touch WORK/{1,2,3}.TXT
% patmv tr/A-Z/a-z/ `find WORK -print`
mv WORK work
mv work/1.TXT work/1.txt
mv work/2.TXT work/2.txt
mv work/3.TXT work/3.txt
patmv generates output that could be re-executed if needed (though
I've seldom used this feature) and that handles the need for quoting
intelligently:
% touch "Someone's Goofy Filename"
% patmv "tr/A-Z '/a-z_-/" S*
mv 'Someone'\''s Goofy Filename' someone-s_goofy_filename
patmv handles existing file names by prompt the user unless it can't
(in which case it fails without overwriting) or --force is given (in
which case it just renames the file):
% touch 1 2
% rename s/1/2/ 1
1 not renamed: 2 already exists
% patmv s/1/2/ 1
2 exists. Overwrite? y
mv 1 2
patmv can read files from stdin as well as taking files on the
command-line. For example, one could convert a large RCS-based source
tree to a CVS repository with something like (untested):
% find . -type f -name '*,v' | grep RCS/ > /tmp/1
% tar -c --files-from /tmp/1 -f - | (cd /my/cvs-repo; tar xf -)
% cd /mn/cvs-repo
% find . -type f -print | patmv -w s,RCS/,,
My copyright says that the software can be redistributed and used for
any purpose, which is less restrictive than the Aristic license. At
the time I wrote my version of the script, I wrote it from scratch
without using any of the original example code which was only a few
lines long anyway. I could probably be convinced to use the Artistic
license, though for something so short, I see no need to maintain any
kind of artistic control. (I don't view myself as having violated the
original copyright since I didn't use any of the code and since the
idea was so simple, but if you disagree, by all means let me know.)
--Jay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: patmv -- a bulk renaming tool
> > There are several differences, though: patmv has logic to handle > > recursive renames in an intelligent way and has options for > > manipulating the whole path or the last component as an option. In my > > opinion, it also handles file existence cases more robustly and > > generates more useful output. > > Your examples are persuasive that patmv has some advantages over Perl's > rename. I wonder whether it might be worthwhile to see if patmv could > replace rename in the perl package, though, since it appears to be > intended for an identical purpose. > > I suppose on the other hand people might be more aware that the program > exists at all by virtue of a separate package. I would prefer it to be a separate package. I've released it from my personal software website and have also made a Red Hat package (for my less enlightened friends have haven't switched yet ;-]). Also, "rename" isn't actually part of the upstream Perl package -- it's added in Debian by the patch. In fact, Red Hat distributions also have a "rename" command that does something different. There's no real reason why patmv should be part of Perl either. Although it was definitely inspired by a Perl example, it has, in my opinion, enough functionality to be a separate package in its own right (in addition to the good point you make about awareness). Also, by having it be a separate package, enhancements or bug fixes can be made without having to re-release Perl. (I have every intention of becoming a DD, though I know this takes some time.) Although I failed to mention this in my initial post, the thing that pushed me over the edge and made me decide to submit this package for sponsorship was the recent inclusion of the "renameutils" package, which I learned about in the Debian Weekly News[1] new package list. 1. http://www.debian.org/News/weekly/2004/16/ I feel that patmv is no more special-purpose than renameutils (which is in its own package) and serves a different cross section of the Debian user community. > I might be willing to sponsor it; let me think about it a bit. I appreciate your consideration. So that I don't have to come across as nagging, can you give me some kind of timeframe within which you expect to respond? If I don't hear anything within that timeframe, I'll post a second RFS request. :-) Thanks! -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: patmv -- a bulk renaming tool
> Jay Berkenbilt wrote: > > Although I failed to mention this in my initial post, the thing that > > pushed me over the edge and made me decide to submit this package for > > sponsorship was the recent inclusion of the "renameutils" package, > > which I learned about in the Debian Weekly News[1] new package list. > Ah. The only thing that kept me from suggesting the same for patmv as > for pdfmerge was that I didn't know which package is would well fit in. > Thanks for taking care of that. > So: I suggest you submit it for addition to renameutils. > As a side effect, renameutils and your package get a comaintainer. Thanks for the suggestion. My preference would still be to have patmv as its own package as I think patmv and renameutils have different audiences. Also, patmv has its own life outside of perl or renameutils. My point about renameutils was only that the fact that this package was recently included into Debian convinced me that there was a place for something small and special-purpose like my patmv command. As for comaintainership, that's always a good idea, but I've changed patmv about four times in 10 years, so I don't think it will generate too much activity. :-) --Jay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: patmv -- a bulk renaming tool
strength of my conviction on this point. I truly appreciate the suggestions and the implication of interest that they imply. Thanks again for listening. Please let me know if I you are still planning on looking at patmv and considering sponsoring it. Thanks. --Jay -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
withdrawing RFS for patmv (was RFS: patmv -- a bulk renaming tool)
> Tiny packages are generally frowned upon in Debian since they > unnecessarily bloat the Packages file. So, small scripts like yours > tend to be collected into a single package with other related scripts. > > If everyone packaged their pet scripts into separate packages, the > already very large number of packages in Debian would grow enormously. Your arguments and those of others have persuaded me to withdraw my RFS for patmv. For now, I'll just put the Debian package for patmv on my personal site along with a handful of other small tools that are useful enough to share with a wider audience than their current user base. If someone else decides that it's worth including in renameutils, I have no objection. I'll likel contact the remameutils maintainers and let them know about it, at least as a more advanced alternative to the rename program that is packaged with Perl. Please understand that I'm not withdrawing this because I feel bitter or disappointed, but because I genuinely agree with the arguments. My thinking prior to submitting my RFS was that, if a reasonable package had been debianized, it made sense to submit it for inclusion in the distribution where it would be easy to find and install. I now feel that it's better to wait until the package has a wider user base or serves some important purpose not served by other packages. (This seems obvious in retrospect.) I'm sure I'm not alone, especially among relative newcomers to Debian, in not even having read the names of all the available packages, let alone knowing what they all do. Although it's great to be able to install just about anything I know about with apt-get install (rather than search all over the place for, say, an rpm that may or may not coexist peacefully with other packages), I completely acknowledge that patmv is not something anyone will come looking for. Thanks again for the responses and interest! -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upload of a new package
> Hi, > I'm the mantainer of phpldapadmin, a web-based tool for managing ldap > servers. I'm not (yet!) an official Debian developer, so I asked for a > sponsor. He checked my package and uploaded in the unstable debian > archive about ten days ago... > > Here my questions: > - how long takes the verification process and when will be the package > available in unstable? How can I monitor the state of the package? > > - A new minor upstream version is available for the package, my sponsor > told me it is better to wait the package enters in unstable before > send the new version, because every upload before this happens "reset > the timer" and I have to wait more time to see my package in unstable. > > I'm not in this list, so if you answer please CC me. > > Thanks a lot, > Fabio. As a point of comparison, I'm helping with maintenance of the xerces packages and had xerces25 (new) uploaded by a sponsor. The package was initially uploaded on May 4 and appeared in unstable on May 18. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /etc/init.d/ script policy violation?
> > One question I have however, is should it be a policy violation if a > > script hangs waiting for user input? Perhaps the policy document > > should be updated to explicitly deal with this case? > > If it does wait on input (or might) it should start afte, ssh, pcmcia, > hotplug and networking. Thus allowing acces to the "hanging" machine > even with pcmcia network cards. This is true only as long as DELAYLOGIN=no in /etc/default/rcS or rmnologin is moved earlier as well. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: setgid-wrapper
> My understanding of the position of Bob and Mike can be summed up as,
> "in general, shell script's can't be made to use setuid/setgid
> securely". Basically, the problem comes down that a user can manipulate
> their PATH to redefining basic commands that are used by the shell
> scripts (like "ls") in order to elevate their privileges.
>
> I'm not willing to give up on the basic idea yet, however, as I still
> need to run a Java program setgid to "games" to handle a score history
> file. Similarly, I hope to one day run a Java application server (e.g.
> Tomcat, JBoss, or Geronimo) setuid to some system id. Therefore I
> humbly request your comments on how to salvage this idea. Please keep
> in mind that "/usr/bin/java" is, itself, almost certainly a script.
I missed the original discussion, so I risk saying something someone
has already said. My strategy for dealing with setuid/setgid shell
scripts in general is always to use sudo (which mdz mentioned as an
example of controlling elevation of privileges). I abandoned wrappers
in favor of this long ago. sudo is easy to set up, and it explicitly
moves responsibility to the local administrator. My standard approach
is to name my script whatever.real and have a wrapper that runs sudo.
For example, I allow certain users on some of my systems to create
accounts with adduser. I have renamed adduser to adduser.real and
created the following adduser script:
#!/bin/sh
echo "If prompted, enter your password to enter user creation program."
exec sudo $0.real ${1+"$@"}
Use of $0.real here is okay because the sudoers file has the full path
to the program that the user is authorized to run. (Anyway, the user
can always run sudo by hand.) I also set the permissions on the
whatever.real script to 0750 or 0700. Now if I want to control this
with a group or just a list of authorized users, I can do that in
sudoers. Although my home-written adduser script could certainly be
exploited by a knowledgeable user, I trust the people who are
authorized to create accounts on my systems, so I'm willing to accept
that risk in this instance.
As for the specific example of writing to a high scores file, I would
assert that this functionality is not essential to the proper
functioning of the game, and you should make the game work with or
without this functionality. That way, if whatever strategy you choose
for updating the high scores file is overridden by the local
administrator, the game will still work. I wouldn't make the whole
game setgid just so it can write to its high score file. I would do
one of two things instead: make the high score file world-writable and
put it in a non-world-writable directory (some may object to
world-writable files on a system partition), or create a separate
program that your main program communicates to whose sole purpose in
life is to update the high scoring program. This can be a normal
compiled C or C++ program. You can create a debconf question that
explains to the installer that this component of the application needs
to be installed setgid games to update its high scoring file and ask
the user whether to do this, explaining the potential security risks,
and have the default be "no". You can look at man-db
(dpkg-reconfigure man-db) for example of how you might want to word
this.
--
Jay Berkenbilt <[EMAIL PROTECTED]>
http://www.ql.org/q/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Feedback wanted: audacity 1.2.1-3
> I have recently reworked some of the packaging scripts for "audacity". > The package now uses CDBS and debhelper more extensively. I would > appreciate it if anyone can take a look at the package and provide > suggestions or feedback. This package installs its help file, audacity-1.2-help.htb, in /usr/share/doc/audacity. Since this isn't a human-readable file (or, more accurately, a file intended to be read manually by the user), I wonder whether that's really the right place for it. I see it's put in that location explicitly by the Makefile, so it would be there on any system, even one which doesn't follow Debian's conventions on use of /usr/share/doc. I would think /usr/share/audacity would be a better location for the help file, but I could be off base here. (For this reason, I cc my reply to debian-mentors, giving someone else the chance to contradict me.) Otherwise, this looks like a nice cbds example. :-) I'm not a DD (yet?), but that's my $0.01. (I didn't say enough to be worth $0.02 ;-]). That's for helping to create audacity. I've been a light audacity user since before 1.0. It just keeps getting better. It also was the tool that introduced me to wxWidgets (f.k.a. wxWindows) which I use for my own GUI development now. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages.qa.d.o bug?
>I maintain cvs2svn, and my sponsor uploaded a new version of the > package four days ago. Still, "Testing Status" shows the previous > package: "* 21 days old (needed 10 days); * Valid candidate" etc. > Is this known, or should I file a bugreport? Skimming over 'general' > bugs in BTS does not show anything relevant. In your package status package: http://packages.qa.debian.org/c/cvs2svn.html You'll see, under "Problems", that the package has not entered testing even though the 10-day delay is over. Click on "Check why" there to see the reasons. http://bjorn.haxx.se/debian/testing.pl?package=cvs2svn You'll see that this is blocked by subversion which in turn is blocked by perl. Lots of things are blocked by perl, but there appears to be active effort in resolving that issue. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
two new packages, one depends upon the other
Suppose I have two packages: A and B where B depends and build depends upon A. Neither package has been uploaded before. I can easily build A in pbuilder using pdebuild, but I can't do the same with B because B build depends upon A and A is not in the archive (thereby causing pbuilder-satisfydepends to fail). I have gotten around this by using pbuilder login, installing A's debs manually, running pbuilder-satisfydepends, and then run dpkg-buildpackage, but I'm wondering whether there is a better/usual way to do this. Any suggestions would be welcome. Also, when A and B are ready to be uploaded into unstable, I am assuming that, as long as A is uploaded first, there's no reason not to upload them together. Of course, B won't be able to built from source until its build dependencies can be satisfied, which won't happen until A is built. Would it be useful to wait a few days between uploading A and B? If B fails to build from source, is it the case that manual intervention is then required to get it to retry, or does this happen automatically? Thanks again for any clarification. The actual situation is a set of development libraries and command-line tools in one source package that creates four binary packages (runtime, dev, doc, and tools) and then a separate graphical front end that depends on the runtime and build-depends on the dev. I'll be posting an RFS for these packages probably within the next day or so. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: two new packages, one depends upon the other
> > Suppose I have two packages: A and B where B depends and build depends > > upon A. Neither package has been uploaded before. I can easily build > > A in pbuilder using pdebuild, but I can't do the same with B because B > > build depends upon A and A is not in the archive (thereby causing > > pbuilder-satisfydepends to fail). I have gotten around this by using > > pbuilder login, installing A's debs manually, running > > pbuilder-satisfydepends, and then run dpkg-buildpackage, but I'm > > wondering whether there is a better/usual way to do this. Any > > suggestions would be welcome. > > You can always add your own repository to the /etc/pbuilderrc. > If you don't have time to create your own, you can use mentors.debian.net, > that's what I do usually. That's so obvious I completely overlooked it. :-) Thanks! It worked perfectly. I already have a local repository, so I just copied these packages into it, reran dpkg-scanpackages, and added it to /etc/pbuilderrc in OTHERMIRROR. It worked perfectly (after I ran pbuilder update --config-override). > > If B fails to build from source, is it > > the case that manual intervention is then required to get it to retry, > > or does this happen automatically? Thanks again for any > > clarification. > > That depends on the reason of not-building. What reasons do you expect? Only not waiting long enough between uploading A and B. Probably nothing to worry about. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: vips and nip
I have packaged [1] vips and nip. The packages can be found on mentors.debian.net (details follow). All packages are lintian clean and were built in an up-to-date pbuilder environment. I have locally installed and tested the packages. 1. http://www.vips.ecs.soton.ac.uk The following introductory text, largely lifted from the vips web site, briefly describes the software: VIPS is a free image processing system. It is good with large images (images larger than the amount of RAM in your machine), and for working with colour. VIPS consists of two main components: an image processing library, and a spreadsheet-like graphical user interface, available in the nip package. The nip program is really quite remarkable, and has functionality unlike what I've seen any other packages. This is most certainly not just another image viewer or manipulation program. With this program, you can form complex pipelines of image operations using a spreadsheet-like user interface. The resulting images are updated dynamically as parameters are changed. One of the more interesting features here is mosaic assembly. I have used this successfully to create "seamless" scanned images out of parts scanned on my 8.5x11 flatbed scanner. Also, nip can work on very large images and is quite efficient. I was able to do manipulations on 9 300-dpi 24-bit color 8.5 x 11 images simultaneously without any observable lag. I have discussed my interest in packaging vips and nip for Debian with the upstream maintainers, who are enthusiastic about this possibility. There are packages for vips and nip for some other distributions including gentoo. An [2] RFS for this package already existed. I retitled the RFS to an ITP and posted a little bit of additional information. 2. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=188478 There are two source packages: vips7.8 and nip. The vips7.8 package creates four binary packages (shown here with their i386 names): libvips7.8-dev_7.8.14-1_i386.deb libvips7.8-doc_7.8.14-1_all.deb libvips7.8-tools_7.8.14-1_i386.deb libvips7.8_7.8.14-1_i386.deb The nip package creates a single binary package: nip_7.8.14-1_i386.deb The vips package has the version number built into the package name because it creates and installs a shared library. Unfortunately, the library version is 0.0.0, but the upstream maintainers have fixed this and are now using sensible shared library naming conventions. To my knowledge, they are not using versioned symbols, though I may take this issue up with them (particularly after this whole tiff fiasco). vips 7.10.0 is out, but it is considered a beta release. The upstream maintainers expressed a preference for having 7.8.14 packaged for Debian for now rather than 7.10.0. The new version of nip is now called nip2. It uses gtk2.0 instead of gtk+. I will package those in a few months when they are considered stable by upstream and have documentation. Clearly they will not be ready in time for sarge. I'm hoping someone will sponsor these packages and upload them soon. They need to be uploaded fairly quickly to make it into sarge. Any feedback on the packaging is, of course, appreciated so that if I need to make changes, there is still time. Since nip build depends upon libvips7.8-dev (which depends upon libvips7.8), a gap of a day or two should be left between uploading vips and uploading nip. A few final notes: I am on the [3] NM queue but have not yet been assigned an AM, so I have some time to go yet. I am currently maintaining the xerces packages (xerces23, xerces24, xerces25, and libxml-xerces-perl) as a member of the debian-sgml-xml group on alioth. I am listed as a co-maintainer of those packages, though I am presently the only person actively working on them. As for vips and nip, I am not associated with the packages in any way other than being a user. 3. http://nm.debian.org/nmstatus.php?email=ejb%40ql.org Thanks for your support. If no one steps up to sponsor these packages within a couple of days, I will ask two people who have sponsored uploads for me before, but I'm hoping someone who is interested in image manipulation software will take a look at these. I don't want to seem impatient, which is why I mention this up front. I'm only trying to act quickly because of the looming sarge freeze. :-) -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
getting packages to rebuild
This is a variant of a commonly asked question, but I'm still not able to find a clearly stated answer. three of my packages: http://packages.qa.debian.org/x/xerces23.html http://packages.qa.debian.org/x/xerces24.html http://packages.qa.debian.org/x/xerces25.html have all not entered testing because of being out of date on some architectures. In the case of xerces25, only arm is shown as out of date. In the case of xerces23 and xerces24, multiple architectures out of date. I have two questions: * On all three packages, the arm build failed because of an unsatisfiable build dependency that was the result of a timing problem. These should succeed now as the problem with the dependent package has been cleared. I emailed [EMAIL PROTECTED] to request these to be rebuilt. Is there anything else I have to do? Should I see out a DD to manually build these on arm and upload them before the freeze? * In xerces23 and xerces24, other architectures out of date, but their buildd logs show success. Why would they be out of date if they were built successfully? What can I do to resolve this? Thanks for any clarification. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: getting packages to rebuild
> > * On all three packages, the arm build failed because of an > >unsatisfiable build dependency that was the result of a timing > >problem. These should succeed now as the problem with the > >dependent package has been cleared. I emailed > >[EMAIL PROTECTED] to request these to be rebuilt. Is there > > In this case you don't have to do anything about arm for your package: > > http://www.buildd.net/cgi/package_status?all_pkg=xerces25&searchtype=go > > arm: libs/xerces25_2.5.0-2: Dep-Wait by buildd_arm-europa [extra:out-of-date] > Dependencies: libicu28-dev > Previous state was Building until 2004 Jun 17 20:04:28 Okay, thanks. I had been looking at build logs and saw the maybe-failed but I didn't check the status. (I didn't know about this, though I had a bookmark to buildd.debian.net. Oops.) > BUT: > > arm: libs/icu28_2.8-3: Building by buildd_arm-netwinder [optional:uncompiled] > Previous state was Needs-Build until 2004 Jun 13 02:33:44 > > You might want to check this out. It certainly isn't still > building. Did it fail? Should it be retried? Does it need bugsfixes? > Check for buildd logs and bugreports. Yes, it seems the most recent arm build failed, but yet the current icu28 (2.8-3) is in testing. Perhaps someone built it manually. There are no bugs posted again icu28. > Check buildd.net: > > arm: libs/xerces23_2.3.0-3: Dep-Wait by buildd_arm-europa [extra:out-of-date] > > mips: libs/xerces23_2.3.0-3: Not-For-Us [extra:out-of-date] > mipsel: libs/xerces23_2.3.0-3: Installed by rmurray-repeat [extra:out-of-date] > Those two puzzle me. Why does mipsel build on mipsel and every other > arch but is not-for-us on mips? Unless you have a good reason not to > support mips please mention that to our leader too. Hmm what does Not-For-Us mean? My packages all had either Architecture: any or Architecture: all, so I don't see why this would happen. > alpha: libs/xerces24_2.4.0-2: Needs-Build [extra:out-of-date] > > Not a big surprise there, just wait or fiond someone with an alpha to > build it manually. Is this just not a big surprise because of the much-discussed long backlog? > mips, mipsel, powerpc: libs/xerces24_2.4.0-2: Not-For-Us [extra:out-of-date] > > Why do you support even less archs? I'd like to know that too. I don't think it's anything I did. How would I find out? Thanks for your helpful and thorough response. --Jay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: getting packages to rebuild
> > Yes, it seems the most recent arm build failed, but yet the current > > icu28 (2.8-3) is in testing. Perhaps someone built it manually. > > There are no bugs posted again icu28. > > In testing but not in unstable for arm? Or in testing without arm > support? Hmm. In testing and unstable without arm support. How does this happen? The debian/control says Architecture: all for relevant packages. I don't see any mention of xerces or icu in http://www.buildd.net/buildd/Packages-arch-specific. > > Hmm what does Not-For-Us mean? My packages all had either > > Architecture: any or Architecture: all, so I don't see why this would > > happen. > > http://people.debian.org/~wouter/wanna-build-states There's a lot of information hidden beneath the surface, it seems. Is there a place through which I could have discovered this, other than asking on debian-mentors? :-) > http://www.buildd.net/buildd/Packages-arch-specific is a global list > for such packages while buildd admins can put packages into the > not-for-us state for a single arch which seems to be your case. > > You need to talk to the mips buildd admin to revert that. I'm not seeing xerces or icu packages in these lists. Am I missing something? yes. > >> mips, mipsel, powerpc: libs/xerces24_2.4.0-2: Not-For-Us [extra:out-of-date] > >> > >> Why do you support even less archs? > > > > I'd like to know that too. I don't think it's anything I did. How > > would I find out? > > Ask the buildd admins since its not on the global list. And how would I go about asking the buildd admins? Is there a list for this? Are there specific people whose email addresses I should use? Sorry if I'm being thick-headed about this, but this seems to be one area where documentation is (uncharacteristically) sparse. --Jay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: getting packages to rebuild
> > http://people.debian.org/~wouter/wanna-build-states
>
> There's a lot of information hidden beneath the surface, it seems. Is
> there a place through which I could have discovered this, other than
> asking on debian-mentors? :-)
Answering my own question, I see a link to this in buildd.net.
> > Ask the buildd admins since its not on the global list.
>
> And how would I go about asking the buildd admins? Is there a list
> for this? Are there specific people whose email addresses I should
> use? Sorry if I'm being thick-headed about this, but this seems to be
> one area where documentation is (uncharacteristically) sparse.
I sent email to {mips,mipsel,[EMAIL PROTECTED] Is this
correct?
--Jay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFD: take over packages
>I was writing to Ivo Timmermans[1] that I would like to continue with some > of his packages, as he has not updated them for a while. They are music > players (mean: binary, libs) for C64 music formats, ie: SID emulator. > He said it is OK for him, but when I have updated the packages, fixed bugs, > uploaded to mentors.debian.net, I have lost contact with him. In this > scenario, given the facts that Sarge is coming, and I have fixed FTBFS > bugs with gcc 3.4, would it be a good reason to ask an other DD to > upload the packages? I do not want to hijack them, but I don't want to > sit tight and just see that the packages are not fixed for Sarge. :( > What do mentors think about this? > > Thanks, > Laszlo/GCS > [1] [EMAIL PROTECTED] If Ivo gave you explicit permission to do this and isn't responding, you are within your right to ask someone else to sponsor the uploads, but you should keep Ivo in the loop. If something is about to happen that he objects to, he can take some action. I think this is a good general rule, but I have done this specifically with packages maintained by Ivo and in my experience, although unresponsive at times, he is supportive and good to work with. --Jay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
request removal of vips7.8 and nip from mentors.debian.net
I tried sending a request for the removal of vips7.8 and nip from mentors.debian.net by sending mail to [EMAIL PROTECTED] However, it appears that mail to the mentors.debian.net domain is not working and hasn't been for at least a few days: % host -t mx mentors.debian.net mentors.debian.net is an alias for mentors.workaround.org. mentors.workaround.org isn't answering on the smtp port though it is answering on http and ssh. Is sending mail to [EMAIL PROTECTED] still the preferred way to request removal of packages from mentors.debian.net? I'm requesting removal of these packages because someone has agreed to sponsor them for upload into the archive, and I want to tweak the description from what's there on mentors. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
advice about splitting a package (libtiff-tools)
The libtiff package (upstream) includes one program, tiffgt, that requires opengl. The current version of libtiff in debian installs tiffgt's manual page but does not install tiffgt. (This is bug 219456.) I have built new libtiff packages that create tiffgt, which seems like a reasonable program to include. I have two packaging choices, both of which I have successfully implemented, but I wanted some opinions on which way was better. 1. Just add the necessary libraries to Build-Depends so that tiffgt gets built. This is the easiest solution, but it has the disadvantage of having libtiff-tools get a bunch of extra dependencies (X and opengl libraries) just to support one program. 2. Split libtiff-tools into libtiff-tools and libtiff-opengl, where the latter contains only tiffgt and its manual page. This is also really easy, but there's one catch: older versions of libtiff-tools already include the manual page for tiffgt, which means libtiff-opengl must conflict with versions of libtiff-tools that are older than this new version. This means that someone installing libtiff-opengl without first upgrading libtiff-tools will have libtiff-tools REMOVED. To work around this, I could make libtiff-opengl require libtiff-tools >= the minimum version instead of making it conflict with the old version, but I don't want to do this because libtiff-opengl doesn't actually depend upon libtiff-tools. So, should I include tiffgt in libtiff-tools and just not worry about all the new dependencies, or should I deal with this short-lived but annoying problem of people possibly installing libtiff-opengl without first upgrading libtiff-tools and losing libtiff-tools as a result? Most people will have all those libraries on their systems anyway, and I suspect not many people running systems without X will bother with libtiff-tools. Thanks for any advice. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: advice about splitting a package (libtiff-tools)
I think I'll reply to my own post. I brought this up on IRC and was pointed to a better solution. > The libtiff package (upstream) includes one program, tiffgt, that > requires opengl. The current version of libtiff in debian installs > tiffgt's manual page but does not install tiffgt. (This is bug > 219456.) I have built new libtiff packages that create tiffgt, which > seems like a reasonable program to include. I have two packaging > choices, both of which I have successfully implemented, but I wanted > some opinions on which way was better. > >1. Just add the necessary libraries to Build-Depends so that tiffgt >gets built. This is the easiest solution, but it has the >disadvantage of having libtiff-tools get a bunch of extra >dependencies (X and opengl libraries) just to support one >program. > >2. Split libtiff-tools into libtiff-tools and libtiff-opengl, where >the latter contains only tiffgt and its manual page. This is >also really easy, but there's one catch: older versions of >libtiff-tools already include the manual page for tiffgt, which >means libtiff-opengl must conflict with versions of libtiff-tools >that are older than this new version. This means that someone >installing libtiff-opengl without first upgrading libtiff-tools >will have libtiff-tools REMOVED. To work around this, I could >make libtiff-opengl require libtiff-tools >= the minimum version >instead of making it conflict with the old version, but I don't >want to do this because libtiff-opengl doesn't actually depend >upon libtiff-tools. > > So, should I include tiffgt in libtiff-tools and just not worry about > all the new dependencies, or should I deal with this short-lived but > annoying problem of people possibly installing libtiff-opengl without > first upgrading libtiff-tools and losing libtiff-tools as a result? > Most people will have all those libraries on their systems anyway, and > I suspect not many people running systems without X will bother with > libtiff-tools. Use Replaces instead of Conflicts. This will enable the new libtiff-opengl to overwrite and claim ownership of tiffgt.1.gz. Since Replaces will appear without Conflicts, libtiff-tools won't get removed. When it gets upgraded, tiffgt.1.gz will not be removed. Once libtiff-opengl is installed, it will no longer be possible to install an older version of libtiff-tools, but I don't consider that to be important. > Thanks for any advice. You're welcome. Actually, thank doogie on IRC. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
renaming a library package (advice and sanity check)
The recent thread on names of library packages on debian-devel made me decide that I made a mistake in naming one of my packages. Specifically, the vips7.10 source package creates four binary packages: libvips7.10, libvips7.10-dev, libvips7.10-tools, and libvips7.10-doc. There's no reason for the version number to be in the name of the package since there's no reason to support more than one version of this library at a time. The vips packages have been in the archive a short time (since late November or so) and only have one reverse dependency: the nip2 package which I also maintain. Renaming the packages now will create a minor nuisance: the small number of users of the package will have to learn a new name for the package, ftp-masters will have to remove these packages that they just approved, and the vips packages will have to go through NEW again. On the other hand, it's better to fix this now than later. Should I do this rename? I think I should because the cost is low (since there are few users) and it's better to do it right. I've read Section 5.9.3 of the developer's reference and understand it clearly. Is that still the best way to go? Basically I would prepare new packages with the correct names and with appropriate Replaces: and Conflicts: lines so that installing the new packages will replace the old packages. Once the new packages clear NEW, I would upload nip2 to depend upon the new packages instead of the old packages and would then request removal of the old packages by posting a bug against ftp.debian.org. Advice welcome and appreciated. Thanks. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: renaming a library package (advice and sanity check)
Jay Berkenbilt <[EMAIL PROTECTED]> writes: > The recent thread on names of library packages on debian-devel made me > decide that I made a mistake in naming one of my packages. > Specifically, the vips7.10 source package creates four binary > packages: libvips7.10, libvips7.10-dev, libvips7.10-tools, and > libvips7.10-doc. There's no reason for the version number to be in > the name of the package since there's no reason to support more than > one version of this library at a time. I neglected to mention the new package names: libvips10, libvips-dev, libvips-tools, libvips-doc. "10" is the soname of the current libvips library. After the next ABI change, we'll have libvips11, libvips-dev, libvips-tools, libvips-doc, etc. In other words, these packages are low profile enough that I think the only version number in any of the package names should be the soname in the runtime library. This should make for the smoothest library transition when this eventually needs to happen. (The library ABI has been very stable, and upstream deals correctly with library sonames.) Leaving the number out of the -dev package means that dependent packages can just be rebuilt without any changes if the binary interface changes but the source interface stays the same. > The vips packages have been in the archive a short time (since > late November or so) and only have one reverse dependency: the nip2 > package which I also maintain. > > Renaming the packages now will create a minor nuisance: the small > number of users of the package will have to learn a new name for the > package, ftp-masters will have to remove these packages that they just > approved, and the vips packages will have to go through NEW again. On > the other hand, it's better to fix this now than later. > > Should I do this rename? I think I should because the cost is low > (since there are few users) and it's better to do it right. > > I've read Section 5.9.3 of the developer's reference and understand it > clearly. Is that still the best way to go? Basically I would prepare > new packages with the correct names and with appropriate Replaces: and > Conflicts: lines so that installing the new packages will replace the > old packages. Once the new packages clear NEW, I would upload nip2 to > depend upon the new packages instead of the old packages and would > then request removal of the old packages by posting a bug against > ftp.debian.org. > > Advice welcome and appreciated. Thanks. > > -- > Jay Berkenbilt <[EMAIL PROTECTED]> > http://www.ql.org/q/ > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: renaming a library package (advice and sanity check)
Santiago Vila <[EMAIL PROTECTED]> writes: > On Fri, 14 Jan 2005, Jay Berkenbilt wrote: > >> I've read Section 5.9.3 of the developer's reference and understand it >> clearly. Is that still the best way to go? > > Not always, unfortunately. Very often, the upgrade will be smoother if > you use empty dummy packages wisely. It's a pity that developer's > reference does not mention dummy packages. > > For example, you can create a dummy (empty) libvips7.10-doc which > depends on libvips-doc and has section: oldlibs. Then libvips-doc does > not need to conflict with every version of libvips7.10-doc, only with > the non-dummy versions. I was planning on doing this. My goal is explicitly that this should be as invisible as possible. The oldlibs part is important for deborphan I suppose. I had not realized this before rereading that part of the developer's reference. > This way, "apt-get upgrade" will install libvips-doc without requiring > "apt-get dist-upgrade", and this will be done automatically and > without user intervention, > . . . more discussion of apt-get upgrade . . . Thank you for mentioning this. I always run dist-upgrade and had intended to use that as my test. I hadn't considered apt-get upgrade, but of course you're right. >> The recent thread on names of library packages on debian-devel made me >> decide that I made a mistake in naming one of my packages. >> Specifically, the vips7.10 source package creates four binary >> packages: libvips7.10, libvips7.10-dev, libvips7.10-tools, and >> libvips7.10-doc. There's no reason for the version number to be in >> the name of the package since there's no reason to support more than >> one version of this library at a time. > > A more conservative approach would be to rename just libvips7.10-dev, > libvips7.10-tools and libvips7.10-doc, and wait for the next ABI > change to get rid of libvips7.10. True, but I think I like going with libvips10 better. That way, the current version of libvips will be named the way I plan to name future versions, and the less desirable name won't be hanging around as an example that someone else might think is right. Many thanks for your very helpful comments. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: renaming a library package (advice and sanity check)
pt-cache show does.) It's like apt-cache rdepends considers the Conflicts as a dependency, which would be a bug. I'll look into it a little further and report it if needed. This same thing happens with libasdf1.0 and libasdf1, so I don't know why deborphan shows these. Anyway, I feel confident now in proceeding with the rename knowing that nothing will get broken by a dist-upgrade even during the transition. The only period of breakage I can find occurs when the new packages have appeared and the upgraded versions of the old packages have not yet appeared. In that case, installing the tools package from the new version would result in removal of the old version of the client package. Again, this problem could happen only under a short window of time, and would only happen if someone explicitly tried to install the new package, not if someone did a dist-upgrade. I think this kind of thing happens all the time. Well, this is long, but maybe it will help someone reading the archive someday. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pdf files in upstream tarball and -doc package
martin f krafft <[EMAIL PROTECTED]> wrote: > also sprach Frank KÃster <[EMAIL PROTECTED]> [2005.02.11.1332 +0100]: >> But you cannot include pdf files for which no source is included, >> or only Micro$oft .doc files, in a Debian package: We need the >> source code, and pdf, even if not compressed, cannot be taken as >> source code. > > This is debateable. PDF is basically PS, and PS is source code. > > So why not > > pdf2ps thefile.pdf > > ship the PS and build the PDF from it? This is not really true. PS is a full-fledged programming language. PDF is not. They are very different from each other at a fundamental level, though they do share the same basic imaging model and page markup operators. Converting PS to PDF involves actually evaluating it and generating page marking operators with specific details hard-coded in. For example, you could write a postscript program that would behave differently depending on the paper size. You can't do this with PDF. You can't simply embed shell commands into a PDF file like you can into a PostScript file. The programming language features of PDF are limited to some small amount of arithmetical function evaluation. PDF doesn't even have a true operator stack like PostScript does. That isn't to say that it is impossible to create a security hole through a PDF file, but it's more comparable to html in that respect than to PostScript. In other words, you could include a malicious link or put invalid PDF data that would exploit a security hole in a specific PDF viewer, but you can't actually embed malicious code. -- Jay Berkenbilt <[EMAIL PROTECTED]>
Re: pdf files in upstream tarball and -doc package
Alejandro Exojo <[EMAIL PROTECTED]> wrote: > El Viernes, 11 de Febrero de 2005 17:21, Jay Berkenbilt escribiÃ: >> That isn't to say that it is impossible to create a security hole >> through a PDF file, but it's more comparable to html in that respect >> than to PostScript. ÂIn other words, you could include a malicious >> link or put invalid PDF data that would exploit a security hole in a >> specific PDF viewer, but you can't actually embed malicious code. > > Really? > > http://lists.kde.org/?l=kde-core-devel&m=110470798901386&w=2 > > I'm a PDF ignorant, so maybe I misunderstood something. This article points to the fact that you can create a link in a PDF that opens an application. This is the kind of thing I meant when I said that a PDF could include a malicious link in the same way HTML code could, though PDF can do it in a more generalized way. Since you could embed the application "rm -rf /" in a PDF, I'll have to back off a bit on my original point, so thanks for the correction. The difference here though is that you could create a postscript file that would remove files just by having you load it in ghostscript, whereas the user would have to actually select a link in this example, but in some ways, this is splitting hairs. It's certainly somewhat more difficult to examine the target of the link in a PDF than in HTML, but as the article you referenced points out, the viewer can help with this. Thanks for making this point in response to my message. I don't want my message to lull anyone into a false sense of security -- you and Martin are correct that it would be possible to create a PDF that has damaging code in it in that sense. Sorry for the confusion. -- Jay Berkenbilt <[EMAIL PROTECTED]>
Re: Updates to d-mentors FAQ
Matthew Palmer <[EMAIL PROTECTED]> wrote: > In preference to doing work, I've added an extra section to d-mentors FAQ > entitled "For Sponsors". Comments / improvements appreciated. > > http://people.debian.org/~mpalmer/debian-mentors_FAQ.html > > - Matt I know you posted this several weeks ago, but I'm only now finally having time to look at it. I saved it with "important messages I need to get to sometime." :-) If you think it's appropriate, I'd suggest some tips for sponsors about how to build and upload someone else's package in a fashion that doesn't make katie think it's a mislabeled NMU. This happened to me a twice when I had packages sponsored. I also had a case of a sponsor trying to upload my .dsc file which got rejected because the key wasn't in the keyring. In at least one case, the package was sponsored by a relatively new DD who had never sponsored before. (I have yet to sponsor a package for someone else.) I think the only thing required for the sponsor is to use the -k flag to dpkg-buildpackage (or whatever front end is being used) to get his/her own key to be used to sign the packages, or to build with -uc -us and then sign with debsign. Is this correct? I think some people may accidentally use -m instead. Not having done this, I could be confused, hence my desire to see this information added to your NM page. Also, I would concur with the other respondent who mentioned that your writing is clear and informative. When I was just getting started, this was one of the most helpful things I read. -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
debian packages: single diff vs multiple patches (as in rpm)
Although philosophically more aligned with Debian, I had been a RedHat user for almost 8 years largely pragmatic reasons that aren't relevant. As such, I have developed a large rpm-based infrastructure for releasing my company's own software to our production facilities and have become quite familiar with RedHat's rpm system from the developer's perspective. Now I'm strongly considering making the switch to Debian and am evaluating moving my whole installation system over to dpkg. dpkg seems superior to rpm in almost all respects (richer dependencies, better documentation, more robustness, apt, etc.), but there's one thing that bothers me. When building an rpm, multiple source files and multiple patch files can be specified, and arbitrary commands can be used to extract sources and apply patches. This makes it easy to build an rpm of a standard package with a handful of separately maintained patches applied. As far as I can tell, a Debian package consists of a single source tarball and a single diff. Is this right, or have I missed something? Coming from an rpm perspective, it seems to me that this would make it much more difficult to manage locally modified versions of packages. I'd appreciate if someone could either explain to me that I've got it all wrong give me a pointer for what to look like, or confirm that my understanding is correct but explain why this isn't really a problem. I'm especially interested in hearing thoughts from other people who have converted an rpm-based infrastructure to a dpkg-based infrastructure. Lastly, please feel free to correct my terminology if I'm using it incorrectly. For example, is it correct to say dpkg-based rather than deb-based? Thanks! -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: xerces -- or -- request for NMU
I am interested in possibly co-maintaining the xerces packages or in taking them over. Ivo Timmermans, the current maintainer of the xerces packages, indicated on [1]debian-devel that he is "looking for people interested in working on the xerces packages, as a comaintainer or maybe to take it over entirely." 1. http://lists.debian.org/debian-devel/2004/debian-devel-200402/msg01047.html There hasn't been any activity relating to that post on the debian-devel list. (There are no other messages in the February or March archives with the word "xerces" in their subject lines.) In [2]Bug 225305, I submitted a patch for libxml-xerces-perl to bring it up to the latest upstream version. In response to my comments to this bug report (prior to submitting the patch), Ivo Timmermans replied, "Go ahead and do an NMU." Of course, I can't do that because I'm not (yet, I hope) a DD. 2. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=225305 My patch in Bug 225305 requires a change to the xerces23 package as well. In [3]Bug 234230, I have submitted a patch to the xerces23 source package that would allow the config.status file leftover from building xerces to be installed in /usr/lib/xerces23. The config.status file is needed in order to build libxml-xerces-perl which needs to know how xerces was configured. The config.status file, though text, is definitely architecture-dependent since it encapsulates the output of running "configure", which is why I figured it would go in /usr/lib/xerces23 rather than /usr/share/xerces23. I discuss this in the bug report. 3. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=234230 Both patches are suitable for NMUs. They follow the policy of not making any gratuitous changes. In other words, the packages built by applying my patch and following the procedure outlined in the bug report do have one lintian warning (an executable header file), but so do the existing packages. I explicitly did not fix the problem (though it is easy to fix) because I was considering this to be fodder for an NMU rather than a new packaging job. If I were to assist with maintenance or take over as maintainer of the xerces packages, I would plan to fix this problem and also to create a xerces24 package for the latest upstream Xerces-C package. (At present, the latest version of Xerces perl is not compatible with the latest version of Xerces-C. There's no reason, however, that one can't have more than one version of the runtime libraries installed even though only one version of the Xerces-C development packages can be installed.) I am definitely interested in becoming a Debian developer and getting onto the new maintainer track. I have not yet gotten by GPG key signed by a developer, but I have made contact and intend to pursue the key signing a bit more aggressively. I am relatively new to Debian, but I have been running Linux since 1992 and have been reasonably active in the Open Source community since the late 80's, submitting small to medium patches to a wide range of packages. I am also capable of [4]following the convention of embedding references in my email, which indicates that I am able to observe and mimic prevailing habits. :-) I have read the policy, social contract, developer's reference, and various other materials, and I have close to 20 years of programming and system administration experience under my belt. Luckily, I'm also very patient and don't expect any special treatment on the basis of these stated qualifications. :-) 4. This message I've been lurking on this list long enough to realize that requesting a sponsor for an NMU is somewhat unusual, so I'd welcome advice about how to proceed. Although I have not spoken with Ivo Timmermans about this in the last couple of weeks, I did discuss this some with him including stating my intentions to post here. See [5]Bug 232474 (defunct, superseded by Bug 234230) for details, though keep in mind that this message includes some rambling as I come to the conclusions asserted in Bug 234230. I believe that my patches here are sufficiently simple that someone with the inclination should be able to decide to do an NMU with very little time or effort. If you're willing to sponsor me as a comaintainer of the packages, I'd like to know that too. We would, of course, have to coordinate with Ivo. Thanks for your time. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xerces -- or -- request for NMU
> Jay Berkenbilt <[EMAIL PROTECTED]> writes: > > I am interested in possibly co-maintaining the xerces packages or in > > taking them over. Ivo Timmermans, the current maintainer of the > > xerces packages, indicated on [1]debian-devel that he is "looking for > > people interested in working on the xerces packages, as a comaintainer > > or maybe to take it over entirely." > [...] > > OK, please send me an URI to your packages (i'd prefer that, but you can > also mail them to me directly). I've put all the packages at: http://www.tux.org/~ejb/debian/xerces/ They are divided into libxml-xerces-perl and xerces23. I copied all the files that I believe would be uploaded. This would include all binary packages as well as diff.gz dsc, and orig.tar.gz for libxml-xerces-perl and all the binary packages as well as diff.gz, dsc, and changes for xerces23. (libxml-xerces-perl has been moved to a new upstream version; xerces23 has just had a minor change.) Here is a complete list of files under the above URL. libxml-xerces-perl/libxml-xerces-perl_2.3.0-4-1.diff.gz libxml-xerces-perl/libxml-xerces-perl_2.3.0-4-1.dsc libxml-xerces-perl/libxml-xerces-perl_2.3.0-4-1_i386.changes libxml-xerces-perl/libxml-xerces-perl_2.3.0-4-1_i386.deb libxml-xerces-perl/libxml-xerces-perl_2.3.0-4.orig.tar.gz xerces23/libxerces23-dev_2.3.0-2_i386.deb xerces23/libxerces23-doc_2.3.0-2_all.deb xerces23/libxerces23_2.3.0-2_i386.deb xerces23/libxercesicu23_2.3.0-2_i386.deb xerces23/xerces23_2.3.0-2.diff.gz xerces23/xerces23_2.3.0-2.dsc xerces23/xerces23_2.3.0-2_i386.changes Thanks for taking a look at this. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xerces -- or -- request for NMU
> In a private email to Ivo I offered to co-maintain them under the > umbrella of the Debian XML/SGML group (see my signature for more > info). Ivo told me that xerces already its own project on Alioth > but that it might be better to move it over to the Debian XML/SGML > group. > > If you want your welcome to join the group. Thanks. I'll definitely check this out. Someone kindly volunteered to look over my packages. Should I still move forward with the NMU? I just need to redo the packages following the proper policy for NMU which I didn't do exactly right. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
wvdial prompts "by hand"... is that release critical?
See bug 219151. The wvdial package prompts the user by hand during installation instead of using debconf. Isn't this against the policy? If so, shouldn't that bug be release critical instead of important? Is it worth trying to change that so that this gets fixed for Sarge? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=219151 -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
