Re: New adzapper package with Konqueror AdBlocK support
[Ludovic Drolez] Just import the file /var/lib/adzapper/konqueror.txt in the adblock panel. Feel free to send me any suggestion. Uh, wouldn't that belong in /usr/share? -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Re: Packages with RFCs deleted
[Charles Plessy] On the other hand, does the effort of removing these documents from the upstream sources has any chance to make things change in the future, by either having the IETF freeing the RFCs, or volunteers paraphrasing free versions of them? The fact that Debian cares about licensing issues, and doesn't just ship random things with random licenses on the theory that the users won't notice or won't care, very much sets us apart. It is a real value-add to many people. A lot of users appreciate our promise to read all the licenses so they don't have to. The moment we decide that, gosh, we may as well save ourselves some trouble and ship a few files that aren't actually free to modify and redistribute, users will no longer be able to trust us to do that, and they'll be back to reading long and boring license texts for themselves, just to determine what they can and can't do. Also, refusing to ship these harmless things raises the visibility of the issues. I often get into arguments where a potential user somewhere says WTF, Debian doesn't even ship RFCs [or Sun Java, or Schilling's cdrecord], what stupid and pointless ideology. When I start to explain which freedoms we promise to our users that these things do not offer, one of two things happens. Often the user will say I don't care about those freedoms anyway, or words to that effect. But sometimes ... sometimes the user will say Whoa, really? You mean I can't write my own document, cutting and pasting from an RFC, and distribute it outside the IETF process? and as I explain further, suddenly we have a user who notices, for the first time, that the RFC (or Sun Java, or whatever) actually _does_ restrict their rights in a way they might actually care about. This happens often enough that I'm convinced that a lot of users would care a lot about DFSG freedom if only they were aware of the issues. Debian's policy has the side effect of bringing visibility to the issues, to educate these users, and I think it is a good thing. Even if it isn't the primary purpose of the DFSG. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian's Linux kernel continues to regress on freedom
[Ron Johnson] If O'Reilly wants to write a book on implementing smtp or dns they must get permission from the IETF? Not if they either (1) do not quote the RFCs at all, beyond what is permitted by fair use, or (2) reprint the RFC verbatim. Those things are permitted, and those are what O'Reilly would probably want. What is not permitted is to create an email exchange protocol, or a hierarchical name record infrastructure protocol, which is similar to SMTP or DNS, and while doing so, use the appropriate RFCs as a starting point for producing your spec. (Note also that your new protocol doesn't even have to be all that similar to SMTP or DNS for the ability to cut and paste RFC text to be potentially useful to you.) I mean, you can do that, but only if you're willing to participate in the IETF standardization process. Which, if you're just some random company producing internal docs for an internal product, you probably don't want. Of course, you are free not to think Debian's required freedoms are actually useful or reasonable. That's nothing new; lots of people don't see why it's useful to require source code for software, either. Fact is, many of us _do_ think these freedoms are valuable, and we don't like the idea of trying to define little special cases, like well, nobody would probably want to cut and paste things from an RFC anyway, like they might from other documents. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Re: Debian's Linux kernel continues to regress on freedom
[Ron Johnson] If I decided that I wanted to build a better mousetrap, the first thing I'd do is go read the relevant RFCs. Right, and the second thing you'd do is start hammering out a spec for your improved protocol. Doing this by cutting and pasting bits from the existing RFC just might be a lot more convenient than rewriting your whole protocol spec from scratch. While I know that a source file is a document, some of us have more difficulty than others believing or even *agreeing* that traditional documents should be GPL-style libre. We're pretty much at an impasse, then, so I don't think I'll reply after this message. I, and many Debian folks, don't quite understand the essential difference, between functional source code and non-functional documents[*], that make the DFSG freedoms only important for the one and not the other. I mean, if I might want to freely make derivative works of software, well, maybe I want to freely make derivative works of spec documents too. For many of the same reasons, in fact. [*] And, in fact, RFC documents are more functional than most other documents. A few even include example source code. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: Bugfix/hardware support updates to stable releases?
[Charles Plessy] Actually, I would be happy to hear opinions (in private if you think the question was trivial) on the follwing bug : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425508 Basically, IBM does not distribute anymore the tarballs supported by Etch's `java-package', wich means that the package becomes much less useful on powerpc. If the package is totally broken because it can't download an external file it needs, then that would be an RC bug, appropriate to fix in an etch point release. It looks as though only part of the functionality is broken, though, in that there are multiple tarballs you can download with java-package and only one fails, so the situation is less clear. I'd still consider it something fixable in etch, but I'm neither a RM nor a java-package maintainer. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: what happened to social contract?
First, please STOP your habit of replying to the same message 4 or 5 times. I will do you the courtesy of reading your first reply, but probably not the rest, I just don't have that kind of time. Your multiple replies rarely add any substance anyway. [EMAIL PROTECTED] I think your problem is that you have confused our priorities are our users... with our priority is everything icelinux believes might help some subset of our users. I see, I must have confused subset of users with users. How dare you. You are effectively telling me that, because I care about Debian users, you can tell me what I should do with the time I devote to Debian, merely because you are a user. You are telling me that you know better than I do what I can do to benefit Debian users. Sorry, it doesn't work that way. I will spend my time doing what I think benefits Debian users, which is to fix bugs in existing packages. Not packaging and maintaining every little new thing you tell me to care about. The social contract does not say that the developers are obligated to pay attention as random users dictate their needs and desires. If you want to dictate your needs and desires to me, please reply in private so we can negotiate a contract. I won't do it for free, but I might do it if the price is right. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: what happened to social contract?
[EMAIL PROTECTED] I must have misunderstood, I thought this was what Debian was all about. Here I come in and point out that many users do not have everything they need or want, start a project to do something about it, and I am met with scorn and that would be too much extra work for us Do you actually have a point to make, or is this just generic trolling? I mean seriously - stop whining. You are met with scorn not because we don't care about our users, but because your questions are either naive or pugilistic. We don't really have time for either sort - that is what debian-mentors and slashdot, respectively, are for. I guess this is to be expected, all societies started with lofty goals and high ideals eventually fall prey to a similar fate. What fate? I guess I haven't noticed that Debian has fallen prey to any fate other than being extremely popular, with a solid userbase numbering in the millions (including a lot of very loyal fans), highly respected everywhere for both our philosophical and technical standards. I guess all those loyal users stick around because we don't care about them? I think your problem is that you have confused our priorities are our users... with our priority is everything icelinux believes might help some subset of our users. To which I can only say, get over yourself. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: proposed release goal: DEBIAN/md5sums for all packages
[Sven Mueller] He doesn't give any information _why_ this complicates packaging Because you then have to handle removal explicitly in postrm, rather than just letting dpkg take care of it. However, I don't agree that this complicates things enough to justify doing it. Especially when you end up with lintian getting a special case just to handle your needs. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: proposed release goal: DEBIAN/md5sums for all packages
[Lars Wirzenius] It strikes me that if we want to make it policy, having dpkg generate the checksums upon creating the .deb would be the simplest and best way to do it. I'd opt for dpkg generating the checksums upon _extracting_ the .deb file. We already claim that the md5sums file isn't supposed to be any kind of security thing. Why bother to ship it? It is redundant information which can easily be regenerated on the user's system. Russ's mention of packages that alter their installed files in the postinst just seems not worth supporting. Copy a template file instead. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: proposed release goal: DEBIAN/md5sums for all packages
[Russ Allbery] While it's not the be-all and end-all of security, other OS vendors (Sun in particular) have found it useful to make available a central database of MD5 checksums of known-good versions of various binaries. H. As far as being authoritative (and cryptographically secure), we already have $MIRROR/dists/stable/main/binary-i386/Packages.bz2. The thing is, if you're checking your system, you have to have something to check it against. If this is the md5sums file in /var/lib/dpkg/info, it doesn't matter whether it's included in the package. But if you're using the copy from the .deb (because, say, you don't trust your /var), it wouldn't be much harder to do 'dpkg-deb --extract' and then md5sum the extracted directory, than to do 'dpkg-deb --control' and read DEBIAN/md5sums. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: proposed release goal: DEBIAN/md5sums for all packages
[Joey Hess] It's even easier to do: dpkg --fsys-tarfile $deb | tar -C / -d Ha. I didn't know about tar -d. Yes, that is even better. However, not all machines have the luxury of being able to store the orignal .debs in /var, or of being able to redownload the same debs. Indeed, but that is unrelated to the discussion of storing a md5sums file in the .deb. (: -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: Request for ideas how to fix #297074
[Marcin Owsiany] What happens in step 3 is that vim looks at an ascii-only file (since msgids are in POSIX locale) and when the user inputs the translation in her own language, the editor decides to use encoding B (since it's the locale default). Then in step 5 poedit merges the original (in encoding A) and the temporary (in encoding B) creating a broken and a difficult to fix file with different parts in differing encodings. Uh ... I suppose you could add vim metadata to comments at the top of the temporary file, telling it to use a particular encoding. I forget the format vim uses for that. Might also include a -*- tag for emacs. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: new ICU in experimental
[Mike Hommey] Frankly, I'm not even sure the bump of soname is necessary on the library. That's an upstream question, though, right? Keeping an old soname in Debian when everyone outside Debian is using a new one would seem to cause more problems than it avoids. Of course the reverse is occasionally necessary, if an upstream doesn't bump their soname when they should. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: making debian/copyright machine-interpretable
[Sam Hocevar] And there is more to come. The GPL version 3 is compatible with the CDDL, but the GPL version 2 isn???t. Which means that in the near future, GPLv2-only software cannot be distributed as part of a CDDL operating system such as Nexenta. That's a rather delicate way of saying GPLv2-only software cannot be distributed as part of a CDDL operating system such as Nexenta - and this has always been true. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: release update: Release goals, testing transition, arch requalification
[Lionel Elie Mamane] Ok, now to the approved release goals: - full IPv6 support What does that mean precisely? Drop all packages that don't support IPv6? IPv6 shall be enabled if supported not too buggily? Something in between? (I'm quite certain you don't mean drop all packages that don't support IPv6.) Geez, I thought woody was supposed to fully support IPv6, except for a few rough edges. And that was how many years ago? I think it is high time to start talking about patching or dropping network apps that work with IPv4 but not IPv6. Of course, there will be a few apps that by their nature don't make sense in IPv6, such as anything related to NAT or the MBone, or whose functionality is provided quite differently in IPv6, such as dhcpd, or clients that require specific non-free IPv4 servers, such as libnet-amazon-perl. I suppose those can stay. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: Installation of Recommends by default on October 1st
[Bernd Zeimetz] Especially with -dev packages I can't see a reason to 'recommend' another package - either you need foo-dev to be able to use bar-dev, or not. Developers usually know which libraries they want to use. I disagree - I think Recommends is appropriate for a -dev package which only needs another -dev package in the static linking case. Or should that be Suggests? Currently I think most packagers use Depends here, which I believe is too strong. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: /bin/sh diversions
[Pierre Habouzit] the 3 biggest problems I've seen are: * [[ for test, trivial: add it as a test alias, and also check for ]] termination in the test.c builtin. Ummm, [[ is not the same as [. (If they were the same, there would have been no need to invent [[.) They behave quite differently with regard to argument quoting. Try this in bash: unset foo [ -n $foo ] echo foo is non-empty [[ -n $foo ]] echo foo is non-empty As you can see, only the second one works. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: /bin/sh diversions
[Oleg Verych] Not quoting possible empty argument is a script writing bug. Not when you use [[. This is exactly how [[ is supposed to work; it is explicitly defined to be shell syntax, as opposed to a builtin command, so it is allowed to cheat with argument quoting. If you don't like that, don't use [[ ... but if you're going to implement it, implement it correctly. A simple alias to [ is not correct. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: ITP: ttf-atarismall -- Very small 4 x 8 font
[Gürkan Sengün] Notes: I have created a fontforge sfd version which one can generate otf/ttf out of. If anyone knows how to limit the fontsize to 8 only for a otf/ttf font, please contact me. (The original font is in bdf format) If this font is intended to be used at one fixed size, why bother with ttf/otf at all? Just ship it as bdf. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: FTBFS if built twice in a row
[Lucas Nussbaum] The problem is that it isn't required to have exactly the same source tree after ./configure ; make ; make clean. It's just required that ./configure ; make ; make clean ; ./configure ; make works. It is possible that the first build modifies some files, but that the package can still be built, without being differerent from the one from the first build. How about this then: if you debuild without -b, -B, or -nc, it builds a source package before building the binary packages. What if it were to build another source package afterwards, and compare the two .diff.gz files? Timestamps in the diff would be ignored. But if the actual file contents of the diff were different, that would IMO be a bug. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: Archive rebuild with improved dpkg-shlibdeps
[Raphael Hertzog] Also, please omit @Base from the log messages, it adds visual clutter without adding information. Well, it can be worthwhile to know which version the symbol is attached to. If I remove it, I only remove @Base and not @GLIBC_2.4 or any other versions. Yeah, I meant @Base specifically. Of course it's useful to report on other symbol versions. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: Archive rebuild with improved dpkg-shlibdeps
[Raphael Hertzog] If you encounter any strangeness, please report it so that we can check. Those warnings could be the base of some mass-bug filings althought we might want to start with the second one (those are real bugs, while the other are not creating any technical problem (except useless dependencies)). Please do not file bugs for unnecessary linking _except_ where this actually changes the Depends line. In many cases upstream might link several binaries against a fixed list of libraries, where not every binary needs every library. This is generally quite annoying to fix, and is not worth the trouble, since it doesn't affect package relationships or install/remove/upgrade scenarios. Also, please omit @Base from the log messages, it adds visual clutter without adding information. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: APT 0.7 for sid
[Daniel Burrows] I'm in favor of either enabling this by default in apt or downgrading Recommends in policy to just a really Suggests. [snip interesting background material] I would suggest - nay, I would recommend - keeping Policy the way it is and fixing packages to use Recommends as it was intended. It is a very useful semantic and I wouldn't want to see it get lost. We already have Suggests, after all. This has led to a situation where I occasionally hear things like this statement, from a developer whose incorrect Recommendation was being obeyed by aptitude and breaking the system: It's things like this that encourage me to continue using apt-get instead of aptitude! Simply astonishing. I hope the developer was roundly larted, by you or someone else, with a copy of Policy printed on heavy paper and hardbound with brass accents. Peter signature.asc Description: Digital signature
Accepted subversion 1.4.4dfsg1-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 07 Jun 2007 00:57:11 -0500 Source: subversion Binary: libsvn-javahl libsvn1 libsvn-perl libsvn-doc libsvn-dev libsvn-ruby libapache2-svn libsvn-ruby1.8 libsvn-java python-subversion subversion-tools subversion Architecture: source all i386 Version: 1.4.4dfsg1-1 Distribution: unstable Urgency: low Maintainer: Peter Samuelson [EMAIL PROTECTED] Changed-By: Peter Samuelson [EMAIL PROTECTED] Description: libapache2-svn - Subversion server modules for Apache libsvn-dev - Development files for Subversion libraries libsvn-doc - Developer documentation for libsvn libsvn-java - Java bindings for Subversion libsvn-javahl - Java bindings for Subversion (dummy package) libsvn-perl - Perl bindings for Subversion libsvn-ruby - Ruby bindings for Subversion (dummy package) libsvn-ruby1.8 - Ruby bindings for Subversion libsvn1- Shared libraries used by Subversion python-subversion - Python bindings for Subversion subversion - Advanced version control system subversion-tools - Assorted tools related to Subversion Closes: 416582 419348 Changes: subversion (1.4.4dfsg1-1) unstable; urgency=low . * New upstream version. - Fixes rare case of data loss / repository corruption. (Closes: #419348) * Fix note in README.Debian about how to download vc-svn.el. Thanks to Michael Richters. (Closes: #416582) * rules: configure --disable-neon-version-check, to allow use of neon 0.26.3. * rules: replace $(PWD) with $(CURDIR) to appease lintian. Our use of PWD was safe, this is just a cleanup. * rules: ship a shlibs file only for libsvn1; nobody should ever link to the libraries in other packages. (Thanks again to lintian.) - lintian-overrides: inform lintian that it's ok not to have shlibs files in the swig-based packages Files: aa313c15bc6312ee714c8330cd183a92 1239 devel optional subversion_1.4.4dfsg1-1.dsc 5b47bc3439cd5bd009a1262255df66ef 6457862 devel optional subversion_1.4.4dfsg1.orig.tar.gz b5e305515a5ab81e76a1a6f72d3aba3e 76758 devel optional subversion_1.4.4dfsg1-1.diff.gz 5d1d0d706f3f30ca6c0c239623cfe440 1122700 doc extra libsvn-doc_1.4.4dfsg1-1_all.deb 25e25af195449c09c89396be55275730 168306 admin extra subversion-tools_1.4.4dfsg1-1_all.deb 99e99d3f7a0ddc8db9cda2e82ed3d9ba 774 devel optional libsvn-javahl_1.4.4dfsg1-1_all.deb 54bae93b1a7ba55ec71f5f1a783e9a2b 744 devel optional libsvn-ruby_1.4.4dfsg1-1_all.deb 352e596ab3936ba2d3d2223b3e1f91d3 1052272 devel optional subversion_1.4.4dfsg1-1_i386.deb 4fafaa5615a14ded8e3d919281845cb1 595214 libs optional libsvn1_1.4.4dfsg1-1_i386.deb 6906420e21417057d90f7c6c33584ace 815804 libdevel extra libsvn-dev_1.4.4dfsg1-1_i386.deb d0ab3f2e1db039c32fd09ef5abeb6b1b 133726 net optional libapache2-svn_1.4.4dfsg1-1_i386.deb d36bcc7e36f15fd3c31d2ebcc85b73ea 512074 python optional python-subversion_1.4.4dfsg1-1_i386.deb af08207dd7cfa41919569b686c0196f7 214674 devel optional libsvn-java_1.4.4dfsg1-1_i386.deb 66bef2bb7b04785c8f0a2e8365bb 805346 perl optional libsvn-perl_1.4.4dfsg1-1_i386.deb d5fb7ae54ed6d4b465b29b0e0db92c01 382174 devel optional libsvn-ruby1.8_1.4.4dfsg1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGagG5QOr9C+GfGI4RAsY3AKDCBP177FSugLggDFE7AkxlH1r+KACfTdEW VN48pq5yf/8BV600+37JpoU= =Xj6j -END PGP SIGNATURE- Accepted: libapache2-svn_1.4.4dfsg1-1_i386.deb to pool/main/s/subversion/libapache2-svn_1.4.4dfsg1-1_i386.deb libsvn-dev_1.4.4dfsg1-1_i386.deb to pool/main/s/subversion/libsvn-dev_1.4.4dfsg1-1_i386.deb libsvn-doc_1.4.4dfsg1-1_all.deb to pool/main/s/subversion/libsvn-doc_1.4.4dfsg1-1_all.deb libsvn-java_1.4.4dfsg1-1_i386.deb to pool/main/s/subversion/libsvn-java_1.4.4dfsg1-1_i386.deb libsvn-javahl_1.4.4dfsg1-1_all.deb to pool/main/s/subversion/libsvn-javahl_1.4.4dfsg1-1_all.deb libsvn-perl_1.4.4dfsg1-1_i386.deb to pool/main/s/subversion/libsvn-perl_1.4.4dfsg1-1_i386.deb libsvn-ruby1.8_1.4.4dfsg1-1_i386.deb to pool/main/s/subversion/libsvn-ruby1.8_1.4.4dfsg1-1_i386.deb libsvn-ruby_1.4.4dfsg1-1_all.deb to pool/main/s/subversion/libsvn-ruby_1.4.4dfsg1-1_all.deb libsvn1_1.4.4dfsg1-1_i386.deb to pool/main/s/subversion/libsvn1_1.4.4dfsg1-1_i386.deb python-subversion_1.4.4dfsg1-1_i386.deb to pool/main/s/subversion/python-subversion_1.4.4dfsg1-1_i386.deb subversion-tools_1.4.4dfsg1-1_all.deb to pool/main/s/subversion/subversion-tools_1.4.4dfsg1-1_all.deb subversion_1.4.4dfsg1-1.diff.gz to pool/main/s/subversion/subversion_1.4.4dfsg1-1.diff.gz subversion_1.4.4dfsg1-1.dsc to pool/main/s/subversion/subversion_1.4.4dfsg1-1.dsc subversion_1.4.4dfsg1-1_i386.deb to pool/main/s/subversion/subversion_1.4.4dfsg1-1_i386.deb subversion_1.4.4dfsg1.orig.tar.gz to pool/main/s/subversion/subversion_1.4.4dfsg1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependencies on shared libs, take 2
[Josselin Mouette] A possible part of the solution would be a script parsing the diff between headers and emitting warnings such as: * type foo has changed, please check it doesn't affect functions bar/baz/... * enum foo has new possible values, please check it doesn't affect functions ABI * OMFFSM function bar's prototype has changed! * struct foo has changed, please kill upstream Sounds like a job for icheck (maintainer CC'd). Consider adapting that rather than reinventing it. Of course it wouldn't be enough to detect more subtle changes like new supported file formats, which only change the code, not the headers. Right, in cases where new _features_ (or, indeed, bug fixes) affect a particular reverse dep, obviously there's no general way to handle that automatically. Which is comforting, in a way; it's nice to know we can't all be replaced with a very small shell script. signature.asc Description: Digital signature
Re: Dependencies on shared libs, take 2
[Russ Allbery] They *usually* do, but not all E tags are certain problems. Of course, maintainers could use overrides. I'm opposed to adding overrides to my packages for cases where, in my view, lintian should somehow have enough information to see the case as a false positive. I use them only when a lintian check seems useful in the general case but I cannot think of a reasonable way for the check to be fixed to ignore my situation. I suppose others feel that being lintian-clean is so important that it's worth muddying the waters by overriding all false positives, not only the exceptional situations but the lintian bugs. If most people feel that way, I guess it would be reasonable to add lintian to the set of dak sanity checks. But I don't believe I'm the only one who disagrees. signature.asc Description: Digital signature
Re: Building packages twice in a row
[Lennart Sorensen] But dpkg-buildpackage will then spit out lots of warnings about being unable to store the deletion of a binary file in the diff. So it will look ugly, but work I guess. dpkg-buildpackage doesn't store _any_ deletions in the diff.gz - the warning about deletions has nothing to do with a file being binary or not. (It also warns about binary files being _modified_, which is quite a different matter.) In my opinion, dpkg-buildpackage should not warn about deleted files at all, since it is a common and correct practice. It is much easier and less error-prone than saving/restoring pristine files, and as such, it ought to be encouraged, not warned about. I'd file a bug asking for this, but clearly the warning is intentional, so a bug is not likely to get much more attention than #12564, which is also related. signature.asc Description: Digital signature
Re: passing options to modules loaded in initramfs
[Martín Ferrari] So, this could be handled by various ways: - Putting notices in relevant places so that everybody can understand what's happening (release notes, FAQs, package documentation..) - Compiling with CONFIG_BLK_DEV_IDE=y (Ubuntu does this) A growing number of people no longer need that module - not only SCSI users but now libata users. Then again, since usb_storage needs it (strange but true, it needs one trivial function from it) - Adding more intelligence to initramfs to detect this options and pass them to the correct module That sounds sanest to me. signature.asc Description: Digital signature
Re: LDAP breaks kcheckpass when not setuid root (#298148)
On Fri, May 04, 2007 at 11:51:02PM +0200, Petter Reinholdtsen wrote: Actually, you got it backwards, as explained above. pam-ldap isn't using the password hash to check the password. It is passing the password over to the LDAP server (using an LDAP bind), and letting the LDAP server decide if the password is correct or not. [Roberto C. Sánchez] You mean that the passwords go in the clear? Yes, unless you are securing the entire LDAP session, using SSL. signature.asc Description: Digital signature
Re: packages newer in Ubuntu than in Debian (reduced false positives)
[Bart Martens] I've thought about adding an column for the versions in experimental, but that is not a high priority to me because this does not change that Debian Unstable is outdated for the listed packages. Uh ... I thought the point of your project was to help package maintainers. Obviously if the maintainer has put something in experimental, he has already done the work to package it! Wouldn't putting the experimental version in your table be _more_ useful than the sid version, if it's newer? signature.asc Description: Digital signature
apache 1.3 will soon be removed from testing/unstable
[sean finney] just a heads up, php4 will not be supported in lenny and will be disappearing from the unstable trees sometime in the not too distant future. Same for apache 1.3 (including apache, apache-ssl, apache-perl); it too will soon disappear from sid and lenny. There are currently only a handful of apache 1.3 module packages in sid, against which bugs will be filed, but there are quite a few packages which depend on things like apache | httpd, which should be updated, though not urgently. Reply-To set to to the debian-apache list. Peter signature.asc Description: Digital signature
Re: apache 1.3 will soon be removed from testing/unstable
[Matthew Wilcox] Should apache2 Replace/Provide: apache in Lenny in order to facilitate upgrades from Etch? My feeling is no, because migrating a config from one to the other is a Fairly Hard Problem. It was hard enough to try to migrate 2.0 to 2.2, we didn't even get that right in all cases. signature.asc Description: Digital signature
Re: Mandatory -dbg packages for libraries? (and API docs too)
[Neil Williams] I chose Debian as a development platform for my own reasons and my decision was not deemed to be wise in the eyes of some of my upstream colleagues. As the newbie to that particular team, I was under significant pressure to upgrade to Fedora or SuSE. Are you saying Fedora and SuSE have API documentation for all the libraries they ship? I must say, that surprises me. My own experience with upstream's opinion of Debian is that they think we should have fixed #291641 a long, long time ago. And I can't disagree. (The problem is that since libtool apparently exposes a shortcoming in binutils, nobody seems willing to add a workaround to libtool, waiting instead for a fix from binutils.) signature.asc Description: Digital signature
Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)
[Luis Matos] CATIA has unix versions ... i don't really know if they will ever have linux versions. I'd be pretty surprised if they ever did. The CATIA 4 architecture would have fit Linux very well, if Dassault had seen a market for it back then (it was based on Motif, OpenGL and a huge Fortran/C API available for extensions - yes, F77, including those 6-char function names), but CATIA 5 is all about VB scripting, data interchange with Excel, stuff like that. The Unix port runs on a Windows emulation toolkit of some sort, and truly is a second-class port - last I tried it, at least, it felt very Windowsy and very slow. Even assuming the toolkit is available for Linux, I can't see anyone getting excited about deploying CATIA that way. I had the distinct impression that Dassault would like for interest in the Unix port to dwindle away so they wouldn't have to bother. signature.asc Description: Digital signature
Accepted apache2 2.2.3-4 (source all amd64 i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 27 Mar 2007 07:06:49 -0500 Source: apache2 Binary: apache2-utils apache2-prefork-dev apache2 apache2-mpm-prefork apache2-doc apache2-mpm-event apache2.2-common apache2-mpm-worker apache2-src apache2-threaded-dev apache2-mpm-perchild Architecture: all amd64 i386 source Version: 2.2.3-4 Distribution: unstable Urgency: high Maintainer: Debian Apache Maintainers debian-apache@lists.debian.org Changed-By: Peter Samuelson [EMAIL PROTECTED] Description: apache2- Next generation, scalable, extendable web server apache2-doc - documentation for apache2 apache2-mpm-event - Event driven model for Apache HTTPD 2.1 apache2-mpm-perchild - Transitional package - please remove apache2-mpm-prefork - Traditional model for Apache HTTPD 2.1 apache2-mpm-worker - High speed threaded model for Apache HTTPD 2.1 apache2-prefork-dev - development headers for apache2 apache2-src - Apache source code apache2-threaded-dev - development headers for apache2 apache2-utils - utility programs for webservers apache2.2-common - Next generation, scalable, extendable web server Closes: 396782 407171 415775 Changes: apache2 (2.2.3-4) unstable; urgency=high . * High-urgency upload for RC bugfixes. * Ack NMUs - thanks Andi, Steve. * Refactor apache2.2-common.postinst slightly, to account for sarge upgrades (since it's a new package name, rather than an upgrade). (Closes: #396782, #415775) * If mod_proxy was configured in sarge, add proxy_http and disk_cache modules, which used to be included in the mod_proxy config. (Closes: #407171) Files: 0cf48600c189ba1c7a39c12fc3e3e9c0 416660 web optional apache2-mpm-prefork_2.2.3-4_i386.deb 2f704ffd6c26ae80096bada82a8d289c 340270 web optional apache2-utils_2.2.3-4_amd64.deb 40287bdb181cacd02edf755db606a016 420750 web optional apache2-mpm-worker_2.2.3-4_i386.deb 60d71587edd8ccf73e901d6a1166ec8c 931828 web optional apache2.2-common_2.2.3-4_i386.deb 63c467512ab4c88ca6f1b8b741615ea4 403224 devel optional apache2-prefork-dev_2.2.3-4_i386.deb 6763826c8e099e2341e065f307aff000 421116 web optional apache2-mpm-event_2.2.3-4_i386.deb b13ea035f24dcd88fb0fa51b5b69eb92 965278 web optional apache2.2-common_2.2.3-4_amd64.deb c08c212d5ea22e719c677503ee5c2f31 340720 web optional apache2-utils_2.2.3-4_i386.deb c0fb4609da31ae104141b453152a8c38 403392 devel optional apache2-prefork-dev_2.2.3-4_amd64.deb c417aa8bd6b797269bceb2f82f942579 432876 web optional apache2-mpm-event_2.2.3-4_amd64.deb 0c9ad4a8cd0484d879ed6e73d064e886 6669388 devel extra apache2-src_2.2.3-4_all.deb cfdb4895e84c5ce767b185de6b8ba02e 403956 devel optional apache2-threaded-dev_2.2.3-4_amd64.deb d4543ece6bc25303b2667df2da50f1dc 403802 devel optional apache2-threaded-dev_2.2.3-4_i386.deb de8022076e6184b8d2a10b4b54126af9 38598 web optional apache2_2.2.3-4_all.deb e615c29c9b8b4a531d6022dbf033949a 428770 web optional apache2-mpm-prefork_2.2.3-4_amd64.deb c0c3b17e2db54a3260243138817798f7 1056 web optional apache2_2.2.3-4.dsc f3a48f1a93f88a398b69d8742fbb0b8e 2119558 doc optional apache2-doc_2.2.3-4_all.deb 42608a4d747c473ed4a1314e63c599ee 271994 web optional apache2-mpm-perchild_2.2.3-4_all.deb fd200cf87715defd2e701fbedcbf36c0 432470 web optional apache2-mpm-worker_2.2.3-4_amd64.deb 8972470b3a2da936e357aef5e9e452cc 102928 web optional apache2_2.2.3-4.diff.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGCSU9fPP1rylJn2ERAmo+AJwNpphWRdC/PR1LQ9GB2JheI2gR5QCeJcAV MM5nMFyJsEM3tA1t1zgo+ug= =+FPW -END PGP SIGNATURE- Accepted: apache2-doc_2.2.3-4_all.deb to pool/main/a/apache2/apache2-doc_2.2.3-4_all.deb apache2-mpm-event_2.2.3-4_amd64.deb to pool/main/a/apache2/apache2-mpm-event_2.2.3-4_amd64.deb apache2-mpm-event_2.2.3-4_i386.deb to pool/main/a/apache2/apache2-mpm-event_2.2.3-4_i386.deb apache2-mpm-perchild_2.2.3-4_all.deb to pool/main/a/apache2/apache2-mpm-perchild_2.2.3-4_all.deb apache2-mpm-prefork_2.2.3-4_amd64.deb to pool/main/a/apache2/apache2-mpm-prefork_2.2.3-4_amd64.deb apache2-mpm-prefork_2.2.3-4_i386.deb to pool/main/a/apache2/apache2-mpm-prefork_2.2.3-4_i386.deb apache2-mpm-worker_2.2.3-4_amd64.deb to pool/main/a/apache2/apache2-mpm-worker_2.2.3-4_amd64.deb apache2-mpm-worker_2.2.3-4_i386.deb to pool/main/a/apache2/apache2-mpm-worker_2.2.3-4_i386.deb apache2-prefork-dev_2.2.3-4_amd64.deb to pool/main/a/apache2/apache2-prefork-dev_2.2.3-4_amd64.deb apache2-prefork-dev_2.2.3-4_i386.deb to pool/main/a/apache2/apache2-prefork-dev_2.2.3-4_i386.deb apache2-src_2.2.3-4_all.deb to pool/main/a/apache2/apache2-src_2.2.3-4_all.deb apache2-threaded-dev_2.2.3-4_amd64.deb to pool/main/a/apache2/apache2-threaded-dev_2.2.3-4_amd64.deb apache2-threaded-dev_2.2.3-4_i386.deb to pool/main/a/apache2/apache2-threaded-dev_2.2.3-4_i386.deb apache2-utils_2.2.3-4_amd64.deb to pool/main/a/apache2/apache2-utils_2.2.3-4_amd64.deb apache2-utils_2.2.3-4_i386.deb
Re: Compiling Debs on AMD vs. Intel and 32bit vs. 64bit
[Wouter Verhelst] Both amd64 and x86_64 are names that AMD coined to describe the architecture. They changed their opinion at some point, I don't know which is the most recent name they chose. AMD64 is the newer name. When Intel released their clone chip, the Linux kernel was still using the older x86-64 name, but Debian's amd64 project had already switched to the new name. Linus Torvalds read Intel's announcement and was a bit disgusted that Intel tried as hard as they could to imply (without actually saying so) that the architecture was their own invention - he said he was sorely tempted to call it amd64 in kernel-land, but pragmatism won out over emotion. As I recall, Debian kept the new name partly because it would have been annoying to change back, but also to avoid the '-' and '_' characters, which can be problematic in some contexts (like autoconf tuples or .deb filenames). And x8664 just looks funny. (x86=64 would have been amusing too. Is it a veiled Commodore 64 reference, or is it quoted-printable?) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: May one use ~rc1 within versions although older lintians are complaining?
[Roman Müllenschläder] So, why are you using a version that's not the one in testing, nor the one in stable? Because my laptop, where I'm building the packages on, is running Edgy ;) I know I'm stating the obvious here ... but you shouldn't try to develop packages for Debian exclusively on Ubuntu systems. You won't be able to test your packages. Not being able to test your packages is generally considered a Bad Thing. (Or you at least tell your sponsor this package has not been tested on Debian, right?) signature.asc Description: Digital signature
Re: On management
[Roberto C. Sanchez] I am not advocating having a manager without technical competency or the ability to understand technical issues. Just that being a manager does not require being a fourth-degree blackbelt in Perl or having written a textbook on C++ programming. And you think the current NM process is geared toward people who have a fourth-degree blackbelt in Perl or have written a textbook on C++ programming? My experience is that the expectations on new maintainers are far, far lower. You're supposed to know how to build packages that don't suck, but I don't remember noticing any test of my skills as a programmer, beyond simple shell scripting. If an applicant knows enough about Debian's technical side of things to be an effective manager for Debian processes, I don't see why that person should have any more trouble with NM than programmers do. Peter, also in NM signature.asc Description: Digital signature
Accepted subversion 1.4.3dfsg1-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 25 Jan 2007 18:30:04 -0600 Source: subversion Binary: libsvn-javahl libsvn1 libsvn-perl libsvn-doc libsvn-dev libsvn-ruby libapache2-svn libsvn-ruby1.8 libsvn-java python-subversion subversion-tools subversion Architecture: source all amd64 Version: 1.4.3dfsg1-1 Distribution: experimental Urgency: low Maintainer: Peter Samuelson [EMAIL PROTECTED] Changed-By: Peter Samuelson [EMAIL PROTECTED] Description: libapache2-svn - Subversion server modules for Apache libsvn-dev - Development files for Subversion libraries libsvn-doc - Developer documentation for libsvn libsvn-java - Java bindings for Subversion libsvn-javahl - Java bindings for Subversion (dummy package) libsvn-perl - Perl bindings for Subversion libsvn-ruby - Ruby bindings for Subversion (dummy package) libsvn-ruby1.8 - Ruby bindings for Subversion libsvn1- Shared libraries used by Subversion python-subversion - Python bindings for Subversion subversion - Advanced version control system subversion-tools - Assorted tools related to Subversion Changes: subversion (1.4.3dfsg1-1) experimental; urgency=low . [ Peter Samuelson ] * New upstream version. - patches/neon26 removed; applied upstream * rules: Small cleanups, thanks to Patrick Desnoyers. * patches/jelmer-python-bindings: Remove some python2.4isms (should help with porting to sarge and elsewhere). Thanks to Romain Francoise, and upstream. Files: 2c22bf09e140c2d2f10c7c8ab79e9520 1239 devel optional subversion_1.4.3dfsg1-1.dsc 10db033e91a76f470c343e38eb088f5e 6453130 devel optional subversion_1.4.3dfsg1.orig.tar.gz d837e3865a7695726254e47148aad9c7 76654 devel optional subversion_1.4.3dfsg1-1.diff.gz c9a99a346fd5ab9974d6e952592f29f6 1071286 doc extra libsvn-doc_1.4.3dfsg1-1_all.deb 837fb9a940ff10f5fc59f5640fec03a7 167192 admin extra subversion-tools_1.4.3dfsg1-1_all.deb 76b0187b8a061abd4e3d184da36a9f88 772 devel optional libsvn-javahl_1.4.3dfsg1-1_all.deb 6f342b2fac288e80f3235a91d8cc3e24 740 devel optional libsvn-ruby_1.4.3dfsg1-1_all.deb 46a0c88b45e99b68ac5c7652f2d83a52 1063062 devel optional subversion_1.4.3dfsg1-1_amd64.deb c954c1f2d44a526433a965c17186d46d 643338 libs optional libsvn1_1.4.3dfsg1-1_amd64.deb ce4c6d0aa0443d7661646e16cf9cd60f 921440 libdevel extra libsvn-dev_1.4.3dfsg1-1_amd64.deb 4efb15bc6019634ffe58ff590117dd7b 137256 net optional libapache2-svn_1.4.3dfsg1-1_amd64.deb c0018e1c468a42e4e9530a567ccb438c 587372 python optional python-subversion_1.4.3dfsg1-1_amd64.deb 3c7adcf7ce1469675345312c71277c75 214334 devel optional libsvn-java_1.4.3dfsg1-1_amd64.deb 77d5f7ac0431642e8454a517dc66768d 858242 perl optional libsvn-perl_1.4.3dfsg1-1_amd64.deb 3a3b4c038897d61b06c3f160e46afe9e 429138 devel optional libsvn-ruby1.8_1.4.3dfsg1-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFujYpQOr9C+GfGI4RAhIBAJ91NY4eRAVcQ57wFGTggbkZRzlOlQCfYwDN zXJGqFQRqhuN4LLHzKuXS8c= =kIkk -END PGP SIGNATURE- Accepted: libapache2-svn_1.4.3dfsg1-1_amd64.deb to pool/main/s/subversion/libapache2-svn_1.4.3dfsg1-1_amd64.deb libsvn-dev_1.4.3dfsg1-1_amd64.deb to pool/main/s/subversion/libsvn-dev_1.4.3dfsg1-1_amd64.deb libsvn-doc_1.4.3dfsg1-1_all.deb to pool/main/s/subversion/libsvn-doc_1.4.3dfsg1-1_all.deb libsvn-java_1.4.3dfsg1-1_amd64.deb to pool/main/s/subversion/libsvn-java_1.4.3dfsg1-1_amd64.deb libsvn-javahl_1.4.3dfsg1-1_all.deb to pool/main/s/subversion/libsvn-javahl_1.4.3dfsg1-1_all.deb libsvn-perl_1.4.3dfsg1-1_amd64.deb to pool/main/s/subversion/libsvn-perl_1.4.3dfsg1-1_amd64.deb libsvn-ruby1.8_1.4.3dfsg1-1_amd64.deb to pool/main/s/subversion/libsvn-ruby1.8_1.4.3dfsg1-1_amd64.deb libsvn-ruby_1.4.3dfsg1-1_all.deb to pool/main/s/subversion/libsvn-ruby_1.4.3dfsg1-1_all.deb libsvn1_1.4.3dfsg1-1_amd64.deb to pool/main/s/subversion/libsvn1_1.4.3dfsg1-1_amd64.deb python-subversion_1.4.3dfsg1-1_amd64.deb to pool/main/s/subversion/python-subversion_1.4.3dfsg1-1_amd64.deb subversion-tools_1.4.3dfsg1-1_all.deb to pool/main/s/subversion/subversion-tools_1.4.3dfsg1-1_all.deb subversion_1.4.3dfsg1-1.diff.gz to pool/main/s/subversion/subversion_1.4.3dfsg1-1.diff.gz subversion_1.4.3dfsg1-1.dsc to pool/main/s/subversion/subversion_1.4.3dfsg1-1.dsc subversion_1.4.3dfsg1-1_amd64.deb to pool/main/s/subversion/subversion_1.4.3dfsg1-1_amd64.deb subversion_1.4.3dfsg1.orig.tar.gz to pool/main/s/subversion/subversion_1.4.3dfsg1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Suggesting new method to handle dpkg diversions
[keeping debian-devel CC, this seems to still be relevant] [Goswin von Brederlow] What if each package could list all its current diversions in DEBIAN/diverions (i.e. in the control.tar.gz)? Upon install dpkg would then add those diversions to its list and removed them on deinstall. During updates it would add new diversions before unpacking and remove obsolete diversions after removal of old files. Sounds to me like a job for a 'dh_diversions' script, and 'debian/packagename.diversions' files in the source package. Or maybe a 'dh_alternatives' that handles both alternatives and diversions, since they are similar concepts and alternatives are a great deal more common. Presumably slave alternatives would be handled by indenting the slave line just under its master. Peter signature.asc Description: Digital signature
Re: libapache-mod-auth-mysql
[Raphaël Pinson] Some time ago, libapache-mod-auth-mysql was removed from Debian testing because it didn't work. However, this package is largely used and really needs to be present in Debian. After spending some time trying to find a patch, I finally packaged the new upstream version and made a new package, including a patch from Mandriva to make it work with Apache 2.2. Does it actually work properly? Does it integrate with the apache 2.2 auth model? I understand the supported way forward is to use mod_authn_dbd (included in apache) with its mysql backend. Which I plan to try to support for etch, though we don't currently. Are you in a position to test a migration to mod_authn_dbd and report whether it works? If you could, that would be wonderful so we can document the process in a NEWS.Debian or something. You'll need libaprutil1 from http://p12n.org/tmp/apr-util+mysql/, which is not yet uploaded to unstable. Thanks, Peter signature.asc Description: Digital signature
Re: Etch Software RAID Upgrade Trouble Suggested Installer Improvements
[Claus Fischer] 9. cdrecord's miserable state is well known Like the majority of other Linux users, I wonder when $ burn_my_iso_to_cd iso-file /dev/cdrom will work as expected. Hmmm. $ wodim filename.iso works for most situations. But: 1) You must be root, or a member of the 'cdrom' group. Use 'adduser yourusername cdrom' to define the group membership, users allowed to talk directly to the CD drives. (Note also, changes in group membership only take effect at login time.) 2) You have a /dev/cdrw symlink to your CD writer device. I'm not certain whether that symlink is set up automatically by udev, as I don't use udev. If you want to use a different default device than /dev/cdrw, see /etc/wodim.conf. signature.asc Description: Digital signature
Accepted gpm 1.19.6-24 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 5 Jan 2007 05:46:52 -0600 Source: gpm Binary: libgpmg1 gpm libgpmg1-dev Architecture: source amd64 Version: 1.19.6-24 Distribution: unstable Urgency: low Maintainer: Debian GPM Team [EMAIL PROTECTED] Changed-By: Peter Samuelson [EMAIL PROTECTED] Description: gpm- General Purpose Mouse Interface libgpmg1 - General Purpose Mouse - shared library libgpmg1-dev - General Purpose Mouse - development files Closes: 399397 405642 Changes: gpm (1.19.6-24) unstable; urgency=low . * New debconf translations: - Portuguese, from Rui Branco (Closes: #399397) - Russian, from Yuri Kozlov (Closes: #405642) Files: 6e531478c5751362a70a68a2b10a77eb 734 misc optional gpm_1.19.6-24.dsc 70e11fdb0cd5e01b142cb2c4ef6481de 78573 misc optional gpm_1.19.6-24.diff.gz 1acbb732be1484710e62ceb4e17cd840 360586 misc optional gpm_1.19.6-24_amd64.deb f97b85f1db01c3edca92b32f22b43a8a 51804 libs standard libgpmg1_1.19.6-24_amd64.deb 3cbe6345f051a7594832c28ff31ddf40 54606 libdevel optional libgpmg1-dev_1.19.6-24_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFnkh2xa93SlhRC1oRAtRiAKDUews/C+AKII4a23V+R55fUUJC1ACg+RIT RGFX3ilskleIhQ0+id8ocyI= =M4K4 -END PGP SIGNATURE- Accepted: gpm_1.19.6-24.diff.gz to pool/main/g/gpm/gpm_1.19.6-24.diff.gz gpm_1.19.6-24.dsc to pool/main/g/gpm/gpm_1.19.6-24.dsc gpm_1.19.6-24_amd64.deb to pool/main/g/gpm/gpm_1.19.6-24_amd64.deb libgpmg1-dev_1.19.6-24_amd64.deb to pool/main/g/gpm/libgpmg1-dev_1.19.6-24_amd64.deb libgpmg1_1.19.6-24_amd64.deb to pool/main/g/gpm/libgpmg1_1.19.6-24_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Archive Automatic Signing Key (4.0/etch)?
[Martin Zobel-Helas] gpg --recv-keys A70DAF536070D3A1 (gpg --export -a A70DAF536070D3A1 | apt-key add -) Uh, don't forget the part about verifying that the key is actually signed by the ftpmasters. Skipping that step pretty much defeats the entire point. gpg --list-sigs A70DAF536070D3A1 signature.asc Description: Digital signature
Re: Bug#395262: Arch: all package FTBFS due to test needing network access - RC?
[Goswin von Brederlow] Do they fail when you use sudo instead of fakeroot or when you run the complete build process as root? The usual reason a package fails with sudo is that it assumes the $(PWD) macro will be available, pointing to the current working directory. sudo does not preserve this environment variable, which is often set by interactive shells. And why do they fail? Is there some specific test they do just to detect fakeroot or is it a shortcomming of fakeroot that makes the build suddenyl behave differently and succeed? fakeroot does not emulate root completely. It does not wrap the access(2) systen call, which _should_ pretty much always succeed when run as root. Succeeding can cause a test failure if the test is testing permissions that are supposed to be denied. signature.asc Description: Digital signature
Accepted subversion 1.4.2dfsg1-2 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 10 Nov 2006 08:45:01 -0600 Source: subversion Binary: libsvn-javahl libsvn1 libsvn-perl libsvn-doc libsvn-dev libsvn-ruby libapache2-svn libsvn-ruby1.8 libsvn-java python-subversion subversion-tools subversion Architecture: source all amd64 Version: 1.4.2dfsg1-2 Distribution: unstable Urgency: medium Maintainer: Peter Samuelson [EMAIL PROTECTED] Changed-By: Peter Samuelson [EMAIL PROTECTED] Description: libapache2-svn - Subversion server modules for Apache libsvn-dev - Development files for Subversion libraries libsvn-doc - Developer documentation for libsvn libsvn-java - Java bindings for Subversion libsvn-javahl - Java bindings for Subversion (dummy package) libsvn-perl - Perl bindings for Subversion libsvn-ruby - Ruby bindings for Subversion (dummy package) libsvn-ruby1.8 - Ruby bindings for Subversion libsvn1- Shared libraries used by Subversion python-subversion - Python bindings for Subversion subversion - Advanced version control system subversion-tools - Assorted tools related to Subversion Closes: 396435 Changes: subversion (1.4.2dfsg1-2) unstable; urgency=medium . [ Peter Samuelson ] * rules: fix 'dontberoot' target not to run when it shouldn't. (Closes: #396435) * Add subversion-tools Conflicts: kdesdk-scripts (= 4:3.5.5-1). I'm told that their next release will remove the 'svn-clean' script, which is quite similar to the one in subversion-tools. (See: #397874) * Add manpages for svn-clean, svn-hot-backup, svn-fast-backup, and svn-backup-dumps. Troy Heber helped write the last three. * Ship svnmerge.README in subversion-tools. Files: 3b3e1aa8325a4dd5d81c905ff19d8e10 1239 devel optional subversion_1.4.2dfsg1-2.dsc 773717d4526beee9740035dde114b95c 76756 devel optional subversion_1.4.2dfsg1-2.diff.gz b2b52eafecaa094cffd7e481b628742b 1089600 doc extra libsvn-doc_1.4.2dfsg1-2_all.deb 7c1275f3cd756b56378afc23a31fbbaf 166286 admin extra subversion-tools_1.4.2dfsg1-2_all.deb 21cef6ea6cd93a78be2aded3ef1df700 768 devel optional libsvn-javahl_1.4.2dfsg1-2_all.deb f35c84bcfaeaf37cd2ceae37a87f5706 736 devel optional libsvn-ruby_1.4.2dfsg1-2_all.deb badeaa9f468d8eb8597c9aa2d66c517a 1036110 devel optional subversion_1.4.2dfsg1-2_amd64.deb 4b7ac4c4795cfdcffa5d2e80193415c6 642324 libs optional libsvn1_1.4.2dfsg1-2_amd64.deb 3c16692a36ddd454ee33cf5af5708f0a 920478 libdevel extra libsvn-dev_1.4.2dfsg1-2_amd64.deb adf130f5062b4adee642d169840dc129 136500 net optional libapache2-svn_1.4.2dfsg1-2_amd64.deb 3ad61dc24740fdec56f79844b2f87db2 586584 python optional python-subversion_1.4.2dfsg1-2_amd64.deb 332248eeb766387f07ba2f33bb49fa46 213130 devel optional libsvn-java_1.4.2dfsg1-2_amd64.deb 377cc73e79392a37ff07ddc65d779fa8 857302 perl optional libsvn-perl_1.4.2dfsg1-2_amd64.deb 85b61d09f099297171667e972c50c7e2 428426 devel optional libsvn-ruby1.8_1.4.2dfsg1-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFVLMgQOr9C+GfGI4RAlhlAJ9CkHXSb521ul0aL/2Masq+hU0epQCgwSu1 c1cpnHm/td/Q5g/oyEtbWvg= =R6nf -END PGP SIGNATURE- Accepted: libapache2-svn_1.4.2dfsg1-2_amd64.deb to pool/main/s/subversion/libapache2-svn_1.4.2dfsg1-2_amd64.deb libsvn-dev_1.4.2dfsg1-2_amd64.deb to pool/main/s/subversion/libsvn-dev_1.4.2dfsg1-2_amd64.deb libsvn-doc_1.4.2dfsg1-2_all.deb to pool/main/s/subversion/libsvn-doc_1.4.2dfsg1-2_all.deb libsvn-java_1.4.2dfsg1-2_amd64.deb to pool/main/s/subversion/libsvn-java_1.4.2dfsg1-2_amd64.deb libsvn-javahl_1.4.2dfsg1-2_all.deb to pool/main/s/subversion/libsvn-javahl_1.4.2dfsg1-2_all.deb libsvn-perl_1.4.2dfsg1-2_amd64.deb to pool/main/s/subversion/libsvn-perl_1.4.2dfsg1-2_amd64.deb libsvn-ruby1.8_1.4.2dfsg1-2_amd64.deb to pool/main/s/subversion/libsvn-ruby1.8_1.4.2dfsg1-2_amd64.deb libsvn-ruby_1.4.2dfsg1-2_all.deb to pool/main/s/subversion/libsvn-ruby_1.4.2dfsg1-2_all.deb libsvn1_1.4.2dfsg1-2_amd64.deb to pool/main/s/subversion/libsvn1_1.4.2dfsg1-2_amd64.deb python-subversion_1.4.2dfsg1-2_amd64.deb to pool/main/s/subversion/python-subversion_1.4.2dfsg1-2_amd64.deb subversion-tools_1.4.2dfsg1-2_all.deb to pool/main/s/subversion/subversion-tools_1.4.2dfsg1-2_all.deb subversion_1.4.2dfsg1-2.diff.gz to pool/main/s/subversion/subversion_1.4.2dfsg1-2.diff.gz subversion_1.4.2dfsg1-2.dsc to pool/main/s/subversion/subversion_1.4.2dfsg1-2.dsc subversion_1.4.2dfsg1-2_amd64.deb to pool/main/s/subversion/subversion_1.4.2dfsg1-2_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted subversion 1.4.2dfsg1-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 9 Nov 2006 00:07:42 -0600 Source: subversion Binary: libsvn-javahl libsvn1 libsvn-perl libsvn-doc libsvn-dev libsvn-ruby libapache2-svn libsvn-ruby1.8 libsvn-java python-subversion subversion-tools subversion Architecture: source all amd64 Version: 1.4.2dfsg1-1 Distribution: unstable Urgency: low Maintainer: Peter Samuelson [EMAIL PROTECTED] Changed-By: Peter Samuelson [EMAIL PROTECTED] Description: libapache2-svn - Subversion server modules for Apache libsvn-dev - Development files for Subversion libraries libsvn-doc - Developer documentation for libsvn libsvn-java - Java bindings for Subversion libsvn-javahl - Java bindings for Subversion (dummy package) libsvn-perl - Perl bindings for Subversion libsvn-ruby - Ruby bindings for Subversion (dummy package) libsvn-ruby1.8 - Ruby bindings for Subversion libsvn1- Shared libraries used by Subversion python-subversion - Python bindings for Subversion subversion - Advanced version control system subversion-tools - Assorted tools related to Subversion Closes: 293528 350133 357506 392805 393414 394395 396435 397113 397173 Changes: subversion (1.4.2dfsg1-1) unstable; urgency=low . [ Peter Samuelson ] * New upstream release. - No longer ships IETF draft spec. (Closes: #393414) - patches/svnsync-manpage, parts of patches/neon26, patches/svnshell: Obsolete, removed. - Re-roll upstream tarball to remove some unlicensed files from the contrib directory. Update debian/copyright regarding other files in contrib. (Closes: #394395) * patches/neon26: update for 1.4.2, add neon 0.26.2 to the whitelist. * Improve libapache2-svn installation experience: - Use a2enmod/a2dismod instead of hand-hacking. - dav_svn.conf: Comment everything out. (Many will want to use sites-available/* rather than dav_svn.conf anyway.) Fix some of the text and add more. (Closes: #392805) * libsvn-java: Remove alternative Depends: java1-runtime. It does in fact require JRE 1.2 (java2-runtime). * Build with neon26 instead of neon25. * Ship some example code from upstream in the various devel packages. - patches/examples-compile-instructions: New patch, some small doc fixes. * Ship a lot more scripts in subversion-tools, including svnmerge (Closes: #293528), svn2cl (Closes: #350133). - List these scripts in the Description. (Closes: #357506) - Downgrade most Depends to Recommends, augment Recommends and Suggests to match the scripts. * rules: Add explicit check and informative error message for trying to build as root. (Closes: #396435) * libapache2-svn Description: it's Apache 2.2, not 2.0. (Closes: #397113) * patches/ruby-test-ra-race: replace my fix by upstream's better one, should _really_ fix m68k build this time. (Closes: #397173) * patches/jelmer-python-bindings: New patch: backport python binding improvements by Jelmer Vernooij from trunk. This is needed for certain advanced python-based tools. Files: 82bb29ae0dcf7a198823dca09b72af9d 1239 devel optional subversion_1.4.2dfsg1-1.dsc 2f9d9b879712cb4311bf1c0475c8352a 6436039 devel optional subversion_1.4.2dfsg1.orig.tar.gz ab0c99329e42576fafbc6250e01eb51f 74235 devel optional subversion_1.4.2dfsg1-1.diff.gz 3bcd915f84b05457a2dcd1d9a063953e 1089344 doc extra libsvn-doc_1.4.2dfsg1-1_all.deb e74f2857f53b9afa7771b6bc94f368e4 158582 admin extra subversion-tools_1.4.2dfsg1-1_all.deb 242284c96b8c93abbd8a70acc5e3f173 768 devel optional libsvn-javahl_1.4.2dfsg1-1_all.deb 2385ec35cae619643b6f12e390b1d13d 736 devel optional libsvn-ruby_1.4.2dfsg1-1_all.deb 4ed7ad6ddb899573b84fbb541c5eff01 1035948 devel optional subversion_1.4.2dfsg1-1_amd64.deb bfc7cd9ad44074ccf4f0c38bd76ae3e9 642144 libs optional libsvn1_1.4.2dfsg1-1_amd64.deb 2e66ba08a819582359d272e345ad2675 920262 libdevel extra libsvn-dev_1.4.2dfsg1-1_amd64.deb e90bdf954df102e9c0dc9f3304214d52 136292 net optional libapache2-svn_1.4.2dfsg1-1_amd64.deb 09a05c4643bb1de725f9a9f9a8a019e4 586432 python optional python-subversion_1.4.2dfsg1-1_amd64.deb 139c063ab1bc23d2439c178c3bfc6242 212934 devel optional libsvn-java_1.4.2dfsg1-1_amd64.deb 0bae183d682c4b39875de345d4dbedad 857120 perl optional libsvn-perl_1.4.2dfsg1-1_amd64.deb e4b384d39468b6b162bd915c47372774 428260 devel optional libsvn-ruby1.8_1.4.2dfsg1-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFU0hiQOr9C+GfGI4RAo7bAJ0U6xGPHx2N0eZyraSiwtIry1kCKACfXgqp +RA0BVs0n8XAXSPkm/XuE9w= =ERRg -END PGP SIGNATURE- Accepted: libapache2-svn_1.4.2dfsg1-1_amd64.deb to pool/main/s/subversion/libapache2-svn_1.4.2dfsg1-1_amd64.deb libsvn-dev_1.4.2dfsg1-1_amd64.deb to pool/main/s/subversion/libsvn-dev_1.4.2dfsg1-1_amd64.deb libsvn-doc_1.4.2dfsg1-1_all.deb to pool/main/s/subversion/libsvn-doc_1.4.2dfsg1-1_all.deb libsvn-java_1.4.2dfsg1-1_amd64
Re: Bug#395262: Arch: all package FTBFS due to test needing network access - RC?
[Goswin von Brederlow] Real or fake makes no difference. Anything that test id or file permissions will (hopefully) behave the same with fakeroot. Ahh, the difference between theory and practice. fakeroot does not emulate the access(2) system call, which is one obvious thing to use when testing file permission functionality. As a result, some things do in fact behave differently under fakeroot than as root. signature.asc Description: Digital signature
Re: Arch: all package FTBFS due to test needing network access - RC?
[Goswin von Brederlow] Your unspoken premise is that there is a _reason_ to support building packages as root. Why? I think it is better just to tell people not to do that. My premise is that there is no reason to sabotage building as root. Nearly all sources do build as root and many test suites skip tests that fail as root. I see no reason to stop that now. We're not talking about sabotage, we're talking about extra effort. I have a reason not to support building packages as root: it is more work for me, it takes time which I could be using to fix bugs or write manpages. Now it is your turn to give me a reason to support building packages as root. What is so important about building as root that I should spend time making it work? Also keep in mind that my upstream takes the same position that I do. signature.asc Description: Digital signature
Re: Arch: all package FTBFS due to test needing network access - RC?
[Manoj Srivastava] We're not talking about sabotage, we're talking about extra effort. Not really an answer I expected from a DD. I don't mind putting in extra effort when there is some gain to be had. I'm not so excited about putting in extra effort when there is no gain to be had. I'm still waiting for the answer to why it is so important that users be able to build our packages as root. So far all I'm hearing is what if I can't be bothered to create a non-root user which, to me, just doesn't sound very compelling. Offering options to users does add to th quality of implementation, just as fixing bugs or writing man pages does. You mean offering options to users who want to rebuild packages we already provide for them. That would be a set of users who already went to a certain amount of trouble to set up a chroot and 'apt-get build-dep' inside the chroot. (If they aren't building in a chroot, the argument about 'adduser' doesn't really hold up.) I just don't see a lot of value in saving those users from the two extra steps of calling 'adduser foo' and 'su foo'. Your argument seems to be that doing anything else for debian or one's packages apart from bug fixing or writing man pages is a waste of time -- so, to please you, should we just mass file bugs so you can happily fix them while allowing root to build packages? :) :) If I ever run short on real bugs to fix, I'll let you know. (: Seriously, of course I care about quality of implementation, I just don't see how the ability to build as root is particularly necessary to any user under any circumstances. As such, it seems like a waste of time to go out of one's way to support it. mailagent has a series of tests it runs that fail when run as root, so for about a decade now mailagent has detected that it is running as root, and then su's to a non-root user to run the tests. So I guess that assumes there's a handy non-root user that could have been used to build the package in the first place. So much for _that_ counter-argument, then. signature.asc Description: Digital signature
Re: .ssh/authorized_keys on alioth is disappearing
[Norbert Preining] | The SSH keys are not synchronized between alioth.debian.org and | svn.debian.org. so this seems to be outdated. Correct - svn.debian.org _is_ alioth.debian.org, as of last Friday. signature.asc Description: Digital signature
Re: Arch: all package FTBFS due to test needing network access - RC?
Robert Collins [EMAIL PROTECTED] writes: I can also note why bazaar wont build as root: its test suite includes a test for the ability to handle read only directories correctly. As root, anything is writable, so this test fails. [Goswin von Brederlow] That test should add a test for root and skip it. If that is the only reason not to build as root then that should be no excuse (post etch). Your unspoken premise is that there is a _reason_ to support building packages as root. Why? I think it is better just to tell people not to do that. signature.asc Description: Digital signature
Re: How can the OS autodetect that a user is a newbie and offer help?
[Sander Marechal] True, but I meant that an app can kill X, requiring it to be restarted. Newbies get very confused at that point. Look, if you typed startx once, you can type it again. If you didn't, it means you're using a display manager like xdm, and xdm will restart X when it dies. If X just _freezes_ rather than dies, you don't get a shell prompt anyway. What you get is the opportunity to hit Ctrl-Alt-Backspace, so that X will die, and then you're back to the previous cases. I see no case where it is useful to alias startx to start-desktop. Unless X dies and then xdm _also_ dies. Does this ever happen? signature.asc Description: Digital signature
Accepted subversion 1.4.0-5 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 11 Oct 2006 03:30:03 -0500 Source: subversion Binary: libsvn-javahl libsvn1 libsvn-perl libsvn-doc libsvn-dev libsvn-ruby libapache2-svn libsvn-ruby1.8 libsvn-java python-subversion subversion-tools subversion Architecture: source all i386 Version: 1.4.0-5 Distribution: unstable Urgency: medium Maintainer: Peter Samuelson [EMAIL PROTECTED] Changed-By: Peter Samuelson [EMAIL PROTECTED] Description: libapache2-svn - Subversion server modules for Apache libsvn-dev - Development files for Subversion libraries libsvn-doc - Developer documentation for libsvn libsvn-java - Java bindings for Subversion libsvn-javahl - Java bindings for Subversion (dummy package) libsvn-perl - Perl bindings for Subversion libsvn-ruby - Ruby bindings for Subversion (dummy package) libsvn-ruby1.8 - Ruby bindings for Subversion libsvn1- Shared libraries used by Subversion python-subversion - Python bindings for Subversion subversion - Advanced version control system subversion-tools - Assorted tools related to Subversion Closes: 392004 Changes: subversion (1.4.0-5) unstable; urgency=medium . [ Peter Samuelson ] * rules: Set HOME to a dummy value to prevent a build failure if the real HOME is mode -x. Plus a few minor cleanups. * rules: Link -ldb explicitly (rather than implicitly via -laprutil-1). This is required for libdb symbol versioning to propagate. Thanks to Pitr Jansen for help tracking this down. * patches/svnshell: Fix insufficient argument checking in 'setrev' command. (Closes: #392004) Files: 49b75730671e4e5d225e67dbe70711bc 1224 devel optional subversion_1.4.0-5.dsc c3aa79215bd3e548f96dc399cd8c046d 47930 devel optional subversion_1.4.0-5.diff.gz 2c61f8d76332e0c08d99aa53de1fba63 1065618 doc extra libsvn-doc_1.4.0-5_all.deb f1133a04d313ab5288b1a0a6e60f0104 129126 admin extra subversion-tools_1.4.0-5_all.deb d3c7d2d32a49182bfb839ca970c6bf89 772 devel optional libsvn-javahl_1.4.0-5_all.deb 25810b60be896f25ebc168abd186e12d 738 devel optional libsvn-ruby_1.4.0-5_all.deb eef0b90f08ce197d0038b83aebf7557d 1012942 devel optional subversion_1.4.0-5_i386.deb a5f3c0eb04eef0b866697fe54015aa90 583708 libs optional libsvn1_1.4.0-5_i386.deb e31062f7fc41398d89dad5fddfbd59b3 817378 libdevel extra libsvn-dev_1.4.0-5_i386.deb 3ab1823a49be8b44c0194571d00e38bb 124016 net optional libapache2-svn_1.4.0-5_i386.deb dbc37e9d6d6cb0f0e45a54ecb54dca04 492742 python optional python-subversion_1.4.0-5_i386.deb e0202b8c06e04d36a5bc4cea99b6b5e8 201528 devel optional libsvn-java_1.4.0-5_i386.deb 4ecd17d3bba6eb88d7318eedda0eb7bc 795138 perl optional libsvn-perl_1.4.0-5_i386.deb ef140c7126bc0b7cef9c97825c3fbead 376436 devel optional libsvn-ruby1.8_1.4.0-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFLSy0QOr9C+GfGI4RApPiAJ4jXsbcpPIHhuyHjZvqVnuuxdTD5wCgmGl9 uYOrWR0oZwVPbnNOStzqkxE= =pNQY -END PGP SIGNATURE- Accepted: libapache2-svn_1.4.0-5_i386.deb to pool/main/s/subversion/libapache2-svn_1.4.0-5_i386.deb libsvn-dev_1.4.0-5_i386.deb to pool/main/s/subversion/libsvn-dev_1.4.0-5_i386.deb libsvn-doc_1.4.0-5_all.deb to pool/main/s/subversion/libsvn-doc_1.4.0-5_all.deb libsvn-java_1.4.0-5_i386.deb to pool/main/s/subversion/libsvn-java_1.4.0-5_i386.deb libsvn-javahl_1.4.0-5_all.deb to pool/main/s/subversion/libsvn-javahl_1.4.0-5_all.deb libsvn-perl_1.4.0-5_i386.deb to pool/main/s/subversion/libsvn-perl_1.4.0-5_i386.deb libsvn-ruby1.8_1.4.0-5_i386.deb to pool/main/s/subversion/libsvn-ruby1.8_1.4.0-5_i386.deb libsvn-ruby_1.4.0-5_all.deb to pool/main/s/subversion/libsvn-ruby_1.4.0-5_all.deb libsvn1_1.4.0-5_i386.deb to pool/main/s/subversion/libsvn1_1.4.0-5_i386.deb python-subversion_1.4.0-5_i386.deb to pool/main/s/subversion/python-subversion_1.4.0-5_i386.deb subversion-tools_1.4.0-5_all.deb to pool/main/s/subversion/subversion-tools_1.4.0-5_all.deb subversion_1.4.0-5.diff.gz to pool/main/s/subversion/subversion_1.4.0-5.diff.gz subversion_1.4.0-5.dsc to pool/main/s/subversion/subversion_1.4.0-5.dsc subversion_1.4.0-5_i386.deb to pool/main/s/subversion/subversion_1.4.0-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gids assigned non-deterministically
[Roberto C. Sanchez] That is a problem if I want to server everything up out of LDAP. There really should be a reserved range, maybe 100-499 of Debian gids, where they are assigned in a predertmined way. I don't think it's a good idea to put system users and groups into LDAP anyway. They are specific to a system. There is nothing wrong with having regular users and groups in LDAP and system users and groups in /etc/passwd. This is, in fact, probably the common case. signature.asc Description: Digital signature
Accepted subversion 1.4.0-4 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 8 Oct 2006 09:26:04 -0500 Source: subversion Binary: libsvn-javahl libsvn1 libsvn-perl libsvn-doc libsvn-dev libsvn-ruby libapache2-svn libsvn-ruby1.8 libsvn-java python-subversion subversion-tools subversion Architecture: source all i386 Version: 1.4.0-4 Distribution: unstable Urgency: medium Maintainer: Peter Samuelson [EMAIL PROTECTED] Changed-By: Peter Samuelson [EMAIL PROTECTED] Description: libapache2-svn - Subversion server modules for Apache libsvn-dev - Development files for Subversion libraries libsvn-doc - Developer documentation for libsvn libsvn-java - Java bindings for Subversion libsvn-javahl - Java bindings for Subversion (dummy package) libsvn-perl - Perl bindings for Subversion libsvn-ruby - Ruby bindings for Subversion (dummy package) libsvn-ruby1.8 - Ruby bindings for Subversion libsvn1- Shared libraries used by Subversion python-subversion - Python bindings for Subversion subversion - Advanced version control system subversion-tools - Assorted tools related to Subversion Closes: 391744 Changes: subversion (1.4.0-4) unstable; urgency=medium . [ Peter Samuelson ] * patches/apr-abi: switch to a simpler test that actually DTRT on 64-bit platforms. (Closes: #391744) Files: 7165798be06444b9ee50205627643630 1224 devel optional subversion_1.4.0-4.dsc 4cf4ed36a200c87f05cc65a804200e3b 47687 devel optional subversion_1.4.0-4.diff.gz 756f65be16bbdee6b5744a590790377e 1065240 doc extra libsvn-doc_1.4.0-4_all.deb f5e62b5c720856ad1bd1ad3e5fc8be71 128846 admin extra subversion-tools_1.4.0-4_all.deb 23ae3da9296eeb9e1d66fb8586f3f56d 770 devel optional libsvn-javahl_1.4.0-4_all.deb 298c6e3003f3ba9727dfd489a790488e 738 devel optional libsvn-ruby_1.4.0-4_all.deb c28663e47c0b559b84c5ef1e2b49bc04 1012674 devel optional subversion_1.4.0-4_i386.deb ca5c87520aaee73e2f999da211d29fc2 583450 libs optional libsvn1_1.4.0-4_i386.deb d0c6b45eb33dd9166e995312a30089a7 817174 libdevel extra libsvn-dev_1.4.0-4_i386.deb 8aa98acd493f42d8906d1e35c38f8464 123838 net optional libapache2-svn_1.4.0-4_i386.deb d75a5d1fa3c35c9f68ee802fe2e10888 492520 python optional python-subversion_1.4.0-4_i386.deb 10fba61d7d8b04961e6635dc0bcbbaf7 201316 devel optional libsvn-java_1.4.0-4_i386.deb 356bfef0ca02ef6ac48cb464866d163e 794896 perl optional libsvn-perl_1.4.0-4_i386.deb bab01079f0386e1f07f8b9312965e303 376168 devel optional libsvn-ruby1.8_1.4.0-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFKYo8GJU/LHOwJZIRAsZ+AKC4Yd3pScAOlKNVin+1w8nipsgMngCcDIVt OALGXThraOxRr0rMb3Yhvjc= =Pzuf -END PGP SIGNATURE- Accepted: libapache2-svn_1.4.0-4_i386.deb to pool/main/s/subversion/libapache2-svn_1.4.0-4_i386.deb libsvn-dev_1.4.0-4_i386.deb to pool/main/s/subversion/libsvn-dev_1.4.0-4_i386.deb libsvn-doc_1.4.0-4_all.deb to pool/main/s/subversion/libsvn-doc_1.4.0-4_all.deb libsvn-java_1.4.0-4_i386.deb to pool/main/s/subversion/libsvn-java_1.4.0-4_i386.deb libsvn-javahl_1.4.0-4_all.deb to pool/main/s/subversion/libsvn-javahl_1.4.0-4_all.deb libsvn-perl_1.4.0-4_i386.deb to pool/main/s/subversion/libsvn-perl_1.4.0-4_i386.deb libsvn-ruby1.8_1.4.0-4_i386.deb to pool/main/s/subversion/libsvn-ruby1.8_1.4.0-4_i386.deb libsvn-ruby_1.4.0-4_all.deb to pool/main/s/subversion/libsvn-ruby_1.4.0-4_all.deb libsvn1_1.4.0-4_i386.deb to pool/main/s/subversion/libsvn1_1.4.0-4_i386.deb python-subversion_1.4.0-4_i386.deb to pool/main/s/subversion/python-subversion_1.4.0-4_i386.deb subversion-tools_1.4.0-4_all.deb to pool/main/s/subversion/subversion-tools_1.4.0-4_all.deb subversion_1.4.0-4.diff.gz to pool/main/s/subversion/subversion_1.4.0-4.diff.gz subversion_1.4.0-4.dsc to pool/main/s/subversion/subversion_1.4.0-4.dsc subversion_1.4.0-4_i386.deb to pool/main/s/subversion/subversion_1.4.0-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A plan to get rid of unnecessary package dependencies
[Loïc Minier] Can't we just tell people to not use *.la files for static linking? The problem is that .la files provide a way to pull in all the dependent libraries for static linking, and unless you also ship .pc files, there is no other automated way to do this. Some people apparently care about this capability, which is why we can't just delete _all_ .la files _now_. signature.asc Description: Digital signature
Re: A plan to get rid of unnecessary package dependencies
[Mike Hommey] Why not add support for Libs.private in libtool ? That's essentially what the .la file already provides, with _debian_ libtool. The main problem we have with libtool these days is packages that use their own shipped libtool rather than debian's. Anyway, it's probably easiest just to get people to stop shipping .la files at all. Easy to lintian for, etc. signature.asc Description: Digital signature
Re: A plan to get rid of unnecessary package dependencies
[Mike Hommey] A first step in that direction would be to fix .la, .pc and -config files so that they only give the needed libraries. The correct fix for .la files for dynamic linking (remove all dependent libraries, relying on the runtime linker to pull them in recursively) does not work for static linking. Some people apparently still care about static linking, don't ask me who or why. .pc files do not have this limitation, as it's possible to specify two separate lists of libraries, one only for static linking. So, the real solution, insofar as there _are_ real solutions, is to phase out .la files entirely. One problem is that if your .la file is referenced within someone else's .la file, you can't remove it without breaking their package. To eliminate _this_ problem, I suggest that everyone add the following (or similar) to debian/rules: binary-arch: build-arch # [something like '$(MAKE) install DESTDIR=$(shell pwd)/debian/tmp'] # sed -i 's:/usr/lib/lib\([^ ]*\).la:-l\1:g' debian/tmp/usr/lib/*.la signature.asc Description: Digital signature
Re: A plan to get rid of unnecessary package dependencies
[Richard Atterer] On Mon, Sep 25, 2006 at 02:40:49PM -0700, Kevin B. McCarty wrote: Thank you for this very cool effort! Might we see checklib packaged for Debian soon? Hmm, maybe the functionality could be included in lintian? See #340934. Henning wrote this lintian check several months ago, but Jeroen explains in the bug log why it was not accepted. I use it locally, and it works fine. (Well, modulo the bug I reported later to that same bug log.) signature.asc Description: Digital signature
Re: Moving /var/run to a tmpfs?
[Kurt Roeckx] Afaik, Ubuntu is already using this. As a result, I've actually got a bug against my package submitted because it didn't handle it. My package now recreates the directory from the init script if it's missing, and I'm not really happy about that solution. Why not? 'mkdir -p' (or 'install -d' if you need a non-root owner or custom permissions) is a quick one-liner. I'd much rather my system didn't assume that /var/run or /tmp or /dev/shm will retain anything at all between reboots. signature.asc Description: Digital signature
Re: how to treat upgrade bugs that only affect unstable-unstable?
If a bug was in a prerm script in unstable for 7 days, but never appeared in stable or testing, should we include cruft in present and future prerm versions to work around it? [Henrique de Moraes Holschuh] It depends only on the ammount of damage the bug causes. No damage, it simply doesn't work. So you can't remove or upgrade the package. The workaround in the new prerm is simple enough but it's still cruft that I'd rather not have to carry around. signature.asc Description: Digital signature
Re: A few problems in sight switching to Debian
[Gilles Pelletier] I'm not a developer and I'd just like to point a few issues to check for the next release. I'm planning to switch to Debian when Etch comes out but, for now, my findings are from Knoppix. Knoppix and Debian use completely different methods of hardware detection and autoconfiguration. As such, I don't think we can draw any useful conclusions from your findings unless someone can verify them on Debian etch. signature.asc Description: Digital signature
Re: Bug#387385: ITP: shed -- Hex editor using ncurses, with a friendly pico-style interface
[Christoph Berg] - Can handle files up to 2Gb. That's a feature? No, a bug (or rather, doesn't meet a release goal): And more importantly, editing disk partitions which may be larger than 2 GB is a significant use case for a hex editor. signature.asc Description: Digital signature
how to treat upgrade bugs that only affect unstable-unstable?
CC: debian-devel, as I'm asking about packaging best practices.
[Agustin Martin]
* python-subversion.{prerm,postinst}: use pyversions, fix stupid
bug (Closes: #379278) in prerm. Tighten python build-dep to
ensure availability of pyversions.
Note that some upgrades might still be a problem,
dpkg: warning - old pre-removal script returned error exit status 1
dpkg - trying script from the new package instead ...
That raises a philosophical question:
If a bug was in a prerm script in unstable for 7 days, but never
appeared in stable or testing, should we include cruft in present and
future prerm versions to work around it?
Or, put another way: a prerm is designed to run with the package
version it is shipped with. To what lengths should it go to do the
right thing when dpkg runs it with previous versions of the package?
signature.asc
Description: Digital signature
Accepted subversion 1.4.0-2 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 10 Sep 2006 05:05:47 -0500 Source: subversion Binary: libsvn0 libsvn-perl libsvn-doc libsvn-dev libsvn-ruby libapache2-svn libsvn-ruby1.8 libsvn-java python-subversion subversion-tools subversion Architecture: source all i386 Version: 1.4.0-2 Distribution: unstable Urgency: low Maintainer: Guilherme de S. Pastore [EMAIL PROTECTED] Changed-By: Peter Samuelson [EMAIL PROTECTED] Description: libapache2-svn - Subversion server modules for Apache libsvn-dev - Development files for Subversion libraries libsvn-doc - Developer documentation for libsvn libsvn-java - Java bindings for Subversion libsvn-perl - Perl bindings for Subversion libsvn-ruby - Ruby bindings for Subversion (dummy package) libsvn-ruby1.8 - Ruby bindings for Subversion libsvn0- Shared libraries used by Subversion python-subversion - Python bindings for Subversion subversion - Advanced version control system subversion-tools - Assorted tools related to Subversion Changes: subversion (1.4.0-2) unstable; urgency=low . [ Peter Samuelson ] * Run tests in 'build' target, not 'binary' target. This prevents a build failure if 'binary' is run as root (not fakeroot). * patches/svnsync-manpage: trivial typo fix from upstream. * Delete README.db4.4: the upgrade procedure it describes is now fully automatic. Files: 9b14817e62962c15bdf1147a8d4be6a3 1231 devel optional subversion_1.4.0-2.dsc 75aaa8131833227935ed187dbeda3c56 46345 devel optional subversion_1.4.0-2.diff.gz d68757d7d5522c50a34b0387e3a0f2d6 1065064 doc extra libsvn-doc_1.4.0-2_all.deb f6897a892bc7cbab506a318f8db3422c 128498 admin extra subversion-tools_1.4.0-2_all.deb be060b0b1a784a6a0553223f4aea8a5f 744 devel optional libsvn-ruby_1.4.0-2_all.deb 02ac191d08e31892d937713be726b132 1012396 devel optional subversion_1.4.0-2_i386.deb 0b3435d050302fa92fdd8e46a92b306f 579604 libs optional libsvn0_1.4.0-2_i386.deb 91d7a134401450a647eedcbbc45b67c2 812658 libdevel extra libsvn-dev_1.4.0-2_i386.deb 5cdf4eac4d32a3fd0f80b81892477376 123638 net optional libapache2-svn_1.4.0-2_i386.deb 22dbf63f31e4c593c9a352854dd1177c 492350 python optional python-subversion_1.4.0-2_i386.deb 9c5db9dde09d86d14f4d4206b26d5a79 200932 devel optional libsvn-java_1.4.0-2_i386.deb 2d35f540f113212884ef17ffe4810f06 794624 perl optional libsvn-perl_1.4.0-2_i386.deb 5dd8d6227f470dd8712edd77c693fe58 375724 devel optional libsvn-ruby1.8_1.4.0-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFBqwuQOr9C+GfGI4RAuYHAJ9HJ3gpWgUTrR2kbeRtEeBYKxGLvgCcC7Zu 5psTnryrzU2ewVlG/BkWyZc= =sd9c -END PGP SIGNATURE- Accepted: libapache2-svn_1.4.0-2_i386.deb to pool/main/s/subversion/libapache2-svn_1.4.0-2_i386.deb libsvn-dev_1.4.0-2_i386.deb to pool/main/s/subversion/libsvn-dev_1.4.0-2_i386.deb libsvn-doc_1.4.0-2_all.deb to pool/main/s/subversion/libsvn-doc_1.4.0-2_all.deb libsvn-java_1.4.0-2_i386.deb to pool/main/s/subversion/libsvn-java_1.4.0-2_i386.deb libsvn-perl_1.4.0-2_i386.deb to pool/main/s/subversion/libsvn-perl_1.4.0-2_i386.deb libsvn-ruby1.8_1.4.0-2_i386.deb to pool/main/s/subversion/libsvn-ruby1.8_1.4.0-2_i386.deb libsvn-ruby_1.4.0-2_all.deb to pool/main/s/subversion/libsvn-ruby_1.4.0-2_all.deb libsvn0_1.4.0-2_i386.deb to pool/main/s/subversion/libsvn0_1.4.0-2_i386.deb python-subversion_1.4.0-2_i386.deb to pool/main/s/subversion/python-subversion_1.4.0-2_i386.deb subversion-tools_1.4.0-2_all.deb to pool/main/s/subversion/subversion-tools_1.4.0-2_all.deb subversion_1.4.0-2.diff.gz to pool/main/s/subversion/subversion_1.4.0-2.diff.gz subversion_1.4.0-2.dsc to pool/main/s/subversion/subversion_1.4.0-2.dsc subversion_1.4.0-2_i386.deb to pool/main/s/subversion/subversion_1.4.0-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted subversion 1.4.0-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 7 Sep 2006 21:03:06 -0500 Source: subversion Binary: libsvn0 libsvn-perl libsvn-doc libsvn-dev libsvn-ruby libapache2-svn libsvn-ruby1.8 libsvn-java python-subversion subversion-tools subversion Architecture: source all i386 Version: 1.4.0-1 Distribution: unstable Urgency: low Maintainer: Guilherme de S. Pastore [EMAIL PROTECTED] Changed-By: Peter Samuelson [EMAIL PROTECTED] Description: libapache2-svn - Subversion server modules for Apache libsvn-dev - Development files for Subversion libraries libsvn-doc - Developer documentation for libsvn libsvn-java - Java bindings for Subversion libsvn-perl - Perl bindings for Subversion libsvn-ruby - Ruby bindings for Subversion (dummy package) libsvn-ruby1.8 - Ruby bindings for Subversion libsvn0- Shared libraries used by Subversion python-subversion - Python bindings for Subversion subversion - Advanced version control system subversion-tools - Assorted tools related to Subversion Changes: subversion (1.4.0-1) unstable; urgency=low . [ Peter Samuelson ] * New upstream version - well, not really new, it's rc5 rebranded. * Revert libsvn1/apache2.2 change, since apache 2.2 is not yet in unstable. libsvn1 is libsvn0 again, for now. * patches/no-extra-libs: detect apr0/apr1 correctly, and use pkg-config for neon. * patches/neon26: new patch to build cleanly with neon 0.26.1. Though we won't actually use it until #386652 is fixed. * Document BDB 4.4 upgrade better; also, move the NEWS entry from 'libsvn0' to 'subversion' where it is more likely to actually be read. * patches/no-extra-libs-2: Tweak to remove more unnecessary linking. * rules: pass LIBTOOL=libtool into sub-makes, to use Debian libtool rather than upstream's. Files: 4e6270915479640357ed745844f4e442 1231 devel optional subversion_1.4.0-1.dsc 6f7485986776204138a1d221ac5eec40 6268503 devel optional subversion_1.4.0.orig.tar.gz 2f48937fc970e2ca21bf2038d422d952 48098 devel optional subversion_1.4.0-1.diff.gz c1db757d2bc15638d55242ca2dc7b3e8 1064970 doc extra libsvn-doc_1.4.0-1_all.deb 039d20f69eae068a48495410e907898d 128396 admin extra subversion-tools_1.4.0-1_all.deb 2e109f517d6cc15c375d530e25fc7aaa 748 devel optional libsvn-ruby_1.4.0-1_all.deb 3581a87a7690b58d289920cf893426a0 1012134 devel optional subversion_1.4.0-1_i386.deb 2dfa15936db3965e124340674ca69fc4 581882 libs optional libsvn0_1.4.0-1_i386.deb ad453054f4079a04807f5b3b7e38d660 812578 libdevel extra libsvn-dev_1.4.0-1_i386.deb b63ac44a586fbc40f42c216c267fc62a 123534 net optional libapache2-svn_1.4.0-1_i386.deb d10dda8a09b6294236917eaa2735da44 492238 python optional python-subversion_1.4.0-1_i386.deb 5576d8eec2ce140e72d6c6a84269893b 200846 devel optional libsvn-java_1.4.0-1_i386.deb d9ae9c69358f077b98fdfdb169be7689 794520 perl optional libsvn-perl_1.4.0-1_i386.deb 645f7b0a8c8654d0ea6bf76a68e131a4 375618 devel optional libsvn-ruby1.8_1.4.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFA2j+QOr9C+GfGI4RAqdNAJ9l8QXHI+oALacx4sxeFyGMgwnbRwCdFn58 4vKA/AdUrRvi2+bKv5DiwQ8= =I8kg -END PGP SIGNATURE- Accepted: libapache2-svn_1.4.0-1_i386.deb to pool/main/s/subversion/libapache2-svn_1.4.0-1_i386.deb libsvn-dev_1.4.0-1_i386.deb to pool/main/s/subversion/libsvn-dev_1.4.0-1_i386.deb libsvn-doc_1.4.0-1_all.deb to pool/main/s/subversion/libsvn-doc_1.4.0-1_all.deb libsvn-java_1.4.0-1_i386.deb to pool/main/s/subversion/libsvn-java_1.4.0-1_i386.deb libsvn-perl_1.4.0-1_i386.deb to pool/main/s/subversion/libsvn-perl_1.4.0-1_i386.deb libsvn-ruby1.8_1.4.0-1_i386.deb to pool/main/s/subversion/libsvn-ruby1.8_1.4.0-1_i386.deb libsvn-ruby_1.4.0-1_all.deb to pool/main/s/subversion/libsvn-ruby_1.4.0-1_all.deb libsvn0_1.4.0-1_i386.deb to pool/main/s/subversion/libsvn0_1.4.0-1_i386.deb python-subversion_1.4.0-1_i386.deb to pool/main/s/subversion/python-subversion_1.4.0-1_i386.deb subversion-tools_1.4.0-1_all.deb to pool/main/s/subversion/subversion-tools_1.4.0-1_all.deb subversion_1.4.0-1.diff.gz to pool/main/s/subversion/subversion_1.4.0-1.diff.gz subversion_1.4.0-1.dsc to pool/main/s/subversion/subversion_1.4.0-1.dsc subversion_1.4.0-1_i386.deb to pool/main/s/subversion/subversion_1.4.0-1_i386.deb subversion_1.4.0.orig.tar.gz to pool/main/s/subversion/subversion_1.4.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Extended partition creation policy ?
[David Balazic] I noticed, that when the debian installer is instructed to create two partitions, whose joint size is less than the size of the disk, then it creates one primary partition and one logical partition inside an extended partition. cfdisk does the same thing - however, it also has no problem resizing the extended partition any time you create another logical drive. It handles extended partitions so transparently you never even know they are there, unless you already know how partition tables work. I suggest getting accustomed to cfdisk. Once you figure out what the 4 arrow keys do, it's really easy to use. I'm not saying the issue you talk about isn't an issue, I'm just saying it has a very simple workaround. (Note also: unlike some partitioning tools, it does not make changes to the disk immediately, you have to save your changes explicitly using the [Write] command.) signature.asc Description: Digital signature
minutes of debburn/cdrkit team meeting, 2006-09-05
The debburn/cdrkit maintainers held an IRC meeting on #debburn on irc.debian.org, Tuesday, 2006-09-05, 19:00 UTC. 26 people were in the channel. Participating and actively lurking: * Joerg Jaspert, developer / project admin * Eduard Bloch, developer * Steve McIntyre, developer * Peter Samuelson, contributor * Luis Medinas, Gentoo cdrtools maintainer * Christian Fromme, contributor * Motoko Aoyama (Note: in these minutes, Joerg is Joerg Jaspert, _not_ former upstream maintainer Joerg Schilling.) Joerg opened the meeting at 19:02 with a question: Do we want to go away from source compatibility with cdrtools? He believes that license problems prevent merging most patches from cdrtools anyway, except mkisofs. Eduard said it's possible to encourage contributors to send patches to both forks; Peter and Joerg suggested that patches might flow from cdrkit to cdrtools. Steve expressed some doubt that Joerg Schilling ever accepts outside patches to cdrecord anyway. Consensus was that source-level compatibility is _not_ worth the trouble, although command-line compatibility with cdrecord shall be provided at least until after etch is released. Joerg proposed a hacking policy of doing disruptive changes on a branch, and keeping the development trunk stable. Nobody disagreed. Joerg asked whether to split the source into multiple tarballs - wodim, cdda2wav, mkisofs, possibly the support libraries. He suggested that this be done after etch. Luis thought separate tarballs would be easier to maintain. Peter thought it was a good idea, though possibly a lot of work due to the use of libscg and libschily. Joerg agreed. Steve wanted to start phasing out libschily, as we should be able to assume a working libc for our target platforms. More general agreement, though Joerg was concerned about ensuring portability. Peter asked for confirmation that cdrkit can officially require ANSI C. (The question had come up earlier as an aside, and several people had agreed.) Joerg proposed that this happen on a branch. Everyone agreed. Eduard asked for confirmation that the 'mods-archive' directory (a set of Debian cdrtools patches, already applied to cdrkit) could be deleted or moved. [Two minutes later he moved it outside the main tree.] Joerg asked about a policy for deciding to give someone svn commit access. He noted that while some contributors are well known from Debian work, other current and future contributors will come from outside Debian and will not be well known here. Peter suggested that it be decided simply based on a history of good patches. Steve agreed. Eduard suggested also requiring a gpg chain-of-trust. Joerg agreed that it's necessary to see some patches before giving a person commit access, and suggested that when someone asks for access, an existing commiter advocate the person. Luis thought that was fair. Eduard asked for opinions on a copyright messages policy, given the potential for social and legal FUD and harassment from the original upstream author. Peter clarified that this was about user-visible output messages, not copyright notices inside the source, which must be retained regardless. Joerg suggested leaving the original copyright lines in the output, and adding a line for the current maintainers where appropriate, as well as a notice not to bother the original author. Peter was unhappy with the verbose report currently output. Eduard proposed adding even more text, including the address for bug reports ([EMAIL PROTECTED]). Consensus was to add this notice, but also streamline the whole header somewhat. [Eduard wrote and committed a patch for this a few minutes after the meeting]. Eduard asked what to do about the bugs now open against cdda2wav and mkisofs in the Debian BTS. He suggested to ping the contributors, wait 4 weeks, close? Joerg agreed. After a bit of off-meeting-topic discussion, Joerg declared the meeting adjourned at 19:35. signature.asc Description: Digital signature
Accepted subversion 1.3.2-6 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 2 Sep 2006 05:04:09 -0500 Source: subversion Binary: libsvn-core-perl libsvn0 libsvn-javahl libsvn-doc libsvn-ruby libapache2-svn libsvn-ruby1.8 python-subversion subversion-tools subversion libsvn0-dev Architecture: source all i386 Version: 1.3.2-6 Distribution: unstable Urgency: low Maintainer: Guilherme de S. Pastore [EMAIL PROTECTED] Changed-By: Peter Samuelson [EMAIL PROTECTED] Description: libapache2-svn - Subversion server modules for Apache libsvn-core-perl - Perl bindings for Subversion libsvn-doc - Developer documentation for libsvn0 libsvn-javahl - Java bindings for Subversion libsvn-ruby - Ruby bindings for Subversion (dummy package) libsvn-ruby1.8 - Ruby bindings for Subversion libsvn0- Shared libraries used by Subversion libsvn0-dev - Development files for Subversion libraries python-subversion - Python bindings for Subversion subversion - Advanced version control system subversion-tools - Assorted tools related to Subversion Closes: 378837 383880 385146 385589 Changes: subversion (1.3.2-6) unstable; urgency=low . [ Peter Samuelson ] * Add libsvn0 Conflicts: subversion ( 1.3) to prevent chaos from linking to both neon24 and neon25. * Add libsvn0 Conflicts: python2.3-subversion ( 1.2.3dfsg1-1) because of the libsvn_swig_py move. (Closes: #385146) * Link with Berkeley DB 4.4. (Closes: #385589, #383880 again) - patches/bdb-44: new patch cobbled together from upstream trunk * patches/ruby-test-svnserve-race: update from our 'sleep 3' hack to what I hope is a proper fix. Thanks to Kobayashi Noritada, Wouter Verhelst and Roman Zippel. (Closes: #378837) * Switch to python-support. Files: 9fce589312478a23801beb47ce3e8e94 1243 devel optional subversion_1.3.2-6.dsc b76c72d16a27a7ac2ccfaa1b1db0cc43 64362 devel optional subversion_1.3.2-6.diff.gz ef231f1f10b82bf4e22bddf1626e4012 1031804 doc extra libsvn-doc_1.3.2-6_all.deb eae69eaf21c8e007c9c3e31f62041ff9 121414 admin extra subversion-tools_1.3.2-6_all.deb ee11a3e0b93d694e9067bf0eeef17f2e 748 devel optional libsvn-ruby_1.3.2-6_all.deb a8d886e01f5806d590d4755706989cef 946284 devel optional subversion_1.3.2-6_i386.deb 89a3257dbe590634080454e2328b86b0 546430 libs optional libsvn0_1.3.2-6_i386.deb c0f07fe3c7d46cdb60e4a302c8ad3ce7 760786 libdevel extra libsvn0-dev_1.3.2-6_i386.deb 16c5cd538640c81c49614d1fe1fc7503 116424 net optional libapache2-svn_1.3.2-6_i386.deb 1fa7b652319254e0c49ab441d2ccc14b 454480 python optional python-subversion_1.3.2-6_i386.deb b05fc8977e8bd4a856e135c68035e631 193938 devel optional libsvn-javahl_1.3.2-6_i386.deb 299358ff6ff155b810ad03d5bba6edb2 735206 perl optional libsvn-core-perl_1.3.2-6_i386.deb 560ab7a112f39f46e2f3c89f998f8b24 347720 devel optional libsvn-ruby1.8_1.3.2-6_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFE+YBDHTOcZYuNdmMRAjE5AJ0TvaGRm1ciLBVPdrGEXmkp7O311ACdE9F4 NawBu2/xzhKcmBcDU/du+w0= =a0LU -END PGP SIGNATURE- Accepted: libapache2-svn_1.3.2-6_i386.deb to pool/main/s/subversion/libapache2-svn_1.3.2-6_i386.deb libsvn-core-perl_1.3.2-6_i386.deb to pool/main/s/subversion/libsvn-core-perl_1.3.2-6_i386.deb libsvn-doc_1.3.2-6_all.deb to pool/main/s/subversion/libsvn-doc_1.3.2-6_all.deb libsvn-javahl_1.3.2-6_i386.deb to pool/main/s/subversion/libsvn-javahl_1.3.2-6_i386.deb libsvn-ruby1.8_1.3.2-6_i386.deb to pool/main/s/subversion/libsvn-ruby1.8_1.3.2-6_i386.deb libsvn-ruby_1.3.2-6_all.deb to pool/main/s/subversion/libsvn-ruby_1.3.2-6_all.deb libsvn0-dev_1.3.2-6_i386.deb to pool/main/s/subversion/libsvn0-dev_1.3.2-6_i386.deb libsvn0_1.3.2-6_i386.deb to pool/main/s/subversion/libsvn0_1.3.2-6_i386.deb python-subversion_1.3.2-6_i386.deb to pool/main/s/subversion/python-subversion_1.3.2-6_i386.deb subversion-tools_1.3.2-6_all.deb to pool/main/s/subversion/subversion-tools_1.3.2-6_all.deb subversion_1.3.2-6.diff.gz to pool/main/s/subversion/subversion_1.3.2-6.diff.gz subversion_1.3.2-6.dsc to pool/main/s/subversion/subversion_1.3.2-6.dsc subversion_1.3.2-6_i386.deb to pool/main/s/subversion/subversion_1.3.2-6_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted subversion 1.4.0~rc5-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 24 Aug 2006 05:31:24 -0500 Source: subversion Binary: libsvn1 libsvn-perl libsvn-doc libsvn-dev libsvn-ruby libapache2-svn libsvn-ruby1.8 libsvn-java python-subversion subversion-tools subversion Architecture: source all i386 Version: 1.4.0~rc5-1 Distribution: experimental Urgency: low Maintainer: Guilherme de S. Pastore [EMAIL PROTECTED] Changed-By: Peter Samuelson [EMAIL PROTECTED] Description: libapache2-svn - Subversion server modules for Apache libsvn-dev - Development files for Subversion libraries libsvn-doc - Developer documentation for libsvn1 libsvn-java - Java bindings for Subversion libsvn-perl - Perl bindings for Subversion libsvn-ruby - Ruby bindings for Subversion (dummy package) libsvn-ruby1.8 - Ruby bindings for Subversion libsvn1- Shared libraries used by Subversion python-subversion - Python bindings for Subversion subversion - Advanced version control system subversion-tools - Assorted tools related to Subversion Changes: subversion (1.4.0~rc5-1) experimental; urgency=low . * New upstream version. - patches/ruby-txtdelta-apply-instructions: remove (obsolete). Files: 71c1711be450c9ea949cf6cb7493576c 1262 devel optional subversion_1.4.0~rc5-1.dsc 8872e0f20e2d1cb796cf75fd9e4a47ea 6264047 devel optional subversion_1.4.0~rc5.orig.tar.gz bf6ab8e41a4924acff6a135e3505d117 46237 devel optional subversion_1.4.0~rc5-1.diff.gz 3eef88c3d0eb9370d3b8f7397c9226ff 1064576 doc extra libsvn-doc_1.4.0~rc5-1_all.deb a906edfd90addccab0c2574f9d141382 127850 admin extra subversion-tools_1.4.0~rc5-1_all.deb 4b384c372044a8cfb059b40245646754 748 devel optional libsvn-ruby_1.4.0~rc5-1_all.deb 55d112a0064a0822b984afae0530060d 1011624 devel optional subversion_1.4.0~rc5-1_i386.deb 568c6a6650ad3324a06ac4e1529a8c89 586054 libs optional libsvn1_1.4.0~rc5-1_i386.deb c9eeab27b46290414645f75d565df617 817804 libdevel extra libsvn-dev_1.4.0~rc5-1_i386.deb 2a397b9923a10fecd981afafbdae0732 123130 net optional libapache2-svn_1.4.0~rc5-1_i386.deb 0935a54d2884feff279974150e22933a 491914 python optional python-subversion_1.4.0~rc5-1_i386.deb df52eaeb4a09f68590aad361be20dc51 200430 devel optional libsvn-java_1.4.0~rc5-1_i386.deb 0906cec3cce947191bf568497e1e3a4c 794068 perl optional libsvn-perl_1.4.0~rc5-1_i386.deb 5827ea2f63c4e79d9a116acb2a183deb 375350 devel optional libsvn-ruby1.8_1.4.0~rc5-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE9yCnQOr9C+GfGI4RAtGmAKCuhOnsWge+LrfuImWztuSwQKEEHwCdGM7s 5l6Qzic7184dQyhM6I4fuXc= =2LzW -END PGP SIGNATURE- Accepted: libapache2-svn_1.4.0~rc5-1_i386.deb to pool/main/s/subversion/libapache2-svn_1.4.0~rc5-1_i386.deb libsvn-dev_1.4.0~rc5-1_i386.deb to pool/main/s/subversion/libsvn-dev_1.4.0~rc5-1_i386.deb libsvn-doc_1.4.0~rc5-1_all.deb to pool/main/s/subversion/libsvn-doc_1.4.0~rc5-1_all.deb libsvn-java_1.4.0~rc5-1_i386.deb to pool/main/s/subversion/libsvn-java_1.4.0~rc5-1_i386.deb libsvn-perl_1.4.0~rc5-1_i386.deb to pool/main/s/subversion/libsvn-perl_1.4.0~rc5-1_i386.deb libsvn-ruby1.8_1.4.0~rc5-1_i386.deb to pool/main/s/subversion/libsvn-ruby1.8_1.4.0~rc5-1_i386.deb libsvn-ruby_1.4.0~rc5-1_all.deb to pool/main/s/subversion/libsvn-ruby_1.4.0~rc5-1_all.deb libsvn1_1.4.0~rc5-1_i386.deb to pool/main/s/subversion/libsvn1_1.4.0~rc5-1_i386.deb python-subversion_1.4.0~rc5-1_i386.deb to pool/main/s/subversion/python-subversion_1.4.0~rc5-1_i386.deb subversion-tools_1.4.0~rc5-1_all.deb to pool/main/s/subversion/subversion-tools_1.4.0~rc5-1_all.deb subversion_1.4.0~rc5-1.diff.gz to pool/main/s/subversion/subversion_1.4.0~rc5-1.diff.gz subversion_1.4.0~rc5-1.dsc to pool/main/s/subversion/subversion_1.4.0~rc5-1.dsc subversion_1.4.0~rc5-1_i386.deb to pool/main/s/subversion/subversion_1.4.0~rc5-1_i386.deb subversion_1.4.0~rc5.orig.tar.gz to pool/main/s/subversion/subversion_1.4.0~rc5.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
[Nathanael Nerode] So -- point me to the correct parts of the installer. I don't know where to find this anna. svn://svn.debian.org/d-i/trunk/packages/anna signature.asc Description: Digital signature
Re: apache2.2 uploaded to experimental
[Thom May] This version is not yet ready for unstable, and hence also not for etch, because it requires more testing. All maintainers of apache modules are encouraged to test their modules against apache2.2 from experimental, and upload tested modules to experimental. In the same vein, we've just uploaded subversion 1.4.0~rc4-2 to experimental (see 'incoming'). We hope to have 1.4.0 in etch; it's not a revolutionary change from 1.2.x/1.3.x, but even so, of course, some testing would be appreciated. (This release is tied to apache 2.2, but we can return to 2.0 if need be.) The code itself seems quite solid to me, but I do need to note that it's still a release candidate. Also, PLEASE DO read /usr/share/doc/libsvn1/NEWS.Debian.gz, regarding upgrades and downgrades. Thanks, Peter, for the Debian Subversion team signature.asc Description: Digital signature
Accepted subversion 1.4.0~rc4-2 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 18 Aug 2006 13:06:49 -0500 Source: subversion Binary: libsvn1 libsvn-perl libsvn-doc libsvn-dev libsvn-ruby libapache2-svn libsvn-ruby1.8 libsvn-java python-subversion subversion-tools subversion Architecture: source all i386 Version: 1.4.0~rc4-2 Distribution: experimental Urgency: low Maintainer: Guilherme de S. Pastore [EMAIL PROTECTED] Changed-By: Peter Samuelson [EMAIL PROTECTED] Description: libapache2-svn - Subversion server modules for Apache libsvn-dev - Development files for Subversion libraries libsvn-doc - Developer documentation for libsvn1 libsvn-java - Java bindings for Subversion libsvn-perl - Perl bindings for Subversion libsvn-ruby - Ruby bindings for Subversion (dummy package) libsvn-ruby1.8 - Ruby bindings for Subversion libsvn1- Shared libraries used by Subversion python-subversion - Python bindings for Subversion subversion - Advanced version control system subversion-tools - Assorted tools related to Subversion Changes: subversion (1.4.0~rc4-2) experimental; urgency=low . [ Peter Samuelson ] * Reenable apache support; build-depend on apache2-threaded-dev 2.2, now that it's in experimental. * Build-Depends: remove bison, relax python version again (as python handling is now done by python-support). * patches/ruby-txtdelta-apply-instructions: new patch from upstream, fixes the test failure on amd64. * Compile against libdb4.4, which should fix the famous wedged repository issue. - Build-Depends: libaprutil1-dev (= 1.2.7+dfsg-1) - Update rules, control, README.db4.4 - Add note to libsvn1.NEWS - please read it! Files: 2c0132f1af222893ac1a1aadb7ce2b97 1262 devel optional subversion_1.4.0~rc4-2.dsc 285673de3bb75b30177b0c2144d57abf 46483 devel optional subversion_1.4.0~rc4-2.diff.gz 04e0f929615c0067ad6fe8949ed4dc12 1109414 doc extra libsvn-doc_1.4.0~rc4-2_all.deb 6c6e382df2a6f2b7b321b1d921d526f9 127872 admin extra subversion-tools_1.4.0~rc4-2_all.deb 6860188cc3398593248ac14b6fdbc70c 752 devel optional libsvn-ruby_1.4.0~rc4-2_all.deb 0680fd816227d1a4b07509fcfb0efaaa 1008978 devel optional subversion_1.4.0~rc4-2_i386.deb 68d3ec3dd1cbb7e544cf0ed6c3106dfb 585214 libs optional libsvn1_1.4.0~rc4-2_i386.deb b1b9afab7c095245c2fb1c19f67e029f 814780 libdevel extra libsvn-dev_1.4.0~rc4-2_i386.deb 5578ce2a6a5e61334c8039ac71bd43ac 123050 net optional libapache2-svn_1.4.0~rc4-2_i386.deb 2eb63c6d1c7f7f355a5dc06d81d9b1f4 490334 python optional python-subversion_1.4.0~rc4-2_i386.deb 944ba589655f913cdfbb4f51dc9f9364 199854 devel optional libsvn-java_1.4.0~rc4-2_i386.deb ba961a0ab76ef53105d5274d53bcdeb8 794016 perl optional libsvn-perl_1.4.0~rc4-2_i386.deb ca5a7a25d27e8a65f3522dbfc49cddb6 375498 devel optional libsvn-ruby1.8_1.4.0~rc4-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE52zqQOr9C+GfGI4RAsW8AJ9jVme/l0mjDUPAJYC7iND3mKlY/ACeJDkf EtII6bZxvzwVYDh7r2M4VzA= =ICTH -END PGP SIGNATURE- Accepted: libapache2-svn_1.4.0~rc4-2_i386.deb to pool/main/s/subversion/libapache2-svn_1.4.0~rc4-2_i386.deb libsvn-dev_1.4.0~rc4-2_i386.deb to pool/main/s/subversion/libsvn-dev_1.4.0~rc4-2_i386.deb libsvn-doc_1.4.0~rc4-2_all.deb to pool/main/s/subversion/libsvn-doc_1.4.0~rc4-2_all.deb libsvn-java_1.4.0~rc4-2_i386.deb to pool/main/s/subversion/libsvn-java_1.4.0~rc4-2_i386.deb libsvn-perl_1.4.0~rc4-2_i386.deb to pool/main/s/subversion/libsvn-perl_1.4.0~rc4-2_i386.deb libsvn-ruby1.8_1.4.0~rc4-2_i386.deb to pool/main/s/subversion/libsvn-ruby1.8_1.4.0~rc4-2_i386.deb libsvn-ruby_1.4.0~rc4-2_all.deb to pool/main/s/subversion/libsvn-ruby_1.4.0~rc4-2_all.deb libsvn1_1.4.0~rc4-2_i386.deb to pool/main/s/subversion/libsvn1_1.4.0~rc4-2_i386.deb python-subversion_1.4.0~rc4-2_i386.deb to pool/main/s/subversion/python-subversion_1.4.0~rc4-2_i386.deb subversion-tools_1.4.0~rc4-2_all.deb to pool/main/s/subversion/subversion-tools_1.4.0~rc4-2_all.deb subversion_1.4.0~rc4-2.diff.gz to pool/main/s/subversion/subversion_1.4.0~rc4-2.diff.gz subversion_1.4.0~rc4-2.dsc to pool/main/s/subversion/subversion_1.4.0~rc4-2.dsc subversion_1.4.0~rc4-2_i386.deb to pool/main/s/subversion/subversion_1.4.0~rc4-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: afraid to build from source? (was Re: Remove cdrtools)
[Wouter Verhelst] It has nothing to do with being afraid to, but everything with not needing to. There's lots of things we don't _need_ to do but we do anyway, as a matter of quality of implementation. I believe that building a package from source is something we should do as well, if only to ensure that our packages do continue to build from source, using our tools. And when I say from source, I'm using the GPL definition of source code, the preferred form for making modificatons, which I think is a pretty useful definition in general. Sure, you should verify that things still work if you run autoreconf on your source tarball, but there is no real need to build autotools output files in the build target of debian/rules if all you want to do is verify that they build properly. The same could be said for lots of other tools: bison and flex are the obvious ones, but also yodl, docbook2x and other documentation convertors. Is it reasonable to tell maintainers that every architecture-independent generated file should be built manually and shipped in the .diff.gz rather than built as part of the debian build? Moreover, this thread, at least to me, is more about what an upstream should do rather than what a Debian developer should do; it is not good practice as an upstream to assume that anyone else than yourself will need to run the autotools on your input files on a regular basis. What an upstream should do and what Debian should do are quite different things. It has long been accepted that an upstream's best practice is _not_ to require users to have autoconf installed locally - they can assume you have a compiler and make and common tools like awk, but not autoconf or flex. Debian does not have this problem. Our 'apt-get build-dep' command ensures that it is convenient for our users to use pretty much any tool we need, when rebuilding our packages. We don't _have_ to worry about providing pre-built output from autoconf, flex, bison and the like. Our build dependencies even make it easy to require a particular minimum version of any tool. In summary, I think it's important for our users to be able to build packages from source. This implies that _we_ should build from source, in order to exercise the whole toolchain, so that we know it always works. And if it's so fragile that it _doesn't_ always work ... well, then _that's_ a problem which needs to be addressed. Is the autoconf unreliability problem really so intractible that it requires a workaround of don't ever use it except in a manual process where you can test it immediately to see if it worked? Would we tolerate that same requirement in a tool like docbook2x? signature.asc Description: Digital signature
Re: Remove cdrtools
[Steve Greenland] By autoconf related problems I mean things like it suddenly deciding it's running a cross compiler, or that stdlib.h is missing. A lot of this kind of stuff could be improved by simply SHOWING ME THE FSCKING ERROR MESSAGES, rather than just checking the return code and guessing. Too bad autoconf doesn't keep a log of everything configure does.[1] [1] In case you missed it, it's called 'config.log'. signature.asc Description: Digital signature
Re: Remove cdrtools
[Steve Greenland] My experience is that the ones whose build instructions say edit the makefile to pick your platform and compiler compile and work, and when they don't, they're easy to fix. The ones that use autoconf tend to blow up on non-Linux[1], in ways that are hard to debug and damn near impossible to fix. This, as you note in your footnote, is probably attributable entirely to whether the developers actually have a clue that there is more to Unix than Linux/i386. The style of uncommenting defines in a Makefile, versus autoconf, is an _effect_, not a cause - the effect only _appears_ to be causal because the Unix-ignorant don't tend to use the former style. There is, either way, no substitute for awareness of portability issues, and no substitute for actual development experience on multiple Unix platforms. As for useless autoconf tests - have you looked at how autoconf is used? You pick the tests you think you need. It's not like the system forces you to use a certain range of obsolete baseline tests. A huge number of test macros are provided, but nobody forces you to use them. signature.asc Description: Digital signature
Re: Is inability to operate with root read-only (and separate /etc, /dev, etc) a bug or design decision?
[Philipp Matthias Hahn] Which doesn't work because of linux-utils-2.12r/mount/fstab.c:55 As I recall, Andries (util-linux upstream) produced, at least a year ago, a kernel patch which allows the kernel to store an extra string of user data from 'mount', and display it in /proc/mounts, so that neither mount nor umount need bother with /etc/mtab. In other words, upstream is well aware of this issue and has a solution ready to implement, if only someone would merge the patch into the kernel. And if only I could actually find the lkml reference to this. signature.asc Description: Digital signature
afraid to build from source? (was Re: Remove cdrtools)
[Michael Poole] On top of the default automake behavior being horribly broken, does that make usual revision control practices horribly broken? It really bothers me to hear people claim as a best practice that you should never recompile configure.ac or Makefile.am except under controlled conditions. To me it is a very important philosophical point that Debian be self-hosting. That means packages should build without error from source, not just from intermediate text files like 'y.tab.c', 'configure', or 'Makefile.in' which, while arch-independent, are not particularly human-editable, and certainly not source code in the GPL sense. Using a provided 'configure' binary instead of building from source has the same problem as using any other provided binary rather than building from source. It clearly expresses a lack of confidence that the system _is_ in fact self-hosting. It tells our users, we will give you all the source code, but you'd better not modify that one configure.in source file, because we do not dare trust our tools to build it correctly. So yeah, I advocate always building packages from source, and if autoconf someday comes up with an incompatibility that causes a FTBFS somewhere, let that be reported and fixed. Not just worked around by trying to avoid running autoconf. signature.asc Description: Digital signature
Re: afraid to build from source?
[Goswin von Brederlow] The big problem is that those autogenerated build scripts will be non deterministic on the buildd network and on users system. Depending on the installed packages (automake/autoconf versions) you get different results and often failures. :( What low expectations we have. Why are we willing to tolerate this in autotools? We wouldn't tolerate it in other development tools like make. Reliable ability to build things seems to be a fairly basic property of a build tool. signature.asc Description: Digital signature
Re: afraid to build from source?
[Goswin von Brederlow] Even make breaks from time to time. I distinctly remeber an update of make that caused problems. There are also several gcc versions that are quite different in their behaviour. Yes, and we treat such instances as bugs and fix them - whether it's fixing your packages or fixing the tools. We don't just try to avoid ever running the development tools on the expectation that they'll probably fail. I don't see why we should give autoconf and automake special treatment. We control their distribution in Debian, we should be able to control whether they break. Saying that we can't control their stability, and that developers should just avoid relying on them to work, is abdicating an important responsibility of a maintainer. But unlike automake/autoconf we only have one version of make in the archive and everything is fixed to work with it. It seems to me that the multiple automakes in debian are a _feature_ which allow you to safely build-depend on the one you need, since they aren't all alike. Not a reason to avoid using automake at build time. If you can't figure out how to build-depend on the same version of automake your upstream uses ... uh, you have a few things to learn about package maintenance. As for autoconf, there's only been one major interface break in the past ten years, at 2.50. Regressions and interface changes since 2.50 should be treated as bugs to be fixed, until such time as upstream declares that they're once again breaking the API on purpose, like they did in 2.50. It probably is due to the fact that you can change the source and build it without altering the configure.in/Makefile.am/Makefile.in files in most cases. It's true that you can, but it's no excuse. Upstream has reason to ship pre-built automake/autoconf output, because historically, random users could be expected to have 'make' and a C compiler, but couldn't be expected to have autoconf. In Debian we are not constrained by that, we should not have to avoid building packages entirely from source. signature.asc Description: Digital signature
Re: ITP: subtitleeditor -- Graphical subtitle editor with sound waves representation
[Amaya Rodrigo Sastre] This program also shows soundwaves which makes it easier for subtitles synchronisation that most other subtitle editors like ksubtile or gaupol. This program also shows sound waves, which makes it easier to synchronise subtitles to voices. No need to mention the competitors, really. signature.asc Description: Digital signature
Re: Is inability to operate with root read-only (and separate /etc, /dev, etc) a bug or design decision?
[Goswin von Brederlow] Instead move the things in etc that need writing to other places: 1) link /etc/mtab to /proc/mounts and create a dummy /proc/mounts on / for when /proc isn't mounted (works with quota in current kernels). Does the wrong thing with (a) user and (b) loop mounts. [I just tested 2.6.16-1-k7.] /etc/mtab needs to keep enough state for umount to know (a) who mounted something, so the same user can unmount it, and (b) that a loop device was set up automatically via 'mount -o loop', rather than done separately, so that umount can 'losetup -d /dev/loopN'. This is information which cannot, at present, be put in /proc/mounts. 2) Link /etc/resolv.conf to /var or install resolvconf package. 3) Link /etc/network/run to /dev/shm/ Wait, didn't /run get created at some point? Did that get reverted, and if so, why? signature.asc Description: Digital signature
Accepted subversion 1.4.0~rc4-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 10 Aug 2006 20:43:19 -0500 Source: subversion Binary: libsvn1 libsvn-perl libsvn-doc libsvn-dev libsvn-ruby libapache2-svn libsvn-ruby1.8 libsvn-java python-subversion subversion-tools subversion Architecture: source all i386 Version: 1.4.0~rc4-1 Distribution: experimental Urgency: low Maintainer: Guilherme de S. Pastore [EMAIL PROTECTED] Changed-By: Peter Samuelson [EMAIL PROTECTED] Description: libsvn-dev - Development files for Subversion libraries libsvn-doc - Developer documentation for libsvn1 libsvn-java - Java bindings for Subversion libsvn-perl - Perl bindings for Subversion libsvn-ruby - Ruby bindings for Subversion (dummy package) libsvn-ruby1.8 - Ruby bindings for Subversion libsvn1- Shared libraries used by Subversion python-subversion - Python bindings for Subversion subversion - Advanced version control system subversion-tools - Assorted tools related to Subversion Closes: 217133 233099 377119 Changes: subversion (1.4.0~rc4-1) experimental; urgency=low . * There is a known issue with amd64 and the SvnDeltaTest in the ruby testsuite. . [ Peter Samuelson ] * New upstream release. - commit-email.pl has option not to send diffs. (Closes: #217133) - Help text clarified for options like --file. (Closes: #233099) - Rediff patches. Delete patches already included upstream: apache-crash-fix, bash_completion, lc_ctype, perl-test-clean, svn_load_dirs-symlinks, swig-1.3.28. - Add Build-Depends: zlib1g-dev. * Bump subversion-tools dependencies on the other packages to = 1.4. * Support ENABLE_APACHE macro, to disable 'libapache2-svn'. Disable apache until apache 2.2 makes its way into experimental. * Switch to libapr1, which entails an ABI change to libsvn. - libsvn0 - libsvn1 - libsvn0-dev - libsvn-dev - patches/apr-abi: New patch: change the libsvn_* SONAMEs. (This type of change should be upstream-driven, but upstream has declined to do it.) - patches/fix-bdb-version-detection: New patch: tweak BDB version detection not to rely on an apr-util misfeature (#387105). * Rename libsvn-javahl to libsvn-java, to comply (in spirit) with the Java Policy. (Closes: #377119) * Rename libsvn-core-perl to libsvn-perl, because it provides several modules in the SVN:: namespace, not just SVN::Core. * patches/limit-zlib-link: New patch from upstream to prevent unnecessary -lz linkage in client binaries. * Update copyright file again. * Switch to python-support. * subversion-tools: downgrade rcs and exim4 to Recommends. * Add NEWS entry to libsvn1, explaining compatibility issues - please read it, folks! . [ Troy Heber ] * tweaked rpath patch HUNK 2, so it would apply cleanly. Files: fd91bf123ea45a78593b528d61b46924 1233 devel optional subversion_1.4.0~rc4-1.dsc 7797a9c637c49ba2ad0c9cbf386e0176 6324928 devel optional subversion_1.4.0~rc4.orig.tar.gz dc57f6cae08dd70d7c823e0d45bb31a7 45794 devel optional subversion_1.4.0~rc4-1.diff.gz fd4c9a4767910b49a9ad2d2a4d5d3dd0 105 doc extra libsvn-doc_1.4.0~rc4-1_all.deb 7d214eb7b1f3b4c60156fbc498aee3c5 127268 admin extra subversion-tools_1.4.0~rc4-1_all.deb 9a2de3b74b204c5172ae7e242c553929 752 devel optional libsvn-ruby_1.4.0~rc4-1_all.deb 1e7a093624755be92ec4c3d000116bcd 1008368 devel optional subversion_1.4.0~rc4-1_i386.deb 5d982e4f78ca59292e4d0f9511c71b4e 584876 libs optional libsvn1_1.4.0~rc4-1_i386.deb 14494646ee073da374434f1bdb9433c4 815236 libdevel extra libsvn-dev_1.4.0~rc4-1_i386.deb 0db962a2eec58af6febca9e9eda2dac2 491278 python optional python-subversion_1.4.0~rc4-1_i386.deb 98471ac90d17d7c776718db73d8ce6b9 200054 devel optional libsvn-java_1.4.0~rc4-1_i386.deb ce6a37164b54ca619db934c857110ffa 793636 perl optional libsvn-perl_1.4.0~rc4-1_i386.deb b8258ddf1fd85b168663a139e82c61aa 374580 devel optional libsvn-ruby1.8_1.4.0~rc4-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE3CorgcCJIoCND9ARAudHAKDJ0J4kiOiARaN7PvOkj+KcwVA0cwCgrRV5 gqup3YHAeDgA/mffRydlGWI= =0v6W -END PGP SIGNATURE- Accepted: libsvn-dev_1.4.0~rc4-1_i386.deb to pool/main/s/subversion/libsvn-dev_1.4.0~rc4-1_i386.deb libsvn-doc_1.4.0~rc4-1_all.deb to pool/main/s/subversion/libsvn-doc_1.4.0~rc4-1_all.deb libsvn-java_1.4.0~rc4-1_i386.deb to pool/main/s/subversion/libsvn-java_1.4.0~rc4-1_i386.deb libsvn-perl_1.4.0~rc4-1_i386.deb to pool/main/s/subversion/libsvn-perl_1.4.0~rc4-1_i386.deb libsvn-ruby1.8_1.4.0~rc4-1_i386.deb to pool/main/s/subversion/libsvn-ruby1.8_1.4.0~rc4-1_i386.deb libsvn-ruby_1.4.0~rc4-1_all.deb to pool/main/s/subversion/libsvn-ruby_1.4.0~rc4-1_all.deb libsvn1_1.4.0~rc4-1_i386.deb to pool/main/s/subversion/libsvn1_1.4.0~rc4-1_i386.deb python-subversion_1.4.0~rc4-1_i386.deb to pool/main/s/subversion/python-subversion_1.4.0~rc4-1_i386.deb subversion-tools_1.4.0~rc4
Re: Bug#378112: ITP: gzrt -- gzip recovery toolkit
[Martin Wuertele] Please install cpio 2.5 or higher to facilitate recovery from damaged gzipped tarballs. No need to mension it in the description, that's what dependencies are for. Presumably he intends to merely Recommend cpio, in which case it's entirely appropriate to explain why in the description. signature.asc Description: Digital signature
Re: Alioth Tracker: no correspondence to BTS?
[Toni Mueller] I've just poked around a bit in Alioth for a project I'm working on and found a bug report with a bug number that has no resemblance to anything in BTS, quite contrary to my initial assumption. Yeah, the sourceforge software includes a primitive bug tracker which, as far as I know, people don't really use on alioth. Imho this would only make sense if integrating these two is hard, and if non-Debian projects are hosted on Alioth (I don't know). Yeah, I couldn't tell you why that feature is even enabled on alioth. Do people actually use it? I certainly never check the tracker for alioth projects I'm involved with; I just assume people will use the Debian BTS instead. signature.asc Description: Digital signature
Accepted subversion 1.3.2-2 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 12 Jun 2006 18:50:08 -0500 Source: subversion Binary: libsvn-core-perl libsvn0 libsvn-javahl libsvn-doc libsvn-ruby libapache2-svn libsvn-ruby1.8 python-subversion subversion-tools subversion libsvn0-dev Architecture: source all i386 Version: 1.3.2-2 Distribution: unstable Urgency: low Maintainer: Guilherme de S. Pastore [EMAIL PROTECTED] Changed-By: Peter Samuelson [EMAIL PROTECTED] Description: libapache2-svn - apache modules for Subversion (aka. svn) libsvn-core-perl - perl bindings for Subversion (aka. svn) libsvn-doc - development documentation for Subversion (aka. svn) libraries libsvn-javahl - java bindings for Subversion (aka. svn) libsvn-ruby - ruby modules for interfacing with Subversion (aka. svn) libsvn-ruby1.8 - ruby modules for interfacing with Subversion (aka. svn) libsvn0- shared libraries used by Subversion (aka. svn) libsvn0-dev - development files for Subversion (aka. svn) libraries python-subversion - python modules for interfacing with Subversion (aka. svn) subversion - advanced version control system (aka. svn) subversion-tools - assorted tools related to Subversion (aka. svn) Changes: subversion (1.3.2-2) unstable; urgency=low . [ Peter Samuelson ] * control, rules: switch from kaffe to java-gcj-compat-dev. Thanks to Bastian Blank. Also reenable libsvn-javahl, for now, on all architectures except m68k, mips, mipsel. * ruby-test-svnserve-race.patch: new kludge to avoid a race condition in the ruby testsuite on really slow machines. Files: 37319f4207460891f574759d7032479f 1188 devel optional subversion_1.3.2-2.dsc 7dac57bc95898f5b781adfd6515e2fb5 45744 devel optional subversion_1.3.2-2.diff.gz 59c4f453883a2c25ff95bcd29dd4d2c6 988686 doc extra libsvn-doc_1.3.2-2_all.deb 198de357fbbb19e527d938c392697639 122736 admin extra subversion-tools_1.3.2-2_all.deb f3e7a3f5205cce563cc36307482d 960 devel optional libsvn-ruby_1.3.2-2_all.deb 6c546eca8fac2ccf60490609c034d9dc 945662 devel optional subversion_1.3.2-2_i386.deb b13512754cdf743510f006fb10d8529d 543962 libs optional libsvn0_1.3.2-2_i386.deb 49c5e389096a479f6f100918ac8cdaf1 757154 libdevel extra libsvn0-dev_1.3.2-2_i386.deb 29ba94ed2a73056beba99802e6eca348 115614 net optional libapache2-svn_1.3.2-2_i386.deb 3be8c571f5f16f174f0d65c7b7e0efe6 518346 python optional python-subversion_1.3.2-2_i386.deb 6101240edfe4ae6f706b71c5e55469ec 192840 devel optional libsvn-javahl_1.3.2-2_i386.deb b8209598a1efb56ac65bee855b0cff3d 734490 perl optional libsvn-core-perl_1.3.2-2_i386.deb 0596d8664486a1c61b4b502912c32ca1 345418 devel optional libsvn-ruby1.8_1.3.2-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEkCCwQOr9C+GfGI4RAi1cAJ9KOegWNmQgRGnIFUZNbVsqmIp3PgCfRCjY TpAyqQv5Zn3hUGd4VQ8lm5U= =yBVv -END PGP SIGNATURE- Accepted: libapache2-svn_1.3.2-2_i386.deb to pool/main/s/subversion/libapache2-svn_1.3.2-2_i386.deb libsvn-core-perl_1.3.2-2_i386.deb to pool/main/s/subversion/libsvn-core-perl_1.3.2-2_i386.deb libsvn-doc_1.3.2-2_all.deb to pool/main/s/subversion/libsvn-doc_1.3.2-2_all.deb libsvn-javahl_1.3.2-2_i386.deb to pool/main/s/subversion/libsvn-javahl_1.3.2-2_i386.deb libsvn-ruby1.8_1.3.2-2_i386.deb to pool/main/s/subversion/libsvn-ruby1.8_1.3.2-2_i386.deb libsvn-ruby_1.3.2-2_all.deb to pool/main/s/subversion/libsvn-ruby_1.3.2-2_all.deb libsvn0-dev_1.3.2-2_i386.deb to pool/main/s/subversion/libsvn0-dev_1.3.2-2_i386.deb libsvn0_1.3.2-2_i386.deb to pool/main/s/subversion/libsvn0_1.3.2-2_i386.deb python-subversion_1.3.2-2_i386.deb to pool/main/s/subversion/python-subversion_1.3.2-2_i386.deb subversion-tools_1.3.2-2_all.deb to pool/main/s/subversion/subversion-tools_1.3.2-2_all.deb subversion_1.3.2-2.diff.gz to pool/main/s/subversion/subversion_1.3.2-2.diff.gz subversion_1.3.2-2.dsc to pool/main/s/subversion/subversion_1.3.2-2.dsc subversion_1.3.2-2_i386.deb to pool/main/s/subversion/subversion_1.3.2-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted subversion 1.3.2-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 1 Jun 2006 04:10:19 -0500 Source: subversion Binary: libsvn-core-perl libsvn0 libsvn-javahl libsvn-doc libsvn-ruby libapache2-svn libsvn-ruby1.8 python-subversion subversion-tools subversion libsvn0-dev Architecture: source all i386 Version: 1.3.2-1 Distribution: unstable Urgency: low Maintainer: Guilherme de S. Pastore [EMAIL PROTECTED] Changed-By: Peter Samuelson [EMAIL PROTECTED] Description: libapache2-svn - apache modules for Subversion (aka. svn) libsvn-core-perl - perl bindings for Subversion (aka. svn) libsvn-doc - development documentation for Subversion (aka. svn) libraries libsvn-javahl - java bindings for Subversion (aka. svn) libsvn-ruby - ruby modules for interfacing with Subversion (aka. svn) libsvn-ruby1.8 - ruby modules for interfacing with Subversion (aka. svn) libsvn0- shared libraries used by Subversion (aka. svn) libsvn0-dev - development files for Subversion (aka. svn) libraries python-subversion - python modules for interfacing with Subversion (aka. svn) subversion - advanced version control system (aka. svn) subversion-tools - assorted tools related to Subversion (aka. svn) Changes: subversion (1.3.2-1) unstable; urgency=low . [ Peter Samuelson ] * New upstream release. - Remove patches applied upstream: apache-crash-fix.patch, svn_load_dirs-symlinks.patch, swig-1.3.28.patch * debian/watch: new file for use by 'uscan' from devscripts. * Standards version 3.7.2. (No changes.) * control: upgrade Build-Conflicts to libsvn0 ( 1.3). This is that old workaround for #291641. * rules: rework testsuite invocation: - Add 'check' series of targets, and 'check-help' to remind one of what they are - Conditionalise javahl tests on ENABLE_JAVAHL - Reorder the checks to put the core tests at the end; they are by far the most time-consuming, and rarely fail anyway - Only 'cat tests.log' if the core tests fail: the other testsuites don't use that file anyway Files: 25207a08ff0e38bfcf74478762175c28 1407 devel optional subversion_1.3.2-1.dsc f790c49c219b4196e37ebfa71ab797d5 8803719 devel optional subversion_1.3.2.orig.tar.gz a5a82964435a8315b7d0bb6a617203aa 45027 devel optional subversion_1.3.2-1.diff.gz deef6b666e81f7ced4a7c2e74f110192 988456 doc extra libsvn-doc_1.3.2-1_all.deb d5716d72c91849cc874b1f753120700c 122504 admin extra subversion-tools_1.3.2-1_all.deb 738e3388b21463266f760b979ce0aa1e 954 devel optional libsvn-ruby_1.3.2-1_all.deb f7d92f76a6c39258d8fd4b729e663b87 944916 devel optional subversion_1.3.2-1_i386.deb a051ce2b310b6bb08fbf90b38dc89985 545328 libs optional libsvn0_1.3.2-1_i386.deb 513751903c909a693874bad24e822923 759286 libdevel extra libsvn0-dev_1.3.2-1_i386.deb f04dd7cd34749c6f7e3de0189f2eca4d 115660 net optional libapache2-svn_1.3.2-1_i386.deb 1fdf7dba2e7c66ac39ac8b547d90b82f 518800 python optional python-subversion_1.3.2-1_i386.deb 38ab78a5029666ce45e897afe9438ea8 193078 devel optional libsvn-javahl_1.3.2-1_i386.deb 371e3ae6759a25a671220e26439bf8a6 736630 perl optional libsvn-core-perl_1.3.2-1_i386.deb 673fe0387c870724975d7b3b559051b4 345614 devel optional libsvn-ruby1.8_1.3.2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEfz2yipBneRiAKDwRAompAJ9LPmgiBRnE1pFiF0BRt5xJDqgGdgCglNcw Kilet/A9Z5YhKeGTp2NXNlY= =pi+g -END PGP SIGNATURE- Accepted: libapache2-svn_1.3.2-1_i386.deb to pool/main/s/subversion/libapache2-svn_1.3.2-1_i386.deb libsvn-core-perl_1.3.2-1_i386.deb to pool/main/s/subversion/libsvn-core-perl_1.3.2-1_i386.deb libsvn-doc_1.3.2-1_all.deb to pool/main/s/subversion/libsvn-doc_1.3.2-1_all.deb libsvn-javahl_1.3.2-1_i386.deb to pool/main/s/subversion/libsvn-javahl_1.3.2-1_i386.deb libsvn-ruby1.8_1.3.2-1_i386.deb to pool/main/s/subversion/libsvn-ruby1.8_1.3.2-1_i386.deb libsvn-ruby_1.3.2-1_all.deb to pool/main/s/subversion/libsvn-ruby_1.3.2-1_all.deb libsvn0-dev_1.3.2-1_i386.deb to pool/main/s/subversion/libsvn0-dev_1.3.2-1_i386.deb libsvn0_1.3.2-1_i386.deb to pool/main/s/subversion/libsvn0_1.3.2-1_i386.deb python-subversion_1.3.2-1_i386.deb to pool/main/s/subversion/python-subversion_1.3.2-1_i386.deb subversion-tools_1.3.2-1_all.deb to pool/main/s/subversion/subversion-tools_1.3.2-1_all.deb subversion_1.3.2-1.diff.gz to pool/main/s/subversion/subversion_1.3.2-1.diff.gz subversion_1.3.2-1.dsc to pool/main/s/subversion/subversion_1.3.2-1.dsc subversion_1.3.2-1_i386.deb to pool/main/s/subversion/subversion_1.3.2-1_i386.deb subversion_1.3.2.orig.tar.gz to pool/main/s/subversion/subversion_1.3.2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: effectiveness of rsync and apt
* Goswin von Brederlow: Look at zsync and help develope it far enough so it can look into debs. Without that the gain is practicaly 0 or less. The other thing to do would be to lobby for dpkg-deb and dpkg-source to use 'gzip --rsyncable' when building stuff. (That, or sneak --rsyncable into $GZIP inside buildd and pbuilder environments everywhere.) [Florian Weimer] The downside is that anything that doesn't work on entire .debs is very likely to change them at the byte stream level (you only need to use slightly different zlib versions or parameters). Yeah, that's the weakness of the zsync idea. Fortunately for them, zlib uses a very mature algorithm so it doesn't change often. signature.asc Description: Digital signature
Re: Lintian package-has-a-duplicate-relation
[Andreas Metzler]
[EMAIL PROTECTED] wrote:
Is there a way to force a specific library version known in
${shlibs:Depends} ?
Why would you want to do that?
Don't know about the original poster, but here's my reason: I want to
reduce user confusion. Most of the interesting bits of subversion are
actually in libsvn0, but this is not obvious to users, so if their
subversion and libsvn0 packages are not the same version, they get the
wrong idea about what features and behaviors are available.
It's not strictly _necessary_ for subversion to Depends: libsvn0
(= ${Source-Version}), but I'd like to do it anyway to reduce instances
of non-bugs like #359215.
signature.asc
Description: Digital signature
Re: Debian Light Desktop - meta package
[Kevin Mark] What about: '100-300MHZ system desktop(XFCE)' Also, based upon the cpu/mem info, display: you machine has a 766MHZ processor with 128MB memory. [x]KDE desktop environment[500mhz or greater] [ ]GNOME desktop evirnoenne[500mhz or greater] [ ]XFCE desktop enviorneme[300mhz or greater] [ ]TWM desktop enviroemnet[100mhz or greater] Your implication that some absolute number of MHz means much about system performance is very i386-centric. May as well go back to using the bogomips value, at least the bogo- prefix is honest. (Now, amount of RAM is at least _somewhat_ comparable as a metric for what combination of apps will thrash the system and what might not. For a single-user, single-login machine. Doesn't particularly apply to, say, a terminal server.) signature.asc Description: Digital signature
Accepted subversion 1.3.1-2 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 9 Apr 2006 05:10:42 -0500 Source: subversion Binary: libsvn-core-perl libsvn0 libsvn-javahl libsvn-doc libsvn-ruby libapache2-svn libsvn-ruby1.8 python-subversion subversion-tools subversion libsvn0-dev Architecture: source all i386 Version: 1.3.1-2 Distribution: unstable Urgency: low Maintainer: Guilherme de S. Pastore [EMAIL PROTECTED] Changed-By: Peter Samuelson [EMAIL PROTECTED] Description: libapache2-svn - apache modules for Subversion (aka. svn) libsvn-core-perl - perl bindings for Subversion (aka. svn) libsvn-doc - development documentation for Subversion (aka. svn) libraries libsvn-javahl - java bindings for Subversion (aka. svn) libsvn-ruby - ruby modules for interfacing with Subversion (aka. svn) libsvn-ruby1.8 - ruby modules for interfacing with Subversion (aka. svn) libsvn0- shared libraries used by Subversion (aka. svn) libsvn0-dev - development files for Subversion (aka. svn) libraries python-subversion - python modules for interfacing with Subversion (aka. svn) subversion - advanced version control system (aka. svn) subversion-tools - assorted tools related to Subversion (aka. svn) Closes: 361488 Changes: subversion (1.3.1-2) unstable; urgency=low . [ Peter Samuelson ] * Fix libsvn-ruby1.8: actually ship the swig glue, which we had overlooked. Thanks to Thiago Avancini for the report and some Ruby help. * Exclude Java bindings on kfreebsd-amd64. (Closes: #361488) Files: 16afff9efe7c248a70763a0d4311fc1f 1375 devel optional subversion_1.3.1-2.dsc e001a6e971bb861b239a09abefc1c64b 44176 devel optional subversion_1.3.1-2.diff.gz 0cf2056af9cd9be7832f02e188072784 987044 doc extra libsvn-doc_1.3.1-2_all.deb 7fe168572bbfe525bed9d3719c3f4085 119216 admin extra subversion-tools_1.3.1-2_all.deb 94300a854d68c83cf32e2441dc589349 952 devel optional libsvn-ruby_1.3.1-2_all.deb c2787d77794f428b6c143f81cb1dbd53 941888 devel optional subversion_1.3.1-2_i386.deb 322c46d0506481c85b5c140d458944d5 543988 libs optional libsvn0_1.3.1-2_i386.deb 663345ec718d6b10c24cc360acd913e0 757814 libdevel extra libsvn0-dev_1.3.1-2_i386.deb 316e331997401bdb35705cec7fbbda2a 114238 net optional libapache2-svn_1.3.1-2_i386.deb 9f7a910a3c921d8bdb6f8c9267ddaa16 517472 python optional python-subversion_1.3.1-2_i386.deb 9cc15510d3a7c91bf30d62ebeb3e589d 191784 devel optional libsvn-javahl_1.3.1-2_i386.deb 2bba973ba3fde2acebf9c3ccca7b6b5d 735290 perl optional libsvn-core-perl_1.3.1-2_i386.deb 5012a66ac345cf97bc97c4b2bbcc6eab 344362 devel optional libsvn-ruby1.8_1.3.1-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEOOsVxa93SlhRC1oRAswoAKCzh017u9meynx3xlj7AxMWNr3MdgCghU3m Z3Cd1LmCWNOTLqddhRxkzy0= =ta+D -END PGP SIGNATURE- Accepted: libapache2-svn_1.3.1-2_i386.deb to pool/main/s/subversion/libapache2-svn_1.3.1-2_i386.deb libsvn-core-perl_1.3.1-2_i386.deb to pool/main/s/subversion/libsvn-core-perl_1.3.1-2_i386.deb libsvn-doc_1.3.1-2_all.deb to pool/main/s/subversion/libsvn-doc_1.3.1-2_all.deb libsvn-javahl_1.3.1-2_i386.deb to pool/main/s/subversion/libsvn-javahl_1.3.1-2_i386.deb libsvn-ruby1.8_1.3.1-2_i386.deb to pool/main/s/subversion/libsvn-ruby1.8_1.3.1-2_i386.deb libsvn-ruby_1.3.1-2_all.deb to pool/main/s/subversion/libsvn-ruby_1.3.1-2_all.deb libsvn0-dev_1.3.1-2_i386.deb to pool/main/s/subversion/libsvn0-dev_1.3.1-2_i386.deb libsvn0_1.3.1-2_i386.deb to pool/main/s/subversion/libsvn0_1.3.1-2_i386.deb python-subversion_1.3.1-2_i386.deb to pool/main/s/subversion/python-subversion_1.3.1-2_i386.deb subversion-tools_1.3.1-2_all.deb to pool/main/s/subversion/subversion-tools_1.3.1-2_all.deb subversion_1.3.1-2.diff.gz to pool/main/s/subversion/subversion_1.3.1-2.diff.gz subversion_1.3.1-2.dsc to pool/main/s/subversion/subversion_1.3.1-2.dsc subversion_1.3.1-2_i386.deb to pool/main/s/subversion/subversion_1.3.1-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#359662: libpcre3-dev doesn't install libpcre.pc, so pkg-config can't find libpcre
[Christian Ohm] Now what will someone do who doesn't know how to investigate a failed ./configure run? In my opinion this fits the description of 'important' (a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone), depending on the definition of 'major'. Just remember that every bug that hits *you* is important to *you*, and causes major usability effects for *you*. A good rule of thumb for filing bugs: think long and hard about what severity you think a bug warrants, then ignore your conclusion and leave it at normal. In this case, the only way this bug would be 'important' would be if most people only use libpcre3-dev for compiling someone else's software, rather than for writing and developing their own. If you're writing your own software that uses pcre, obviously you'll know better than to rely on pkg-config to find every last library in the world. Even if you know that pcre is supposed to support pkg-config, it won't faze you much when Debian's happens not to. signature.asc Description: Digital signature
Re: Atftp patch
[Michael Martinez] Debian packages atftp. You may wish to incorporate the following patch into the distribution: http://atftplocalnet.sourceforge.net/ Your patch looks interesting; the usual way to contact the maintainers of a specific package is to email [EMAIL PROTECTED] - I'm CC'ing them - or use our bug database, http://bugs.debian.org/. (That site lets you browse the database and includes instructions for submitting a bug via email.) Thanks, Peter signature.asc Description: Digital signature
Accepted subversion 1.3.0-5 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 28 Mar 2006 00:56:59 -0600 Source: subversion Binary: libsvn-core-perl libsvn0 libsvn-javahl libsvn-doc libsvn-ruby libapache2-svn libsvn-ruby1.8 python-subversion subversion-tools subversion libsvn0-dev Architecture: source all i386 Version: 1.3.0-5 Distribution: unstable Urgency: high Maintainer: Guilherme de S. Pastore [EMAIL PROTECTED] Changed-By: Peter Samuelson [EMAIL PROTECTED] Description: libapache2-svn - apache modules for Subversion (aka. svn) libsvn-core-perl - perl bindings for Subversion (aka. svn) libsvn-doc - development documentation for Subversion (aka. svn) libraries libsvn-javahl - java bindings for Subversion (aka. svn) libsvn-ruby - ruby modules for interfacing with Subversion (aka. svn) libsvn-ruby1.8 - ruby modules for interfacing with Subversion (aka. svn) libsvn0- shared libraries used by Subversion (aka. svn) libsvn0-dev - development files for Subversion (aka. svn) libraries python-subversion - python modules for interfacing with Subversion (aka. svn) subversion - advanced version control system (aka. svn) subversion-tools - assorted tools related to Subversion (aka. svn) Closes: 359234 Changes: subversion (1.3.0-5) unstable; urgency=high . * rpath.patch: Delete rpaths for apache2 modules. (Closes: #359234) - rules: Do not override INSTALL_MOD_SHARED, this is no longer needed - libapache2-svn.install: Use modules from the install, not from the build tree Files: 225c0d5097fba4856d13701d602025bc 1325 devel optional subversion_1.3.0-5.dsc 0a825d740f9efe55fff437f504e7217a 42723 devel optional subversion_1.3.0-5.diff.gz 796c071c595fabb6c5cd64a95fcea146 1034956 doc extra libsvn-doc_1.3.0-5_all.deb 8bd8f46630b714690cca777e4d31c96a 121148 admin extra subversion-tools_1.3.0-5_all.deb 3f9ed7a8459ed23a678e5610c1008651 958 devel optional libsvn-ruby_1.3.0-5_all.deb 64f92a9fc4acc89cb238fcf8bb9c891d 940780 devel optional subversion_1.3.0-5_i386.deb 01907df1a5f2883af6b4288cfb1514dd 542180 libs optional libsvn0_1.3.0-5_i386.deb 5c929e58bf61564f9fb5606bbe116790 756556 libdevel extra libsvn0-dev_1.3.0-5_i386.deb 68d719f4af7f89ed33adef317ba56bac 113676 net optional libapache2-svn_1.3.0-5_i386.deb ad8df6d620c725ba32e71aa020a3b423 521954 python optional python-subversion_1.3.0-5_i386.deb c6316a6de6c832935aad2e4ed58d3d42 190706 devel optional libsvn-javahl_1.3.0-5_i386.deb 622b7a16321a601142542179a67944c4 733960 perl optional libsvn-core-perl_1.3.0-5_i386.deb 867e3b5feb7933ebbd2cc84953a663f9 325720 devel optional libsvn-ruby1.8_1.3.0-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEKQngDecnbV4Fd/IRAqUGAKD58sMyiqALyxwkLhxPb1u2KtI4TgCgqaMq 0iLC8+gBe7hVMe1Zd3zFi1I= =Sd1J -END PGP SIGNATURE- Accepted: libapache2-svn_1.3.0-5_i386.deb to pool/main/s/subversion/libapache2-svn_1.3.0-5_i386.deb libsvn-core-perl_1.3.0-5_i386.deb to pool/main/s/subversion/libsvn-core-perl_1.3.0-5_i386.deb libsvn-doc_1.3.0-5_all.deb to pool/main/s/subversion/libsvn-doc_1.3.0-5_all.deb libsvn-javahl_1.3.0-5_i386.deb to pool/main/s/subversion/libsvn-javahl_1.3.0-5_i386.deb libsvn-ruby1.8_1.3.0-5_i386.deb to pool/main/s/subversion/libsvn-ruby1.8_1.3.0-5_i386.deb libsvn-ruby_1.3.0-5_all.deb to pool/main/s/subversion/libsvn-ruby_1.3.0-5_all.deb libsvn0-dev_1.3.0-5_i386.deb to pool/main/s/subversion/libsvn0-dev_1.3.0-5_i386.deb libsvn0_1.3.0-5_i386.deb to pool/main/s/subversion/libsvn0_1.3.0-5_i386.deb python-subversion_1.3.0-5_i386.deb to pool/main/s/subversion/python-subversion_1.3.0-5_i386.deb subversion-tools_1.3.0-5_all.deb to pool/main/s/subversion/subversion-tools_1.3.0-5_all.deb subversion_1.3.0-5.diff.gz to pool/main/s/subversion/subversion_1.3.0-5.diff.gz subversion_1.3.0-5.dsc to pool/main/s/subversion/subversion_1.3.0-5.dsc subversion_1.3.0-5_i386.deb to pool/main/s/subversion/subversion_1.3.0-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#358003: ITP: ttf-dzongkha -- TrueType fonts for Dzongkha language
On Tue, Mar 21, 2006 at 07:08:02AM +0100, Christian Perrier wrote: Well, I have one very little argument against doing so: why do it for Dzongkha and why not do it for, say, French...:-) [Lionel Elie Mamane] Because French is the adjective in English (the language the package description is written in) for from France. The same, I would not expect it to be done if the language were called Bhutanese. OTOH, if you have no idea what language or what country the font pertains to, why would you want that font? I think a good default assumption when reading package descriptions is If you don't have any idea what this is, you don't need it. Package descriptions should be written so that people who would want the package will understand them; for the rest of the world, it's nice to have some idea what the package is, but it's much less important. In the present case, communicating that this is a font for some specific language (which a person may never have heard of) seems sufficient. signature.asc Description: Digital signature
Re: shared libraries dependecy problem.
[Grzegorz Bizon] Linda complains that: W: tleenx2; A binary links against a library that is not depended on. (By the way - shoudn't it be error rather than warning ?) No, because it's sometimes hard to fix and often harmless. We don't like it but error is too strong. I have checked binary with objdump and ldd and i got ... simillar but not the same results. As others have already explained, ldd resolves recursive dependencies, so it will usually give more output than 'objdump -p $f | grep NEEDED'. The point is that you probably don't need to link to, e.g., -lX11, unless you directly use functions like XOpenDisplay or XBeep. Typically if you are using GTK, you won't be using any of those low-level functions. signature.asc Description: Digital signature
Re: Adding dependencies to e2fsprogs: libdevmapperr, libselinux and libsepoll
[Steve Langasek] You could also do, e.g.: Build-Depends: [...] libselinux1-dev [alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc linux-any] Build-Depends: [...] libselinux1-dev [!hurd-i386 !kfreebsd-i386] When other non-linux ports run into a FTBFS, you add them. Since the list is short, the [linux-any] may not be all that much simpler. Note that this syntax only works in source dependency fields (Build-*), not with the runtime fields (Depends, Conflicts, etc). signature.asc Description: Digital signature
but ./configure makes it look so easy, or why cross compiling isn't always trivial
[Peter Kourzanov] For most of the packages, what is so different in cross-compilation in comparison to native? Whether or not 'configure' believes it can use tests of the form try compiling and running this little program to see what it does. If it is cross-compiling, it is forced to skip such tests and use predetermined default answers. Note that this can produce nefarious little bugs, if the defaults aren't correct for your target architecture. Note also that not all configure scripts are given these default answers - if they aren't, you get a warning from autoconf about not supporting cross compilation, and I *believe* --host fails entirely. There are also many packages which build _and run_ utilities as part of the build process. Three of my packages do this, though in two cases it's Debian-specific, so could be edited without much difficulty. Most packages do not distinguish between compiler-for-the-host-system and compiler-for-the-target-system (what the Linux kernel makefiles call HOSTCC and CC). So those will require significant hacking in upstream configure scripts and makefile to teach them to detect, and use, two separate compilers. Also, debian/rules must make sure not to run any testsuites when cross- compiling. This is generally not hard, but it *is* an extra thing to have to fix. Yes. There are... 25411 Debian packages according to my 'apt-cache stats' and what I would like is to just issue a 'dpkg-buildpackage -aHOST ' on every single one of them and get a .deb file(s) that could be then immediately installed on a HOST machine. Of the six or so packages I'm involved with, three of them need more than just '--host'. (And two of the others are arch:all, so there's no need to cross-compile them anyway.) If that's representative, you're looking at a *lot* of work by a *lot* of people to realise your dream. Well, that or a *lot* of work by you, to write and submit patches for all these packages. signature.asc Description: Digital signature
Re: Adding dependencies to e2fsprogs: libdevmapperr, libselinux and libsepoll
[Michael Banck] Please take into consideration that libselinux is not available on Debian's non-Linux ports. It's not libselinux you should be worried about, but libdevmapper. He's not depending on libselinux directly, but he notes that on Linux systems, the dependency chain will pull it in. signature.asc Description: Digital signature
