second appeal for libtiff testers
A new version of libtiff, version 3.7.0 + CVS (more like an alpha of 3.7.1, expected soon) has been uploaded to experimental. i386 and powerpc packages are available. (Many thanks to Giuseppe Sacco for sponsoring this upload and building the packages.) This version is expected to be binary compatible with the current libtiff4 package in sid and sarge and should be safe to just install and test. I have done a fair amount of testing myself and have found no problems with this version. If a few people, particularly maintainers of packages that depend upon libtiff, can test this, perhaps we can put 3.7.1 into sarge when it comes out. The 3.7 series has many bug fixes over 3.6.1, which is the version currently in sid/sarge. If you find any problems, please report them through the BTS (of course). I would be grateful if you could send me a personal email message if you try 3.7.0 and it works well for you. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Re: Are mails sent to xxxx buildd.debian.org sent to /dev/null ?
> Josselin Mouette debian.org> writes: > > One month ago, I asked the alpha and mips buildd maintainers to > > reschedule h5utils, which failed to build because of a missing build for > > dependency. Was this email even read? Do these addresses have an utility > > in the real world? > > The source package fseries was over 40 days behind on s390 and arm > when I mailed the respective [EMAIL PROTECTED] A few days later, an s390 > package was built, whether or that was due to my mail I do not > know. I've sent messages to various [EMAIL PROTECTED] addresses many times for various reasons, and they have all always been ignored. The xerces23 and xerces24 packages are still on not-for-us lists for architectures that they do and always have worked on though I have requested resolution of this multiple times over many months, and the nip2 packages need to be requeued on some platforms because of failed build dependencies that have long since been resolved. My requests on this have also been ignored. > > Do I have to re-upload a new version with no change, just to make it > > propagate to sarge? > > Good question. Any takers? An alternative to this would be build manually on the missing architectures and to do a binary upload, right? Someone did this for me of the xerces packages. I can't do it myself because I'm not a DD yet (I was approved by my AM in August and by the front desk in September), so I'm not sure whether the sponsor used one of the available build systems or used his own system. (It was a powerpc build in this case that was needed, and he does have a powerpc.) I'm not sure if developers have any recourse when things get stuck in person wait, as seems to be the case with some autobuilder problems as well as with the NM process. My strategy has always been to be patient and to try to find an alternative. I'm sure the unwitting bottlenecks are overcommitted rather than uncaring, and I don't want to be a nag. Are there polite/helpful things those of us waiting on [EMAIL PROTECTED] can do to help speed the process? I've even resorted to sending email to the individual buildd admins, but this has also always failed, even though I try my best to be pleasant about it. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Re: please post listing and status of NEW queue
Anibal Monsalve Salazar <[EMAIL PROTECTED]> wrote: > It's now redirected to http://ftp-master.debian.org/new.html The new page looks really clean and easy to read. Thanks to everyone who participated in making it available. I like the "Age" column, but I think it's still useful to know the actual date when something was uploaded. This would be less useful if we didn't see things in months (where one can't tell how close to two three months or one month something that says two months is), but as long as we do, it would be useful. Just my $0.02. When something is uploaded multiple times, does the age count from the date of the first upload or of the last upload? I've always wondered whether doing a subsequent upload after the first one went into NEW "resets the clock" on ftp-master approval. My policy has been to do an upload to experimental for any existing source package with a new binary package and to not do any further uploads to experimental until it gets approved. This way, uploads without the new binary package can proceed to unstable without risking resetting the clock. Once the package is approved, I would turn around and immediately upload to unstable. (See tiff for an example.) Do you happen to know whether this procedure makes a difference? (I realize, of course, that generating information from the package list in NEW does not imply knowledge of the order in which ftp-masters approve or reject packages.) -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
mixing different upstream sources in one package
>From time to time, someone announces an intention to package some tiny script or program, and people suggest including it in some other package instead to avoid pollution of the archive with lots of tiny packages. Although I understand the reasoning and the issues here (additional overhead for each package), this has always bothered me a little. I'm not sure that, as an upstream author, I would necessarily want the debian version of my package to be bundled with other software that was similar in functionality but otherwise unrelated to my package. I've recently taken over maintenance of psutils and am gradually working through the outstanding bugs on that package. A few of the bugs suggest adding external programs. Assuming there are no other impediments (like licensing problems), do people generally think that it's reasonable to do this even if the other packages aren't really part of the upstream package? If so, are there usual mechanisms for doing this? What about version numbers? My inclination would be decline requests to add unrelated packages to psutils, but I thought I'd solicit input from others in case someone has some perl (oops, pearl) of wisdom that I have overlooked. Thanks! -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mixing different upstream sources in one package
sean finney <[EMAIL PROTECTED]> wrote: > hi jay, > > On Sat, Nov 19, 2005 at 12:27:33PM -0500, Jay Berkenbilt wrote: >> I'm not sure that, as an upstream author, I would necessarily want >> the debian version of my package to be bundled with other software >> that was similar in functionality but otherwise unrelated to my >> package. > > as an upstream author, you'd better be allright with it if you've > released your software under a free-as-in-speech license. that's kind > of the point of Free Software. of course, it goes without saying > that any terms of the original work's copyright need to continue > to be honored (as you mentioned there can't be any licensing > conflicts). for most gpl-within-gpl situations, this simply means > updating debian/copyright. David Moreno Garza <[EMAIL PROTECTED]> wrote: > On 12:27 Sat 19 Nov 2005, Jay Berkenbilt wrote: >> little. I'm not sure that, as an upstream author, I would necessarily >> want the debian version of my package to be bundled with other >> software that was similar in functionality but otherwise unrelated to >> my package. > > I don't agree with this, then upstream author should maintain the > package and decide what's the best action to be taken for the > package itself. Point taken on both counts; I retract my statement and offer this clarification. As an upstream author, I would accept contributions and incorporate them into the package. (I have done this before.) As an upstream author who was not the packager, I would offer my opinions to the packager but would defer to the packager's judgment or preference. I think my objections would be completely mitigated by simply mentioning this in the package description. Luk Claes <[EMAIL PROTECTED]> wrote: > Maybe you could consider to add a package psutils-addons or > something similar? Yes, this would be a definite possibility -- it would allow the convenience of bundling everything in one source package without the issue of having the binary package whose name matches upstream pull in additional software. In this case, it may not be worth the trouble, but it's a good suggestion to keep in mind. -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mixing different upstream sources in one package
Thomas Viehmann <[EMAIL PROTECTED]> wrote: > Hello Jay, > > Jay Berkenbilt wrote: >> My inclination would be decline requests to add unrelated packages to >> psutils, but I thought I'd solicit input from others in case someone >> has some perl (oops, pearl) of wisdom that I have overlooked. Thanks! > > IMHO (and I have suggested this particulary for 'sed through a postscipt > file' packages on d-mentors) this is about the users and free software. > Both are greatly helped by putting the stuff providing > yet-another-postscript-manipulation-scriptlet in the psutils package > where users have a chance to find it. > > OTOH if upstream is actively opposing such additions, you might > reconsider to keep them happy. I think this sums it up nicely. Thanks. Thanks for all the comments. I no longer find the idea of mixing things into packages like this to be objectionable after seeing the various arguments in favor of doing so. I think my objections from before had more to do with my tendencies toward being a compulsive organizer than in doing what is best for users, so I'm glad I asked so I could become aware of this and fix it. --Jay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
> [Anand Kumria's sarcastic criticism of the ftp-master team removed] On the contrary, it seems to me that the ftp-master team is doing a fantastic job and has been for many months. They have stayed on top of the flurry of NEW packages generated by two series of library renames from two separate C++ transitions, have generally kept the response times for most packages down to a good level, and have come forward with a list of most reasons for package rejection. Removal requests are also handled in a timely fashion. These are all vast improvements from not that long ago when NEW processing had pretty much stalled. I think the debian project owes much gratitude to the members of the ftp-master team whose job is vital to the smooth functioning of the project but who receive notice generally only when things aren't going well. The team works because people like Joerg Jaspert have come forward and just started helping when there was a need, and have continued to help in a job in which silence is considered a complement. I think that real, non-sarcastic congratulations are in order. I'm sure the appreciation I feel for the team is much more common among the developer community than the complaints of an irate user. It's also worth noting that constructive comments or actual help have a stronger track record of improving things than do sarcastic remarks. Either way, the original subject of the message was right on target! -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multiple package variants with CDBS?
"W. Borgert" <[EMAIL PROTECTED]> wrote: > I have a package that is configured and compiled two times, so > that two binary packages are built in one dpkg-buildpackage run: > One with --enable-gnome, the second without. Is this supported > by CDBS somehow? Is there a package, that already does such a > thing using CDBS? Any hint or example debian/rules file > appreciated, thanks in advance! I used to do this kind of thing with the xerces packages. I no longer do, but the versions of xerces25 and xerces26 in sarge still demonstrate one way to do it. Feel free to contact me off list if you look at this and have any questions about how it works. The basic approach I used was to create two symlink farms to the extracted sources and build once in each location. -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: svn problem: Can you help me?
Lionel Elie Mamane <[EMAIL PROTECTED]> wrote: > What a cryptic error message for a "destination directory doesn't > exist" error condition. There are a number of similar situations (a directory not existing) I've seen where subversion gives a misleading error message. For example, trying to svn switch to a non-existent directory results in "Cannot replace a directory from within" -- hardly illuminating. There are probably a few places where certain conditions manifest themselves in ways that result in these odd messages. Whenever I get a cryptic message from subversion, the first thing I do is check for typos, and the second thing I do is check to make sure all prerequisites for whatever I'm trying to do have been satisfied. That might have caused you to notice the missing mkdir between your two svn mv commands. Just my $0.02. -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: svn problem: Can you help me?
Lionel Elie Mamane <[EMAIL PROTECTED]> wrote: > What a cryptic error message for a "destination directory doesn't > exist" error condition. There are a number of similar situations (a directory not existing) I've seen where subversion gives a misleading error message. For example, trying to svn switch to a non-existent directory results in "Cannot replace a directory from within" -- hardly illuminating. There are probably a few places where certain conditions manifest themselves in ways that result in these odd messages. Whenever I get a cryptic message from subversion, the first thing I do is check for typos, and the second thing I do is check to make sure all prerequisites for whatever I'm trying to do have been satisfied. That might have caused you to notice the missing mkdir between your two svn mv commands. Just my $0.02. -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: advice on a patch set
martin f krafft <[EMAIL PROTECTED]> writes: > I am trying to package the swsusp2 kernel patch, which comes in > hundred little files. My thought was to simply concat these files > into one large patch for use with kpatches... however, this does not > work because some files are created by early patches and later > modified. Since kpatches first tests the patch with --dry-run, it > will fail when the later patches do not find a file to patch. > > What can I do? Is there a tool that can merge multiple patches into > a single patch in a "recursive" manner (i.e. to produce the smallest > patch that has the same result)? Any reason you can't just make a copy of the unpatched source, apply all the patches, and then diff -urN the original with the patched version to create a fresh patch? Test by applying the newly created patch with the original to make sure that your patch and the original patch set produce the same result. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ICU 3.6 beta in experimental
I have uploaded a beta release of ICU (International Components for Unicode) 3.6 to experimental. Version 3.4 is currently in unstable and testing. If you use ICU, please try testing with 3.6 beta by developing with libicu36-dev instead of libicu34-dev. If ICU 3.6 comes out in time, I'm hoping (if the release team approves) to be able to get ICU 3.6 into etch. Thanks. -- Jay Berkenbilt <[EMAIL PROTECTED]> pgpKKTltMsuan.pgp Description: PGP signature
Bug#360357: ITP: diff1 -- compares file's actual state with file's desired state
Package: wnpp Severity: wishlist Owner: Jay Berkenbilt <[EMAIL PROTECTED]> * Package name: diff1 Version : 0.4.1 Upstream Author : April Furst * URL : http://www.diff1.net/ * License : GPL, `diff1 -u GFDL | patch` Description : compares file's actual state with file's desired state diff1 is a special version of diff that takes only one file as an argument. diff1 then compares the file's present state with the file's desired state and reports any differences in the same format as the regular diff command, suitable for input to the patch program. diff1 is very useful for correcting writing and, when used with source code, can be extremely useful for correcting bugs. diff1 works best when its input is close to correct, but in a pinch, diff1 can be used to create complete original works if given an empty file as an argument. At this point, diff1 is still under development and depends upon the utm (Universal Truth Machine) and dwim (Do What I Mean) libraries. The eventual goal is that diff1 should be "self-hosting" -- the final, bug-free version of diff1 will be generated by running diff1 on its own sources, at which point it will be finished and will be able to determine the correct answers to all questions that can be expressed using written language. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686-smp Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dxpc in sid and ready for backports, FYI
For the small handful of people use dxpc (differential X protocol compressor, a useful tool for running X over slow network connections even including dialup), you should be aware that I have just uploaded 3.9.0-1 to sid. Version 3.9.0 is not runtime compatible with older versions of because of non-compatible changes to the protocol. I have a version ready to upload to backports.org which I will upload as soon as 3.9.0 hits testing. In the mean time, if you use dxpc, please be aware that the next upload will break compatibility with dxpc running on older systems. -- Jay Berkenbilt <[EMAIL PROTECTED]> pgpIM2VO0W2td.pgp Description: PGP signature
Re: Editing history... (about debian/changelog in experimental)
Frank KÃster <[EMAIL PROTECTED]> writes: > it seems to be consensus that one should generally not "correct" older > changelog entries, like adding (closes: #...) if it turns out later that > this bug had been closed by this release. I am wondering whether there > is an exception to this rule, namely packages in experimental. The > changelog of tetex-base in experimental looks like this: > . . . > However, there are some bugs that I didn't know they were fixed when I > did the upload, it only turned out later. Therefore putting a "closes" > into the changelog entry of a *later* beta release does not make sense, > and I wonder whether I shouldn't simply add them to this list in the > first experimental upload, although it's an older changelog entry. > > What do you think - shouldn't I edit the list of closed bugs in this > first experimental changelog entry? I personally feel that adding new changelog "blocks" is okay but editing old changelog blocks isn't okay, even if you are going to do a subsequent build with a -v when you go back to unstable. I would either close the bug manually or put an entry in the latest changelog block with a parenthetical remark saying that bug was actually fixed by version x.y-z. I feel that if you grab any old version of a package, the changelog should look identical to the current changelog after you remove all blocks whose date is later than the date of the old version. > On a related note: If I do uploads of 2.0.2c to unstable while 2.99 or > 3.0 is in experimental, shouldn't I copy the changelog entries to the > appropriate place in experimental's changelog, too? This is also kind of > "editing history"; however if I don't do it, the changes made to 2.0.2c > will be only documented in the changelog of the stable release, and if > there's some revision that never makes it to sarge, it will be lost > almost entirely (except for snapshot.debian.org or similar). I just went through this same issue with tiff. After a brief discussion on IRC, I decided to make sure that the package in experimental (now subsequently uploaded to unstable) had all the changelog entries of the changes made in unstable in order by revision. My question was really whether it would be better to go in order by revision or in order by date. We decided to go in order by revision because it is less confusing to the eventual reader. (I never checked to see whether the -v flag to dpkg-buildpackage would work correctly if I went in order by date. That could be another reason.) Between my (sponsored) upload of 3.7.0-1 to experimental and 3.7.1-1 to unstable, there were two security fixes (3.6.1-4 and 3.6.1-5) to unstable and one additional upload (3.7.0-2) to experimental. I inserted them in revision order in the changelog of the experimental package which ultimately made it back to unstable. I did this even though the new version was actually completely repackaged and the latest upstream version already had the fixes. In other words, I didn't actually have to change the experimental at all other than to add the changelog blocks. I did not, however, update the changelog with the security team NMUs made to the much older version in stable. That seemed rather pointless (since the stable version of the package was several upstream versions back), and had not been done by previous maintainers prior to my inheriting the package. A case could be made that I should have done that as well so that the latest version uploaded would reflect the entire upload history of the package. This would, for example, give someone a chance to double check that security fixes applied to stable had also been applied to unstable. On the other hand, anyone doing such a check shouldn't rely on someone having done that. Anyway, changes to stable are definitely in a different category from changes to unstable My opinions should, of course, not be construed as "consensus" since I'm definitely a newcomer. I consider them worth posting though because they came partially from a discussion on IRC that involved people of greater experience. :-) -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Re: Editing history... (about debian/changelog in experimental)
Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: > On Wed, Jan 12, 2005 at 01:01:34PM -0500, Jay Berkenbilt wrote: >> ... or put an entry in the latest changelog block with a parenthetical >> remark saying that bug was actually fixed by version x.y-z. > > I've seen this done more often, and frankly, in my opinion this really > is ugly. There is text in a changelog entry that has _nothing_ to do > with that particular revision, better close the bug manually by just > quoting the older changelog entry, or if it wasn't in the older > changelog entry, just say it was fixed there. Yes, this makes sense. Generally I would just close the bug manually, but I hadn't considered the other option to be worse. [Edits brain. Saves.] Okay, I agree now. > Branden Robinson told me that he does changelog editing of past > revisions continuously for X, for reasons of being able to correctly > lookup when a certain bug was fixed. Especially typo's in bugnumber for > example can make a changelog quite useless if I want to determine when a > certain bug was fixed, and a correct changelog makes it very easy to > close bugs that were fixed some time ago by quoting the relevant > changelog entry. I like that idea too. Policy section 4.4 states: Mistakes in changelogs are usually best rectified by making a new changelog entry rather than "rewriting history" by editing old changelog entries. This is the source of my habits on this point. When I really think about it though, it seems much more useful for the latest changelog to contain an accurate history than for the old version to equal the new version minus new entries as I previously remarked. Certainly gratuitous changes should be avoided. I suppose the word "usually" in the above paragraph from the Policy is probably sufficient to allow this type of editing. Frank KÃster <[EMAIL PROTECTED]> writes: > Jay Berkenbilt <[EMAIL PROTECTED]> wrote: > > > I personally feel that adding new changelog "blocks" is okay but > > editing old changelog blocks isn't okay, even if you are going to do a > > subsequent build with a -v when you go back to unstable. I would > > either close the bug manually or put an entry in the latest changelog > > block with a parenthetical remark saying that bug was actually fixed > > by version x.y-z. I feel that if you grab any old version of a > > package, the changelog should look identical to the current changelog > > after you remove all blocks whose date is later than the date of the > > old version. > > I generally agree, but does this really hold for experimental? And > there's quite a benefit in having sensible, well-readable, comprehensive > changelogs for people using stable (and looking at old versions). I don't see why changelog entries for experimental should be handled any differently from changelog entries for unstable. Based on my revised opinion, I guess that means it's sensible to go back and edit old entries under very specific circumstances. (I suppose one could always have an entry in the most recent changelog block that says, "Corrected erroneous changelog entry from version x.y-z" but this seems like it doesn't really do anyone any good and isn't really necessary.) -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
intent to rename vips7.10 -> vips
Executive summary: I'm planning on renaming the vips7.10 packages to get the "7.10" out of the package name unless someone tells me that I shouldn't. I've discussed this on debian-mentors already. Read on for the copious details. - The recent threads on sonames and package names convinced me beyond a doubt that I made a mistake in the names of the vips packages. I had reasons at the time, but in retrospect, they were wrong. I now intend to rename the packages. I discussed it on debian-mentors and have prepared everything for upload and have tested it thoroughly, but I wanted to run it past debian-devel before doing the actual upgrade. Right now, vips7.10 has only been in the archive for a short time. There is only one dependent package in the archive which I also maintain. In other words, this is the right time to correct the mistake. Right now, the vips7.10 source package creates four binary packages: libvips7.10, libvips7.10-dev, libvips7.10-tools, and libvips7.10-doc. My intention is to do the following: Create new source package "vips" which will create four binary packages: libvips10, libvips-dev, libvips-tools, libvips-doc. (10 is the current soname.) Each package Conflicts with the package it replaces with a version << the future dummy transition version of the existing packages and Replaces the old package as well. For example: Package: libvips10 Conflicts: libvips7.10 (<< 7.10.dummy) Replaces: libvips7.10 Upload this package and wait for it to clear NEW. Upload new version of vips7.10 (currently 7.10.8-1) called 7.10.dummy-1 that creates four dummy packages in section "oldlibs" each of which installs no files (except the mandatory ones in /usr/share/doc) and depends upon its replacement package. The Description of the package includes the word "dummy", and is akin to this, as adjusted appropriately for each package: Package: libvips7.10 Description: transitional dummy package replaced by libvips10 This is the old name for libvips10. It can be safely removed. Upload new version of the package that depends upon libvips7.10 (nip2) replacing its dependencies and build dependencies as needed. (Dependencies will be automatic with the new shlibs file.) By doing this, anyone who has the current packages installed and does apt-get dist-upgrade will automatically get the new packages with the new names. They will also (unfortunately) have the dummy transition packages, but I see no way around that. Someone who explicitly apt-get installs the new packages prior to upgrading the old packages would have the old packages removed. For all the gory details, see this thread: http://lists.debian.org/debian-mentors/2005/01/msg00240.html and particularly http://lists.debian.org/debian-mentors/2005/01/msg00253.html I'm going to ask my usual sponsor to upload these in the next few days unless someone gives me a compelling reason not to. :-) In the interest of full disclosure, in the original ITP, David Moreno Garza <[EMAIL PROTECTED]> asked why I was including the version number in the package name and I gave a reason. In retrospect, the reason wasn't really valid. 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]
changing architecture from any to all
If one changes the architecture of a package from "any" to "all" but makes no change to the package name, does this require any special manual intervention, or would an upload that makes such a change go through as quickly as a normal upload would go through? Hypothetical situation: a compiled executable gets replaced with a shell script. Real situation: an architecture-dependent library packages gets replaced by an architecture-independent dummy transitional package. As far as I can tell from my own experiments, the override file does not know anything about this, and apt-get upgrade/dist-upgrade are happy to upgrade a package whose architecture status has changed. I just want to double check to avoid an unnecessary delay in planning a package transition. 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: intent to rename vips7.10 -> vips
Anthony Towns wrote:
> Jay Berkenbilt wrote:
>> The recent threads on sonames and package names convinced me beyond a
>> doubt that I made a mistake in the names of the vips packages.
>
> Oh dear...
>
>> [...] Right now, the vips7.10 source package creates four binary
>> packages: libvips7.10, libvips7.10-dev, libvips7.10-tools, and
>> libvips7.10-doc. My intention is to do the following:
>
>> Create new source package "vips" which will create four binary
>> packages: libvips10, libvips-dev, libvips-tools, libvips-doc. (10 is
>> the current soname.)
>
> There's no real reason to change "libvips7.10" to "libvips10" -- the
> package name doesn't have to match the soname, it just has to change
> whenever the soname does. So if you've matched "libfoo" to a soname of
> 4, you don't have to do anything beyond renaming the package when
> version 5 comes out -- and that's the point you should say "ah, I can
> call it libfoo5 now".
Well, I can just leave libvips7.10 alone then and wait for the next
soname change (or C++ transition), at which point I can do the one and
only inconsistent name change and switch to using the soname, which I
find preferable, especially for packages where the upstream maintainer
deals with sonames well. I guess I'm still trying to find the right
balance between living with a past mistake that doesn't really matter
that much vs. fixing up as many things as I can in one shot. If this
were a more visible package, I wouldn't consider as radical a change.
> Changing the -dev package name isn't a huge win -- having it
> Provides:/Conflicts: with "libvips-dev", encouraging your users to
> build-depend on the unversioned -dev, then just changing the package
> name when your soname next gets bumped is just as effective.
Luckily, I had already had these Provides:, but not the Conflicts. On
the other hand, libvips7.10-dev conflicted with libvips7.8-dev (now
gone -- thanks), so the right thing should happen. Maybe a note in
README.Debian would be in order.
> OTOH, when the soname gets bumped you generally don't want to change
> the source package name so you get to avoid waiting for bugs like
> #283145 to be dealt with, and source package names basically don't
> affect users at all.
>
> libvips-tools and libvips-doc likewise can probably lose their version
> happily, presuming people who Depend: on libvips-dev today, and end up
> getting the tools from soname 11 aren't going to be unhappy. But for
> both of those you should be able to just have "libvips-*
> Conflicts:/Provides:/Replaces: libvips7.10-*" to satisfy dependencies.
Well, since the libvips7.10-* packages provide the corresponding
libvips-* packages now, it sounds like another possibility would be to
just leave this alone for now and wait for a new soname change before
bothering to change the source package. Then when I do, I will change
it to "vips", and it will be the last time it has to change. Then I
can request removal of vips7.10. Once that's done, I don't have to
mess with removal requests anymore. vips is a mature and stable
package, so this could be a ways off.
My main concern here is that any kind of change like requires
intervention from an ftp master and a delay (not complaining!) from
the maintainer's perspective while the package is in NEW. I was
thinking that if I was going to change any package names, I may as
well get it the way I wish I had done it originally. You're in a
unique position to comment on this aspect. :-)
>> Each package Conflicts with the package it
>> replaces with a version << the future dummy transition version of the
>> existing packages and Replaces the old package as well. For example:
>
> I'm fairly sure the above should ensure you don't need any dummy
> packages, and gain all the benefits you were aiming for. Dummy
> packages are almost always evil.
Yes, I understand. Simply reversing which is the actual package name
and which is the Provides: could alleviate the need for dummy packages
since only one real package will match libvips7.10{,-dev,-tools,-doc}.
I'll still simulate this locally to make sure I completely have worked
out what will happen in the various scenarios. I have no idea what
apt-get dist-upgrade would do in this case, but it will be easy for me
to find out. I would certainly prefer an option where users are not
left with useless empty packages on their systems.
As for the whole discussion in subsequent messages about using dummy
packages or not, it's an interesting and important discussion but, at
the end of the day, it's not a huge deal for these packages. They are
very new and probably not installed by very
Re: should changelogs be in chronological order
Anthony Towns writes: > Matthew Dempsky wrote: >> Anthony Towns writes: >>>Travis Crump wrote: >>>>Should changelogs be in chronological order or should they be in >>>>version number order? >>>The changelog should be in the order changes were made. >> Isn't that necessarily chronological order? > > Not if you're merging two branches, and reusing the changelogs to > describe the (merged) changes. > > Well, you could still call that chronological order, but the > chronology wouldn't necessarily match the dates listed in the > changelog. > > Cheers, > aj I actually discussed the tiff situation on IRC before making the changelog entries. My exact concern was the one you raised: whether the changlog entries should be in chronological order or in version order. 3.7.0 was a complete repackaging of tiff. The only reason there were two simultaneous branches was because 3.7.0-2 introduced a new binary package and was waiting in NEW when the two security changes to 3.6.1 came out. Otherwise, 3.7.1, which had already been released, would have directly followed 3.6.1-3. One reason for putting the entries in version number order rather than in chronological order was so that debuild -v3.6.1-5 would close all the bugs tagged fixed-in-experimental from 3.7.0-1 and 3.7.0-2. To be honest, I didn't investigate whether the right thing would have happened had I gone in chronological order. > Travis Crump wrote: >> Should changelogs be in chronological order or should they be in >> version number order? > > The changelog should be in the order changes were made. > >> Specifically I just noticed that libtiff4's changelog is out of >> chronological order[attached for reference]. It seems that the >> maintainer was maintaining two branches: an experimental >> branch[3.6.1-3->3.7.0-1->3.7.0-2], and an unstable/testing >> branch[3.6.1-3->3.6.1-4->3.6.1-5]. 3.7.1-1 would then be >> potentially descended from either branch. > > If the changelog includes entries from 3.7.0-2 and 2.6.1-5, then > 3.7.1-1 > should be descended from _both_ branches -- ie, it should include all > the changes from both, merging any conflicts. Since this was a complete repackaging, literally speaking, 3.7.0-1 did not derive from 3.6.1-3 so there's no issue of merging changes, etc. I can assure you, however, that 3.7.1-1 includes the security fixes made in 3.6.1-4 and 3.6.1-5. The former was already present in 3.7.1, and the latter appears as an explicit patch in the 3.7.1 package. Perhaps I should have mentioned explicitly in 3.7.1-1 that security fixes had been applied, but I did not because they were already mentioned in earlier changelog entries. The fact that 3.7.0-1 came right after 3.6.1-3 is a point that only a very observant person looking carefully at the dates would really know about. If I had made explicit mention, someone might scratch their head and say, "Why is he repeating mention of previously noted changes?" I'm walking away from this discussion with the impression that I handled the changlog for tiff correctly. If I should walk away with a different conclusion, someone should please point that out to me. :-) -- 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: intent to rename vips7.10 -> vips
Colin Watson <[EMAIL PROTECTED]> writes: > On Mon, Jan 17, 2005 at 03:53:58PM +0100, Santiago Vila wrote: >> On Tue, 18 Jan 2005, Anthony Towns wrote: >> > We really need to get dpkg/apt and dselect/aptitude working as designed. >> > Not supporting auto-selecting packages like this, in spite of it >> > having been documented for years, is just embarassing. >> >> I agree, but I'm not sure that conflicts/replaces/provides is an >> elegant way of telling the package manager "this package is what >> this other package used to be". > > According to Ian, a simple Replaces was originally intended to have > those semantics (in addition to suppressing warnings about overwritten > files). Conflicts/Replaces/Provides would indeed be overkill. > > -- > Colin Watson [EMAIL PROTECTED] Seems like you'd need something like "Replaced-By:" so that an upgrade process would know which new package to choose. --Jay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: intent to rename vips7.10 -> vips
I've done more analysis and experimentation with the vips rename, and I'd like to stick to my original plan of uploading a new source package that creates new binary packages followed by creating dummy packages out of the old source package followed eventually by requesting removal of the old packages. In a nutshell, this requires the least disruption in the long term and creates the smoothest upgrade path, with the only drawback being the dummy packages. Here's my reasoning. You stated: > Changing the -dev package name isn't a huge win -- having it > Provides:/Conflicts: with "libvips-dev", encouraging your users to > build-depend on the unversioned -dev, then just changing the package > name when your soname next gets bumped is just as effective. My understanding (based on discussion that went on during the tiff transition and stuff during my NM process) is that depending upon pure virtual packages is frowned upon, even if only one package in the archive provides the virtual packages. It breaks if you have a package in your local apt that also provides the package, which I almost always do when I'm building nip2. It would also break at some future point when I would eventually upload a new version with a different source package. So ultimately I feel that keeping libvips-dev as a virtual package isn't actually just as effective after all. If I rename the -doc and -tools packages now, we need to go through an override editing cycle anyway. Then I have nothing to lose by renaming the -dev package at the same time. For that matter, I have nothing to lose by renaming the shared library package either. Based on Santiago's information and my own experimentation, there's no way to get apt-get dist-upgrade and, presumably, dselect to automatically upgrade to the new packages without using dummy packages. Dummy packages are therefore necessary to achieve a completely smooth upgrade. As long as we have to go through an override editing cycle anyway, I'd like to go ahead and take care of renaming the source package. This also means I can use the old source package to create the dummy packages as I originally planned. That won't require override edits at all. Then I can request removal of the dummy packages and old source package in some time, probably right around the release of sarge. (I'd create an RC bug and ask the release team to remove the packages from sarge closer to the release so sarge doesn't ship with these dummy packages and so that that there's no urgency on removing them from sid.) I have a plan B that would be easier though not quite as satisfying. That would be to leave the source package name alone for now and just change the binary package names without creating dummy packages. Once this goes through, I can upload nip2 that depends upon the new names. When people upgrade that, they'll at least get the new shared library package. They'll have to deal with -dev, -doc, and -tools manually, but this is not a huge deal, though it will break some users. Then the source package name is still vips7.10, which is okay but undesirable aesthetically. Ultimately, when something > 7.10 comes out, I'd still end up requesting removal of the vips7.10 source package, an extra step that could be avoided if I just go with my original plan. A future upgrade of vips would be made more complex by having to take care of that at the same time. So unless there are any objections that I haven't addressed (or if I've really missed something here), I'd like to proceed with my original plan. Is that okay? I really appreciate the responses to this. I feel like I'm making a lot of noise over a few packages that are not that important over an issue that isn't that major. All this input is helping me become a better maintainer. 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: SUMMARY: Re: shared library -dev package naming proposal
Steve Langasek <[EMAIL PROTECTED]> wrote: > - Leave the .la files in place; -dev packages need to depend on -dev > packages corresponding to those runtime dependencies that are also built > using libtool. This is the status quo. If we do this (which I think we should for now), I would suggest that we have a debhelper script analogous to dh_shlibdeps that parses .la files to automatically generate -dev build dependencies, and that this should also be fixed if libtool is fixed (and should detect whether it is using a fixed libtool). Then maintainers of libraries that use libtool will automatically get the -dev dependencies required to satisfy issues with libtool now, and if/when libtool is fixed, those dependencies can disappear automatically without having to have all the maintainers go through a lot of trouble twice. My suggestion doesn't solve the problem, but it does make it easier to deal with. Maybe this already exists and I'm just not aware of it. I've been thinking about writing this for a while since I maintain several libraries that use libtool and have made the mistake of forgetting a -dev dependency before. --Jay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SUMMARY: Re: shared library -dev package naming proposal
Steve Langasek <[EMAIL PROTECTED]> wrote:
> It doesn't exist; I think it's a great idea. Perhaps a tool named
> dh_libtool, which populates a substvar named ${libtool:Depends}?
Sounds good to me.
I'm going to be leaving my current job in a few weeks and taking
several weeks off between jobs. I'll try to work on it then along
with some other debian tasks that I've been putting off. I can't
imagine it would be very difficult.
> FWIW, detecting a fixed libtool would be rather difficult, since it's the
> libtool used by the depending application which does the recursion and
> therefore needs to be fixed.
I was thinking we'd be able to tell from the .la file what we needed
to do. If a new libtool still generated a .la file, perhaps it could
put some kind of version indicator or something similar. Anyway, it's
not clear to me what a fixed libtool would do differently (I don't
know libtool that well) though. Anyway, I've been looking for an
excuse to dig into this. Once I could clearly articulate why libtool
is broken and what a non-broken libtool would look like, it will be
much clearer what kind of strategy would work in both cases.
--Jay
--
Jay Berkenbilt <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SUMMARY: Re: shared library -dev package naming proposal
GOMBAS Gabor <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 28, 2005 at 08:57:29AM -0400, Stephen Frost wrote:
>
>> I'd think we could come up with a way to detect the version of libtool
>> in use, somehow. :)
>
> LTMAIN_SH_PATH=`autoconf --trace='AC_CONFIG_AUX_DIR:$1'`
> LTMAIN_SH_PATH="${LTMAIN_SH_PATH:-.}"
> grep ^VERSION "$LTMAIN_SH_PATH"/ltmain.sh | cut -d= -f2
This is nice, but I think it's not really very autoconfish [tm] in
spirit. Perhaps it would be better to be able to detect whether the
desired feature (whatever that is) is present in the appropriate
libtool rather than looking at the version number. I had indicated in
an earlier post that maybe looking at .la files would be possible,
though this is by no means a certainty. Also, this invokes autoconf,
which we don't necessarily want to do at package build time since this
will cause packages to require a build dependency on autotools, a
topic which has been discussed at length before. If we went the route
of detecting libtool version, I believe we would need to know the
version of libtool that was used to create the .la file of the
dependent package. Is this right? Maybe not -- I'm not fully up to
speed on all the issues yet. Anyway, I'll put together a more
comprehensive proposal on how dh_libtool should work when I have a
chance to work on it. (Unfortunately, that's not going to be for a
few weeks -- things are even more unusually busy than their usual
level of unusualness right now in both my personal and professional
lives...) Of course, all ideas and suggestions such as this are
welcome and are being saved in my notes, in spite of any first
impressions I may have on whether they will actually work
specifically. Thanks. :-)
--
Jay Berkenbilt <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
possible ICU transition
The version of icu in debian is very old. I have recently taken over maintainership of the package. I had originally intended to wait until after the g++ transition had completed to do the ICU transition, but I'm now strongly considering building new ICU packages to upload to unstable before the g++ transition is finished. The main reason for this is that icu 2.1 fails to build on ARM, but icu 3.4 beta succeeds. The only direct reverse dependencies of the icu package are the xerces packages which I also maintain. There are only three or four reverse dependencies of the xerces packages. Right at this moment, libxml-xerces-perl has succeeded on arm even though xerces25 has failed, which probably means that it is not in a stable state with respect to the g++ transition. Also, I'm about to move, go on vacation, and change jobs, so my available time will drop for a short time (from late August through mid September), and it might be good to have this done before then. There is also an icu28 package in debian, but it is not necessary to convert its reverse dependencies to use the new icu package at the same time -- that can wait until after the g++ transition. If I start this transition as early as this weekend, it should not hold up the g++ transition, and I will be able to monitor it closely for two or three weeks before I start being much less available. Given all this, can anyone think of any reason why I should not start an ICU transition this weekend? An alternative would to resolve the FTBFS on arm for icu 2.1 (which worked before g++ 4.0) and to wait for xerces25 to rebuild and then to do a binary NMU rebuild of libxml-xerces-perl Thoughts? --Jay -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: possible ICU transition
I've uploaded ICU 3.4. Once it clears new, people who depend upon icu28 or embed icu in their packages can try it. Read on if you care about ICU. Steve Langasek <[EMAIL PROTECTED]> wrote: >> Given all this, can anyone think of any reason why I should not start >> an ICU transition this weekend? > > If the only packages that need to be rebuilt for this change are xerces25 > and xerces26, and those packages don't also need to have name changes in the > process, then I see no reason not to proceed with the change. You'll have > to upload icu one way or another to fix the FTBFS, so you might as well go > with the lib transition while you're at it since the set of affected > packages is so small. I uploaded ICU 3.4 yesterday with a significantly simplified packaging based on reading about changes to the library since 2.1 and looking at the packaging section of the upstream manual. When it clears NEW and finishes building on all architectures, I'll re-upload xerces25 and xerces26 packages rebuilt with the new ICU. I've also reorganized those packages to create only an ICU version of the library. (Rather than libxerces26c2 and libxercesicu26c2 both existing, now only libxerces26c2 exists, but it replaces, provides, and conflicts with libxercesicu26c2 to avoid any breakage and smooth upgrade path -- I've tested multiple scenarios.) With the new ICU packaging, it is no longer necessary to load extra packages outside of the xerces packages' own dependencies to get fully working locale support, hopefully resolving this category of bugs once and for all. If my understanding is correct and I haven't made any mistakes, xerces's reverse dependencies should be unimpacted and probably don't even need to be rebuilt. I tested some of my own applications with the new xerces libraries, and they worked fine both with and without recompilation. (I had discussed this xerces reorganization many months ago on debian-devel, or at least on IRC, and decided to wait until this ICU transition.) The new ICU packages keep locale data in a shared library (which is the library default). This creates a bit of a larger architecture-dependent package, but parts of the architecture-independent parts of 3.4 are byte-order dependent anyway, and the new packaging is much simpler and should be more robust. Besides, based on popularity contest, no one is really using the features of the old packaging that would allow certain very advanced customizations to be made after installation. It's also worth noting that blade's icu28 packages use the shared-library data packaging method as well, and no issues related to that have been raised. -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
package tracking system issues
How does one report problems with the package tracking system? I followed the link on packages.qa.debian.org and got no response. That's certainly not a complaint -- I don't necessarily expect to get a response right away, but I have no way of tracking this or knowing whether my comments have been received. There are three things that seem wrong about what's on the package tracking package for icu (http://packages.qa.debian.org/i/icu.html): 1. The system warns that the bug tracking system contains patches, but there aren't any bugs with patches except one bug that has been closed for a long time and in fact will be archived in one day. There's a note about a patch from Ubuntu. Maybe it's counting that. 2. PTS shows one release critical bug and shows that icu (source) is buggy in the testing status area. There aren't any release critical bugs against icu right now. Even clicking on the link from PTS doesn't show any. Also, the release critical bug report doesn't show any bugs against icu. There is a bug against icu28 which creates a binary package with the same name as one of icu's packages (this is the release critical bug). Maybe PTS is getting confused by that? 3. ICU has not been rebuilt on hppa (like anything else recently uploaded), m68k, or sparc, but PTS is not showing it to be out of date on those platforms. I thought it always showed that even when there were other issues such as the age being too low. If anyone can shed some light on any of these, that would be helpful. It looks like PTS has had many recent improvements, which is great. If there are a few problems, I'd like to do my duty and report them so that they can get fixed while the changes are fresh. The first thing I did was look for a pseudopackage in the bug tracking system for PTS, but I couldn't find one. Perhaps I overlooked it? Thanks! -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
order of builds on a buildd: icu (optional/libs)
Based on what I've seen in other threads, the order in which packages get built on a buildd is a function of, among perhaps other factors, its priority and section. I uploaded icu several days ago and have watched other packages (including my other uploads) sneak in front of it that shouldn't have based on these two factors. For example, nip2 (optional/graphics, no reverse dependencies) built much faster than icu (optional/libs). The only thing I can think of is that the latest icu builds two binary packages that have not previously existed because it is a library with a new soname. Does that impact it? libicu21c2 and libicu21-dev, built by the old icu, have reverse dependencies, but libicu34 and libicu34-dev don't yet. (I'm waiting to upload the packages that depend upon these until they are built on all architectures.) Is there a place where I could have looked (other than reading the code to buildd and/or wanna-build) to find the exact method used to calculate the build order? -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
icu, vips transition to testing
Though grep-excuses shows them to be valid candidates, both icu and vips appear to be not transitioning to testing because of making packages uninstallable on alpha (according to http://bjorn.haxx.se/debian/testing.pl?package=icu and corresponding for vips), but I don't see any evidence that they actually will make packages uninstallable on alpha. Am I missing something (including possibly some announcement), or is something wrong? It seems like, disregarding m68k, icu, xerces25, xerces26, libxml-xerces-perl, vips, and nip2 should all be able to transition. Is this the case, or have I overlooked something? I don't see why these transitions should happen on their own. Thanks for any resolution or explanation. -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: icu, vips transition to testing
Steve Langasek <[EMAIL PROTECTED]> wrote: > On Mon, Sep 19, 2005 at 04:45:31PM -0400, Jay Berkenbilt wrote: > >> Though grep-excuses shows them to be valid candidates, both icu and >> vips appear to be not transitioning to testing because of making >> packages uninstallable on alpha (according to >> http://bjorn.haxx.se/debian/testing.pl?package=icu and corresponding >> for vips), but I don't see any evidence that they actually will make >> packages uninstallable on alpha. Am I missing something (including >> possibly some announcement), or is something wrong? > > Standard scenario requiring a hint to update multiple packages together. > This isn't done automatically because it's computationally infeasible. > Hints added for both of these package groups which should take effect > tomorrow as long as there are no other packages that still need to be > updated in unstable. Is the scenario in question that package A2 replaces package A1 and a new version of package B that used to depend upon A1 now depends upon A2 such that replacing A1 with A2 would make B in testing uninstallable even though an upgrade of B would resolve the problem? (That's a mouthful.) I'd have to think a bit to convince myself that detecting this in the general case would be computationally infeasible (though it seems like a distinct possibility that it would be for large numbers of dependencies), but I can certainly accept that it is tricky to code and, more importantly, not currently coded, so thanks for the hint. :-) --Jay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#329425: RFA: psutils -- A collection of PostScript document handling utilities
I use these and would be happy to adopt the package. -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#329425: RFA: psutils -- A collection of PostScript document handling utilities
Rob Browning <[EMAIL PROTECTED]> wrote: > Jay Berkenbilt <[EMAIL PROTECTED]> writes: > >> I use these and would be happy to adopt the package. > > OK, that sounds good, and thanks. I just uploaded 1.17-19 which seems > to be doing fine with the autobuilders. Sounds good. I'm at the tail end of unpacking in my new place, so right this moment, I'm doing only major Debian work. In a week or two when I get back to "normal", I'll have a closer look at this and do a new upload resolving any bugs I can take care of right away and adopting the package at the same time. > (I had also wondered, if further upstream development still isn't > likely, if there might be any people who would want to contact the > current author about continuing development themselves.) The thought crossed my mind as well. At the moment, I wouldn't be inclined to do more than prepare patches to send upstream, but we'll see. I have a few unrelated packages (though one is PDF related) that I'm trying to get ready for release, so that will take most of my discretionary development time. (I have a PDF library and some useful tools I wrote as part of my job that my former employer graciously allowed me to release as an open source project. Details forthcoming.) -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dh_libtool proposal (-dev dependencies on -dev from libtool)
This is an informal proposal for a dh_libtool program which I was
considering implementing over the next few days. I'm not so sure
though after reading bug 192008, so I thought I'd bring it up here and
see if there's any kind of consensus.
Basic problem: -dev packages for packages that use libtool need to
have runtime dependencies on the -dev packages that provide the .la
files that they need at link time.
Basic proposal: provide dh_libtool to automate this. Note that this
is called dh_libtool and not something more general to make it clear
that it is addressing only the subset of the general problem that
directly relates to libtool. This seems like a normal enough case to
require a special case even if that special case doesn't fully solve
the entire problem.
Objections raised in 192008: this solution misses several cases
including multiple -dev packages providing the same library and
packages that don't use libtool. Joey Hess raises objections very
clearly in his response to bug 192008, and I find them convincing,
though sometimes we may fail to provide a solution that's good in many
cases because it isn't good in all the cases we can think about. I'm
not convinced that this tool couldn't still be useful as long as its
limitations are understood.
Details:
In late July, there was a thread on debian-devel about handling -dev
packages' dependencies on other -dev packages as required by libtool
among other things. (Subject: "SUMMARY: Re: shared library -dev
package naming proposal") The thread discussed various aspects of
libtool brokenness, but regardless of any of that, I had suggested
that we have a program that could populate these dependencies
automatically by parsing .la files, and various participants liked the
idea. I had intended to implement this program during some time off I
have between jobs. I'm now in that time off period and intend to work
on this over the next few days.
The proposal is to have this program populate a substvar named
${libtool:Depends}. I've studied this problem at a cursory level, and
this is what I currently intend to do:
* Traverse the directory to be installed for .la files
* Parse the .la file to read dependency_libs item; scan this item for
other .la files
* Determine what packages provide the given .la files
* Filter out packages that are already in the dependency list
* Place the resulting packages in the libtool:Depends substitution
variable
This would, like other debhelper tools, take various arguments to
control which package is being scanned and to control other aspects of
the behavior that should be configurable. I will also study
dh_shlibdeps and dpkg-shlibdeps to make sure that I'm not leaving
anything out that's important.
For the initial version, I will not "overdesign" this with anything
analogous to shlibs files, though it would probably be important to at
least support local overrides in case a .la file is provided by more
than one package and the packager wishes to specify a specific
dependency on one other than the one that is installed. (This case
would not be covered by simply excluding existing explicit
dependencies.) If this catches on and libtool isn't fixed to make it
unnecessary, then some additional infrastructure support analogous to
shlibs files could be added. In the mean time, versioned dependencies
on other -dev packages can be listed explicitly or handled in local
overrides, even though this has the unfortunate property of requiring
the packager of the dependent package to keep track rather than the
packager of the package that provides the lower .la file.
For testing purposes, I would create a native package called
dh-libtool that I would probably just put in my people.debian.org
area. If people decide that this is a useful item, it should
presumably be included as part of debhelper and also invoked from
debhelper.mk in cdbs. (Other builder helpers that invoke debhelper
could also be modified as needed, of course.) In that case, I would
suggest it to the debhelper maintainers.
There's actually a proof of concept script written by Michael Dänzer
posted to bug 192008 (which I saw after writing all of the above) that
could be a good starting place if this is actually worth pursuing.
Comments? If there's no consensus, I'll probably abandon this project
and just use a script to help me do it by hand when I need to do this.
--
Jay Berkenbilt <[EMAIL PROTECTED]>
Re: dh_libtool proposal (-dev dependencies on -dev from libtool)
Hello all. I've read enough of this thread to be convinced that dh_libtool is not a good idea and not worth pursuing. Thanks for all the insightful comments. Perhaps a lintian check, as suggested by Joey Hess in the bug 192008 would be better, or perhaps we should just focus energies on fixing the underlying problem as many suggested. -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
reorganization of xerces-c packages
For quite a while, there have been multiple versions of xerces in the debian archive. With 3.0.0 now finally in beta and the release being managed by someone who will likely get it done in a timely fashion, I'm hoping to take advantage of this opportunity to clean things up. 3.0.0 is not source-compatible with the 2.x series, and according to upstream, there may be packages that require significant effort to port from 2.x to 3.x. I would therefore like to support only one 2.x version and only one 3.x version in the archive at a time. Once all packages in debian that use the 2.x series have been ported to 3.x, we could consider dropping the 2.x packages, unless there is some demand to support things that aren't debian packages. There is one likely casualty with this strategy: libxml-xerces-perl. That specific package, and as far as I know, only that package, seems to be tied to a specific minor version of xerces-c and is not really being actively maintained upstream, though they do occasionally release. Given that popcon indicates only 0.03% of popcon users use libxml-xerces-perl regularly (it gets just 18 "votes"), it doesn't seem like enough of a reason to keep multiple source-compatible versions of xerces-c in the archive at once. Can anyone see any serious problems with the decision to support only one source-compatible version at a time (consistent with just about everything else in the archive) even knowing that this might cause libxml-xerces-perl to have to disappear from the archive? I hope to have xerces27 removed before lenny releases anyway, and the only reason I haven't pushed people to transition from xerces27 to xerces28 is because I was hoping to do this reorganization in time for lenny. I haven't tested this yet, and I would thoroughly test it before doing anything, but here's what I'm thinking: right now, we have source package xerces28 that creates libxerces28, libxerces28-dev, and libxerces28-doc, and we have source package xerces27 with the analogous binary packages. My inclination is to upload 3.0.0 as source package xerces-c, a source package that would always contain the latest upstream release of xerces-c. It would install libxerces-c3.0 (the runtime library is libxerces-c-3.0.so, similar to how the Berkeley DB packages are set up, rather than the more accepted such as libxerces-c.so.30.0.0), libxerces-c-dev, and libxerces-c-doc. The libxerces-c-dev package would provide libxerces-c3-dev and conflict with libxerces-c2-dev, libxerces28-dev, libxerces27-dev, etc. The libxerces-c-doc package would provide libxerces-c3-doc. Then I would reupload xerces28 as source package xerces-c2. It would create binary packages libxerces-c28 (which installs libxerces-c.so.28.0), libxerces-c2-dev, and libxerces-c2-doc. The libxerces-c28 package would provide libxerces28, the libxerces-c2-dev package would provide libxerces28-dev, and the libxerces-c2-doc package would provide libxerces28-doc to make transitions from the xerces28 packages seamless and automatic. I would then request removal of the xerces27 and xerces28 packages. If we don't have a version of libxml-xerces-perl that works with the latest 2.x or 3.x versions of xerces-c, I would also request removal of libxml-xerces-perl. I'll have to test this scheme carefully to make sure it works, but I think it will work fine. Comments? -- Jay Berkenbilt <[EMAIL PROTECTED]> pgpXg9YM8sWdm.pgp Description: PGP signature
Bug#478585: ITP: qpdf -- command-line PDF transformation software
Package: wnpp Severity: wishlist Owner: Jay Berkenbilt <[EMAIL PROTECTED]> * Package name: qpdf Version : 2.0 Upstream Author : Jay Berkenbilt <[EMAIL PROTECTED]> * URL : http://qpdf.sourceforge.net/ * License : Artistic License Version 2.0 Programming Lang: C++, Perl Description : command-line PDF transformation software QPDF is a program that does structural, content-preserving transformations on PDF files. It could have been called something like pdf-to-pdf. It also provides many useful capabilities to developers of PDF-producing software or for people who just want to look at the innards of a PDF file to learn more about how they work. QPDF offers many capabilities such as linearization (web optimization), encryption (password protection), and decryption of PDF files as well as changing whether or not PDF files use object streams (compressed objects). It also has facilities for checking PDF files for structural errors, inspecting stream contents, or extracting objects from PDF files. QPDF is not PDF content creation software -- it does not have the capability to create PDF files from scratch. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (200, 'experimental'), (200, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
tarball in tarball: opinions
In light of the upcoming change to 3.0 (quilt) source package format and Raphael Hertzog's guidelines suggesting that we not use tarball in tarball packages, I'm re-evaluating my habit of using this pattern. There are many reasons that I prefer to use tarball in tarball, but there are two that I can't find a straightforward way around with the new format: * I like to have an exact copy of the downloaded source tarball with the same md5 checksum, gpg detached signature, etc. Using the rules/tarball.mk from cdbs provides a very convenient way of handling this. * I manage my debian directories in subversion, and I use svn-buildpackage to build. I always use "mergeWithUpstream". Sometimes I want to do something more involved, so I just manually extract my .orig.tar.gz files. I can't do this without tarball in tarball if my packages either contain their own debian directories that I don't use or if they extract to a directory other than pkg-version. So, is using tarball in tarball considered "bad" these days? Is it viewed as an approach that once had its time but is now discouraged, or is it just a matter of personal preference and creating a README.source that tells the user what to do file makes it all okay? I want my packages to be in the best possible shape, so I'm trying to decide whether I should go to the trouble of changing my personal packaging habits to work around the two issues above. Some of these will be easier to handle after we can switch to 3.0 (quilt), but as far as I know, there is no way to replace your .orig.tar.gz without changing the package version, and I don't want to introduce epochs for this. Advice welcome. In the absence of any specific suggestions, I'll just continue to use tarball in tarball and will wait to restructure my packages until after we can switch to 3.0 (quilt). I'm going to try to make a decision soon since I have a new upstream version of ICU ready to upload to experimental as soon as I resolve this. Thanks. -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
using libxerces-c-dev instead of libxerces-c2-dev
I've sent a message out to all package maintainers of packages that depend on libxerces-c2, but in case I missed anyone, this is a request to use libxerces-c-dev instead of libxerces-c2-dev. If your package declares a build dependency on libxerces-c2-dev, please try depending on libxerces-c-dev instead. The libxerces-c2-dev package is specifically for the 2.x Xerces C versions, which are now obsolete. The libxerces-c-dev package will always point to the latest version of the Xerces C libraries, which are presently version 3.0.1. Although there are some source-level API changes between 2.x and 3.x, they only relate to a small portion of the API. Many (probably most) packages will be able to change their build dependencies without running into any trouble. For details on the potentially breaking API changes, please see http://xerces.apache.org/xerces-c/migrate-archive-3.html#Migrateto300 I will eventually be requesting that the xerces 2 packages be classified as "oldlibs" or maybe removed entirely. I anticipate not requesting removal until squeeze+1, but we'll see how it goes. Thanks! -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
please try new libtiff4 in experimental
Executive summary: I've uploaded a new libtiff based on upstream's 3.9 branch to experimental. I believe it to be fully source and binary compatible with 3.8.2. Unless there are major problems, I will be uploading this version to unstable soon. There is no transition required, but I'm going through experimental since this is not an official upstream release. I would encourage people to grab the libtiff4 package from experimental and make sure all your applications that process tiff files still work as expected. Details: It's been over three years since the last upstream release of libtiff (3.8.2), and it's been over two years since the release of 3.9.0 beta. Even so, there is plenty of activity, and upstream has been saying for a long time that version 3.9.0 is just about ready to release. It has many bug fixes and many security fixes (all of which were already backported to 3.8.2 for debian). Although the 3.9.0 beta release itself was not binary compatible with 3.8.2, the problems that broke compatibility were fixed in CVS, and I have personally verified that the head of the 3.9 branch is binary compatible with 3.8.2. (I both checked the relevant source and header files and also ran several tests using various old executables loading newer shared libraries.) There are an increasing number of operations, including processing of files with "old style" jpeg compression, that don't work with 3.8.2 but do work with 3.9.0. Rather than continuing to wait for the upstream release of 3.9.0, I have decided to "roll my own" 3.9.0 release based on the current head on CVS. I follow upstream carefully and believe this is likely to be more stable than 3.8.2 in spite of its somewhat unofficial status. I mentioned to upstream that I intended to do this and will make sure they are aware of it before I upload it to unstable. In any case, if you maintain something that uses libtiff, I'd be grateful if you could test your packages using the libtiff from experimental. No need to rebuild -- just grab the libtiff4 package and install it. Everything should "just work". Thanks. -- Jay Berkenbilt pgpXOB0Tum5ti.pgp Description: PGP signature
Re: please try new libtiff4 in experimental (never mind)
Never mind about trying the new libtiff4 in experimental. The response from upstream to my statement that I was putting the head of the 3-9 branch in debian was to agree that it was ready to release and to release 3.9.0. :-) -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
please test with tiff 4.0.0~beta4 from experimental
If you maintain a debian package that directly uses libtiff or if you maintain software that uses libtiff, it would be a great help if you could test your packages against the version of libtiff in experimental, 4.0.0~beta4. If you find any problems, please report them as bugs against the tiff package in the debian BTS. If you test and everything works fine, I'd like to know that as well as I can communicate back to upstream. The 4.0 release supports bigtiff (64-bit offsets) and old-style jpeg compression. It is *mostly* but not entirely source compatible with the 3.x series. For details, please see http://libtiff.maptools.org/v4.0.0.html With libtiff 4.0.0, debian and upstream will be back in sync with shared library version numbering. In fact, the debian package for 4.0.0 beta 4 now contains no patches at all -- all debian patches have been incorporated upstream. The shared library runtime packages install as libtiff5, so they can coexist with the versions in sid/squeeze. The development package, libtiff-dev, conflicts with libtiff4-dev from sid/squeeze. Thanks! -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: tarball in tarball: opinions
Thanks for all the input on tarball within tarball. I will stop using that format for all my packages with the possible exception of ICU which contains its own debian directory. I was aware of the fact that dpkg-source handles the tarball nnot extracting to package-version and have, in fact, advised others that repackaging the orig.tar.gz to get around this is not necessary. One of my own packages (psutils) is this way. My point wasn't that dpkg-source doesn't handle it, but that it makes it somewhat less convenient to manually extract the source over top of my svn-controlled debian directories. I was not aware of svn-buildpackage --svn-export, pointed out by Magnus Holmgren <[EMAIL PROTECTED]>, and I think that will solve my problem quite nicely and prevent me from writing my own script that duplicates the logic in dpkg-source. With regard to the ICU packages, which include their own debian directory, I tried unsuccessfully two years ago to convince upstream to drop this. There has been a recent change of leadership in the project, and I have (prior to my sending out my message to debian-devel), post a bug to their bug tracking system requesting that they drop the debian directory. If they don't, I may regenerate the orig.tar.gz as I do not, but instead of using a tarball within a tarball, I'll just push everything down one level. Once the 3.0 (quilt) format becomes acceptable to use for regular packages in the archive, this becomes a non-issue, and I can use the upstream source download as the .orig.tar.gz file. Thanks for all the input and tips. -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
new ICU in experimental
To all users of ICU, and particularly to maintainers of packages that depend upon ICU, I have uploaded a new ICU to experimental. This is a "draft" release, as they call it, of ICU 3.8. There are some new interfaces and support for several new features as well as a number of bug fixes. Starting with 3.8, I have removed the soname from the -dev package name. Starting with the 3.8 upload, the -dev package will be called simply libicu-dev. The ICU people have been historically careful about source compatibility, and besides, after a few years of maintaining several library packages plus the release team's ability to trigger automatic binary NMUs, I have come to believe that it's better to omit the soname from the -dev package unless there is an explicit desire to be able to support multiple versions simultaneously. Once ICU 3.8 hits unstable (which I will coordinate with the release team since will cause a small library transition), maintainers of packages that use ICU should replace their build depends on libicu34-dev or libicu36-dev to libicu-dev. Hopefully for future ICU releases, a binary NMU will be sufficient. The new libicu-dev packages will not "provide" libicu34-dev or libicu36-dev because I have not rigorously verified that they can and wish to encourage this transition to be made once and for all. I have done some informal testing of the new packages and haven't found any problems, but I certainly encourage people with a vested interest to give these a spin especially with upstream primed to include fixes before the 3.8 release in September. -- Jay Berkenbilt <[EMAIL PROTECTED]> pgpEA63htKiHm.pgp Description: PGP signature
xerces28
I have uploaded xerces-c 2.8.0 rc1 to experimental as xerces28. Their release cycle was very fast, so during the (quite acceptable amount of) time it took xerces28 to clear NEW, upstream has already frozen for the 2.8.0 release which is expected out in the next few weeks. If you use xerces27, please try xerces28 instead. You can either grab the package from experimental or wait for the upload to sid. I have attempted to contact maintainers of packages that depend upon xerces27 in separate email. xerces27 and xerces28 can coexist in debian as we have done with past xerces releases since it tends to happen that some particularly tightly integrated packages like libxml-xerces-perl and xalan only work properly with one specific version of xerces. It is my intention to request removal of xerces27 before lenny releases if at all possible. -- Jay Berkenbilt <[EMAIL PROTECTED]> pgpJ4vr8p3Iv4.pgp Description: PGP signature
developer access to amd64 system
Sorry if this is a stupid question, but I'm afraid I must be missing something. I have an amd64-specific bug in one of my packages, and I don't have an amd64 system. According to db.debian.org/machines.cgi, pergolesi is supposed to be an amd64 with developer access, but it looks like it's configured as i386. From a sid chroot: pergolesi% dpkg-architecture DEB_BUILD_ARCH=i386 DEB_BUILD_ARCH_OS=linux DEB_BUILD_ARCH_CPU=i386 DEB_BUILD_GNU_CPU=i486 DEB_BUILD_GNU_SYSTEM=linux-gnu DEB_BUILD_GNU_TYPE=i486-linux-gnu DEB_HOST_ARCH=i386 DEB_HOST_ARCH_OS=linux DEB_HOST_ARCH_CPU=i386 DEB_HOST_GNU_CPU=i486 DEB_HOST_GNU_SYSTEM=linux-gnu DEB_HOST_GNU_TYPE=i486-linux-gnu This is even though /proc/cpuinfo shows it to have Opteron processor/processors: processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 5 model name : AMD Opteron(tm) Processor 240 stepping: 1 cpu MHz : 1394.743 cache size : 1024 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow bogomips: 2792.88 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts ttp processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 5 model name : AMD Opteron(tm) Processor 240 stepping: 1 cpu MHz : 1394.743 cache size : 1024 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow bogomips: 2789.65 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts ttp So, what am I missing? How do I get access to an amd64 system to fix this problem? If anyone is interested, please look at bug 446276. -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: developer access to amd64 system
Mike Hommey <[EMAIL PROTECTED]> wrote: > On Sat, Oct 13, 2007 at 12:36:04PM -0400, Jay Berkenbilt wrote: >> So, what am I missing? How do I get access to an amd64 system to fix >> this problem? > > try the sid_amd64_pure chroot ;) Thanks! Okay, now how was I supposed to know about that? :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
help on icu bug 451767/451978: extra dependency
Fellow developers,
I'm requesting some assistance on bugs 451767 and 451978 (which are
the same). On some 64-bit platforms, the ICU packages create 32-bit
libraries. Unfortunately, the dependencies on the 32-bit library
package for 64-bit systems (lib32icu36) is listed as a dependency of
the regular 32-bit libraries (libicu36) on at least amd64. The
Depends line for each in the control file is just ${shlibs:Depends}.
So it seems that dh_shlibdeps is deciding that the 64-bit libraries
should depend on the 32-bit libraries, and it's not clear how to
prevent from doing so.
I can think of a two potential solutions:
* Figure out exactly why dh_shlibdeps is deciding to do this.
Unfortunately, I don't have a really good way to do this since
pergolesi doesn't have all of icu's build dependencies installed
and I don't have access to any other amd64 system. I could work
around these issues as I describe below.
* Work around this by sticking something in the package generation
process that edits debian/libicu36/DEBIAN/control to remove the
offending dependency. This is a hack, and since I'm using cdbs, it
would also require overriding pieces of cdbs in an unsafe manner.
If anyone has another suggestion, I'd be interested in hearing it.
Feel free to reply to this or to update bug 451767 with a patch or
suggestion.
If I don't hear anything, I'll take a crack at it when I'm back in
town by just manually setting things up on pergolesi and running the
various debhelper or underling dpkg-dev commands by hand to see if I
can figure this out. Although I can't currently build the packages
there because I lack the cross development environment, I may be able
to at least partially simulate what's going on by just populating
debian/tmp or debian/pkg-name from the results of extracting the
binary packages, which I can just download. Then I can run the end
pieces of the build manually.
Unfortunately, I have had to do a lot of uploads of the icu packages
to fix problems with providing 32-bit libraries on 64-bit platforms.
As an ix86-only person, I've had to go against my principles and rely
on the autobuilders to test the packages on amd64. I've also used
zlib as an example, which has been very useful.
I've made a second request to debian-admin to install the missing
prerequisites on pergolesi in the appropriate chroot.
Thanks for any suggestions.
--
Jay Berkenbilt <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ICU 3.8 transition coming up
As soon as the current icu 3.6 version transitions to lenny (should be about three days), I intend to upload ICU 3.8 to sid. Once this is done, you will have to change your packages BuildDepends to depend on libicu-dev instead of libicu36-dev. Now that I am removing the soname From the lib dev package, future icu transitions should be achievable with binary NMUs, but for this time, the explicit change will be required. ICU 3.8 has been in experimental for some time, and ICU 3.8 is supposed to be source compatible with ICU 3.6, so I hope that the transition to go smoothly and quickly. I'll report bugs to any depending packages that have not uploaded a new version within several days of the upload. I'll send another message out when I upload (but I will not copy debian-devel on that one). -- Jay Berkenbilt <[EMAIL PROTECTED]> pgpzjY6Rg0fnm.pgp Description: PGP signature
new ICU in experimental
I've uploaded ICU 4.3.4 to experimental. Soon this will be ICU 4.4. If you maintain a package that depends on ICU, it would be great if you could test against this release. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ICU 4.4 rc1 in experimental
There's a release candidate for ICU 4.4 in experimental. If you maintain a package that depends on ICU, it would be great if you could test with this version. There should be no changes required to your package -- just install libicu-dev from experimental and rebuild. If I don't hear any problems, I'm going to coordinate with the release team to get ICU 4.4 into squeeze. I've already tested the xerces packages, and they are fine with the new ICU. Thanks! -- Jay Berkenbilt pgppMEXhW8vkr.pgp Description: PGP signature
Re: PDF is blocked for printing, etc. OK for acroread (it behaves as expected), but KPDF allows me to print it, even if it is protected! Why?
Merciadri Luca wrote: > Sjoerd Hardeman wrote: >> Pdf "anti-features" are fake security. Don't trust on them, never. > And what do you suggest if one wants some real protection _and_ the > benefits of a format like PDF? Thanks. The PDF specification itself recommends using external encryption in this case. From section 7.6.1 of the PDF specification: NOTE: Conforming writers have two choices if the encryption methods and syntax provided by PDF are not sufficient for their needs: they can provide an alternate security handler or they can encrypt whole PDF documents themselves, not making use of PDF security. It is very easy to defeat PDF security in any file that has a blank user password since it is just up to the application to enforce security. I've written a detailed explanation of this which I can dig up and send you if you're interested. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100419204257.0890259570.qww314...@soup
Re: Jörg Schilling is damage; the community should route around him
> Branden Robinson: > > It's time to fork. Let us work with the rest of the community to > standardize on a new set of tools based on the last free version of > cdrtools, thank Mr. Schilling for his valuable contributions, and leave him > be to pursue his interests in proprietary software without interference > or argument from us. He appears to regard placing his work under the plain > vanilla GNU GPL that works for so many projects as an act that he cannot > perform in good conscience. Let us stop placing him in that uncomfortable > position. > Jose Carlos Garcia Sogo: > > I agree with you. And I guess that the "good" direction would be > pushing libburn, which seems a bit stalled right now. Also, DVD[-R[W], > +R[W]] support should be added to it. On top of that library, it would > be easier to build command line and GUI oriented programs, which could > drop at that moment cdrecord. > > But what is needed there is people with time and access to different > drives. Perhaps people behind dvd+rw-tools could be interested, and some > company out there could sponsor this piece of software. In support of this statement, I'd like to add that my limited interactions with Andy Polyakov, the author of dvd+rw-tools, have been overwhelmingly positive. I'd also remind people that dvd+rw-tools is already able to write dvd-r and dvd-rw (even though its name implies dvd+r and dvd+rw) in some modes. I have used dvd+rw-tools for some time as my exclusive software for DVD authoring, even on dvd-r and dvd-rw. Also, cdrdao has some CD writing capability (not withstanding caveats and warnings in README.Debian) and is not, to my knowledge, related to cdrtools. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Re: proposal: 'xterm' alternatives entry
> > The procedure would be to upload a new 'xterm' package which moves > > /usr/bin/xterm to /usr/bin/xterm.real and introduces /usr/bin/xterm Of course, you mean /usr/X11R6/bin/xterm... > Mandrake did something like that a while ago(*) - broke the > application name for X resources. I was also going to point out the issue of X resources. While remaining in favor of fixing other applications rather than changing xterm, I would point out that this issue could be mitigated by having xterm be moved into another directory so its base name would be the same. (I suppose /usr/lib/xterm/xterm could work...) That said, I am not able to convince myself that this is an issue here... if I clear my X resources, set HOME to a temporary directory, copy /usr/X11R6/bin/xterm (as root, preserving setuid) to /tmp/xterm.real, and invoke /tmp/xterm.real, I see a client class of UXTerm and a client name of xterm. Maybe this is debian-specific? I thought only uxterm did that. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
debhelper >= 7.2.3, doc-base, and lintian
I just built a new version of one of my packages, and I got some lintian errors like this: E: qpdf: prerm-does-not-call-installdocs usr/share/doc-base/qpdf-manual N: N:Since the package installs a file in /usr/share/doc-base, the package N:should probably call the install-docs command in its prerm script. N: N:For example, use the following code in your maintainer script: N: if [ -x /usr/sbin/install-docs ]; then N: /usr/sbin/install-docs -r || true N: fi N: N:Refer to Debian doc-base Manual section 2.4 (Registering Documents Using N:install-docs) for details. N: N:Severity: important, Certainty: certain N: This package uses cdbs with the debhelper rules. Looking at the debhelper changelog, I see debhelper (7.2.3) unstable; urgency=low * dh_installdocs: No longer add maintainer script code to call doc-base, as it supports triggers in stable. This version was uploaded on 3/7/2009. I can't really parse "as it supports triggers in stable." Who is "it" and what triggers is "it" supporting? Who is right? Is lintian and also the doc-base manual that it references correct? Is there something else I'm supposed to be doing? I'd like to find out what the story is here before I upload a package with lintian errors. I can't tell whether lintian is just behind an intended change, debhelper is doing something wrong, cdbs is doing something wrong with how it invokes debhelper, or I'm doing something wrong in my rules. All I do in my rules is include /usr/share/cdbs/1/rules/debhelper.mk and I have one .doc-base file. Once I know where the problem is, I can either fix my packages or submit a bug to the appropriate place. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: debhelper >= 7.2.3, doc-base, and lintian
>> I just built a new version of one of my packages, and I got some lintian >> errors like this: >> >> E: qpdf: prerm-does-not-call-installdocs usr/share/doc-base/qpdf-manual > > Upgrading to Lintian 2.2.7 should fix this problem. debhelper is correct. > > + [RA] Explicit install-docs calls are no longer needed since doc-base >registration is done with triggers. (Closes: #518801) To those who pointed out that my lintian was out of date, thanks. Sorry for the noise on this. I don't know how I could have missed that. I must have updated my chroot and not updated my regular system. Or maybe I got caught in a window with my local mirror. Oh well. Time to clean and reconnect my brain cables. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Unicode 7.0 released - some packages contain outdated embedded data copies
Paul Wise wrote: > Hi all, > > Unicode 7.0 was recently released. I discovered some source packages > contain outdated copies of various Unicode data files. At minimum, the > following packages embed part of the Unicode data (UnicodeData.txt). > > . . . > > Please ask your upstreams to remove the Unicode data files from their > version control systems and source tarballs and instead check for and > use external Unicode data files at build-time or run-time. Then your > packages can Build-Depend or Depend on the unicode-data binary package. I'd have to study it a little more, but I'm not sure this actually makes sense for a package like ICU whose sole purpose in life is handling Unicode. That said, it's probably a good idea to make sure we get an ICU with Unicode >= 7.0 in it before Jessie. Since new ICU versions always require soname bumps and transitions, I generally try to keep it to no more than once or twice per release cycle. Unfortunately though, with one exception, ICU 53 uses Unicode 6.3, and it doesn't look like ICU 54 will make it out in time for the Jesse freeze, so this probably means we'll be stuck with Unicode 6.3 in ICU (and ICU4J) for Jessie, but I'd welcome other suggestions. If someone thinks I'm off base in suggesting that ICU and ICU4J might be in a different place from other packages that use Unicode data in some incidental way, feel free to set me straight. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140618132701.1894127908.qww314...@jberkenbilt-linux.appiancorp.com
new libtiff dev packages
[I'm not subscribed to debian-devel at the moment, so please cc me on responses in the unlikely event that there need to be any.] I've uploaded new versions of libtiff4-dev and libtiff-dev (now the name for libtiff5-dev, with libtiff5-dev as a virtual package). libtiff-dev now provides both libtiff4-dev and libtiff5-dev, and libtiff4-dev provides libtiff-dev. The consequence of this change is that packages that depend on libtiff-dev will not get libtiff5-dev (which is what we want) and packages that depend on libtiff5-dev or libtiff-dev can build depend on other packages that themselves depend on libtiff4-dev. This makes it possible for people who want bigtiff support to immediately change their build dependencies to libtiff-dev (>> 4.0.1-6~). That version also includes pkg-config support. If you're already using libtiff5-dev as a build dependency, there's no need to change it, but if you want to switch to libtiff-dev at your next upload, that would be reasonable. Technically, it's not 100% correct for libtiff-dev to provide libtiff4-dev because there are a very few source-incompatible changes. However, all the changes are in parts of the interface that are deprecated or not used by normal applications. My spot check of a handful of high-profile or complex packages has not revealed any trouble, and I didn't have to change any of my own code to switch from tiff4 to tiff5. Lots of applications can support both, and many have been supporting both for some time. If you run into compile errors, you can either explicitly build depend on libtiff4-dev and nag your upstream, or you can fix them yourselves based on the information here: http://libtiff.maptools.org/v4.0.0.html -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120513103548.0386547332.qww314159@soup
Re: libtiff borken - cannot build anymore?
Norbert Preining wrote: > Including the maintainer of libtiff* Thanks! I'm not currently subscribed to debian-devel, but please feel free to keep me on this thread. > On Mo, 20 Mai 2013, Norbert Preining wrote: >> Hi everyone, >> >> when trying to build a new release of telxive-bin fixing a nasty bug >> alas, I cannot build anymore: >> The following packages have unmet dependencies: >> libtiff4-dev : Conflicts: libtiff5-dev but 4.0.2-6 is to be installed. >> libtiff5-dev : Conflicts: libtiff4-dev but 3.9.6-11 is to be installed. >> Unable to resolve dependencies! Giving up... >> >> The build deps that I have are: >> libgd2-xpm-dev | libgd2-noxpm-dev => libtiff5-dev >> libgs-dev => libtiff4-dev >> How should this work out? The situation is that you can't have both libtiff4-dev and libtiff5-dev on the build dependency chain of any two packages at the same time. For now, what you have to do instead is to have the package that requires libtiff5-dev instead build-depend on libtiff5-alt-dev. The README.Debian installed with libtiff5-dev and libtiff5-alt-dev explains how to use this, but basically if you use pkg-config to get the libtiff5 headers and libraries, you will be good to go before and after debian fully transitions. This situation will be resolved after we transition from tiff 3.x (supplied by the tiff3 source package, runtime is libtiff4) to tiff 4.x (supplied by the tiff source package, runtime is libtiff5). At that point, everyone using libtiff4-dev, libtiff5-dev, or libtiff5-alt-dev should switch to libtiff-dev, which will be based on tiff 4.x (libtiff5). People who can't use libtiff5 for some compatibility reason (and this should be extremely rare) will be able to switch to libtiff4-alt-dev for a transitional period. I hope that jessie will include only libtiff5 and that the tiff3 source package will be dropped. My plans for transition have not been accepted by the release team yet, so it may not happen exactly the way I'm thinking it will. For additional details, see my message to the release team: http://lists.debian.org/debian-release/2013/05/msg00127.html -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130520115122.0240752036.qww314...@jberkenbilt-linux.appiancorp.com
Re: libtiff borken - cannot build anymore?
Andreas Metzler wrote: > I think the proper fix for the time being (until a proper transition > to tiff5 is started) is to ask the libgd-dev maintainer to switch back > to libtiff4-dev. Or to ask the libgd-dev maintainer to switch to libtiff5-alt-dev. I may be wrong, but I think gd requires tiff 4.x. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130520141303.0240764509.qww314...@jberkenbilt-linux.appiancorp.com
Re: libtiff borken - cannot build anymore?
Norbert Preining wrote: > On Di, 21 Mai 2013, Norbert Preining wrote: >> > >> libgd2-xpm-dev | libgd2-noxpm-dev => libtiff5-dev >> > >> libgs-dev => libtiff4-dev > ... >> DOes that mean now that I have to wait a few months until >> I can again build texlive-bin? > > Well, I goes I will include the copy of libgd again in the sources > of texlive-bin (it is originally there) and drop the libgd build dep. In case you didn't see my other response, the better solution would be to get the maintainer of gd to switch from libtiff5-dev to libtiff5-alt-dev until the tiff transition. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130520141454.0240755266.qww314...@jberkenbilt-linux.appiancorp.com
Re: libtiff borken - cannot build anymore?
Ondřej Surý wrote: > This results in: > > E: libgd-tools: binary-or-shlib-defines-rpath usr/bin/annotate > /usr/lib/x86_64-linux-gnu/libtiff5-alt > E: libgd-tools: binary-or-shlib-defines-rpath usr/bin/gd2copypal > /usr/lib/x86_64-linux-gnu/libtiff5-alt > E: libgd-tools: binary-or-shlib-defines-rpath usr/bin/gd2togif > /usr/lib/x86_64-linux-gnu/libtiff5-alt > E: libgd-tools: binary-or-shlib-defines-rpath usr/bin/gd2topng > /usr/lib/x86_64-linux-gnu/libtiff5-alt > E: libgd-tools: binary-or-shlib-defines-rpath usr/bin/gdcmpgif > /usr/lib/x86_64-linux-gnu/libtiff5-alt > E: libgd-tools: binary-or-shlib-defines-rpath usr/bin/gdparttopng > /usr/lib/x86_64-linux-gnu/libtiff5-alt > E: libgd-tools: binary-or-shlib-defines-rpath usr/bin/gdtopng > /usr/lib/x86_64-linux-gnu/libtiff5-alt > E: libgd-tools: binary-or-shlib-defines-rpath usr/bin/giftogd2 > /usr/lib/x86_64-linux-gnu/libtiff5-alt > E: libgd-tools: binary-or-shlib-defines-rpath usr/bin/pngtogd > /usr/lib/x86_64-linux-gnu/libtiff5-alt > E: libgd-tools: binary-or-shlib-defines-rpath usr/bin/pngtogd2 > /usr/lib/x86_64-linux-gnu/libtiff5-alt > E: libgd-tools: binary-or-shlib-defines-rpath usr/bin/webpng > /usr/lib/x86_64-linux-gnu/libtiff5-alt > E: libgd3: binary-or-shlib-defines-rpath > usr/lib/x86_64-linux-gnu/libgd.so.3.0.0 > /usr/lib/x86_64-linux-gnu/libtiff5-alt Yes, I'm afraid that's unavoidable. This issue is mentioned in the README.Debian file. This works by installing the .so file in a non-standard location so that it can coexist with libtiff4, and linking in that way with libtool the rpath to be embedded. Once the tiff transition is completed and the packages are rebuilt, this problem will go away. Until then, you will have to use a lintian override. Here's mine from the vips package: # This is temporary until libtiff5-alt-dev goes away. libvips31: binary-or-shlib-defines-rpath -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130520212119.0541075621.qww314159@soup
Re: libtiff borken - cannot build anymore?
Russ Allbery wrote: > Jay Berkenbilt writes: >> Ondřej Surý wrote: > >>> This results in: >>> >>> E: libgd-tools: binary-or-shlib-defines-rpath usr/bin/annotate >>> /usr/lib/x86_64-linux-gnu/libtiff5-alt > >> Yes, I'm afraid that's unavoidable. This issue is mentioned in the >> README.Debian file. This works by installing the .so file in a >> non-standard location so that it can coexist with libtiff4, and linking >> in that way with libtool the rpath to be embedded. Once the tiff >> transition is completed and the packages are rebuilt, this problem will >> go away. > > This shouldn't be required, since the two libtiff shared libraries can > both go into /usr/lib (since they have different SONAMEs). The only thing > that can't go into /usr/lib and has to go somewhere else is the *.so > symlink, which doesn't require an rpath setting, only a -L flag during > linking. The .so files (there are two libraries), static libraries, and .la files are already the only files in a non-standard location. Basically only the files whose names clash are in non-standard locations. (Tiff still can't remove its .la file yet, or at least it couldn't though I can't remember the exact details of when it's okay to remove the .la fileit has a lot of reverse dependencies It's the only package I maintain that still installs .la files.) I don't remember exactly what is causing the rpath to appear, but I remember having investigated it and determined, possibly incorrectly, that I couldn't fix it without modifying libtool. I will give it another look. It is my recollection that libtool is automatically adding the rpath when it finds the .so file in a non-standard location since it assumes that the actual shared library will be in the same directory as the .so file. In other words, the rpath is not actually being used hereit is pointing to a place where the libraries are not found. I am already adjusting the .so file manually in the installation to ensure that it points to the correct place: $ dpkg --contents libtiff5-alt-dev_4.0.2-6_amd64.deb | fgrep .so lrwxrwxrwx root/root 0 2013-01-26 12:33 ./usr/lib/x86_64-linux-gnu/libtiff5-alt/libtiff.so -> ../libtiff.so.5.1.0 lrwxrwxrwx root/root 0 2013-01-26 12:33 ./usr/lib/x86_64-linux-gnu/libtiff5-alt/libtiffxx.so -> ../libtiffxx.so.5.1.0 > See the krb5-multidev and heimdal-multidev packages for how this is done. I'll give them a look and see if I can tell what they're doing differently. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130522141348.0222507418.qww314...@jberkenbilt-linux.appiancorp.com
changes in python packaging
I'm having problems with one of my packages that includes a python module. The package is vips. I am not a python person, so this may be simple. The last time I built the package, there were several module binary files that got installed appropriately. For example: % dpkg --listfiles python-vipscc| grep vmaskmodule.a /usr/lib/python2.6/dist-packages/vipsCC/vmaskmodule.a /usr/lib/python2.7/dist-packages/vipsCC/vmaskmodule.a Now when I rebuild the package with no changes at all, I get something like this: % dpkg --contents python-vipscc_7.34.2-1_amd64.deb| grep vmaskmodule.a -rw-r--r-- root/root 1127858 2013-09-15 09:33 ./usr/share/pyshared/vipsCC/vmaskmodule.a lrwxrwxrwx root/root 0 2013-09-15 09:33 ./usr/lib/python2.7/dist-packages/vipsCC/vmaskmodule.a -> ../../../../share/pyshared/vipsCC/vmaskmodule.a Okay, this example shows a newer version of the package, but when I rebuild the exact same version as before, I get the same result. This looks like a bug to me, but I'm not even sure where to report the bug. What thing is responsible for having decided to move this module to /usr/share and make a symlink, assuming that's what happened, even though it's architecture-dependent? Is this a problem with my packaging, or is there a bug in whatever is doing this? My best guess is that this is an issue with dh_python2, though I don't know whether a change in dh_python2 is exposing a long-standing problem with the upstream package, or whether this is a new bug, or whether this is a difference because of fewer python versions being available or what. Thanks. This is blocking me from uploading a new version of vips. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130915094224.0521296614.qww314159@soup
Re: changes in python packaging
Jakub Wilk wrote: > * Steve Langasek , 2013-09-15, 13:54: >>> I'm having problems with one of my packages that includes a python >>> module. The package is vips. I am not a python person, so this may >>> be simple. >>> >>> The last time I built the package, there were several module binary >>> files that got installed appropriately. For example: >>> >>>% dpkg --listfiles python-vipscc| grep vmaskmodule.a >>>/usr/lib/python2.6/dist-packages/vipsCC/vmaskmodule.a >>>/usr/lib/python2.7/dist-packages/vipsCC/vmaskmodule.a >> >> Well, to start off, this doesn't look correct at all. Python >> modules are never .a files; these appear to be spurious static >> builds of the modules because you're using a non-pythonic build >> system that assumes it's appropriate to build both shared and static >> versions of "libraries". But these are not libraries, they're DSOs; >> you should not ship these .a files in your package. > > ACK > > You might want to try out lintian4python, which emits: > > w: python-vipscc: static-extension > usr/lib/python2.6/dist-packages/vipsCC/vmaskmodule.a > w: python-vipscc: static-extension > usr/lib/python2.7/dist-packages/vipsCC/vmaskmodule.a > > . . . Good to know about. Thanks. Thanks to both of you for the helpful responses. This makes perfect sense...while I'm not much of a python programmer (I did one decent-sized python project in 1997 or thereabouts), I can see that there would be no use for a .a file by a python program. I already have other stuff in my rules file to get rid of some other files that vips installs that we don't want. I'll just tweak the rule to remove the appropriate .a files as well. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130916100632.0254824885.qww314...@jberkenbilt-linux.appiancorp.com
multiarch conversion for packages with lib32* packages
Please cc me on replies as I am not presently subscribed to debian-devel. I would like to do multiarch conversion for the icu packages. I understand the concept and the implementation, and I have looked at http://wiki.debian.org/Multiarch/Implementation. One issue not covered is what to do if your package already builds 32-bit libraries on a 64-bit system by building 32-bit explicitly and packaging as lib32whatever. The ICU source package creates lib32icu-dev and lib32icu48 on amd64, ppc64, and kfreebsd-amd64. Do I just stop doing this and let packages that build depend on lib32icu-dev just stop doing it, or is there some kind of transitional package that I should create? Anyway it would be nice if the wiki page were explicit about this. I could certainly just stop doing it and let packages that have this build dependency FTBFS until they do whatever changes they need to do, but I'm not sure whether a precedent or convention has been established. Thanks. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120323230432.0524837962.qww314159@soup
Re: multiarch conversion for packages with lib32* packages
Goswin von Brederlow wrote: > Sven Joachim writes: > >> On 2012-03-24 10:50 +0100, Adam Borowski wrote: >> >>> On Sat, Mar 24, 2012 at 09:48:58AM +0100, Sven Joachim wrote: >>>> On 2012-03-24 04:04 +0100, Jay Berkenbilt wrote: >>>> > One issue not covered is what to do if your package already builds >>>> > 32-bit libraries on a 64-bit system by building 32-bit explicitly and >>>> > packaging as lib32whatever. >>>> >>>> The lib32* packages need to built as long as they have reverse (build) >>>> dependencies. I suppose most of them should go away in the long term, >>>> but this is not going to happen in wheezy. >>> >>> All of lib32icu's rdepends seem to have already dropped *32* builds, so >>> it can be removed right now. >> >> Oh, indeed. Somehow I assumed that ia32-libs would build-depend on >> lib32icu-dev, but it doesn't. Thanks for all the replies. I'll convert icu as soon as I have time (hopefully in the next couple of weeks) and drop the lib32 packages. This will greatly simplify icu's build. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120324183528.0296425563.qww314159@soup
libtiff5 transition
Once sentence summary: if your package has a build dependency on libtiff4-dev, libtiff5-dev, or libtiff5-alt-dev, you will probably just want to change the build dependency to be on libtiff-dev, but there are some special cases, so read on if in doubt. [As I write this, the tiff 4.0.3-6 is not built yet on hurd-i386, mipsel, or sparc, so you may want to wait until at least 2013-12-06 before making changes and re-uploading packages or at least check https://buildd.debian.org/status/package.php?p=tiff.] Today we are starting the transition from tiff 3.x to tiff 4.x as the default, and soon only, tiff library in debian. To clear up one constant area of confusion right off the bat, tiff 3.x is packaged in the tiff3 source package and provides the libtiff4 binary package, and tiff 4.x is packaged in the tiff source package and provides the libtiff5 binary package. Some other distributions have already made the transition, and almost all packages will require no code changes. The libtiff4-dev and libtiff5-alt-dev packages are now transitional packages that just depend on libtiff5-dev, and there is no longer any -dev package that builds against tiff 3.x. The libtiff4-dev and libtiff5-alt-dev packages, as well as the tiff3 source package, will be removed before jessie is released. In a few weeks, I will file bugs against any packages that still build depend on libtiff4-dev or libtiff5-alt-dev. If you have a package that has a build dependency on libtiff*dev*, here's what you need to do: * If your package build-depends on libtiff-dev already, no action required; the release team will automatically schedule a rebuild of your package at the appropriate time. * If your package depends on libtiff4-dev but can work fine with tiff 4.x (most packages), replace your dependency on libtiff4-dev with a new dependency on libtiff-dev. * If your package build-depends on libtiff5-dev or libtiff5-alt-dev and is known to work with both tiff 3.x and tiff 4.x (i.e., it does not use the BIGTIFF extensions in tiff 4.x), you can just change the build dependency to an unversioned libtiff-dev. You can also remove any special code that you may have added to your package to get it to find tiff in the non-standard location. If you were finding tiff with pkg-config, you shouldn't have to make any changes to your package other than the build dependency. * If your package build-depends on libtiff5-dev, you don't HAVE to do anything, but you may be helping yourself in the future if you change the build dependency to libtiff-dev (>> 4.0.3-6~). I have replicated most of this information in README.Debian for the tiff package. -- Jay Berkenbilt pgp0mEJFZ4CCC.pgp Description: PGP signature
Re: virtual/alternative B-D (was Re: libtiff5 transition)
Sune Vuorela wrote: > On 2013-12-06, Thorsten Glaser wrote: >> Hm indeed. Makes me wonder whether it would not be better to make >> libtiff-dev the real package and abandon libtiffN-dev altogether. >> (Never understood why the -dev packages need the numbers, anyway.) > > The -dev packages needs numbers if you want to have several around at > the same time. My original proposal to debian-release was to drop libtiff4-dev and libtiff5-dev completely and to change the name of libtiff5-dev to libtiff-dev, but this makes it too hard to actually do the transition because too many packages become FTBFS for too long. You can see my original suggestion and subsequent discussion in bug 717923. Sorry about the suggestion to build-depend on a versioned virtual package. When we changed what the package was being called, I forgot to update that in my notes of what I was going to say. Many months elapsed between the original discussion and the uploads, and I just forgot about that detail. I think it would be best for people to avoid versioned dependencies on libtiff*-dev. The only reason to do it might be as a hint to backporters that they can't backport to a version of debian that doesn't have a libtiff5-dev alternative available to it. I think it would be best to just change all the build dependencies to libtiff-dev, but package maintainers and/or backporters should probably know what to do in those relatively rare cases where tiff 4.x is required. Most of those cases are going to GIS and similar applications, some of which may be using libgeotiff anyway, since that's where BIGTIFF is especially needed. Other packages, like vips (which I also happen to maintain), will detect with ./configure whether a tiff 4.x is in use and will use new functionality if available but will fall back if not. So if someone backported vips and ended up using a tiff 3.x version, they'd get a working package without BIGTIFF support. Perhaps after the dust settles and tiff3 is gone, I can rename libtiff5-dev to libtiff-dev, but that would break packages with versioned dependencies on libtiff5-dev and not provide much more than aesthetic benefit, so I'm not sure that it's worth it. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131206101706.0942190878.qww314...@jberkenbilt-linux.appiancorp.com
planning on requesting removal of xerces-c2
I'm planning on requesting removal of xerces-c2 soon. xerces-c2 is for 2.x versions of Xerces-C. Version 3.0.0 was released over 5 years ago now. I had hoped to remove xerces-c2 before the release of wheezy, but there were too many packages that depended on it at the time. There are now only five packages left that haven't already had removal requested, and some of those are no longer in testing. I have filed bug reports against the five packages asking them to change their build dependencies from libxerces-c2-dev to libxerces-c-dev, and I have a note on my calendar to follow up with possible NMUs in a few weeks. xerces-c2 is going to be very hard to support from a security standpoint, and most programs port to xerces-c without any changes, so it would be great to be back to having only one xerces-c in the archive for Jessie. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131224212421.0400323632.qww314...@soup.q.qbilt.org
libtiff5 transition mass bug filing
It's been a little over a month since my announcement to debian-devel that I would be preparing to remove the tiff3 package from debian and asking people to switch build dependencies on libtiff4-dev to libtiff-dev. There are 64 packages that have a version in either testing, unstable, or experimental that have a build dependency on libtiff4-dev. I'm about to do the mass bug filing. The text of the mass bug filing is the following: - The libtiff4-dev package is a transitional package that is going to disappear soon. Please update your build dependency from libtiff4-dev to libtiff-dev. - At this point, libtiff4-dev has actually been an alias for libtiff5-dev for several weeks, so this is basically a no-op for almost all packages. I am using the user tag libtiff4-dev (with user q...@debian.org) to mark the bug reports. http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libtiff4-dev;users=q...@debian.org -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140118223748.0400818596.qww314...@soup.q.qbilt.org
Re: Bug#735134: perl: rename(1) is ancient
Dominic Hargreaves wrote: > On Mon, Feb 03, 2014 at 09:28:03AM +, Jonathan Dowland wrote: >> Hi Gregor, >> >> On Sun, Feb 02, 2014 at 07:31:02PM +0100, gregor herrmann wrote: >> > It's the package for the CPAN File::Rename distribution, and >> > therefore named accordingly to >> > https://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-package_names >> > in Debian. >> >> Thanks for pointing me at that. It seems to me this makes sense for >> libraries but not for end-user binaries. >> >> > (Cf. also >> > http://pkg-perl.alioth.debian.org/policy.html#package_naming_policy ) >> >> This seems to agree since it suggests end-user binary packages should >> not follow the libfoo-bar-perl scheme. >> >> [ as a side-note, if the perl group are following the latter, then >> a minor-severity bug against policy to update the former to reflect >> that practise sounds like it might be in order. I'll do this unless >> anyone objects. ] >> >> I guess there are common situations where you have both an end-user >> binary and a perl module in the same source, and you might not want >> to split that into two binary packages (if they're very small or >> something), however that doesn't appear to be the case here. > > Yeah, I think I agree that this package should be named 'rename' since > it will be predominantly used as an standalone utility rather than > library. (I'm assuming noone is going to object to such a generic name). > I'll file a new bug for that. > > Thanks, > Dominic. Sorry to come late to the party, but I thought I'd chime in a few points. Feel free to disregard as they are not that important. I haven't read the whole thread, so hopefully I'm not covering previously covered ground. Back in 2004 before I was a debian developer, I was looking to package a script I wrote called patmv. patmv was inspired by rename perl but has slightly different behavior. You can find the thread about it here: https://lists.debian.org/debian-mentors/2004/04/msg00391.html The upshot of the discussion was that people objected to having a package for a single script even though there seemed to be general agreement that what it did was useful. It was suggested at the time that I try to get the script added to the renameutils package, but I never pursued that. If you would be interested in including patmv in your package or in following up on the idea of having it included in renameutils, I can supply patmv. I should put it online anyway in case anyone would find it useful. Basically the main difference between rename and my patmv script is that patmv keeps track of renames that it has already done and tries to operate on the last path element unless the -w flag is given. So, for example, if you wanted to take an entire directory and recursively make it lower-case, you can do that with patmv. Here is a quick illustration: % mkdir -p A/B/C % echo test > A/B/C/D % tree . └── A └── B └── C └── D 3 directories, 1 file % find . | rename tr/A-Z/a-z/ Can't rename ./A/B ./a/b: No such file or directory Can't rename ./A/B/C ./a/b/c: No such file or directory Can't rename ./A/B/C/D ./a/b/c/d: No such file or directory Note that rename fails here because after it renames A to a, the other files are no longer valid. The result is that just A got renamed: % tree . └── a └── B └── C └── D 3 directories, 1 file patmv can do this though: % mv a A % find . | patmv tr/A-Z/a-z/ mv ./A ./a mv ./a/B ./a/b mv ./a/b/C ./a/b/c mv ./a/b/c/D ./a/b/c/d % tree . └── a └── b └── c └── d 3 directories, 1 file % patmv -w s,/,.,g a/b/c/d mv a/b/c/d a.b.c.d Also, since patmv echoes the mv commands that it is running (unless run with -s), you can also do stuff like patmv -n s/\./_/g | sed -e 's/^/git /' to generate git mv commands. I use it this way all the time. If anyone is interested, I will take a few minutes and stick this with in a github repository. I also write a manual page for it when I was planning on packaging it. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140208172330.0402008619.qww314...@soup.appiancorp.com
Re: Preparing openjpeg 2.0
Jakub Wilk wrote: > * Mathieu Malaterre , 2014-03-24, 12:38: >> I am preparing to upload openjpeg 2.0. This is a major API (yes API) >> change from previous openjpeg 1.x. > > None of these openjpeg versions seem to use versioned symbols. If you > want to have both in the archive at the same, then both should use > them. As has already been pointed out, with tiff, the two versions were almost entirely API compatible. Also, tiff didn't have versioned symbols before the change, but upstream added versioned symbols to support the change. Even adding version symbols by slapping a version on every symbol is better than not having versioned symbols, and that turns out to be a really easy change. You can probably convince upstream to do it since none of the major Linux distributions are likely to be willing to take this without them. At least that was the experience I had with tiff. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140407141400.0240630403.qww314...@jberkenbilt-linux.appiancorp.com
anyone interested in adopting ICU?
aintain. Sometimes I can go months without having to touch it at all, and other times there is a flurry of activity dealing with backporting security fixes or fixing obscure problems. Many times problems have been found in pre-release versions, so I highly recommend packaging those in experimental and encouraging people to try them out. In this way, we have had very few problems with serious problems getting into unstable. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110509133500.3226151089.qww314159@motoko.argon.local
a few packages for adoption
** Please reply to me directly (or CC me on replies) as I am not currently subscribed to debian-devel. ** I recently became a father of twins and, as such, have less time to work on packages than I used to. While I do plan on keeping some of my packages, there are others I'm interested in finding new maintainers for, if anyone is interested: * ICU: This is ICU4C. I sent another (lengthy) message about it. * xerces-c, xerces-c2: These are two versions of Xerces-C (http://xerces.apache.org). These are generally pretty low effort to maintain, and upstream is helpful and responsive. xerces-c2 is an older version that is no longer really being maintained, and backporting security fixes to it can be very hard, but so far, there hasn't been anything major. xerces-c is the 3.x series and is actively maintained upstream. Note that xerces-c2 has an orphaned reverse dependency (xalan), which you may occasionally need to NMU, though I think I only had to do that one time. * libxml-xerces-perl: This is a Xerces-p, a perl interface to Xerces-c. As far as I can tell, it is dead upstream, and there are better alternatives. At one time, it was the only perl module capable of doing XML validation with both DTD and schema support and with the capability of providing values for default attributes when doing validation, but I haven't actually tried to determine whether that's true for about six or seven years. If no one wants this, I may orphan it or request removal. * psutils: This is a collection of tools including psnup and ps2ps. They are pretty popular, but the project has been dead upstream for a while. psutils is part of all the major distributions, and we all have various patches. I put some effort into trying to synchronize with other distributions a while ago. Our psutils package includes a few other tools that are not strictly part of the upstream distribution, and every now and then, someone posts a bug report asking for some additional utility to be added. Some of the time, there's a licensing reason or some other reason why it won't work out (so you have to be careful when analyzing these requests), but every now and then it works out. I'll wait a few days to give people a chance to reply. For the xerces packages, I'd probably give preference to the debian SGML/XML group or to other groups maintaining stuff from apache. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110509134418.322691.qww314159@motoko.argon.local
ICU 4.8 in experimental
[I am not currently subscribed to debian-devel, so please CC me on any response that I need to see.] I have uploaded ICU 4.8 to experimental. If you have a package that depends on ICU, please try testing with this version. I will coordinate with the release team to upload to unstable as soon as possible. Thanks. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110529084644.3019965905.qww314159@soup
Re: anyone interested in adopting ICU?
Please reply to me directly (or CC me on replies) as I am not currently subscribed to debian-devel. Enrico Weigelt wrote: > * Jay Berkenbilt schrieb: >> >> I'm looking for someone who might like to take over the icu package. >> This is ICU4C (C/C++), not to be confused with ICU4J (Java), which is a >> separate package maintained by someone else. ICU is "International >> Components for Unicode". > > If it's not urgent, I'd like to take the job (need some time to set > up an recent Debian build machinery again, as I didn't use it for > almost a year now, and I'm little bit busy right now :(). > > ICU4C is a little bit tricky case, as it tends to break ABI (sometimes > even API) between releases, sometimes even semantic changes (at least > had been the case in recent years). So I'd go for a full MVCc installation > (IMHO better than Gentoo's slotting + revdep-rebuild approach ;-p). > > I'll yet have to pull it through my own embedded QM process and > build machinery first, so we'll also get crosscompile fixups etc > as a buy-product here ;-) My offer stands, so if you'd like to take it, go right ahead. There's a problem right now with icu 4.8 in experimental on kfreebsd-amd64 that I haven't been able to solve in the 20 minutes or so I spent trying to figure it out. Also, 4.8.1 has been released, and I have not packaged yet. There is an open bug for tracking the transition to 4.8, but obviously these issues should be corrected first. How long do you think it will be before you are ready to adopt the package? Maybe you can take a look at bug 630517 and see if you can make some headway on it. Also, are you a DD? I can't find any indication that you are. I am not interested in sponsoring uploads (as I don't really have time to do the reviews, etc.), so hopefully I have either overlooked your debian account or you have sponsorship arrangements. I have a local subversion repository with all my packaging stuff in it, and I use svn-buildpackage against my local repository. If you're interested in a dump of that, let me know, and I can send it to you. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110724091158.0304813597.qww314159@soup
Re: anyone interested in adopting ICU?
Please reply to me directly (or CC me on replies) as I am not currently subscribed to debian-devel. Enrico Weigelt wrote: > * Jay Berkenbilt schrieb: >> I'm looking for someone who might like to take over the icu package. >> This is ICU4C (C/C++), not to be confused with ICU4J (Java), which is a >> separate package maintained by someone else. ICU is "International >> Components for Unicode". > > If it's not urgent, I'd like to take the job (need some time to set > up an recent Debian build machinery again, as I didn't use it for > almost a year now, and I'm little bit busy right now :(). > > . . . I should have done this a long time ago, but I finally got around to posting an RFA for this. The bug number is 638590. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110820090838.0299465509.qww314159@soup
packages for adoption: icu, tiff, xerces-c, psutils
I have four packages that I'd like to give away. If I don't find a new maintainer for them, I may orphan them after jessie is released since I no longer have time to maintain them. I have been maintaining these packages for a long time (over 10 years in some cases), and all four packages are in good shape. I have filed RFA bugs for each package. Two of the packages, tiff and icu, are important library packages with lots of reverse dependencies and frequent security issues. They are fairly low effort to maintain but require occasional surges of effort. In particular, ICU gets two non-binary-compatible (soname bump) upstream releases each year and requires regular coordination with the release team and often some of its downstream packages. The tiff packages are mostly inactive upstream but do get occasional upstream releases. The other two packages are relatively low-effort packages to maintain. The psutils package is dead upstream though there is someone out there who might be interested in taking over upstream. I would introduce him to any new maintainer. The xerces-c package is a library package but a pretty easy one as they go. It has few downstream packages within debian and gets very infrequent upstream releases. All four packages are maintained with git-buildpackage, but right now their repositories are in github because I switched all my packages over to git-buildpackage during a time when alioth had extended downtime. Pushing the repos over to a better/additional place is trivial, of course. I have provided additional information in the RFA bug reports: icu: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777694 tiff: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777695 xerces-c: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777698 psutils: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777699 -- Jay Berkenbilt signature.asc Description: PGP signature
Re: packages for adoption: icu, tiff, xerces-c, psutils
Ondřej Surý wrote: > JFTR I sent email to tiff RFA and I am willing to take over it. > > Thank you, Jay, for all your hardwork on libtiff4->libtiff5 transition > (and also for the rest of your packages). > > If you don't get any volunteers for the rest, please ping here and me > again after jessie release (instead of orphaning them). > > Cheers, > Ondrej This is great. Thanks for the response. Feel free to take over tiff at any time. There are open security issues that I haven't had time to take care of yet. If you take care of the security issues, you can grab the packages at that time. If you use git-buildpackage and want to take over the repos, you can get https://github.com/jberkenbilt/debian-tiff and push it to wherever. Obviously don't fork it on github since then I won't be able to delete my copy. I could be open to giving up vips and nip2 as well. They are very low effort, and upstream is super-responsive, so I can probably still handle them even with almost no time, but if you wanted them, I'd be open to it. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2015025047.0225557611.qww314...@jberkenbilt-linux.appiancorp.com
Re: packages for adoption: icu, tiff, xerces-c, psutils
Richard Winters wrote: > Hey there: > > Posting again because I didn't hit reply-all (sorry, but would rather > advertise I"m available for help to the whole mailing list.) > > I'm not a 'debian' maintainer or developer...total newbie to alioth -> > but I'm a c++ developer with over 10 years experience. I'm > experienced with linux and more specifically debian development (just > not officially). > > That said I'd love to get involved with Debian development -> I love > debian and live by it. Anyone willing to lemme help out would be > great. I check on alioth often...projects never seem to be posted for > help...as a newbie I'm confused how to get started -> I've read > documentation yet most of these emails looking for helping or > specifying a package to be orphaned require a dev or > maintainersome of the packages I've looked into helping out with > either dont have a buglist or are severely old and have dozens of > helpers already. > > I offer my help here because I tend to need the ICU packages for > building various things...if its gonna be orphaned I'd rather help > out... > > Samples of work can be provided if needed. My suggestion would be to read through the material at https://wiki.debian.org/DebianMaintainer and take it from there. Sounds like you're about where I was when I started with Debian in 2003: I was experienced Linux/C/C++ developer using tiff, xerces, and icu at work. I took over the packages with the help of sponsors and initially as a co-maintainer and used my experience there toward becoming a full debian developer about 18 months later. I'm afraid I don't have time or energy to help with the sponsorship, but maybe you can find someone who can take over maintaining icu with the intention of sponsoring you or who can sponsor you to take over maintenance. I got my start with the tiff packages by managing a transition that corrected an inadvertent binary compatibility problem without an soname bump, and through that, earned enough of a reputation to be able to move through the new maintainer process pretty easily. ICU presents an opportunity to do something similar. Take a look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757025. When I created that, ICU 53 was out, but I was not able to get the transition done for jessie. Now ICU 54 is out, and one of the first jobs of icu's next maintainer will be, post jessie, to orchestrate a transition of icu to version 54.1 or whatever is current at the time. This would be a good way to cut your teeth on slightly more advanced package maintenance activities required with library packages. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150211132653.0261594103.qww314...@jberkenbilt-linux.appiancorp.com
Re: packages for adoption: icu, tiff, xerces-c, psutils
Ian Jackson wrote:
> Jay Berkenbilt writes ("packages for adoption: icu, tiff, xerces-c, psutils"):
>> The other two packages are relatively low-effort packages to maintain.
>> The psutils package is dead upstream though there is someone out there
>> who might be interested in taking over upstream. I would introduce him
>> to any new maintainer. The xerces-c package is a library package but a
>> pretty easy one as they go. It has few downstream packages within debian
>> and gets very infrequent upstream releases.
>
> I regularly use psutils and would be happy to take it on.
That's great! Go ahead and retitle the RFA to ITA.
> I guess we should wait until after jessie before formalising this with
> an upload.
Yeah, unlike tiff and icu which have pending rc bugs that can hopefully
be fixed before jessie by my successor, psutils is not likely to have
any issues like that. Feel free to switch RFA to ITA and upload right
after jessie is released. Thanks!
--
Jay Berkenbilt
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/20150212163857.3019399151.qww314...@jberkenbilt-linux.appiancorp.com
orphaning psutils
retitle 777699 O: psutils -- PostScript document handling utilities thanks I'm going to go ahead and orphan these. The RFA has been open for a long time, and the package has not been adopted yet. I didn't actually notice that someone else had changed this to O and then it got changed back recently until just now, but this is RFA -> O filed by the current maintainer, and I'm about to follow this up by uploading an orphaned package. If Ian Jackson , who had previously indicated a willingness to adopt the package, would still be interested in adopting the package, he should of course do so. Otherwise, I suppose this is ready to be adopted by anyone else who wants to maintain it. Thanks. -- Jay Berkenbilt
Re: orphaning psutils
Ian Jackson wrote:
> Jay Berkenbilt writes ("orphaning psutils"):
>> retitle 777699 O: psutils -- PostScript document handling utilities
>> thanks
>>
>> I'm going to go ahead and orphan these. The RFA has been open for a long
>> time, and the package has not been adopted yet. I didn't actually notice
>> that someone else had changed this to O and then it got changed back
>> recently until just now, but this is RFA -> O filed by the current
>> maintainer, and I'm about to follow this up by uploading an orphaned
>> package.
>>
>> If Ian Jackson , who had previously
>> indicated a willingness to adopt the package, would still be interested
>> in adopting the package, he should of course do so. Otherwise, I suppose
>> this is ready to be adopted by anyone else who wants to maintain it.
>> Thanks.
>
> I have subscribed to the package in the PTS. I have indeed not yet
> got round to doing a maintainer upload. Neither have I found time to
> look in detail at the outstanding bugs to try to debug them. OTOH the
> package is not in terribly bad shape.
Ian, thanks for looking after it even without picking it up. You're
right -- the package is in decent shape. I've fixed all the major issues
with it, and there haven't been any new ones for a while. Most of the
outstanding bugs are either requests for functionality, bugs that are
upstream bugs and require deeper knowledge of the code to fix (the
package is dead upstream), or problems that seem related to other
systems generating PostScript that doesn't match what psutils is
expecting. Mostly these bugs should probably just be closed. Now-a-days,
PDF is in more common use for the kinds of things that psutils used to
be used for, and it's a better format than PostScript for this anyway
because there are clean and predictable ways to work with it. psutils
works by working with encapsulated postscript document structuring
comments, which is only reliable if the underlying document uses them
properly. Most don't. When people have big problems psutils, my general
advice to them is to use something like ps2pdf from ghostscript to
convert to PDF and then do the manipulations in PDF. Before psutils went
more or less completely idle upstream, I had coordinated with the author
to merge in some of the debian patches. The Debian psutils package has a
few added utilities that are not technically part of psutils but kind of
fit functionally into the package. The psmerge in our psutils package is
not the actual upstream psmerge at all but a perl script that depends on
ghostscript. At one point, I studied the Fedora package and tried to get
some convergence, but I don't think that went anywhere.
> If someone else wants to pick it up then they are very welcome.
>
> Otherwise I am still interested in the package and will certainly at
> least fix any RC bugs it may acquire.
Feel free to contact me any time if you have questions. This goes for
anyone else who may pick up the package as well.
--
Jay Berkenbilt
