Re: Can we kill net-tools, please?
[Russ Allbery] > ip address also has one of the worst output UI decisions I've ever seen, > namely this line: > > inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic wlan0 > > specifically "192.168.0.195/24", which is notation (IIRC) invented by this > command, used nowhere else in networking, and confusing to anyone who has > prior networking experience. Huh ... I have exactly the opposite reaction. To me, this notation is _far_ more readable than dotted quads, e.g., I know exactly what a /27 is, but it takes awhile to work out 255.255.255.224. I don't think this notation originated in iproute2, I've seen it in lots of other contexts. (Yes, it's a bit annoying to parse this, as you have to split on / after splitting on whitespace, but to me that's a small price to pay.) In fact in my interfaces(5) files I always use 'address a.b.c.d/nn' and no 'subnet' line. So tidy. (ifupdown added this feature in wheezy.)
Re: Does anybody plan to keep using sbuild with Squeeze or older chroots?
[Johannes Schauer] > Old sbuild will not help you. The problem is mainly, that older > chroots contain an apt installation that has no support for the > [trusted=yes] option in sources.list. So if someone really needs this, I guess a workaround would be to backport apt 1.0 to squeeze...? Yes, it would pollute the chroot for rdepends of libapt, but those don't seem like the sorts of packages most people would be building or rebuilding for squeeze. (I could be wrong.)
Re: ppp plugins and dependencies
[Chris Boot] There probably doesn't need to be an ABI break for every version, but there is with 2.4.6 = 2.4.7 due to the addition of some variables. If this was a shared library it wouldn't necessitate a soname bump as it's essentially just a new symbol, but a plugin that happens to use this new symbol would break badly on an older pppd. So in the present case, you could say Provides: ppp-plugin-api (= 2.4.6), ppp-plugin-api (= 2.4.7) and perhaps many or even most future cases could do likewise - indicating that a bunch of rebuilds / upgrades is not really needed. Of course you'd also want to relax the runtime version check to match, and make sure the plugin dir doesn't change (or that you check multiple plugin dirs). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150630153940.ga3...@p12n.org
Re: aptitude has Priority: standard, why?
[The Wanderer] it is IMO not viable for actual use - except perhaps by people who already know completely what they are doing and how to override aptitude's suggestions. That sounds like you believe aptitude has only a command-line interface. Mostly I use its full-screen interface. (To see this interface, launch it with no arguments.) What would you suggest as a replacement for that? dselect? I did use dselect for many years, only reluctantly switching to aptitude, but I have no desire to go back. Does aptitude include an equivalently functional analog for apt-cache? Well, the things I use most - the 'show' and 'search' functions - are certainly in aptitude, but apt-cache has a dozen other subcommands and I don't know whether aptitude implements those in some way. I'd been told that apt-get was deprecated in favor of aptitude and I'd seen that aptitude did not seem to have equivalents for the apt-cache commands. Deprecating /usr/bin/apt-get is not the same as deprecating the whole apt package, including /usr/bin/apt-cache. If anyone said the entire apt package was deprecated, I think they were misinformed. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150401160242.ga4...@p12n.org
Re: Let's abandon debian-devel.
[Andrey Rahmatullin] Not all Debian contributors are Debian Contributors whatever that means. Lots of people without keys somewhere in official keyrings are doing useful work. Some of them are even maintaining packages. And actually, come January, a pretty high fraction of official Debian Developers won't be in the keyring either. (Though not necessarily a high fraction measured in developer activity.) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141114180157.ga26...@p12n.org
Re: veto?
[Daniel Pocock] Would it be worthwhile giving people another option, for example, allowing a percentage of DDs to formally veto decisions? Would this be better than people leaving outright? That sounds like a pretty good description of either a GR, or the Technical Committee. We have both of those things, and they both work, though not everybody is happy with them. Do you mean, perhaps, that the Further Discussion option in a GR should be weighted much more heavily than other options, so that it can beat another option if only a few people rank it higher? I am not in favor of that. Or perhaps you mean there should be an official platform where someone can say, effectively, Before deciding to do X, you should take into account that I, someone directly involved in its implementation, will not help because I'm not convinced X is a good idea. Also, this may demotivate me from related work Y and Z. But, well, anybody can already say that. Anyway... I don't really see people leaving because of a decision they disagree with. What I do see is people leaving for social reasons, either changes in their own lives, or perceived social changes in the Project. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141114232146.gb26...@p12n.org
Re: More tasks option in Tasksel: what tasks do you want there? (reloaded)
On Mon, Sep 8, 2014 at 11:15 PM, Thomas Goirand wrote: - database-server: commonly one would expect MySQL, and postgress gets installed [Paul Wise] Isn't tasksel for people with no expectations? People who know something about the technology they are looking for will install the relevant packages instead of following tasksel recommendations. Yeah but in what possible world would anybody want a database server but not care which DBMS it is? I mean, on the basic level of MySQL vs. Postgres, not which fork of mysql is cool this week. I just can't fathom the use case for this particular task. Yes, there are cases where you need a DBMS but you don't have an opinion, but I suspect in that case what you need the DBMS for is some other package, which then Depends: or Recommends: on a suitable DB engine. Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140908230757.ga3...@p12n.org
Re: Non-source Javascript files in upstream source
[Manuel A. Fernandez Montecelo] If you agree that source-is-missing also applies in those cases, do you also think that we should immediately declare all source packages in Debian containing a 'configure' script as somehow non free (unless we can check unambigously that they were generated by the .ac) There's 2 reasons to care if configure was built from the configure.ac in the tarball. The immediately practical reason is to ensure that if we or our users need to patch it, we can patch the actual source, and still be able to build correctly. (These things do tend to bitrot if you don't watch them.) Basically that means always rebuilding from source - which is already a best practice in Debian. Not every package does it, but IMO every package _should_. The other reason to care is of course to comply with our free software guidelines. For that purpose, I think it's entirely reasonable to assume good faith in upstream. If we find out that some upstream intentionally tricks us by shipping a mismatching configure, just so they can point and laugh at the DFSG violation, the solution is very simple: remove the package from Debian, because such upstreams clearly can't be trusted not to trick us in more malicious ways. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140426232014.gd4...@p12n.org
Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition
[Paul Tagliamonte] I was going to send a mail about this yesterday. I've decided I'm going to start a quest to support this. I settled on Build-Indep-Architecture myself. Sorry for the bikeshedding, but don't we already have ways to express exactly what we mean? Build-Depends-Indep: some-pkg-only-avail-on-i386-and-amd64 ...that being I guess the common case where you need to build arch:all on a specific architecture: because of availability of build tools. And if there are any cases even more exotic (you need to restrict the arch but _not_ because of build-dep availability): Build-Conflicts-Indep: build-essential [!i386] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140226151520.gb4...@p12n.org
Re: Backports, Stable releases, Testing, Oh my!
[micah] it feels like a bit too aggressive pressure for my tastes. I've seen a lot of developers of packages who have found out their package will be removed from testing, but don't have the time to resolve the situation before it gets removed, resulting in much pulling of hair. If only we had some kind of a setup where, a few days after you upload a fixed version of something, it could reenter testing. Then maybe all that hair trauma wouldn't be needed. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140226173610.gc4...@p12n.org
Re: Ubuntu will switch to systemd
[Christoph Anton Mitterer] btw: And quite obviously, this post is not about bashing upstart,.. No, and it's also not about Debian. Could we ... do our Canonical bashing somewhere else? Please? Thanks. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140214221907.ga4...@p12n.org
Re: Replacing a binary package by another one(was: Communication issue?)
[Norbert Preining] On Di, 03 Sep 2013, Peter Samuelson wrote: texlive-lang-european? It doesn't look like it to me (no Breaks or Conflicts), but I haven't actually tried it. conflicts there are, texlive-base conflicts with all the old packages. I misspoke. There is a Conflicts in texlive-base, but what is probably needed is Provides in texlive-lang-european. As I understand it, that will prompt apt to DTRT on upgrade. Since nobody is worried about versioned dependencies here, I think that would suffice. No need for 30 transitional packages. But I haven't tested it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130904175546.ge6...@p12n.org
Re: Looking for ideas for merging a micro package...
[Thorsten Glaser] I absolutely do not want to see anything related to ruby on my systems. Why? Is this just an emotional reaction, or is it the 13 MB of dependencies, or something else? I wonder if anyone feels the same way about, say, libraries written in FORTRAN, or binaries linked against libX11. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130904180235.gf6...@p12n.org
Re: Replacing a binary package by another one(was: Communication issue?)
[Norbert Preining] I understood your proposal, of course. Still, since there are no rdepends besides very few (1?) build-depends on these two packages, I consider it a a waste of resources. Sounds like you are saying 'texlive-lang-danish' is only useful as a package dependency - in other words, users would never install it explicitly because they want its functionality. Is that correct? This is not clear from the package description, which at least to me looks like something users _would_ install explicitly: Description-en: TeX Live: Danish Support for typesetting Danish. . This package includes the following CTAN packages: hyphen-danish -- Danish hyphenation patterns. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130903234245.gc6...@p12n.org
Re: Replacing a binary package by another one(was: Communication issue?)
Sounds like you are saying 'texlive-lang-danish' is only useful as a package dependency - in other words, users would never install it explicitly because they want its functionality. Is that correct? This [Norbert Preining] I never said that. The functionality is now in texlive-lang-european I can see that. But your argument for removing texlive-lang-danish etc. is basically there are almost no rdeps. But that is only half the story. The other half is to explain what will happen to users who installed texlive-lang-danish because they want Danish language hyphenation support. When they upgrade, will they get texlive-lang-european? It doesn't look like it to me (no Breaks or Conflicts), but I haven't actually tried it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130904014326.gd6...@p12n.org
Re: overriding udev rules
[Thomas Goirand] Oh ok. Not useful at all if you ask me. Why? Because sometimes, you can't change the MAC address. For example, if you use the OpenStack bare metal driver, then you continue to use virtual machine images, though they will be used on a real hardware where you can't change the MAC address. So you're saying, when your NIC is tied to actual physical hardware, udev behaves as though it is tied to actual physical hardware. Seriously, the reason for udev to not make a VM NIC persistent is not because it is virtual, per se, but because certain virtualization platforms may randomly generate a MAC at boot time. Which is not at all the case in the example you give. I think the problem you're trying to solve is more related to imaging and cloning. The fact that you're doing imaging and cloning in the context of virtual machines instead of physical is a bit of a red herring. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130822011215.gb6...@p12n.org
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
On Wed, 2013-07-31 at 01:30 +0100, Steve Langasek wrote: That's correct. If you want to talk to a loopback-only service, you should be connecting to 'localhost', *not* to the hostname. [Christoph Anton Mitterer] Well why not? Imagine that one server in a cluster serves a debian package repo (e.g. via http)... That doesn't sound like a loopback-only service at all. - let the webserver listen as well on 127.0.1.1,... sure that works but it's rather ugly to make such special handling... and not all services are even able to bind to multiple addresses. Special handling? No, I'm pretty sure the default for all web servers in Debian is to listen on INADDR_ANY. That's not special handling at all. Special handling would be to listen on 11.22.33.44 and 127.0.0.1 specifically. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130731214229.ga6...@p12n.org
Re: download of source packages alarmed clamav
On Tue, Jun 25, 2013 at 08:04:00AM -0400, Scott Kitterman wrote: This comes up periodically. They aren't real. [Darac Marjal] It would appear they're real enough to trigger clamav's detection, which was the problem the OP was having. Yes. It is not really a fixable problem. The test files intentionally contain material whose purpose is to trigger a virus scanner. That is their entire point. The fact that they do in fact trigger a virus scanner is unfortunate in this case, but it is a straightforward consequence and there probably isn't much you can do about it (except of course to not use a virus scanner while downloading virus scanning test data). The EICAR string is all very well, but doesn't solve this problem. Either virus scanners treat EICAR just like any real virus, alerting and/or blocking stuff, or they treat it as a special case. If the formert, you haven't solved anything. If the latter, then by the nature of it being a special case, EICAR alone is not sufficient test coverage for virus scanning functionality. Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130625181639.gd13...@p12n.org
Re: epoch fix?
[Alberto Garcia] I was unaware of this thing and I'm sure I'm overlooking something, so can someone give a simple example of actual problems introduced by using epochs? One real problem is that epochs make it easier to introduce human error in specifying reverse runtime and build deps. E.g.: # in stable Package: libfoo-dev Version: 1:1.4.1-1 # in unstable Package: libfoo-dev Version: 1:1.5.5-2 # in unstable Package: bar Build-Depends: libfoo-dev (= 1.5) The 'bar' maintainer intended to require the unstable version of libfoo-dev, but in fact the dependency is satisfied from stable as well. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508103011.gc13...@p12n.org
Re: epoch fix?
[Matt Zagrabelny] I've grepped the d-d list, but didn't find any threads regarding fixing epochs in package versions. This does come up occasionally. If so, could we add a field to debian/control such as Supersede-Epoch. If set to 'yes', then dpkg considers this package to have an epoch of infinity for version comparisons. My preferred variant is to treat epoch 99 as greater than any other 2-digit number, but less than 0. (0: is implied if you don't specify an epoch.) But either way, the problem is that .dsc and .deb version numbers are not used only by dpkg. Lots of tools use them, inside and outside of Debian packages, inside and outside of Debian infrastructure. We cannot be sure that they all use dpkg's own interfaces to do so (e.g. dpkg --compare-versions, perl -MDpkg::Version). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013050725.ga13...@p12n.org
Re: /export (was Re: jessie release goals)
[Igor Pashev] Currently /var/lib contains data for system utilities (dpkg, apt, aptitute) and for user application like databases. What about moving default location for applications to /export ? Wrong list, please bring this up instead on fhs-discuss. (If that still exists - it looks a bit stale - but anyway, debian-devel is not for FHS discussion.) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130507222521.gb13...@p12n.org
Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
[James Cloos] And where does one find dh_make? Searching on goog suggests it would be part of debhelper. But it isn't: Someone suggested 'apt-file', but in this case the simpler thing is: apt-cache search dh_make -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130427010928.gc4...@p12n.org
Re: jpeg8 vs jpeg-turbo
[Mathieu Malaterre] I do not believe in debian life-span, a package manager ever switch an implementation of a package. So libjpeg9 and libjpeg-turbo will have to co-live. It happens. Look at the source for 'libc6'. It used to be glibc, these days it is a fork called eglibc. Likewise the source for the 'ssh' package was once SSH by Tatu Ylonen, these days it is a fork called OpenSSH maintained by some OpenBSD hackers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130425152859.ga4...@p12n.org
Re: bits from the DPL: March-April 2013
Zack, Thank you SO MUCH for your service this past 3 years. Your hard work, persistence, calm voice and especially your transparency have been much appreciated. Peter signature.asc Description: Digital signature
Re: Debian two-factor auth, GSoC?
[Russ Allbery] Oh, I thought they'd given up on Safe. For some reason it stuck in my mind that it had too many issues and ended up being deprecated. Apparently, I either made that up or misremembered something. Possibly you were thinking of suidperl, the hack to allow Perl programs to use setuid and setgid, working around the fact that most Unix kernels don't honor the setuid + setgid bits when launching #! scripts. suidperl was dropped some years ago because it had too many issues. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130412223838.gy4...@p12n.org
Re: Legal possibility of more open package reviews.
[Charles Plessy] - If mentors.debian.org needs to follow the DMCA, why would mentors.debian.net be exempt of it ? It's not exempt, but it's also not Debian's problem. - If mentors.debian.org can distribute unreviewed packages by becomming a DMCA safe harbor, wouldn't it be possible for ftp-master.debian.org/NEW.html ? The difference is that one is open to the public and the other is not. If a service is open to the public without any control over who can post content, then basically you have grounds to claim you do not and cannot reasonably police the content. - Bonus question: since mentors.debian.net seems to be hosted in Germany, does it mean that developers living in the US should refrain from uploading crypto to it ? How do other distributions solve that problem ? Correct, it means developers living in the US need to follow US laws. I suspect other distributions solve the problem by ignoring it, thus leaving individuals responsible for obeying their local laws. Which is a fine principle, but in practice it probably means some individuals violate US law without really noticing. (The US government harrassment of Phil Zimmermann was a long time ago, so I suspect that object lesson has been mostly lost.) Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130410170916.gx4...@p12n.org
Accepted subversion 1.7.9-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 06 Apr 2013 16:16:37 -0500 Source: subversion Binary: subversion libsvn1 libsvn-dev libsvn-doc libapache2-svn python-subversion subversion-tools libsvn-java libsvn-perl ruby-svn libsvn-ruby1.8 libsvn-ruby Architecture: source all amd64 Version: 1.7.9-1 Distribution: unstable Urgency: medium Maintainer: Peter Samuelson pe...@p12n.org Changed-By: Peter Samuelson pe...@p12n.org Description: libapache2-svn - Apache Subversion server modules for Apache httpd libsvn-dev - Development files for Apache Subversion libraries libsvn-doc - Developer documentation for libsvn libsvn-java - Java bindings for Apache Subversion libsvn-perl - Perl bindings for Apache Subversion libsvn-ruby - Ruby bindings for Apache Subversion (dummy package) libsvn-ruby1.8 - Ruby bindings for Apache Subversion (dummy package) libsvn1- Shared libraries used by Apache Subversion python-subversion - Python bindings for Apache Subversion ruby-svn - Ruby bindings for Apache Subversion subversion - Advanced version control system subversion-tools - Assorted tools related to Apache Subversion Closes: 672157 Changes: subversion (1.7.9-1) unstable; urgency=medium . * New upstream version. Some DOS fixes in mod_dav_svn: - CVE-2013-1845: mod_dav_svn excessive memory usage from property changes - CVE-2013-1846: mod_dav_svn crashes on LOCK requests against activity URLs - CVE-2013-1847: mod_dav_svn crashes on LOCK requests against non-existant URLs - CVE-2013-1849: mod_dav_svn crashes on PROPFIND requests against activity URLs - CVE-2013-1884: mod_dav_svn crashes on out of range limit in log REPORT request * patches/python-swig205, patches/g++47: Remove as obsolete. * Don't make python-subversion 'Depends: subversion'. It is quite usable on its own. * Move libsvn1 to section 'libs'. (Ref: #700145) * Update watch file. (Closes: #672157) Checksums-Sha1: 157f1fbd0fda5ac15b0b833e4070648cd4374a03 2243 subversion_1.7.9-1.dsc 1f0e23ea585accba98f0ca3bf9354343314caceb 8225037 subversion_1.7.9.orig.tar.gz 570fcf3d36d4488ba511571bbab733778404c440 230235 subversion_1.7.9-1.diff.gz d42f6042b57ef590d67d096bb923ba6833f89224 2571976 libsvn-doc_1.7.9-1_all.deb a39908c2e4e97149d252358fbc285ca6b6f357e1 284860 subversion-tools_1.7.9-1_all.deb d1174fc3ab6b2cb2f15efd220c119e1e9f4b06bb 800 libsvn-ruby1.8_1.7.9-1_all.deb c8fc0412d50b124e3dd02e0fb4e71246e7f279b1 798 libsvn-ruby_1.7.9-1_all.deb 9357f5c9e0b2780e1d087458e7f51cb124917c26 1300118 subversion_1.7.9-1_amd64.deb 6176f3c38252829723847f629c454b289267f8f6 1200126 libsvn1_1.7.9-1_amd64.deb a5f1211aafabfaab4e8bf0bb5d2a9cae562cfde0 1679782 libsvn-dev_1.7.9-1_amd64.deb d5440bddf21e5d7335d01c9a798bddcdff760fe7 190194 libapache2-svn_1.7.9-1_amd64.deb a4a53f1e2ab713cef17f0abfe5fd27bc6ab822ad 1579124 python-subversion_1.7.9-1_amd64.deb f7e18af88dc512f6dc3fd4e77c42a89641b31d14 362602 libsvn-java_1.7.9-1_amd64.deb 6d53b5070d2862b9ecf5deb85954c68aaffebfe4 1286508 libsvn-perl_1.7.9-1_amd64.deb 58bf7226ee8cd1c7e8892c3f34d687f04a9dee75 729372 ruby-svn_1.7.9-1_amd64.deb Checksums-Sha256: 78147dd683c9ac61c467d4545a14fcc99b905230093d0495adf52e88aa608773 2243 subversion_1.7.9-1.dsc d35430ba11ea050aa7a066773e60e0688989646fdb79f09664a0a70d28b85959 8225037 subversion_1.7.9.orig.tar.gz 246f4fac223d100cb6915f60cedee18228575acbdf54451a3541558c438650f1 230235 subversion_1.7.9-1.diff.gz dc3f8f52d0be7ee3b35dc60941290dbedd62578510dc28e89da6aa99c10e5349 2571976 libsvn-doc_1.7.9-1_all.deb 525161612faf509d26bf23aea923bd87f7ccc3828a05ad861c0018b0d744c668 284860 subversion-tools_1.7.9-1_all.deb 0411e5892dabca1b518344e67d2982c6786bfd719442ace611d74d717135fdb7 800 libsvn-ruby1.8_1.7.9-1_all.deb 23203f4d4b3112200dc99ded57790a5647ae2879f99b9b4d15e0b018a6e49fe7 798 libsvn-ruby_1.7.9-1_all.deb 11e8a350b48f87f3d6e7534c950a85d8941a0b3dbfd63eb4ffc8765236595508 1300118 subversion_1.7.9-1_amd64.deb 79b8b4ebe53f90d27810a01d9b1014e79a24834b8b87920291049b391bd2c478 1200126 libsvn1_1.7.9-1_amd64.deb 817072e357824ed229a7a4ca4ed519c818643346bcedddf6e2de111ffd5b44ca 1679782 libsvn-dev_1.7.9-1_amd64.deb ec7da839e6062c0b78dfb67940f3ff1054eac36b9679d0e756d8021da09558f3 190194 libapache2-svn_1.7.9-1_amd64.deb 61907fa6deee70c80c5c91b1cccb35c1baaaf4ce86db0b295f00b682fa0519bf 1579124 python-subversion_1.7.9-1_amd64.deb 6612811a34712758c1debd982f32d6afcdc2b6de14f0f54f09fb5b81c0ddff93 362602 libsvn-java_1.7.9-1_amd64.deb 27a55e4ed1873cab158c4cee7ca8349f3f6e43bd2905642260850426f78db0de 1286508 libsvn-perl_1.7.9-1_amd64.deb d23d3990ded1bdc24ef200f21edfff658780c55d28f8d6d101febc66aee080a3 729372 ruby-svn_1.7.9-1_amd64.deb Files: e1947831f2848597dbf84973db2c4519 2243 vcs optional subversion_1.7.9-1.dsc dfb083e8bfac88aa28d606168b08e4ff 8225037 vcs optional subversion_1.7.9.orig.tar.gz 9a6129bdb4a9b2ddf6a990b03b51563b 230235 vcs optional subversion_1.7.9-1.diff.gz
Re: Generators for debian/* files?
+++ Jonathan Dowland [2013-04-05 10:09 +0100]: On Fri, Apr 05, 2013 at 11:07:31AM +0200, Thomas Koch wrote: This java code should be replaces with something in perl/python/non-JVM. Why? [Wookey] Because it's an entirely unnecessary circular build-dependency. java is not part of build-essential and this doesn't seem like a good reason for making it so. This sounds like a packaging tool, not a build tool. (At least, I _hope_ nobody is thinking of generating debian/rules during the build process!) I'd say anyone packaging Java stuff probably has a JVM. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130406183437.gw4...@p12n.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
[Jonathan Dowland] On Mon, Apr 01, 2013 at 04:45:19PM +0100, Neil McGovern wrote: You seem to believe that unstable is more important than stable releases. I do not. One of us is in the wrong project. If, you are suggesting here, that the release process in Debian is utterly set in stone and nobody may raise objections about it or try to work to address the problems that people have with it ECHAN? Did you quote the wrong text, or reply to the wrong message or even the wrong sender? Because your paraphrase seems to have nothing to do with the text you quoted. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402183124.gu4...@p12n.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
[Vincent Lefevre] I disagree. If the freeze occurred only once (almost) all RC bugs were fixed, there would be (almost) no delay. I suspect that the length of the freeze is due to the fact that the freeze occurred while too many RC bugs were already open. Agreed: in July 2012, many - too many - RC bugs were already open. So when, in your estimation, would have been a better time to freeze? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402183759.gv4...@p12n.org
Re: realise diff-updates with dpkg
Anyway, rsync sounds like the most appropriate mechanism to transfer these particular databases. [iceWave IT] My blacklists should be available for everyone not only for those who can connect with my server via ssh... rsync doesn't require ssh; for your scenario you probably just want 'rsync --daemon' from inetd. And yes, this is very much a job for rsync. Or go with zsync, if you want to use http as a transport. Don't try to emulate rsync with dpkg, it will not go well. dpkg doesn't add anything you can't get with a little scripting (and producing your incremental debs definitely requires some scripting too). (If reloading a full dataset into your database is _that_ expensive, what you want to do is 'ln'-backup the old file, rsync the new, 'diff' them, and use the diff output to generate a database import script.) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130222193824.gt4...@p12n.org
Re: RFC declarative built-using field generation
[Joachim Breitner]
this seems to be a good disk-space for human-time trade to me as well:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699333
I'm a bit confused. Given that perhaps 99% of Built-Using would be for
trivial things like crt1.o and libgcc.a, which are concentrated into a
relatively tiny number of packages, it seems to make more sense to
annotate those packages - not unlike our shlibs files.
Of course, since many files like crt1.o and libgcc.a are covered under
Build-Essential, it may not be obvious to a tool which packages were
actually needed by the build - most packages don't need to
Build-Depends: libc6-dev or gcc. But at least for the libc6 case, it's
fairly obvious that anything that pulls in a Depends: libc6 via
shlibs should also generate a Built-Using: libc6-dev
({current-version}) due to use of one or more of those object files.
I have no idea if there are similar heuristics for use of static
libgcc.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130208234539.gs4...@p12n.org
Re: No native packages?
[Benjamin Drung] Image the opposite. You want to package a software that is only available in a downstream distribution (e.g. Ubuntu or Linux Mint). Do you prefer to have a non-native format or a native format? If their native format is an archive in gzipped tar file format, like ours is, I'm not sure I would care, if I even _notice_, that there is packaging metadata for some other operating system in there. In fact it's not at all uncommon for upstream projects to ship .spec files, .vcproj files, and other platform-specific build infrastructure. Maybe you're thinking of the inconvenience of the top-level 'debian' directory, which is rather inflexible in that all Debian distributions and derivatives use the same path for their own use, but that ceased to be a problem several dpkg releases ago. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130129045301.gr4...@p12n.org
Re: Packages with incomplete .md5sum files
[Holger Levsen] Hi Andreas, On Donnerstag, 10. Januar 2013, Andreas Beckmann wrote: Hi, the following packages from wheezy ship files that are excluded from the .md5sums file: gridsite: FILE WITHOUT MD5SUM /var/lib/gridsite/.gacl gridsite: FILE WITHOUT MD5SUM /var/lib/gridsite/gridsitefoot.txt gridsite: FILE WITHOUT MD5SUM /var/lib/gridsite/gridsitehead.txt [...] those I'd file with severity important - sure it's a policy violation, surely it's bad, Policy violation? Where? I don't see anything about 'md5sums' in Policy. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130115092337.gq4...@p12n.org
Re: Package variant selection policy using meta packages
[Joachim Breitner] And a foo-dev Recommends: foo-prof is not suitable because? because we cannot tell what the user will want. For example, a user of xmonad will not want -prof packages installed, and an addition 400MB of useless stuff on his computer is not in his, and hence our, interest. So, it appears xmonad is a window manager. It seems a fair question why someone who runs a window manager needs -dev packages at all, let alone -prof packages. According to the package description, you only need the -dev package if you actually plan to configure the window manager instead of using its defaults. Which presumably most people do, so I guess the Recommends makes sense. Excpet for the part where this requires one or more -dev packages at all. It looks as though configuring xmonad involves _recompiling_ it. What is this, an old school Unix kernel? I'm confused. Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121222185144.gp4...@p12n.org
Re: unsafe use of gpg
[Timo Juhani Lindfors] Peter Samuelson pe...@p12n.org writes: Note that this adds a keyring to the current list. If the intent is to use the specified keyring alone, use --keyring along with --no-default-keyring. You probably read man gpg but gpgv is simpler: gpgv: Invalid option --no-default-keyring You're right, in gpgv, it appears you _can't_ suppress the default keyring, ~/.gnupg/trustedkeys.gpg. So either ensure that this file does not exist, or set HOME or GNUPGHOME or --homedir to a location where it will not exist. Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121215161254.go4...@p12n.org
Re: unsafe use of gpg
[Timo Juhani Lindfors] Is /usr/bin/gpgv --quiet --keyring /etc/myprogram/trusted.gpg file file.sig chmod a+x file ./file still a safe way to ensure that only code signed by a key in trusted.gpg gets executed? From the manpage: Note that this adds a keyring to the current list. If the intent is to use the specified keyring alone, use --keyring along with --no-default-keyring. Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121214225649.gn4...@p12n.org
Architecture: all + M-A: foreign
In bug #695229, I noted that an Architecture: all package really should be Multi-Arch: foreign. This led to an IRC discussion between Goswin, Steve L. and me in which I formulated the proposal: If a package is 'Architecture: all', and all its dependencies are 'Multi-Arch: foreign' (including the case where there are no dependencies), this package should implicitly be treated as 'Multi-Arch: foreign' as well. Steve asked what the impact would be, given that Multi-Arch: foreign only matters if you have reverse dependencies that are not Architecture: all. So I wrote a crude script to figure it out. The numbers depend on whether you consider only Depends + Pre-Depends, or if you also consider Recommends and Suggests. Explicit M-A:foreign | Implicit M-A:foreign +-+- |With |With | Total | All non-arch:all | All non-arch:all Rule variant | | rev-dep(s) | rev-dep(s) --+---+-+- Depends + Pre-Depends | 17339 | 580 145 | 5310 994 Dep + P-D + Rec + Sug | 17339 | 580 197 | 2969 1151 Now, whether to consider Recommends and Suggests in the calculations, I don't have a strong opinion. It does change the mix of packages. For example: - bash-completion could be implicitly M-A:foreign, but this only really matters if we consider Recommends + Suggests. Almost nothing Depends on it, but several arch:any packages Recommend or Suggest it. - aptitude-common is implicitly M-A:foreign only if we do _not_ consider Recommends + Suggests, because while it has no dependencies, it Recommends aptitude, which is not M-A:foreign. - alsa-base is implicitly M-A:foreign only if we do _not_ consider Recommends, because while it only Depends on packages which are M-A:foreign, it Recommends alsa-utils, which is not. Anyway, these numbers indicate to me that it may be worth patching dpkg, apt, aptitude and other deb + multi-arch aware tools, to implicitly mark all those Arch:all packages as Multi-Arch:foreign, so that this doesn't have to be done explicitly. (But not during the freeze.) Thoughts? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121206080512.gl4...@p12n.org
Re: Architecture: all + M-A: foreign
[Helmut Grohne] I ask you not to use this proposal for the following reasons: * Given a package it is now much harder to see whether it is tagged M-A or not. Especially you can no longer determine the tagging by simple examination of package lists. That's fair. Though I imagine if apt knew about this mapping, it could just add 'M-A: foreign' to its package cache, so you would see it with 'apt-cache show' or 'apt-cache dumpavail'. Anyway, it's a concern. * Changing one package from Arch:all to Arch:any suddenly can break another package. An effect that one might not expect. Well, today, changing one package from Arch:any to Arch:all can suddenly break another package. (Same problem: lack of M-A:foreign.) Perhaps you think that is unexpected as well, but it is reality. * If for some reason the package is actually not M-A:foreign there is no way to overrule the implicit decision besides turning the package to Arch:any or introducing a new artificial Arch:any dependency. The only reason that I have seen that Arch:all is not _always_ treated as M-A:foreign, relates to recursive dependency resolution: foo:i386 - foo-data:all - bar:amd64, where foo:i386 and bar:amd64 cannot properly interact. My proposed rule accounts for that case. Can you think of any _other_ reasons not to set M-A:foreign on an Arch:all package? As a counter proposal I would like to ask whether such an implicit header could be added by debhelper (at a high enough compatibility level) by default. Could be done - dh could do the same analysis I'm asking apt to do. I believe traditionally dh does not mess with debian/control beyond what dpkg-gencontrol does with substvars and such, but I suppose that doesn't mean it _couldn't_. Maybe the problem also solves itself after extending dh-make? ;-) Heh - dh-make doesn't have enough context to know whether M-A:foreign makes sense. (: -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121206092000.gm4...@p12n.org
Re: Question: Packages.xz and Contents-arch.xz
[Hideki Yamane] henrich@hp:/tmp$ du -k Packages.* 6052Packages.bz2 5812Packages.xz henrich@hp:/tmp$ time bzip2 -d Packages.bz2 real0m0.999s user0m0.956s sys 0m0.020s henrich@hp:/tmp$ rm Packages henrich@hp:/tmp$ time xz -d Packages.xz real0m0.565s user0m0.532s sys 0m0.032s henrich@hp:/tmp$ time gzip -d Packages.gz gzip: Packages already exists; do you wish to overwrite (y or n)? y real0m1.932s user0m0.272s sys 0m0.012s While your post has good points, we need to notice that because of the interactive prompt, the 'real' time value for gzip -d is misleading. decompression speed is best : xz second: bz2 third : gz If you ignore the time gzip spent waiting for you to type 'y', it is the fastest, not the slowest. Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121116012454.gk4...@p12n.org
Re: Where could I upload x32 port bootstrap?
On Sat, Nov 10, 2012 at 10:47:43AM +0100, Adam Borowski wrote: On the other hand, widespread dumb-ass assumptions about i386/amd64 may cause quite a bit of issues: basically any Makefile that talks about x86 is somewhat suspicious. This is the main reason one may want to oppose the inclusion of x32 in Debian, IMHO. [Andrey Rahmatullin] Can you elaborate? [Henrique de Moraes Holschuh] This is no worse than any other new arch. The new wrinkle is that, because x32 uses the x86-64 instruction set, it defines preprocessor symbols associated with x86-64, and which a lot of source code uses to differentiate between i386 and amd64. Thus, code which cares about long and pointer size may well misdetect them on x32. From the revised AMD64 ABI Draft, chapter 7, page 105 (linked from https://sites.google.com/site/x32abi/documents): Table 7.1: Predefined Pre-Processor Symbols __amd64 Defined for both LP64 and ILP32 programming models. __amd64__ Defined for both LP64 and ILP32 programming models. __x86_64 Defined for both LP64 and ILP32 programming models. __x86_64__Defined for both LP64 and ILP32 programming models. _LP64 Defined for LP64 programming model. __LP64__ Defined for LP64 programming model. _ILP32Defined for ILP32 programming model. __ILP32__ Defined for ILP32 programming model. Note that LP64 means longs and pointers are 64-bit, our existing amd64 port. ILP32 means int, long, pointer all 32-bit, or x32. Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121110161009.gj4...@p12n.org
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On Donnerstag, 8. November 2012, Ben Hutchings wrote: And an annoying technical detail makes it suboptimal to add the microcode packages as a recommendation of the firmware-linux-nonfree package. ...which is that dpkg does not support architecture-specific relations in binary packages. [Holger Levsen] So make it recommend both microcode packages? So firmware-linux-nonfree should have two Recommends that are unsatisfiable on all but 2 of Debian's architectures (i386 and amd64)? I agree with Ben that that is suboptimal. ...But it does bring up the question of why intel-microcode and amd64-microcode are not built on kFreeBSD or the Hurd. Maybe those kernels lack a CPU microcode interface? Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121108195848.gh4...@p12n.org
Re: orphaned packages
[vangelis mouhtsis] Can please someone explain why a package should be orphaned from maintaining? (i hope the reason is not lack of maintainers) Yes it is. Or more precisely, every package needs a maintainer with: 1) the skills to maintain it (familiarity not only with Debian packaging in general, but with the implementation language, the frameworks, the problem domain, sometimes specific hardware or other resources); 2) the time to maintain it; 3) a desire to maintain it. For any given package in Debian, it is quite possible that there are people with the appropriate skills and experience, people with time, and people with interest, but nobody with all three. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121025181918.gg4...@p12n.org
Re: (seemingly) declinging bug report numbers
[Kelly Clowers] But I basically never report bugs. I have used Sid for years, and in fact I often don't notice bugs in my personal workflow (maybe if I can think of myself as a user? I notice end-user-impacting bugs in other areas). If someone comes over and sees me working the might say, wow that is an annoying bug and I say what bug? Oh that. I didn't notice, I just worked around it. Even with bugs I do notice, I usually just ignore and work around until it is fixed. Don't feel bad about that. Reporting a bug is a _burden_, especially if you care enough to produce a high-quality report. Even if the actual reporting part is pretty easy, you have to gather a lot of information: is it reproduceable and if so, how? How sure am I that it isn't user error or local configuration? How sure am I that it hasn't already been fixed by a newer upload? Is there anything strange in my environment that I am forgetting to mention, that would make the bug hard for anyone else to reproduce? And of course that's not even counting the time investment of working with the maintainer after the initial report. I don't fault anyone for deciding that the return on investment for producing a high-quality bug report is higher than for just working around it. I often do the same. We of course appreciate when users are willing to contribute a good bug report, but we don't require or expect everybody to do it. Mostly we produce Debian so you can _use_ it, not so you can spend your time helping us make it better. Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121019164112.gf4...@p12n.org
Re: Discarding uploaded binary packages
[Joerg Jaspert] As one thing to keep in mind - we have an acl structure in dak. Currently it reads something like all DD keys are allowed all uploads. all DM keys are allowed their own uploads according to DM rights. all buildd keys are allowed binary only uploads for their arch. It is not impossible nor excluded to have a set of rules like all DD keys are allowed all uploads, binaries dropped all DM keys are allowed their own uploads according to DM rights, binaries dropped all buildd keys are allowed binary only uploads for their arch. Paul Tagliamonte had a nice idea on IRC: all DD keys are allowed all uploads, binaries dropped _iff_ there is a source component This preserves the ability to upload a manual binNMU, which is not common, but is useful and sometimes necessary. (And not only for bootstrapping an arch or a compiler.) Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121019023025.gd4...@p12n.org
Re: Discarding uploaded binary packages
This preserves the ability to upload a manual binNMU, which is not common, but is useful and sometimes necessary. (And not only for bootstrapping an arch or a compiler.) ...and I forgot to add that something like this is required by the GR http://www.debian.org/vote/2007/vote_002, or at least the spirit of it. (The _letter_ of the GR could be argued either way: am I technically allowed to perform combined source and binary package uploads if my binaries are automatically discarded? But in my opinion the _spirit_ of the GR is clear.) Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121019030505.ge4...@p12n.org
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
[Christoph Anton Mitterer] Wouldn't it make sense to start discussions about moving to the strongest possible? No. What makes sense is to use a hash that has the properties that are needed for a particular application. To use your example of dpkg file checksums, their purpose has _nothing_ to do with security. They cannot protect against a malicious attacker, because an attacker who can corrupt /usr/bin/lsof can also corrupt /var/lib/dpkg/info/lsof.md5sums. (And /var cannot be read-only as /usr sometimes is.) If you need protection against a malicious attacker, you need to generate and store your checksums in some other way.[1] [1] Check out 'apt-cache search tripwire' for various ways to reinvent that wheel. tripwire was an early implementation of this idea, so it is mentioned in other package descriptions. Rather, the checksums are for integrity checking in the face of disk corruption or administrative snafu. Basically to answer the question Would it help to reinstall this package? MD5 is perfectly well suited for that. The presence of the md5sums file in control.tar.gz is just a convenience so that end systems don't have to calculate it at install time, much like providing .pyc or .elc files in a .deb (which we don't do, but we could). My point is not to pick on your specific example, but to suggest actually _thinking_ about what a hash is used for, as opposed to the common knee-jerk reaction oooh, MD5 is weak, it must be replaced! every time someone sees MD5. (Or SHA-1.) Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121011163521.gc4...@p12n.org
Re: where is the DNSSEC root key?
[Chris Knadle] However since all DNS servers are generally meant to use port 53, I think it's unlikely to install more than one DNS server locally, so I'm not sure if doing this makes sense from a packaging perspective. [I can see how it does from an administration perspective.] It's actually not uncommon to run, e.g., rbldnsd on a nonstandard port, and a full nameserver on port 53, which forwards queries to it. Now that's not directly related, as rbldnsd will never need to know the DNSSEC root keys ... but I'm just saying. It is quite possible that somebody will want to run a recursive nameserver and an authoritative nameserver, different packages, on the same host. I wouldn't bother with that, mind you. Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121005162324.gb4...@p12n.org
Re: Changes to Debian Maintainer upload permissions
[Joachim Breitner] Would it be possible to extend the syntax to specify lists of packages not by name, but by Maintainer, e.g. pkg-haskell-maintainers@l.a.d.o? Bonus points if such an assigment is expanded at dinstall time, so that the statement “DM 1234 may upload all packages owned by this group” stays up-to-date even if after new packages of this team have been added? So ... you want to give a DM the ability to NMU any package in the archive, just by changing the Maintainer field? While I'm sure such shenanigans would be caught quickly enough and the DM LARTed, it still doesn't seem like a good idea to me. Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120924165905.ga4...@p12n.org
Re: New upstream version of velvet contains debian/ dir
[Neil Williams] These are not native packages, they are expressly used by other distributions than Debian or even Debian derivatives - just because I'm on the upstream team / am the entire upstream team does NOT mean that I am justified in polluting the tarball released to RPM users with stuff which is specific to Debian. There are valid reasons to encourage upstreams not to ship debian/ in tarballs, but this one seems specious. Lots of projects ship RPM spec files, often multiple ones for specific Linux distributions. Neither spec files nor debian dirs are bloat on anything like the same scale as convenience copies of Windows DLLs. Sure, the debian dir in your tarball may give little benefit to most of its users. But does it really inconvenience anyone (other than the Debian maintainer)? Unless the debian dir adds more than, say, 10% to the size of the download, I would say it does not. Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120911194421.ga3...@p12n.org
Re: Help me DTRT with upstream naming
[Russ Allbery] The problem is that the software is called wallet, both the software itself and the primary client binary that users invoke. And, of course, we have a bunch of documentation and automation at Stanford that assumes that name. That actually seems like a reasonable name to me. I'm with Jeremy, I guess, I think normal command-line programs have a little more reason for shorter and simpler names than GUI and administrative software does. Besides, I doubt anybody would prefer that it be called WALL-Et. (We're not really helping you DTRT at all, are we?) If you rename it at all, I suggest 'nwallet', n for network. Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120908135334.ga6...@p12n.org
Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
[Thomas Goirand] Typically, I have / on 2 small RAID1 partitions making the array on the first 2 HDD (1 or 2 gigs), and /usr on a LVM on a much, much larger RAID array (I use mostly software RAID1 and RAID10, but in some cases, much bigger hardware RAID5). So yes, that's my usual server setup. I guess I can understand that you want your /usr to be resizeable, but really, life is so much simpler when you just go ahead and create a 12 GB root filesystem (and no separate /usr) and be done with it. The days have long passed when that 10 or 11 GB of wasted space was anything to worry about. Also, / is a partition on which almost nothing is read or written, while the others (eg: /usr, /var, /tmp, swap) are a lot more I/O intensive. Which means that / is less prone to failure. I always thought reads were pretty harmless and it's mostly writes you have to worry about (both for bugs in the OS FS, and for the physical media). And both / and /usr should have very few writes, percentage-wise. I used to think keeping / fully self-contained was useful. But it is a non-zero amount of effort, and I'm becoming convinced that these days, the separate /usr is going the way of the shared /usr/share. Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120831155225.gb4...@p12n.org
Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
[Russ Allbery]
All PAM modules are installed under /lib, because that's the path
used by libpam to load them. However, I don't think the vast
majority of PAM modules could be considered critical for early boot
or need to be usable without /usr mounted
It seems pam already looks in both /lib/security and /lib/{triplet}/security.
Why not add /usr/lib/{triplet}/security to the mix? (No need for
unqualified /usr/lib/security, I think. It seems GCJ already owns that
directory anyway.)
Peter
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120829223128.ga4...@p12n.org
Re: Enabling uscan to simply remove files from upstream source
[Jonas Smedegaard] Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Source: http://susy.oddbird.net/ Repackaged, excluding non-DFSG licensed fonts and source-less JavaScript Files-Excluded: docs/source/javascripts/jquery-1.7.1.min.js docs/source/javascripts/modernizr-2.5.3.min.js Files-Excluded-comment: Exlude source-less JavaScript A file format in which a comment starts with Files-Excluded-comment: instead of, say, #, is a file format I just can't get excited about. Automating get-orig-source is a fine idea, but tying it to DEP-5 would be unfortunate. And there is something to be said for the dpkg-source / debhelper style, in which each configuration parameter lives in its own tiny file (e.g., 'debian/source/format', 'debian/compat', 'debian/pyversions') rather than as fields of a larger file that is only tangentially related to the task at hand. Unrelated: when I've repacked tarballs, I add a file README.Debian-tarball to the top level source directory, explaining what I did. Nobody ever suggested this to me, it just seems like common sense that information about the new tarball should be, well, in the new tarball. Not just in the .diff.gz. If you're going to generate the tarball with uscan, could you either generate a README.Debian-tarball in the new orig.tar.gz, or actually use that location for configuration in the first place? (I'm not wedded to that filename, of course, but I do think it should be in the orig.tar.gz, and thus outside debian/.) Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120823172752.ga5...@p12n.org
Re: Enabling uscan to simply remove files from upstream source
[Peter Samuelson] And there is something to be said for the dpkg-source / debhelper style, in which each configuration parameter lives in its own tiny file (e.g., 'debian/source/format', 'debian/compat', 'debian/pyversions') rather than as fields of a larger file that is only tangentially related to the task at hand. ...Or add the exclude list to a file called 'debian/watch'. That makes even more sense to me. I mean, that file format isn't perfect (having options start with a prefix of opts= is a bit clunky, as is the design of one self-contained logical line per source, where there is almost always just a single source) but the format is explicitly versioned, so these things can be fixed. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120823173814.gb5...@p12n.org
Re: Enabling uscan to simply remove files from upstream source
Automating get-orig-source is a fine idea, but tying it to DEP-5 would be unfortunate. [Jonas Smedegaard] You mean that you prefer a separate file for this info? What should be its name? What should be its syntax? ...and why start from scratch with this - or does something else already exist, comparable to the work of DEP-5? Well, two reasons not to bundle it into DEP-5 format files. First, there may be a lot of people like me who would find value in a config-file-driven 'get-orig-source' but who do not find any value in maintaining debian/copyright in DEP-5 format. Tying the two together basically means I probably won't use it, as managing my own .orig generation seems easier than having to maintain a DEP-5 file. By making me choose to migrate to DEP-5 in order to get the uscan feature, you're making the feature less useful. Second, debian/copyright isn't a config file. I'd rather see configuration in a config file. Perhaps the DEP-5 mindset is such that you do see debian/copyright as a config file now, but I think its purpose has always been documentation, not configuration. I guess you can tell I never really cared for literate programming Anyway, I thought I wanted a separate file, but then I remembered that uscan already uses 'debian/watch' for configuration. The syntax of a watch file is pretty awkward, being based on (logical) lines rather than stanzas, and using opts=foo=1,bar=2 instead of something like foo=1 bar=2, but it does seem like the right place to put additional uscan configuration. And the watch file format can presumably be fixed, as it is explicitly versioned. Unrelated: when I've repacked tarballs, I add a file README.Debian-tarball to the top level source directory, explaining what I did. Nobody ever suggested this to me, it just seems like common sense that information about the new tarball should be, well, in the new tarball. Not just in the .diff.gz. Nowadays such info is commonly put into README.source I know, but that's typically not in the orig.tar.gz. If someone grabs foo_1.0+dfsg.orig.tar.gz by itself, I think it is useful to have a README in there that explains how it is different from an upstream foo-1.0.tar.gz. Hence if you're going to automate repacking, I just wanted to suggest generating a README file to put into the repacked tarball. And as I said, I haven't heard of anyone else doing this, so perhaps I'm the only one who thinks it makes sense. Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120823221535.gc5...@p12n.org
Accepted mtink 1.0.16-6 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 26 Jul 2012 08:57:46 -0500 Source: mtink Binary: mtink mtink-doc Architecture: source all amd64 Version: 1.0.16-6 Distribution: unstable Urgency: low Maintainer: Debian QA Group packa...@qa.debian.org Changed-By: Peter Samuelson pe...@p12n.org Description: mtink - Status monitor tool for Epson inkjet printers mtink-doc - Documentation for mtink Changes: mtink (1.0.16-6) unstable; urgency=low . * QA upload. * Regenerate debian/control properly from control.in. * patches/lesstif-multiarch: Remove a bit more Configure cleverness trying too hard to detect Motif, finding it in the wrong m-a paths. * Fix FTBFS from recent dpkg-dev: Ensure that docs are built from the build-arch and build-indep targets, not just the build target. * Remove README.source, which just talked about dpatch. Checksums-Sha1: 207988954aa853ab3a9d5baac9eb01819b1e4f05 1253 mtink_1.0.16-6.dsc 413e5beada48f9452c3b1d2103839092a17292f5 33229 mtink_1.0.16-6.debian.tar.gz 5e3d79edf81dd73d08e175822daaa60a0e98fefc 546708 mtink-doc_1.0.16-6_all.deb 2c1575b9afcb97bec85eafc182c95ef77a725748 197750 mtink_1.0.16-6_amd64.deb Checksums-Sha256: 0fb5628ed022b66b4f9e3e6b4531ae5bba23777425c13f97036b09af2e788491 1253 mtink_1.0.16-6.dsc 4232f85c16c7c592c46e8126ea0bad195dc2f32dbd2fb0954ba687ac9db54b20 33229 mtink_1.0.16-6.debian.tar.gz 226821d21a5ebeb3a368c310fb91e8bee894164ab2c669cffa9479622e8cbc97 546708 mtink-doc_1.0.16-6_all.deb 8c30c47a6a885fee883759fd195933a1dff0e9144404ec0cc9dc3ae5acb00989 197750 mtink_1.0.16-6_amd64.deb Files: 7e43de57888f8062464508ade6f722d9 1253 misc extra mtink_1.0.16-6.dsc ddbcf5df54ec07d4a8ac5295a933a54b 33229 misc extra mtink_1.0.16-6.debian.tar.gz 13ebded871595e6f7141863bd7caba00 546708 doc extra mtink-doc_1.0.16-6_all.deb 3fc4a0e7729e7360d2a1b088d38fe86b 197750 misc extra mtink_1.0.16-6_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFQEWKmXk7sIRPQRh0RAuVSAKDK2G09VIhQpzqtY/G6H39EJg5rIQCfQWeO Y8rPBkGEeW5F0rMm15tNYHI= =Wzi5 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1suqhf-0008pp...@franck.debian.org
Accepted lesstif2 1:0.95.2-1.1 (source all amd64 i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 12 Jul 2012 17:17:40 -0500 Source: lesstif2 Binary: lesstif2 lesstif2-dbg lesstif2-dev lesstif-bin lesstif-doc Architecture: all amd64 i386 source Version: 1:0.95.2-1.1 Distribution: unstable Urgency: low Maintainer: Sam Hocevar s...@debian.org Changed-By: Peter Samuelson pe...@p12n.org Closes: 677788 Description: lesstif-bin - user binaries for LessTif lesstif-doc - documentation for LessTif lesstif2 - OSF/Motif 2.1 implementation released under LGPL lesstif2-dbg - lesstif2 debugging files lesstif2-dev - development library and header files for LessTif 2.1 Changes: lesstif2 (1:0.95.2-1.1) unstable; urgency=low . * Non-maintainer upload. * debian/control, debian/rules: multiarch for lesstif2. (Closes: #677788) Checksums-Sha1: 84e23dd419993c500404ef8ecad06fc27feaf722 1577 lesstif2_0.95.2-1.1.dsc 008956ec88248ec28a18fe4a6cf72ab368cee3ec 193083 lesstif2_0.95.2-1.1.diff.gz 7b450d8e1e815da326b8b322d83968f111fa3bc2 358802 lesstif-doc_0.95.2-1.1_all.deb 6becc9d0bb2847e8f56c8fe398fa658ff0db5d17 709604 lesstif2_0.95.2-1.1_amd64.deb 5dfe59ea3e9b6919677bc06e2e223ee9877158af 2321056 lesstif2-dbg_0.95.2-1.1_amd64.deb b4e794cecc4e166c2a84f56d29d3d22a0e38b054 974466 lesstif2-dev_0.95.2-1.1_amd64.deb 619fae1e327463a802f70fad562c95cd4d7e0b6b 188044 lesstif-bin_0.95.2-1.1_amd64.deb 0168979ed5c331bb1f0189074e1808f999e3d0ce 708108 lesstif2_0.95.2-1.1_i386.deb 236521b731da144e35a747e76ed227829c577e42 2175652 lesstif2-dbg_0.95.2-1.1_i386.deb c11191665bfe043ddd575744ed595250b5cf73c3 920854 lesstif2-dev_0.95.2-1.1_i386.deb 01f67121131dda302e8df48814a78d0fe4807b73 181114 lesstif-bin_0.95.2-1.1_i386.deb Checksums-Sha256: 73ffa992f43c0b1b154abb6ef659d270590adb3b32e77e1e6a9befb1f9d7c47e 1577 lesstif2_0.95.2-1.1.dsc b332db79ffaf6208f0a5c08b910ba10b2d03946afabd48ce07dd4da64379a0eb 193083 lesstif2_0.95.2-1.1.diff.gz aa65ae365682bd8d7045a187bc6249644ccd217af71fe7757efa1290ee717ece 358802 lesstif-doc_0.95.2-1.1_all.deb 235d8f7ef22170add2d9c2819e666c031193f32d39a997025b3271821aff367f 709604 lesstif2_0.95.2-1.1_amd64.deb 9091ea67aa5d9d1534ab11e638e8231b46565df90f0c6fcfc96b48f0ef33df2a 2321056 lesstif2-dbg_0.95.2-1.1_amd64.deb 106298951f581ebba2ff33b59306bb725ccbae892da35d6e1f3531db863f1594 974466 lesstif2-dev_0.95.2-1.1_amd64.deb f602496aa4fe0e20ef6fb4f3a1d6d02670743b5b1daef631e4f8212f24bc 188044 lesstif-bin_0.95.2-1.1_amd64.deb 77bd79951721d199c54de9d5d5ce102bb56e86bbd14ebc1aea730d64d6fcb5b4 708108 lesstif2_0.95.2-1.1_i386.deb 23df934c4d196c1ebda794c3aad04db98ef8d558d040097df5536f92dc8e2513 2175652 lesstif2-dbg_0.95.2-1.1_i386.deb 05f7441e79723709c4d26269ef3030515da923479b502fb4d00ed9ac6e2c4fb3 920854 lesstif2-dev_0.95.2-1.1_i386.deb d62c67cacaa6f58e028ea3c8f4e18b2754083b9585f6d9a59085430ca03056c9 181114 lesstif-bin_0.95.2-1.1_i386.deb Files: b2acd2d076a0ff813871d19e261d048c 1577 libs optional lesstif2_0.95.2-1.1.dsc 038f603f25c57c8d03a72657abc03998 193083 libs optional lesstif2_0.95.2-1.1.diff.gz b1698137dd614185f40a3e00ad2362a8 358802 doc optional lesstif-doc_0.95.2-1.1_all.deb 7f657d252247cbdb8028f2130fccc095 709604 libs optional lesstif2_0.95.2-1.1_amd64.deb 5dbcbd0fcd26ec1f188323bc7ceb49fa 2321056 debug extra lesstif2-dbg_0.95.2-1.1_amd64.deb d3a943d111dc0a1d8838da748ed2c03a 974466 libdevel optional lesstif2-dev_0.95.2-1.1_amd64.deb c04a426c2ec51b7bab4aac0ebdb1363a 188044 x11 optional lesstif-bin_0.95.2-1.1_amd64.deb 3d446cbb0c42e7622a44671c4322ebe5 708108 libs optional lesstif2_0.95.2-1.1_i386.deb 0373b28a203332ab7da31ea3de210b9e 2175652 debug extra lesstif2-dbg_0.95.2-1.1_i386.deb 5e853a1adc6ee7ae95c6057cce16dc3c 920854 libdevel optional lesstif2-dev_0.95.2-1.1_i386.deb 67075c759c72d9de30cba21e70449901 181114 x11 optional lesstif-bin_0.95.2-1.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFQEAmwXk7sIRPQRh0RAkF+AJ999xA+he+lIkk1gUSUcGhaf3MTVACg2bK5 Ht1SNG+IwnxFoKmN9Nc5lPU= =yKKi -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1su5ru-0008ga...@franck.debian.org
Accepted mtink 1.0.16-5 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 25 Jul 2012 18:17:04 -0500 Source: mtink Binary: mtink mtink-doc Architecture: source all amd64 Version: 1.0.16-5 Distribution: unstable Urgency: low Maintainer: Debian QA Group packa...@qa.debian.org Changed-By: Peter Samuelson pe...@p12n.org Description: mtink - Status monitor tool for Epson inkjet printers mtink-doc - Documentation for mtink Closes: 660706 Changes: mtink (1.0.16-5) unstable; urgency=low . * QA upload. * patches/lesstif-multiarch: Fix FTBFS due to lesstif2 multiarch. - Also explicitly remove Xp detection (bug #623650). This was needed because, now that we can detect libraries in multiarch paths, the libxp dependency would have returned from the dead. * Add debconf translation: - pt_BR from J.S. Júnior (Closes: #660706) * Policy 3.9.3 (no changes). Checksums-Sha1: 608ce8ef467bd03c40386ff25ce86ef4bad5ae2c 1251 mtink_1.0.16-5.dsc bd3e864d6dbd7aec8787ea6ea9a7198fe56d99b0 33558 mtink_1.0.16-5.debian.tar.gz 93f37923b3da31063962e0b84a9f51c5a6d4f54d 540292 mtink-doc_1.0.16-5_all.deb 9e4902fc24e013b5fa26c61878c844475ca965fc 193392 mtink_1.0.16-5_amd64.deb Checksums-Sha256: fb8ef1a58116073044876b4e7fca94cedbf5ef1230726330ec529f13691e55d3 1251 mtink_1.0.16-5.dsc b3e6d36255675c884de78cac779bbebaab9c180f3463d63c61293977885b84aa 33558 mtink_1.0.16-5.debian.tar.gz d5cbecaf938fa7f8cf7df5e03cd2a53c70387042b54ce6593d32277cd0d6c9bc 540292 mtink-doc_1.0.16-5_all.deb 619f1ffc587999651c4129bf4139369f1ca0234ba296f4dd9407bfd17110b059 193392 mtink_1.0.16-5_amd64.deb Files: 1a73e0244a00f1b6d6a121bb4c265fe3 1251 misc extra mtink_1.0.16-5.dsc b045fa902507176459a0d1cf0ea11e4e 33558 misc extra mtink_1.0.16-5.debian.tar.gz 20fafcab0ad50dd22d4419589f548435 540292 doc extra mtink-doc_1.0.16-5_all.deb 7118065cb43e0d48183bf8b4a6fb23de 193392 misc extra mtink_1.0.16-5_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFQEKwHXk7sIRPQRh0RAoaYAKDCb5SBcAVOu1rdYwgUvx90wd7IlgCfSnNe excZ3bpEmke4LOQSTh+Crrw= =nf50 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1sue6i-00058t...@franck.debian.org
Re: Improving our response to duplicate packages in Debian
[Holger Levsen] if thats true, I don't want any of my package maintainance jobs. can you please fire me? You've been around awhile. If that is true, you should know how to RFA or orphan packages and/or retire from the Project. You should know by now that it isn't up to others to fire you. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120629081013.gb...@p12n.org
Accepted subversion 1.7.5-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Sat, 16 Jun 2012 23:56:38 -0500
Source: subversion
Binary: subversion libsvn1 libsvn-dev libsvn-doc libapache2-svn
python-subversion subversion-tools libsvn-java libsvn-perl ruby-svn
libsvn-ruby1.8 libsvn-ruby
Architecture: source all amd64
Version: 1.7.5-1
Distribution: unstable
Urgency: low
Maintainer: Peter Samuelson pe...@p12n.org
Changed-By: Peter Samuelson pe...@p12n.org
Description:
libapache2-svn - Apache Subversion server modules for Apache httpd
libsvn-dev - Development files for Apache Subversion libraries
libsvn-doc - Developer documentation for libsvn
libsvn-java - Java bindings for Apache Subversion
libsvn-perl - Perl bindings for Apache Subversion
libsvn-ruby - Ruby bindings for Apache Subversion (dummy package)
libsvn-ruby1.8 - Ruby bindings for Apache Subversion (dummy package)
libsvn1- Shared libraries used by Apache Subversion
python-subversion - Python bindings for Apache Subversion
ruby-svn - Ruby bindings for Apache Subversion
subversion - Advanced version control system
subversion-tools - Assorted tools related to Apache Subversion
Closes: 644438
Changes:
subversion (1.7.5-1) unstable; urgency=low
.
[ Peter Samuelson ]
* New upstream version.
- Refresh patches; remove obsolete no-dbus-spam, kwallet-wid,
perl-warning, perl-compiler-flags, po, swig2-compat,
disable-failing-tests, python-exception-syntax
- Split patches/apr-abi into apr-abi1 (to be submitted) and
apr-abi2 (Debian-specific).
- Disable patches/ruby-test-info ... for now.
- Requires serf 1.0 or higher.
* Upstream no longer ships contrib in tarball:
- Remove contrib-license-audit
- subversion-tools now Recommends: svn2cl
- Ship svn-clean, svn-fast-backup, svn_apply_autoprops,
svn_load_dirs, commit-email.pl in debian/contrib
- Don't ship svnmerge.py, it has outlived its usefulness
- Delete patches/{svn2cl-*,svn-clean-ignore,commit-email}
- Overhaul debian/copyright
* rules: Specify that we want our own libtool. Otherwise it finds the
one from /usr/share/apr-1.0/build, which doesn't support C++.
* patches/entropy: Remove as obsolete. It was a workaround for apr
using /dev/random, but apr switched to /dev/urandom in 1.3.
* Move emacs plugins from subversion to subversion-tools.
* patches/java-osgi-metadata: Add OSGi metadata to the libsvn-java
jarfile. Thanks Jakub Adam. (Closes: #644438)
* Switch from python-support to dh_python2.
* patches/python-swig205: New patch: Adjust for swig 2.0.5+ handling of
Python ints vs. longs.
.
[ Michael Diers ]
* More contrib adjustments:
- Provide debian/contrib/emacs from upstream VCS contrib/client-side/emacs
- Add svn_1.6_releasenotes.html, svn_1.7_releasenotes.html
- subversion.docs, subversion.install
- subversion-tools.docs, subversion-tools.manpages
Checksums-Sha1:
c86c99bf6259f16c459e22c91c9887ec3aba7313 2242 subversion_1.7.5-1.dsc
52fcc730232623497491f6c3e544ee8761b9b007 8204322 subversion_1.7.5.orig.tar.gz
e4641ae311153ba9c207d6ac66b67a59f55261b4 230580 subversion_1.7.5-1.diff.gz
879a584263e280fbb1fbb701ae0dcd18c65e9f9f 2516516 libsvn-doc_1.7.5-1_all.deb
8e0937664a05d0e4883831777fd497eb04c0025f 282078
subversion-tools_1.7.5-1_all.deb
e34683d9d32deb3cf6cab55ab0f601aa246143c4 800 libsvn-ruby1.8_1.7.5-1_all.deb
9fab4265c47e2c5c509914055e73dd5d9a2807cc 792 libsvn-ruby_1.7.5-1_all.deb
7e4505b976abc026c8b08288630ec3a61a198c4a 1294902 subversion_1.7.5-1_amd64.deb
1a42d9b101679b792ccd6b0fc777264241488a0e 1195006 libsvn1_1.7.5-1_amd64.deb
5680d46e02972d8b965667ddd1f34a532fb8b7f6 1676582 libsvn-dev_1.7.5-1_amd64.deb
dca575142eb8a2396e25297a20f10ba9ac58aeca 187168
libapache2-svn_1.7.5-1_amd64.deb
11c7b36cbe9dd2c1729e8a4273a8474c52e7 1576500
python-subversion_1.7.5-1_amd64.deb
d0261bf2bbd37b2a0257b3868c8b21ac551f0bab 362504 libsvn-java_1.7.5-1_amd64.deb
271ed88e168881633914bc6af22326476adb12ce 1282386 libsvn-perl_1.7.5-1_amd64.deb
a0f52119da2556b65b1b93b0e5949f66bbc93992 727170 ruby-svn_1.7.5-1_amd64.deb
Checksums-Sha256:
95dbf64826876f7d80a2ade2ee6ff62d8b3bc00cb07ad9be2ffcbc6ad2190087 2242
subversion_1.7.5-1.dsc
cb102a437335a8921f00cef9bf730d84527713f1a5091e3e1eb2f16402f85dc1 8204322
subversion_1.7.5.orig.tar.gz
3fb5c3d92ed608330da627b7a05c2c9be565daa2a93184e0bbe98e5688a890ff 230580
subversion_1.7.5-1.diff.gz
c5a425c057d12d01feca64d7505c2872bcbb4550a6c66d785837b743b255fb3d 2516516
libsvn-doc_1.7.5-1_all.deb
e7030f0a70b28d810d8a1403022600f0ae0d30829b83b737d1320ba478b30143 282078
subversion-tools_1.7.5-1_all.deb
78a9f13fde15a9b8ec3da366e0950e99be274ce553d0ec4c3ccd0487ed6c15c5 800
libsvn-ruby1.8_1.7.5-1_all.deb
d213e5b1ef57a30248a66e4f6f735d299d1cd2943f94477bf855ce68e1492aa5 792
libsvn-ruby_1.7.5-1_all.deb
46de2e3712aec1171335bd6fb4f4d87501c2d7500fa451e899e8624f6ade2573 1294902
subversion_1.7.5-1_amd64.deb
Accepted gpm 1.20.4-6 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 10 Jun 2012 14:55:09 -0500 Source: gpm Binary: gpm libgpm2 libgpm-dev Architecture: source amd64 Version: 1.20.4-6 Distribution: unstable Urgency: low Maintainer: Peter Samuelson pe...@p12n.org Changed-By: Peter Samuelson pe...@p12n.org Description: gpm- General Purpose Mouse interface libgpm-dev - General Purpose Mouse - development files libgpm2- General Purpose Mouse - shared library Changes: gpm (1.20.4-6) unstable; urgency=low . * No source changes; rebuild to make the multiarch *.gz md5sums match. (Should be a binNMU, but those do not work with M-A.) Checksums-Sha1: 064011b01f9d89bb7470cc2330fb3123923315fc 1179 gpm_1.20.4-6.dsc c26fcc43b25d87bd0ab65efd5d83ebcae7afb6c8 92710 gpm_1.20.4-6.diff.gz 0e58670efc53d3d541f31e8401519e331e28f748 233592 gpm_1.20.4-6_amd64.deb 2d01aea1e1eb6c9aab3c8062f1141de7e0f38d20 35780 libgpm2_1.20.4-6_amd64.deb f9d1b078b6d12db01bc7f39df9e7595d7905c038 39942 libgpm-dev_1.20.4-6_amd64.deb Checksums-Sha256: fff3572a6755cd99bad81ff3b8b3bdba1b7e2d03926bed7333a4086fb32c 1179 gpm_1.20.4-6.dsc 5fbcaa1469db0282f7776e57de0b84504467720d974e61705667e8d268c4f823 92710 gpm_1.20.4-6.diff.gz fe06f702bbc226fa8809fd563b821fb70367899f0ead2b8e9b678b319b65495d 233592 gpm_1.20.4-6_amd64.deb 8f2749d3b098ea0af4ea0a9e03b0e401b7152edea8a41581342a4fe86fa73eff 35780 libgpm2_1.20.4-6_amd64.deb b71c0a37219b401a0953094464550c517d528b0d50847e3563b9f902f88dfdbd 39942 libgpm-dev_1.20.4-6_amd64.deb Files: 563c2a11095b31856c35d963dc651c3f 1179 misc optional gpm_1.20.4-6.dsc 5e5f3c99f76f4d2ca6327357c4017cab 92710 misc optional gpm_1.20.4-6.diff.gz cbbda85f0417fb521f946746f3fe52fd 233592 misc optional gpm_1.20.4-6_amd64.deb cb4bcfbeefaa0df356d4df20c42ce361 35780 libs standard libgpm2_1.20.4-6_amd64.deb eaaf7501bafdd160bb9b58bff9d02ff4 39942 libdevel optional libgpm-dev_1.20.4-6_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFP1P08Xk7sIRPQRh0RAtmzAKCWs1nYB/OwXn0rnAGkxN0q++frcwCgw63h COSTUsw4fZGHWtoqraJVSWo= =tLvT -END PGP SIGNATURE- Accepted: gpm_1.20.4-6.diff.gz to main/g/gpm/gpm_1.20.4-6.diff.gz gpm_1.20.4-6.dsc to main/g/gpm/gpm_1.20.4-6.dsc gpm_1.20.4-6_amd64.deb to main/g/gpm/gpm_1.20.4-6_amd64.deb libgpm-dev_1.20.4-6_amd64.deb to main/g/gpm/libgpm-dev_1.20.4-6_amd64.deb libgpm2_1.20.4-6_amd64.deb to main/g/gpm/libgpm2_1.20.4-6_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1sdplt-00023z...@franck.debian.org
Accepted subversion 1.6.18dfsg-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 08 Jun 2012 00:04:19 -0500 Source: subversion Binary: subversion libsvn1 libsvn-dev libsvn-doc libapache2-svn python-subversion subversion-tools libsvn-java libsvn-perl ruby-svn libsvn-ruby1.8 libsvn-ruby Architecture: source all amd64 Version: 1.6.18dfsg-1 Distribution: experimental Urgency: low Maintainer: Peter Samuelson pe...@p12n.org Changed-By: Peter Samuelson pe...@p12n.org 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 (dummy package) libsvn1- Shared libraries used by Subversion python-subversion - Python bindings for Subversion ruby-svn - Ruby bindings for Subversion subversion - Advanced version control system subversion-tools - Assorted tools related to Subversion Closes: 675987 Changes: subversion (1.6.18dfsg-1) experimental; urgency=low . * New upstream version. - patches/sasl-mem-handling: delete obsolete patch. * Add Conflicts and Replaces: libsvn-jni. (Closes: #675987) * Rename libsvn-ruby1.8 to ruby-svn, per Ruby policy. Leave transition package behind for wheezy. Checksums-Sha1: 6a97389b90702e142f25d7999889e0153866f53d 2309 subversion_1.6.18dfsg-1.dsc 898c7523a91bea449b0a6270054a12791ed09866 9216001 subversion_1.6.18dfsg.orig.tar.gz 50a9e475e803fd58a56fa8c94891beb7515a00fe 107562 subversion_1.6.18dfsg-1.diff.gz f73089af2a5afddcfe68fd56ab30fd868963d66a 2076006 libsvn-doc_1.6.18dfsg-1_all.deb 626c0cefa72ef1f5b9076b8054e871aa9a98fd1c 225614 subversion-tools_1.6.18dfsg-1_all.deb 0afa45411b8c0c50465ead3e92c39933d4c0c3d5 796 libsvn-ruby1.8_1.6.18dfsg-1_all.deb 46f1e83ed4e038fc369afd86f211f58a1fa4cbaf 790 libsvn-ruby_1.6.18dfsg-1_all.deb e8ff605eba900c1905bb8aa47c6d057c96cd7e16 1323486 subversion_1.6.18dfsg-1_amd64.deb c0e816ca261d9712d67766273e2f8b665a69ea66 936066 libsvn1_1.6.18dfsg-1_amd64.deb 54f2b4032d3718610ec428ffcf0ad08b10ad15e2 1326060 libsvn-dev_1.6.18dfsg-1_amd64.deb 3a14f25e2d48ef6278ddf26290efdb7d551d4130 174260 libapache2-svn_1.6.18dfsg-1_amd64.deb 5285207c2de7f48c7710938db669b9eb6b3d8a42 1343154 python-subversion_1.6.18dfsg-1_amd64.deb 790778a2b484f4829857b24e9a9a1a9e0df5a0e3 209518 libsvn-java_1.6.18dfsg-1_amd64.deb fa655bcd5fdf4d2129484f91dd03b24b598e79f3 1085644 libsvn-perl_1.6.18dfsg-1_amd64.deb 043aff97949f5dc596cab8427657e48f7fdd 629402 ruby-svn_1.6.18dfsg-1_amd64.deb Checksums-Sha256: ddbe504d088c36be545233c1d69f61589f91445215eb13b9760301d6d23dda93 2309 subversion_1.6.18dfsg-1.dsc 2dd116677e4b2b959febd4401050b071c7d32f7d17585c06a70eec3f3cd6ea97 9216001 subversion_1.6.18dfsg.orig.tar.gz d4defbae7f12e52579016c3060e54783f0528f10bd9277f4382bd26eeb6d3e73 107562 subversion_1.6.18dfsg-1.diff.gz 2210ee78882dbe2a2e45a9ac59688962430065c3dfd903955f29e8fd5a9fa823 2076006 libsvn-doc_1.6.18dfsg-1_all.deb 5ceecb66c6279ee697dba8746be2ea69ad86cbaac4b2114518c12022b07bbe6f 225614 subversion-tools_1.6.18dfsg-1_all.deb c9fa32c1666293a273b5b8b0eec4cdad8be933b645ff8292f2977d577cb9b84c 796 libsvn-ruby1.8_1.6.18dfsg-1_all.deb 7f8d3b7a33e95b7826307bbe363d47ba26792e4b96ae8920d13c5c097a820481 790 libsvn-ruby_1.6.18dfsg-1_all.deb 94100b231f4a3cf4cf3b0d53e059cee1ea8ca1cb9c65d17c3834dcf6e376b2ee 1323486 subversion_1.6.18dfsg-1_amd64.deb 3385ada90a9961e1cf4e81253d74fcfd97a595907aecab978deb91574abf2fd1 936066 libsvn1_1.6.18dfsg-1_amd64.deb 6567498596cdea8ad819efac14d6a14d9fb932f9081e462c236b59dc463d43b0 1326060 libsvn-dev_1.6.18dfsg-1_amd64.deb bb4814469e0543a8fd9dad382fb9a086269e0b700b2fc786daee47e5190eea3b 174260 libapache2-svn_1.6.18dfsg-1_amd64.deb 6daca6a136f72adf694c81253270a020dab5ee54c023fcfe2e10de1b429982a7 1343154 python-subversion_1.6.18dfsg-1_amd64.deb 7190fa3fd9f7bcc22fde7c02cf69a4ef293dd3b88d654c9f5adb1fa0b86a6e4a 209518 libsvn-java_1.6.18dfsg-1_amd64.deb 96a3d4f916341554c3bf55929f4f03188f939415e0a2ed5bf7e089ae03accff9 1085644 libsvn-perl_1.6.18dfsg-1_amd64.deb bd208f6bfcbfe53320055707d8b3b8ccdb2ae423706a73830da4cabb687bbed4 629402 ruby-svn_1.6.18dfsg-1_amd64.deb Files: bee2f81b075f4ca933e661444a17c983 2309 vcs optional subversion_1.6.18dfsg-1.dsc b81eaec3fde9c528449ed22e8389b5aa 9216001 vcs optional subversion_1.6.18dfsg.orig.tar.gz 21058a71cb26fb2c0cead1adc05adca4 107562 vcs optional subversion_1.6.18dfsg-1.diff.gz 2e147dfcf5241dcd2b523f9b8cd784c4 2076006 doc extra libsvn-doc_1.6.18dfsg-1_all.deb 5036a624881477aaf10016a63a2cce4c 225614 vcs extra subversion-tools_1.6.18dfsg-1_all.deb f87b7a775dc5b7eac024d4de0f6464e9 796 oldlibs optional libsvn-ruby1.8_1.6.18dfsg-1_all.deb b5d8d263ce051d147f3715ae4a859247 790 oldlibs optional libsvn-ruby_1.6.18dfsg-1_all.deb 0b7261c6ea4167d4491a9649bc284367
Accepted serf 1.1.0-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 09 Jun 2012 14:26:56 -0500 Source: serf Binary: libserf1 libserf-dev libserf1-dbg Architecture: source amd64 Version: 1.1.0-2 Distribution: unstable Urgency: low Maintainer: Peter Samuelson pe...@p12n.org Changed-By: Peter Samuelson pe...@p12n.org Description: libserf-dev - high-performance asynchronous HTTP client library headers libserf1 - high-performance asynchronous HTTP client library libserf1-dbg - high-performance asynchronous HTTP client library debugging symbo Changes: serf (1.1.0-2) unstable; urgency=low . * Upload to unstable. * Add another lintian override. * Make libserf1-dbg M-A: same as well. Checksums-Sha1: 126933e808672fa829175140568076ad311c4bfd 1167 serf_1.1.0-2.dsc 1c0c76f4c4c004dcbdf8d96dd6b062d2b98d01b5 6176 serf_1.1.0-2.diff.gz 6878d3d8d5993f100e8588fae16d86e7af548c7d 46770 libserf1_1.1.0-2_amd64.deb 3d49bdd4eb4e384a7c577507d3f3ddfc92eccc55 84048 libserf-dev_1.1.0-2_amd64.deb 5377b2159b50517297cfcdeba190a685e6ba0a7d 8804 libserf1-dbg_1.1.0-2_amd64.deb Checksums-Sha256: f22073abfb1f10d2f4899ceae31aeb92435fa3eb1dd877de9db94e9257a1f69a 1167 serf_1.1.0-2.dsc a0a93e2f2c85806f5bb08982328286518fa451ff07c2b3dde6aeb65c5adf651d 6176 serf_1.1.0-2.diff.gz 20a7d48b8f734b1c311d7398c6e454de370be58569ab58c19760acd628922730 46770 libserf1_1.1.0-2_amd64.deb ffc5ea86d6e549578c93a88a8ae8f28f5484dfc0a8eabc8213c5187a78e3a1e8 84048 libserf-dev_1.1.0-2_amd64.deb 04ef7d1d078929501b0e872ac7b437bd01a686ae03e2027ed07c240c59d63ab4 8804 libserf1-dbg_1.1.0-2_amd64.deb Files: f1591bd88f0ebf1a5b293d5c296b40de 1167 libs optional serf_1.1.0-2.dsc b89784cde4362b89aa2f6aca8e717d25 6176 libs optional serf_1.1.0-2.diff.gz b9e56d3654f65b297b8156bc222efd7e 46770 libs optional libserf1_1.1.0-2_amd64.deb 8fb56fc43e547992481f24094c05446b 84048 libdevel optional libserf-dev_1.1.0-2_amd64.deb 2362729932d85561fdf9b1e3e4301108 8804 debug extra libserf1-dbg_1.1.0-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFP07ZiXk7sIRPQRh0RAkHlAJ9EGUQ8Gzvw4fc7XqqRirqzzHlX4ACdFZST ObLSA3kevwIchTMZJfO985k= =RSbk -END PGP SIGNATURE- Accepted: libserf-dev_1.1.0-2_amd64.deb to main/s/serf/libserf-dev_1.1.0-2_amd64.deb libserf1-dbg_1.1.0-2_amd64.deb to main/s/serf/libserf1-dbg_1.1.0-2_amd64.deb libserf1_1.1.0-2_amd64.deb to main/s/serf/libserf1_1.1.0-2_amd64.deb serf_1.1.0-2.diff.gz to main/s/serf/serf_1.1.0-2.diff.gz serf_1.1.0-2.dsc to main/s/serf/serf_1.1.0-2.dsc -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1sdt4i-0001am...@franck.debian.org
Accepted serf 1.1.0-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 08 Jun 2012 00:18:56 -0500 Source: serf Binary: libserf1 libserf-dev libserf1-dbg Architecture: source amd64 Version: 1.1.0-1 Distribution: experimental Urgency: low Maintainer: Peter Samuelson pe...@p12n.org Changed-By: Peter Samuelson pe...@p12n.org Description: libserf-dev - high-performance asynchronous HTTP client library headers libserf1 - high-performance asynchronous HTTP client library libserf1-dbg - high-performance asynchronous HTTP client library debugging symbo Changes: serf (1.1.0-1) experimental; urgency=low . * New upstream version. * Policy 3.9.3 (no changes). Checksums-Sha1: 23404217255dd46133ac84e2e7f726ed3af7e0c9 1167 serf_1.1.0-1.dsc 1500046f7ee9bfb332c316a03c114c14498f8c38 217855 serf_1.1.0.orig.tar.gz 5470157f48d04f9af3438aa83137949db4f79dba 6055 serf_1.1.0-1.diff.gz 39941e049c6871e5f52537be4baf104c7d70c0a9 46630 libserf1_1.1.0-1_amd64.deb e3c54a01fea96f437272cc6435b0ad825c6e1ded 84060 libserf-dev_1.1.0-1_amd64.deb dcb59822849ab313a252156feb915682d36db463 8796 libserf1-dbg_1.1.0-1_amd64.deb Checksums-Sha256: 261b131bc41a77f24f2fdc9dca81151949a7ca401b9a4ed7132990699636ae60 1167 serf_1.1.0-1.dsc fd2a878babe87325272bcea785f66c3c8d2c6c751c1d81013ad18a6f970c1aa4 217855 serf_1.1.0.orig.tar.gz d6c877cc8aabdd4f7c0ea7f802e6e24376f9ce367c422764d91f6c0f26a039f6 6055 serf_1.1.0-1.diff.gz 431914fc85d3c0e12aaeb6416fe3eff86051401ab4820dd9d01117da30ec3ccf 46630 libserf1_1.1.0-1_amd64.deb 71d24dea7e7b394f1ff9f3c30a46547f7acd86b752cb46cf1493fb35d4c5f654 84060 libserf-dev_1.1.0-1_amd64.deb eb7109810c0d637efee229ca2693a176397d02f2eb1cd4568b4f009410892398 8796 libserf1-dbg_1.1.0-1_amd64.deb Files: e34fafe52169bf252f6b76db441288da 1167 libs optional serf_1.1.0-1.dsc a6b52340f38022dd69d649ed13790fa2 217855 libs optional serf_1.1.0.orig.tar.gz 5eade7fe3ce71e0672d86b048b130099 6055 libs optional serf_1.1.0-1.diff.gz fa74487b445437f60b4c16b1728ef957 46630 libs optional libserf1_1.1.0-1_amd64.deb cc81d74e3b27e9a712594503013d23d3 84060 libdevel optional libserf-dev_1.1.0-1_amd64.deb 80c92fb45cfbe8e58a5e466eb3827abf 8796 debug extra libserf1-dbg_1.1.0-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFP0ZRuXk7sIRPQRh0RArEdAKDIIhcFfrOYMtpnUgj6I+r5ZOeFYgCcD0yS K3WLDM92GwhFmlndGeTBaAs= =dRwV -END PGP SIGNATURE- Accepted: libserf-dev_1.1.0-1_amd64.deb to main/s/serf/libserf-dev_1.1.0-1_amd64.deb libserf1-dbg_1.1.0-1_amd64.deb to main/s/serf/libserf1-dbg_1.1.0-1_amd64.deb libserf1_1.1.0-1_amd64.deb to main/s/serf/libserf1_1.1.0-1_amd64.deb serf_1.1.0-1.diff.gz to main/s/serf/serf_1.1.0-1.diff.gz serf_1.1.0-1.dsc to main/s/serf/serf_1.1.0-1.dsc serf_1.1.0.orig.tar.gz to main/s/serf/serf_1.1.0.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1scsmt-0001zy...@franck.debian.org
Accepted gpm 1.20.4-5 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 08 Jun 2012 11:20:49 -0500 Source: gpm Binary: gpm libgpm2 libgpm-dev Architecture: source amd64 Version: 1.20.4-5 Distribution: unstable Urgency: medium Maintainer: Peter Samuelson pe...@p12n.org Changed-By: Peter Samuelson pe...@p12n.org Description: gpm- General Purpose Mouse interface libgpm-dev - General Purpose Mouse - development files libgpm2- General Purpose Mouse - shared library Closes: 645278 653036 658143 Changes: gpm (1.20.4-5) unstable; urgency=medium . [ Peter Samuelson ] * Tweak debian/rules to pass the right CC into configure. Thanks Kyle Moffett. (Closes: #645278) * Add Polish debconf translation, thanks Michał Kułach. (Closes: #658143) * Fix watch file. * Drop long-obsolete libgpmg1-dev dummy package. * A few tweaks to rules and control files. . [ Stefan Lippers-Hollman ] * Fix kernel detection for kernel =3 (Closes: #653036). - patches/090_linux3_versions: New patch: also fix gpm-root.y for kernel 3.x version scheme. Checksums-Sha1: cf06795d525787bccbf600d4c8dffe0948358999 1179 gpm_1.20.4-5.dsc 0de82bc56a023de3ee751d99b2deeff43894d563 92597 gpm_1.20.4-5.diff.gz f3d863e4b3778118b2dda658a740e6d1c8211394 233768 gpm_1.20.4-5_amd64.deb 5d3d6f7b20ba1b0f67da12dea899fc02448408d2 35858 libgpm2_1.20.4-5_amd64.deb 31e1c2068fed89d29b6873adab4a75bfea262d80 40014 libgpm-dev_1.20.4-5_amd64.deb Checksums-Sha256: cd4dd37faddb9facaa8cbb6af453945966c2b5b9cbf1e72b66507d57d670a5c7 1179 gpm_1.20.4-5.dsc 5185de424123d75ac8b9970830681ec0a024077deaac333b84bbf7302bae11a7 92597 gpm_1.20.4-5.diff.gz e8e99d7f861b0042323df4b6775c112980209d532f9f2cd6f4e3f607563b0760 233768 gpm_1.20.4-5_amd64.deb d9df450480fdd3239ccbe6f69b64b1c024f216825a30a12e892833836a7ec10a 35858 libgpm2_1.20.4-5_amd64.deb 37c9f63e95cc600f067e8caf870a8ea569d21427735b36610003fd78a558fbe2 40014 libgpm-dev_1.20.4-5_amd64.deb Files: 2f344d9db343a1f990bdcaae75599d52 1179 misc optional gpm_1.20.4-5.dsc 627a6e9f2d5b31f7a32f79a1874cc753 92597 misc optional gpm_1.20.4-5.diff.gz e56f1e8cc15a936f1a23049e5c7ed372 233768 misc optional gpm_1.20.4-5_amd64.deb 9b9cb5d6508c3f0ef485e2972cfe32a3 35858 libs standard libgpm2_1.20.4-5_amd64.deb 6bfc047ef66a43c837874005260a6b04 40014 libdevel optional libgpm-dev_1.20.4-5_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFP0i1nXk7sIRPQRh0RAsJNAJ96itXgzJdPC08prT68s972vHDYnACfQ/d2 0WdZGxwH2/b5jr3IbuREUlM= =oEQr -END PGP SIGNATURE- Accepted: gpm_1.20.4-5.diff.gz to main/g/gpm/gpm_1.20.4-5.diff.gz gpm_1.20.4-5.dsc to main/g/gpm/gpm_1.20.4-5.dsc gpm_1.20.4-5_amd64.deb to main/g/gpm/gpm_1.20.4-5_amd64.deb libgpm-dev_1.20.4-5_amd64.deb to main/g/gpm/libgpm-dev_1.20.4-5_amd64.deb libgpm2_1.20.4-5_amd64.deb to main/g/gpm/libgpm2_1.20.4-5_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1sd2ah-0005sx...@franck.debian.org
Re: ${misc:Depends} injects broken versioned depends (Was: Bug#676455: gnumed-doc: uninstallable in sid: depends on outdated libjs-jquery-livequery)
[Raphael Hertzog] It the next upstream version of your javascript library provides new files, they will not be in the symlink tree that you built in your package. So at runtime, it will fail because of the missing file. Forgive me if I'm missing something basic here, but this sounds like a job for a dpkg trigger. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120607143138.ga...@p12n.org
Accepted subversion 1.6.17dfsg-4 (source all kfreebsd-amd64 kfreebsd-i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 03 Jun 2012 17:54:15 -0500 Source: subversion Binary: subversion libsvn1 libsvn-dev libsvn-doc libapache2-svn python-subversion subversion-tools libsvn-java libsvn-perl libsvn-ruby1.8 libsvn-ruby Architecture: all kfreebsd-amd64 kfreebsd-i386 source Version: 1.6.17dfsg-4 Distribution: unstable Urgency: medium Maintainer: Peter Samuelson pe...@p12n.org Changed-By: Peter Samuelson pe...@p12n.org 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 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.6.17dfsg-4) unstable; urgency=medium . * Ack NMU, thanks Ondrej. Urgency medium because the NMU fixes RC bugs. - Revert libsvn-java split. Instead, disable multiarch for libsvn-java. If anyone _needs_ multiarch for Java libraries, which I doubt, we should come up with a way to produce deterministic jar files. - Reintroduce specific db dependencies, so a random binNMU can't change the DB version without warning. * Disable serf support for now, as this release won't properly work with serf 1.0. * patches/g++47: New patch to build with g++ 4.7. * Policy 3.9.3 (no changes). * Move ruby files to /usr/lib/ruby/vendor_ruby per ruby policy. Checksums-Sha1: 7017b2d914bd4333a6aa5b419645112ba96aa0c7 2265 subversion_1.6.17dfsg-4.dsc 133c6250d69e3a53cd8bc16d834eb3a430f063b8 107489 subversion_1.6.17dfsg-4.diff.gz c12df81d6724c0e839108c87ae5dfd2c4a4e5bfd 1991020 libsvn-doc_1.6.17dfsg-4_all.deb cdfd4cd9d2f23e86b33e9379a7ed6c105d676671 224258 subversion-tools_1.6.17dfsg-4_all.deb 0e62dea0724aaa8259813f3618b3cc9fe012c14e 758 libsvn-ruby_1.6.17dfsg-4_all.deb dc861861f2bea92667c837827fa162c8ed9398fd 1315850 subversion_1.6.17dfsg-4_kfreebsd-amd64.deb 4a5d13fdfaba127f0f36d87dc4c818389970cd96 933514 libsvn1_1.6.17dfsg-4_kfreebsd-amd64.deb c4cacc0f7f4f06d6d45dbeb6a6344fd9f9d08b2d 1418498 libsvn-dev_1.6.17dfsg-4_kfreebsd-amd64.deb cc93aead23e78b559de89e981ed2638cf9a0f28a 172596 libapache2-svn_1.6.17dfsg-4_kfreebsd-amd64.deb 314e1224d6687d1a8c2efa92fc2a65fe2d476dc5 1340966 python-subversion_1.6.17dfsg-4_kfreebsd-amd64.deb 1c61c153abab724f6329abcb187fcdbeaf7a9812 305494 libsvn-java_1.6.17dfsg-4_kfreebsd-amd64.deb 2933f4258bf01d8e7e0854eb6a5e93ee82b62992 1081802 libsvn-perl_1.6.17dfsg-4_kfreebsd-amd64.deb e863d2d6fdc4c9845b5f9c1e6c393c235629e367 627950 libsvn-ruby1.8_1.6.17dfsg-4_kfreebsd-amd64.deb 1fc40057a8a90dd04f954ef440018e7da464dbd6 1311968 subversion_1.6.17dfsg-4_kfreebsd-i386.deb dd1921762c28bca2b95cd59d88d16362e1e7270c 947496 libsvn1_1.6.17dfsg-4_kfreebsd-i386.deb fce889c55e47a8dff48f2e886683bb9b3eb3b96c 1347982 libsvn-dev_1.6.17dfsg-4_kfreebsd-i386.deb 9ab210b3dc930ffd474ac6e0ee2923b23bbf 172494 libapache2-svn_1.6.17dfsg-4_kfreebsd-i386.deb b668595dec73cd07e024f63e548b8fb51f4fe719 1239402 python-subversion_1.6.17dfsg-4_kfreebsd-i386.deb d7f058bc1e6b410401a482b93ba1d2bbd8203b68 306934 libsvn-java_1.6.17dfsg-4_kfreebsd-i386.deb dd6aef2b86ef7b4d1780a40fab3262db07b2dfe3 1012308 libsvn-perl_1.6.17dfsg-4_kfreebsd-i386.deb 9781c2a0ceef7b801449b8617c207d45218a4928 584570 libsvn-ruby1.8_1.6.17dfsg-4_kfreebsd-i386.deb Checksums-Sha256: c0209bdeaa24f949ac030f5866a9e4280217db5203fbb67d57ab8ab5dce9a046 2265 subversion_1.6.17dfsg-4.dsc 7c7f4a27a7f19d5ad1dc74139ffde70d76acc9ee1b69526a3368c339a4696627 107489 subversion_1.6.17dfsg-4.diff.gz bf94f29d9a0e0e14328c5945d04a97db0c680ab9a886104667ccb4a9b2c4ea9b 1991020 libsvn-doc_1.6.17dfsg-4_all.deb 80170d0597447d444c43c20088c4deab83fc5e62ef01a8db0b7d2274e133b5d5 224258 subversion-tools_1.6.17dfsg-4_all.deb 584c1f451d11af6817f29923ea8056f8cef39af199d7256a446b896031684c3b 758 libsvn-ruby_1.6.17dfsg-4_all.deb 62d8aeb2c000af8e167efedd301165dc639b52d7f70b1f5cc9e8ea7008d8270d 1315850 subversion_1.6.17dfsg-4_kfreebsd-amd64.deb f9d5a487cdc0c94dcb7b7dbb7951ba13bc225a8ef3c78d9b79e544d3e879369d 933514 libsvn1_1.6.17dfsg-4_kfreebsd-amd64.deb be0a39aa5c0f99eadce2252f66981debbfbb257a4e84d72c2e489f51994bb4df 1418498 libsvn-dev_1.6.17dfsg-4_kfreebsd-amd64.deb daee0a831e2b5bd3ffd43bc9ee566b56f8f1df3bfb20c9d52e96de6ef5b87292 172596 libapache2-svn_1.6.17dfsg-4_kfreebsd-amd64.deb d641fa915b83e343eaf0dc154b8965121cd7c206e68a14fd17bc8ca33a0d545c 1340966 python-subversion_1.6.17dfsg-4_kfreebsd-amd64.deb cd64d76ba999146c6b02ab4d17d02111767aee0ad024ee9b5a3a7830109daed6 305494 libsvn-java_1.6.17dfsg-4_kfreebsd-amd64.deb
Re: Exported (ba)sh functions in the environment
[Philip Ashmore] On my machine running set set.txt ls -lsa set.txt reveals that my environment contains 225517 of stuff - some of it is even being taken up by exported function definitions! As mentioned earlier, 'set' is not reporting much more than the environment exported to external processes and scripts. Observe: $ set | wc -c 189097 That's my interactive bash session, including a huge chunk from bash-completion. But... $ env | wc -c 792 That's all that actually gets exported to external processes, including shell scripts. $ sh -c set | wc -c 908 $ sh -i -c set | wc -c 908 That's dash, including the 792 bytes of exported environment noted earlier. Interactive mode (-i) seems to make no difference. $ bash -c set | wc -c 1371 $ bash -i -c set | wc -c 189101 ...and that's bash, which does a bit more at startup than dash. Interactive mode (-i) enables bash-completion and other stuff. Big difference! But probably no shell scripts ever run in interactive mode. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120528181744.gb3...@p12n.org
Re: Exported (ba)sh functions in the environment
[Philip Ashmore] I guess I'm confused as to why bash completion needs these. Easy enough to read /etc/bash_completion and /etc/bash_completion.d/* and see for yourself why it needs these. bash-completion is full of special cases to do the right thing in hundreds or thousands of different circumstances. If it were as simple as offer a list of filenames when you hit tab, that's already built in to bash and we wouldn't need bash-completion as a separate package. As a _very_ simple example, if you type 'kill tab', you get a list of current process IDs. If you type 'kill -tab', you get a list of signals, plus the common options -l and -s. If you can think of a way to implement this same stuff (and remember, bash-completion supports a _lot_ more complex cases than 'kill') without adding 200 kB of shell functions to bash's runtime, by all means, do it and see how it works out. Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120528194448.gc3...@p12n.org
Re: Moving /tmp to tmpfs makes it useless
Switch to the deadline IO scheduler [...] and make proper use of cgroups. [...] And disable memory overcommit [Serge] instead of fixing a single default option you suggest every debian user to tweak and/or rebuild the kernel? Are you serious? ;) What?!? and/or rebuild the kernel is FUD. /proc/sys/vm/overcommit_memory has been tweakable at runtime for almost as long as I can remember (at least Linux 2.4, possibly earlier). The tweak is: # echo vm.overcommit_memory=2 /etc/sysctl.conf # sysctl -p -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120525152520.ga3...@p12n.org
Re: Wheezy release: CDs are not big enough any more...
[Steve McIntyre] You're not measuring the time taken to sync to the flash drive either, so all you're going to be seeing is the speed of writing to cache. Huh, I figured the 'sync' call at the end of each test run covered that. I've done lots of work with USB flash and MMC/SD cards over the last few years, and the best results are typically achieved using dd bs=4M oflag=sync. That way, you'll normally get nicely-aligned date writes big enough to cover the internal flash page size and remove the horrendous effects of read-modify-write cycles. Not noticeable in my test runs, so maybe I have an abnormal flash disk. (The fact that it has a USB interface, rather than something closer to the flash controller, probably makes a difference.) Anyway, I've never been against people recommending things like dd bs=4M oflag=sync when writing to disk media. My pet peeve is when people recommend dd but without any options other than if= and of=. It is clear that many such people don't have a clue _why_ they use dd, except an irrational, dare I say cargo-cult, aversion to cp with block devices. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120516220409.gg2...@p12n.org
Re: big .debian.tar.xz - EG Wordpress
[Russell Coker] Would it be possible to have somewhere on the Debian servers for storing such files so that they can be referenced in a README file or something rather than sent to everyone? I'm sure that most people who build a Wordpress package won't use them. As Paul Wise said, best if we _do_ build things from source rather than relying on upstream binaries. But beyond that, if there is to be a separate place to put all the WordPress source we want to provide but you probably don't really need, for GPL reasons, it needs to be on all the mirrors alongside the source package you _do_ install. Not on some other website. So I guess that brings us to a .dsc that can reference multiple upstream tarballs (already possible, of course) but mark them such that by default you only download or unpack _some_ of the tarballs. The other option of course is to split wordpress into two source packages, and move all the users probably don't ever need to rebuild this stuff into the second source package and its corresponding binary package, which regular wordpress can depend on. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120516222407.gh2...@p12n.org
Re: Wheezy release: CDs are not big enough any more...
[Steve McIntyre] (http://www.debian.org/releases/stable/amd64/ch04s03.html.en) While it is refreshing to see cat debian.iso /dev/sdX instead of the usual dd nonsense (it seems there's an extremely widespread myth that you need to use dd any time you're reading or writing block devices), I think cp is even more straightforward. Bonus: you can easily run it with sudo. (sudo cat debian.iso /dev/sdX does not do what a novice might think.) Though I suppose it might be annoying to those who feel the need for alias cp='cp -i' in .bashrc. But hey, it's their choice to be annoyed by things like this. (: -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515174055.gd2...@p12n.org
Re: Wheezy release: CDs are not big enough any more...
[Samuel Thibault] I think cp is even more straightforward. Does cp accept that way since a long time? I'm not sure, but I've been using things like cp boot.img /dev/fd0 for probably 10 or 15 years on various Linux and Unix systems. (The fact that I referred to a floppy drive may give some idea of how long) I am not sure where the idea came from that reading or writing block devices always requires 'dd', but if I were to guess, I'd say we can blame tape drives (which aren't even block devices, but char devices). As I recall, you can choose the block size when you format or write a tape, and maybe there are ancient systems out there in which userspace must be explicit when reading and writing them. (Normally, though, I _think_ you just tell the kernel tape driver the right parameters using, e.g. 'mt', then let it handle writing full blocks.) Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515230005.ge2...@p12n.org
Re: Wheezy release: CDs are not big enough any more...
[Steve McIntyre]
The major win with dd onto a raw device is that you can specify the
block size. For most USB sticks, using a block size of 4MB or so is
going to be *much* faster than using the default for dd (512 bytes)
or cp (10 KB IIRC).
That seemed a little fishy to me, since none of the above commands do
any fsync by default, so I just benched it locally.
Writing a 50 MB businesscard image to a USB flash drive on my system
(numbers are MB/s):
dd bs=512 1.771.781.77
dd bs=1024 1.791.761.77
dd bs=2048 1.771.781.78
dd bs=4096 2.542.532.51
dd bs=8192 2.482.502.55
dd bs=4194304 2.502.502.54
cp 2.492.472.48
So it appears that if you aren't going to specify a bs= parameter here,
there's no point in using dd, unless you just happen to think its
command line syntax is particularly charming. And even if you do
specify bs=, you'll only barely beat cp.
For completeness, the same test writing a small file (1 MB),
unsurprisingly, is quite inconclusive:
dd bs=512 1.441.040.98
dd bs=1024 1.001.061.04
dd bs=2048 0.821.041.05
dd bs=4096 1.301.311.35
dd bs=8192 1.061.521.56
dd bs=4194304 1.191.281.27
cp 1.141.291.27
--
Peter
#!/bin/sh
infile=/tmp/debian-6.0.2.1-amd64-businesscard.iso
MB=$(stat -c'scale=2; %s/1048576' $infile | bc)
outfile=/dev/sdd
test_start () {
label=$1
sudo sysctl vm.drop_caches=1 /dev/null # probably not really needed
t0=$(date +%s.%N)
}
test_end () {
sync
echo $label : $(echo scale=2; $MB / ($(date +'%s.%N') - $t0) | bc) MB/s
}
for n in $(seq 1 3); do
for sz in 512 1024 2048 4096 8192 $((1024*4096)); do
test_start bs=$sz
dd bs=$sz if=$infile of=$outfile 2 /dev/null
test_end
done
test_start cp
cp $infile $outfile
test_end
done
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120516020029.gf2...@p12n.org
Re: RFC: OpenRC as Init System for Debian
[Uoti Urpala] The reason why most old applications do not follow that approach (at least not yet) is pretty obvious: their authors never considered it. etc-overrides-lib semantics have only become a seriously considered alternative fairly recently. If I'm not mistaken, I first saw this sort of arrangement in CDE, circa 1998. Maybe that's considered recent. Sure, nobody's heard of it anymore, but it was pretty widespread back in the day. There were a lot of things I didn't like about CDE, and this was one of them. From your following text it seems you mean the comparison between 1) criticizing Red Hat for (allegedly) letting packaging system limitations affect the choice of configuration format and 2) saying Debian should choose its preferred configuration format based on the limitations of its packaging system That's ... a misleading way of looking at it. There is a tension between minor upgrades and major upgrades. 1. Major upgrades: default config may change noticeably, and a custom config forked from the default may need to be updated to work optimally or even correctly. - Red Hat apparently has no reason to care about this case, if they don't support major upgrades at all. - This is where copy to /etc can be bad. It's not trivial for the packaging to determine that the local copy needs attention, either to handle it automatically, or to alert the local admin. 2. Minor upgrades, or reinstall: default config rarely changes, and does not change incompatibly. E.g., a security upload. - Red Hat _does_ need to support this case. - This is where copy to /etc works. It prevents the packaging system from overwriting your local config changes. - Apparently RPM packaging and tooling has a history of overwriting local config changes. I don't know the details. But if true, copy to /etc would seem like an attractive workaround. - However, Debian's packaging has had policy and tooling to avoid overwriting local changes for about 20 years, so it should not be surprising that we don't see much upside here, only the downside (mentioned in point 1). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120510190217.gc2...@p12n.org
Re: Node.js and it's future in debian
[David Weinehall] So... A (admittedly expensive) pre-inst script that checks the system for calls to /usr/sbin/node outside of Debian packages would likely do the trick? That seems like a pretty big violation of the spirit, and possibly the letter, of Debian Policy. I mean, why not just tell users Yeah, if you install both of these node packages, and you try to run node.js with /usr/sbin is in your path, you might not get what you expected. That violates the spirit of Policy too, and it's a lot simpler. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120503214609.ga2...@p12n.org
Re: smaller than 0 but not negative (Re: question about Conflicts:
[Patrick Lauer] 1.0_pre20120503 maybe That'd be wrong if you expect a real _alpha, _beta or _pre of the given version in the future. I think in that case you'd need something like 1.0_alpha_alpha20120503 or 1.0_alpha_pre20120503. There's something to be said for imposed structure, but in this case I'd have to side with the more general and flexible ~ syntax. And yeah, pretty happy to see rpm adopt it now too. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120503222900.gb2...@p12n.org
Re: upstart: please update to latest upstream version
[Josh Triplett] To give one particular example: systemd uses Linux-specific features to accurately track all the processes started by a service, which allows accurate monitoring and shutdown of processes which could otherwise disassociate themselves from their parent processes via the usual daemonizing trick. This one particular example is the same feature (cgroups) that everyone keeps talking and talking about. Everyone keeps saying systemd uses Linuxisms like cgroups, but nobody mentions any others. Is this the only major Linuxism in systemd, or is it just the only one that's interesting enough to talk about? I ask because, if porting systemd to kFBSD is a mere matter of emulating cgroups with jails (from what I understand, jails provide roughly a superset of cgroups functionality), that's a somewhat different picture than I've been assuming. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120307011145.gg2...@p12n.org
Accepted serf 1.0.1-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 25 Feb 2012 14:43:53 -0600 Source: serf Binary: libserf1 libserf-dev libserf1-dbg Architecture: source amd64 Version: 1.0.1-1 Distribution: experimental Urgency: low Maintainer: Peter Samuelson pe...@p12n.org Changed-By: Peter Samuelson pe...@p12n.org Description: libserf-dev - high-performance asynchronous HTTP client library headers libserf1 - high-performance asynchronous HTTP client library libserf1-dbg - high-performance asynchronous HTTP client library debugging symbo Changes: serf (1.0.1-1) experimental; urgency=low . * New upstream release. - patches/bind_address_family: Delete, applied upstream. * Delete obsolete lintian override (workaround for an old lintian). Checksums-Sha1: 0ba3b6dccda5ef39118a0bf9be9ba6898fc54aeb 1167 serf_1.0.1-1.dsc 99f0f4d0d39359f5f4dccfc1fc92dfe7352d4d6a 219798 serf_1.0.1.orig.tar.gz 980e28513c4791643162eb84fe31f3af19f9bf00 5964 serf_1.0.1-1.diff.gz b90f33207d04701bd0d70add5ee3896ec4088324 48014 libserf1_1.0.1-1_amd64.deb fbfdfbcdb71c8135103ea81c6b5b4d7613f88f6e 85554 libserf-dev_1.0.1-1_amd64.deb f0d451f6dd0a87ba9badaaaf812e06154ac79cb5 98134 libserf1-dbg_1.0.1-1_amd64.deb Checksums-Sha256: 5c3404f1cc1c5e205667a1a44b21c13c04b2ac9644b6fe63438ad91d5c958576 1167 serf_1.0.1-1.dsc 42a19b7195a581de063a0cd1faf64773e3d816324caa618bc5ae89585b4db941 219798 serf_1.0.1.orig.tar.gz 02b9f3230c28c0003471b4123df24c5959c3fb5d79ef152b0bd25d27be177fb2 5964 serf_1.0.1-1.diff.gz d48c84642a08ab7bdfc7b0025ccbf6551f5a324fc0c37c0335115909dc714561 48014 libserf1_1.0.1-1_amd64.deb 4ad1f8ef1ef46fbdfbe049a27ffdd3d9512bea891f47fb1a86a26822018e3642 85554 libserf-dev_1.0.1-1_amd64.deb f4779b8e65654e7a7e081a38a912ced1eb058f6f95688d8cdaa205eb225d3d13 98134 libserf1-dbg_1.0.1-1_amd64.deb Files: 4edf7001a10e14bfa064c745ce1b4626 1167 libs optional serf_1.0.1-1.dsc cd511518ecea59cf536783714594a025 219798 libs optional serf_1.0.1.orig.tar.gz eebd50ce7b376d8a705ecfe3ed8791f3 5964 libs optional serf_1.0.1-1.diff.gz 172b9ec520015b1dcab42d424204ae60 48014 libs optional libserf1_1.0.1-1_amd64.deb 38c35106ed50930ec46d719bd7891cf5 85554 libdevel optional libserf-dev_1.0.1-1_amd64.deb 7be72b6b5622984cbcff009ba08960e9 98134 debug extra libserf1-dbg_1.0.1-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFPUn7dXk7sIRPQRh0RAiUcAKCl8pR/h5qnntC4d33gO7YBpBSZPQCghX7x 1Y/f+ZZYUy3bk28587gruBs= =AdRV -END PGP SIGNATURE- Accepted: libserf-dev_1.0.1-1_amd64.deb to main/s/serf/libserf-dev_1.0.1-1_amd64.deb libserf1-dbg_1.0.1-1_amd64.deb to main/s/serf/libserf1-dbg_1.0.1-1_amd64.deb libserf1_1.0.1-1_amd64.deb to main/s/serf/libserf1_1.0.1-1_amd64.deb serf_1.0.1-1.diff.gz to main/s/serf/serf_1.0.1-1.diff.gz serf_1.0.1-1.dsc to main/s/serf/serf_1.0.1-1.dsc serf_1.0.1.orig.tar.gz to main/s/serf/serf_1.0.1.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1s3wqc-pi...@franck.debian.org
Re: upstart: please update to latest upstream version
On Freitag, 24. Februar 2012, Karl Goetz wrote: Contributors *to upstart* need to agree to the canonical contribution agreement, I'm not sure what gives you the idea that all daemon maintainers will fall in that category. [Holger Levsen] still. a blocker. Eh, it's only a problem if the upstart maintainers in Debian refuse to accept work (via either BTS patches, or done directly by comaintainers) that upstream will not also accept. This position itself seems incompatible with the belief that upstream was not interested in non-Linux portability patches. If upstream is expected to refuse certain patches needed for kFreeBSD, there's no point in caring about the fact that they will _also_ refuse certain patches because they require signed contributor agreements. Also, the only practical way this differs from the situation with software from either the Free Software Foundation or the Apache Software Foundation seems to be that, oddly, more people think Canonical is evil than think the FSF and ASF are evil. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120224185015.gf2...@p12n.org
Re: Multi-arch all-architecture plugins
[Goswin von Brederlow]
Except is gimp the only way to use gimp plugins? Isn't there another app
foo that also uses libgimp and its plugins? Then you could have
gimp:amd64, foo:i386.
Actually ... if I remember correctly, gimp plugins are executables, not
libraries, so really they should be M-A: foreign. So, not really
relevant to this discussion after all.
So Multi-Arch: same-as glibc-2.13-1 would be fine. Even Multi-Arch:
libc would be fine (if it is provided).
The problem with M-A: same-as glibc-2.13-1 is that it means you need to
binNMU (or even source NMU) every nss plugin for every major glibc
release. So, it would be nice to use something more generic. But, at
the moment, libc's only Provides is glibc-2.13-1.
I like both the same-as and the Recommends idea. I don't like the
idea of using the M-A field for same-as. There could be plugins with
M-A:same as well as M-A:allowed semantic (e.g. a plugin enabling some
scripting support like perl for irssi), maybe even M-A:foreign.
But only M-A:same has the problem we are trying to solve, namely: if
this module is installed on amd64 we want it to also be installed on
i386. With M-A:{allowed,foreign}, there is no question of which
architectures, since you can only install one.
So I don't see a problem overloading the M-A header. I'd rather see
that than a second header that is only used in this one case that
always involves M-A:same.
Now the exact syntax is a bikeshedding issue. My original idea was
M-A: same-as libfoo but perhaps something like M-A: same [libfoo]
or M-A: same: libfoo or even M-A: same: libc6, libc6.1, libc0.1...
Finally, I note that this is somewhat similar to Enhances. But I don't
think it's a good idea to overload Enhances.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120215181932.ge2...@p12n.org
Re: Multi-arch all-architecture plugins
[Ian Jackson] If you install on i386 your 2 binaries and libc6, you /do/ need the i386 libfakeroot. Otherwise if you say fakeroot your binary it won't work, no matter that /usr/bin/fakeroot is amd64. libfakeroot is something of a special case, indeed. As a hack to my proposal, perhaps it can be 'M-A: same-as libc-dev'? I know it's potentially useful beyond development, but in practice, it seems to be almost entirely used for development. Whereas if you have gimp installed you /either/ have the amd64 or the i386 version, and all your gimp plugins need to be the same architecture. [...] And indeed the plugin itself need not have a multi-arch field because it doesn't need to be coinstalled with other arches. Right, so gimp plugins aren't really an interesting case. Package: libsasl2-modules Multi-Arch: same-as libsasl2-2 Would it matter if the list of sasl modules installed was different on different architectures ? Would that mean that i386 sasl-using applications would have different sasl capabilities or would it cause libsasl not to start up due to missing plugins ? The first. It's similar to the PAM modules case. Different apps would have different capabilities. This doesn't _necessarily_ have security implications, like getting your PAM modules out of sync, but it's still something you would not do on purpose, and as such, best if we can prevent it with infrastructure. [Bernhard Link] Would this also work with nss plugins? That might be a bit more complicated as it would be libc6 on most architectures, but libc6.1 or libc0.1 on others. True. It would probably need to use a virtual package, like 'glibc-2.13-1'. This might not be a good solution, though, as apparently the NSS ABI has a wider span than the ABI promised by the glibc virtual package name. Ideal (for my purposes here) would be if glibc could provide a virtual package indicating the NSS ABI, akin to 'perlapi-5.10.0'. Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120214214634.gd2...@p12n.org
Re: Multi-arch all-architecture plugins
[Ian Jackson]
Where should this fact be declared ? Is it a property of a package
that it makes sense to install it only on all configured architectures
or none ? Or is it a property of the dependency from the depending
package ?
Neither. If I've configured i386 on an amd64 system just to install 2
binaries and libc6, but on amd64 I've installed, say, a gimp plugin, I
don't want to have to install, on i386, not only this same plugin but
also libgimp and its dependency tree, including the whole Gtk stack.
s
What we really want to express is: {this package}, if installed, should
have the same list of architectures as {that package}.
E.g., pam modules should be installed on the same architectures that
need libpam0g. Thus, all architectures for which you've installed at
least one daemon that uses pam, will have the same plugins.
The same argument works for many other plugin situations I can think
of; in each case there's a (presumably M-A: same) base library
package that you could say, if that package is installed for a given
arch, the associated modules should match.
Package: libpam-fprint
Multi-Arch: same-as libpam0g
Package: gimp-texturize
Multi-Arch: same-as libgimp2.0
Package: libsasl2-modules
Multi-Arch: same-as libsasl2-2
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120214053211.gc2...@p12n.org
Re: Linux 3.2 in wheezy
[Brad Spengler] Frankly it makes more sense for me to offer .debs myself than to deal with a bureaucracy and non-standard kernel in Debian. It contains who-knows-what extra code, and I doubt anyone looked at any of it to see if it allows for some way to leak information I prevent against a vanilla kernel, or a way to bypass any other existing protection. I hope you aren't complaining that the Debian kernel team doesn't include your patch, and also complaining that Debian kernel team includes too many patches, in the same email. Probably that isn't what you tried to say, but that's kinda what it sounded like. Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120130154049.ga2...@p12n.org
Re: Source package without a binary
On 05/01/2012 18:26, Joachim Breitner wrote: So the logical conclusion is to build a binary package from the source that contains nothing (or maybe a log of the test results) and clearly states in its description that there is no point in installing this binary package. Is this something that we want to allow? [Jean-Christophe Dubacq] You could build a binary package that just contains one file (the test suite log, maybe?). This way, anyone could check that the test suite was passed by the version of ghc being compiled by installing the binary package. Yeah, that's pretty much what he already said. What he's asking is whether this is actually a good idea, or whether there are better options. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120105232427.ga12...@p12n.org
Re: Getting dh_install to do what we need
[Kees Cook] This doesn't work with source-format-1 packages without adding chmod lines for the scripted debhelper config files in the rules file. Perhaps this isn't a big deal since we should all be using source-format-3 anyway. We should? I prefer to think of this whole debacle as yet another reason to never switch to format 3. So long as I stay with format 1, features like this one will never come back to bite me. (Well, yes, it could still happen to me with native packages. But that's a much smaller attack surface than if I used format 3.) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111209105857.gb3...@p12n.org
Re: Getting dh_install to do what we need
[Bernd Zeimetz] So there are sources which have executable debhelper files already? I doubt it as you'd have to chmod them manually. Not for native packages. Not for packages in format 3.0 (quilt). In both cases, execute permission in debian/ is preserved, with the obvious exception of debian/rules, for which dpkg-source forces the +x bit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111209182117.gc3...@p12n.org
Re: suggestion: build-blockers field in control file
[Russell Coker] Why not have software which wants to have the dependencies of a package look at the dependencies line as well as the build-dependencies? It seems to me that the package maintainers are already providing the necessary information and the people who maintain autobuilder systems just need to use it. H. Do you mean: (1) The buildd should parse debian/control prior to building, and delay the build (dep-wait) if any binary package Depends line would not (yet) be satisfied? (2) The buildd should not upload a build until every binary package in the built .changes file is installable? (3) The buildd should edit the .changes file to exclude binary packages that are not installable, upload _that_, then put the rest of the binary packages in some sort of hold queue? (4) ??? (1) is problematic for several reasons; most specifically, that it is possible, and even common, for not every package in debian/control to be built on every architecture. You can't predict which packages will actually be built. (2) is less problematic, but does introduce extra delay into package build and propagation. It also would require manual intervention for any dependency loop. And (3) seems like a very complex workflow to solve a very small problem. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111202081023.ga3...@p12n.org
Re: Increasing minimum 'i386' processor
[Goswin von Brederlow] Where the relevant patches added to binutils and gcc for this? See for yourself: http://sites.google.com/site/x32abi/ -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2023122412.gf2...@p12n.org
Re: Towards multi-arch: Multi-Arch: same file conflicts
[Jakub Wilk]
If a package is marked as Multi-Arch: same, files with the same
name have to be (byte-to-byte) identical across all architectures.
Unfortunately, not all packages obey this requirement.
[libsvn-java 1.6.17dfsg-2+b1]
usr/share/java/svn-javahl.jar
This file is in a package that also contains some JNI, so it is
Architecture: any. I could split the JNI and jar into two packages,
but it really doesn't seem worth it, two packages, tightly coupled,
each with one small file.
Is it reasonable to build or repack a jar file deterministically?
Something like this, to normalize file timestamps and ordering?
mkdir TMP
unzip $jarfile -d TMP
find TMP -exec touch 19800101 {} +
(cd TMP; find | sort | xargs zip -9 ../TMP.zip {} +)
mv TMP.zip $jarfile
rm -fr TMP
Is this what I should do?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2020083449.gd2...@p12n.org
Re: Towards multi-arch: Multi-Arch: same file conflicts
[Goswin von Brederlow] Ugly, but if it works ... You only have those 2 choices for Multi-Arch: same: Split the package or make the files equal. Well, the third choice is to assume nobody _really_ cares about multiarch for JNI libraries, and just drop the Multi-Arch: header. Since you are building the jarfile somewhere in your source you could fix the place where it is created in the first place. But that probably means patching the upstream Makefile. The jar is created with the command 'jar cf $output -C $inputdir org' (where 'org' is the top level of the class name). The 'jar' from gcj-4.6, at least, packs the zip file in 'readdir' order. I tried repacking, but can't get zip to produce consistent output, even on a single platform. Looks like there's one byte per stored directory, and two bytes per stored file, that change on each 'zip' invocation. I'm testing with zip 3.0-4 on kfreebsd-i386. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2020183045.ge2...@p12n.org
Accepted subversion 1.6.17dfsg-3 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 19 Nov 2011 18:56:28 -0600 Source: subversion Binary: subversion libsvn1 libsvn-dev libsvn-doc libapache2-svn python-subversion subversion-tools libsvn-java libsvn-perl libsvn-ruby1.8 libsvn-ruby Architecture: source all amd64 Version: 1.6.17dfsg-3 Distribution: unstable Urgency: medium Maintainer: Peter Samuelson pe...@p12n.org Changed-By: Peter Samuelson pe...@p12n.org 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 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: 642250 Changes: subversion (1.6.17dfsg-3) unstable; urgency=medium . * libapache2.preinst: Fix upgrade case from before 1.6.17dfsg-2. * libapache2.prerm: 'a2dismod' modules in reverse dependency order. * patches/apache_module_dependency: New patch to allow mod_authz_svn to load before mod_dav_svn and still use its functions. All these together, Closes: #642250. * Remove a bit more autofoo in 'clean' target. Checksums-Sha1: fbdda3bfaef3af29fd445485dbbf92c3d6d9e623 2297 subversion_1.6.17dfsg-3.dsc fb809c4f1efac4dfd73e2d71f6fac161ac8f5047 105368 subversion_1.6.17dfsg-3.diff.gz 23d5f56e76158760969ef722708c2cd28a2d6ce7 2062432 libsvn-doc_1.6.17dfsg-3_all.deb 6c82b17363f9bfce21f7e65c614fd12f47e8d9b7 224774 subversion-tools_1.6.17dfsg-3_all.deb 05c4b7f156ef644cc1dd57e7128dadbed4fa5d1c 764 libsvn-ruby_1.6.17dfsg-3_all.deb ffd3bfa1374807ec3cb49c8727556656fee60d64 1321770 subversion_1.6.17dfsg-3_amd64.deb 6faeac25caa8e6a2f9412d6171033f5089d70373 996510 libsvn1_1.6.17dfsg-3_amd64.deb d717beefd31ca404f9238f814f1de03b0109e44c 1500674 libsvn-dev_1.6.17dfsg-3_amd64.deb 0d196d9b98391257c565abc9acc61affd1a2f25c 172762 libapache2-svn_1.6.17dfsg-3_amd64.deb 5eb6b7b0218063d3fb9bb030b0f411b36adaa553 1350680 python-subversion_1.6.17dfsg-3_amd64.deb 01809d6708b345b144fd2ce51aaa40d6ef6f550e 306978 libsvn-java_1.6.17dfsg-3_amd64.deb e934affc29c2eed0852bace9f2f3aacc5e3d2166 1014136 libsvn-perl_1.6.17dfsg-3_amd64.deb 6f85c59b8162692efb1dc2622fc7db57c72da598 627866 libsvn-ruby1.8_1.6.17dfsg-3_amd64.deb Checksums-Sha256: 7344c1e45d8594d981c95d2a8e19cb4011df1ef3492e705a67cbf50bd9531143 2297 subversion_1.6.17dfsg-3.dsc e88b740b94eeba913d277449fab39752b8a205609a363f93ebd80731992bc1c9 105368 subversion_1.6.17dfsg-3.diff.gz 763fc860f7b512651237ca26768994ded0d48b7c2a00181edb46a03176b062ed 2062432 libsvn-doc_1.6.17dfsg-3_all.deb 2a0ea4beade6536f3e3e2fcf8ecfa75a7aaf89978cabd4c1ca1abe71840d9bc9 224774 subversion-tools_1.6.17dfsg-3_all.deb 27b3ec2ffb12d88b49c0d4be2246b2243e6e23e730931e4dda2c7cf26a2704a9 764 libsvn-ruby_1.6.17dfsg-3_all.deb 5466e0c84beee4861fbaef5cd3be23bbe2d39481b5e4ddc6689c218e76f1868a 1321770 subversion_1.6.17dfsg-3_amd64.deb 9ca8b2fd5724dcbaba4764d20ada8e907dd94b4d95bd2ee07d30695444d38fb4 996510 libsvn1_1.6.17dfsg-3_amd64.deb 9240c8189916b51a4868990e10dca1e0f1b024431bd22fbfd490d25f75dcb13e 1500674 libsvn-dev_1.6.17dfsg-3_amd64.deb 0fc54a44ef9f48d5a425737b50e7a83299c4070fb82ede3a8089fee51efcb07a 172762 libapache2-svn_1.6.17dfsg-3_amd64.deb d2da43b2541183358eb8e640fc1dd66cb6d144bc4ebb0deb1265fc70c2ad530e 1350680 python-subversion_1.6.17dfsg-3_amd64.deb f5eaac18276c5ecfbaa4104393033874477bbdfd3bb1d3e5b6ee6b1f57457f38 306978 libsvn-java_1.6.17dfsg-3_amd64.deb e763a50011a2d4b5af4db053c0f08de4bbd6a43bf09cbf190af9ba04b735d268 1014136 libsvn-perl_1.6.17dfsg-3_amd64.deb ee5520908511ebe2ac15aadfa26b48d0370cb166097aa94c6a0dafad1ced1531 627866 libsvn-ruby1.8_1.6.17dfsg-3_amd64.deb Files: 67649be3ccb0d73fa4587ee8394abcf3 2297 vcs optional subversion_1.6.17dfsg-3.dsc bd516c80cd1d0136bf3c7e2c20d81f93 105368 vcs optional subversion_1.6.17dfsg-3.diff.gz abe2c03040346da6c0f5dcb7aa4d536d 2062432 doc extra libsvn-doc_1.6.17dfsg-3_all.deb d1338495b368d46fb0774c0e6c3cc21a 224774 vcs extra subversion-tools_1.6.17dfsg-3_all.deb 3f0c72e4f612e0f61d8e503e2c7263a1 764 ruby optional libsvn-ruby_1.6.17dfsg-3_all.deb a3557f0ceb28d3690303456aadf9e07e 1321770 vcs optional subversion_1.6.17dfsg-3_amd64.deb 9a0e7157821eb67b7ce570fc40ae9d17 996510 vcs optional libsvn1_1.6.17dfsg-3_amd64.deb a1436c71f8079dafab41beb4b91a7afd 1500674 libdevel extra libsvn-dev_1.6.17dfsg-3_amd64.deb c4c82029ffcd5473f69c9539b599072d 172762 httpd optional libapache2-svn_1.6.17dfsg-3_amd64.deb 7be39366d208e4fff95a37530d4501df 1350680 python optional python-subversion_1.6.17dfsg-3_amd64.deb 51f94c742ff4b81ef84d22adf7972bf0 306978 java optional libsvn-java_1.6.17dfsg-3_amd64.deb
Re: Towards multi-arch: Multi-Arch: same file conflicts
[Jakub Wilk] The most common reasons for cross-architecture differences appear to be (in random order): - Compiling GNU message catalogs with gettext, which uses native endianness (see bug #468209). Having read that bug log, it's not clear to me whether there's a consensus about what to do about these. Neil thinks we need native endian .mo (which is problematic for multiarch), others think we need .mo to be Arch: all and dont-care-endian. Has any consensus emerged? And is it worth splitting out a -l10n or -data package from a library just so the library itself can be M-A: same? (I suppose a side benefit is you can use Recommends and cut down a little on the size of your strict Dependency closure.) - BinNMUs (see http://deb.li/CHYh). So I guess we can ignore changelog.Debian.gz hits, as there's not much we can do about them. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2019053920.gc2...@p12n.org
Re: Package mailing lists (was: bits from the DPL for September 2011)
[Iustin Pop]
Could/should Debian make it easier for each package to have an own email
list (i.e. making it easier to have 1-person team maintenance)?
We have {pkg}@packages.debian.org and {srcpkg}@packages.qa.debian.org.
I don't know if mail to these aliases get archived, but at least it is
going through Debian infrastructure. The latter even, I believe, uses
proper list software.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2008232617.gb2...@p12n.org
Re: Minified files and source code requirement
[Russ Allbery] Compressing all the whitespace out of it seems fine to me; you can fix that well enough using an indenter. Yes, but why would _any_ obfuscator, I mean minimizer, compress whitespace but not remove comments? The cleverest re-intender in the world isn't going to be able to restore comments. Agree with the rest, including your formulation of source as _a_ reasonable form for modification in lieu of the classic GPL definition. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111027192936.ga2...@p12n.org
Re: python 2.7 in wheezy
[Olivier Berger] For users, which don't read d-d-a and receive such emails (below), it's a bit unclear what's really happening, IMHO :-/ Ummm ... don't we strongly encourage all package maintainers to read d-d-a? If not, we should. It is very low traffic and sometimes important. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111007004312.ga2...@p12n.org
Accepted equivs 2.0.9 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 30 Sep 2011 01:22:27 -0500 Source: equivs Binary: equivs Architecture: source all Version: 2.0.9 Distribution: unstable Urgency: low Maintainer: Peter Samuelson pe...@p12n.org Changed-By: Peter Samuelson pe...@p12n.org Description: equivs - Circumvent Debian package dependencies Closes: 409557 571638 624175 636310 Changes: equivs (2.0.9) unstable; urgency=low . * Upgrade to Policy 3.9.2 - no changes. * Upgrade to source format 1.0 - no changes. * Support Breaks. (Closes: #571638) * Move up to debhelper 7. (Closes: #624175) * Fix 'Files:' option to expect an install _directory_. (Closes: #636310) * Let 'Source:' field default to package name but be overridable. Based on patch from era erickson. (Closes: #409557) * Improve option handling: allow equivs-build --arch and --full to work together. Previously, with --full, --arch had no effect. Checksums-Sha1: c13b3587ff818a427e77425fd6912eeab721820d 672 equivs_2.0.9.dsc 4d9cd1625a4c7ae1bb4edb2f7b429cf531ada85f 21095 equivs_2.0.9.tar.gz 0107f525cadd21a681cff80635156d1418838e7b 20696 equivs_2.0.9_all.deb Checksums-Sha256: bc461ed25161a77df6650ce88256ba69c510c6800eb7f451397cebbb39f1a48f 672 equivs_2.0.9.dsc e8d9753b6730ae97f71381bee04ebbe64f894d5ff20ec16f1d2e08beef72be99 21095 equivs_2.0.9.tar.gz 3bf142f7efc7e1a89853d1f1423d048630cf6ad554431f104acf2b5be76a52d2 20696 equivs_2.0.9_all.deb Files: 4949517d2d188646b5d62f900a5b08d9 672 admin extra equivs_2.0.9.dsc e63383033fabfbd10912adffaa9b0c26 21095 admin extra equivs_2.0.9.tar.gz 4b3ac16cb43543742ed8d6be6ba62ac1 20696 admin extra equivs_2.0.9_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFOhWBeXk7sIRPQRh0RAktTAKCpk5SWceM3+iJkOOW8Dm/hM93XuwCgm2k5 LOE0BAKpcKNW3PJN3ep0L4I= =XBuA -END PGP SIGNATURE- Accepted: equivs_2.0.9.dsc to main/e/equivs/equivs_2.0.9.dsc equivs_2.0.9.tar.gz to main/e/equivs/equivs_2.0.9.tar.gz equivs_2.0.9_all.deb to main/e/equivs/equivs_2.0.9_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1r9wea-0003zd...@franck.debian.org
Re: Bug#643469: ITP: nqp -- Not Quite Perl compiler
[Alessandro Ghedini] It doesn't really sound as intended *only* for Parrot (ok, as of now it does support only parrot, but in the future this may change). Also, aren't parrot-nqp and nqp different things? (parrot-nqp is currently used to build nqp). Are you saying one of them is nqp and the other is ... not-quite-nqp? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110927181710.ga1...@p12n.org
