Re: Recompiling debian kernel
On Mar 5, 2015 7:26 AM, wrote: > make deb-pkg replaces all this: > > Then I execute > make > to build the kernel, and > > sudo make modules_install > > dpkg-buildpackage -us -uc -b -apowerpc > > but at these last step I get an error message: > make[2]: Leaving directory > `/home/csanyipal/BubbaKernelek/LeforditottKernelek/\ > Community-b3-kernel/community-b3-kernel/debian/build/source' > dtc -b 0 -V 17 -R 4 -S 0x3000 -I dts -O dtb -f debian/dts/bubba.dts > > debian/dts/bubba.dtb > /bin/sh: 1: cannot create debian/dts/bubba.dtb: Directory nonexistent > make[1]: *** [override_dh_auto_build] Error 2 > make[1]: Leaving directory > `/home/csanyipal/BubbaKernelek/LeforditottKernelek/\ > Community-b3-kernel/community-b3-kernel' > make: *** [build] Error 2 > dpkg-buildpackage: error: debian/rules build gave error exit status 2 > > What should I do to solve this problem? > It's worth a shot if there are no other prerecs. Keep old debs in another directory and then you can: cd .. dpkg -i *.deb And reboot.
Re: Jessie sufficiently stable for general use?
On Fri, 6 Mar 2015 18:26:46 -0700 Bob Proulx wrote: > > On a Sid Unstable system there are a lot of transitions. Running > dist-upgrade only mostly works but sometimes the transitions and other > noise confuse APT and it wants to take a different path than we want > it to take. Such as to remove everything. Running upgrade first > upgrades everything that can be upgraded without removing anything or > adding anything. Then the subsequent dist-upgrade has a simpler > solution to find and will usually do the right thing. > I would add here that a Sid system which is only occasionally upgraded can present aptitude with a serious problem, which can hang it for hours (I lost patience, but it might have succeeded in the end) so I'd recommend apt-get in this situation. -- Joe -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150307094818.0c4f6...@jresid.jretrading.com
Re: alternative to avidemux?
On 07/03/2015 02:37, Anil Duggirala wrote: Im using avconv to do this, it is a part of libav-tools package, and its probably faster if you are doing this on a regular basis, use the -ss option along with the -t option. Thanks. Indeed avconv can do it. But as I said, I’d prefer something with a gui. The reason is that I have to also teach my wife and my students how to do it. Commandline would seem too complicated to most of them. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54fadef6.4060...@svictor.net
Re: Jessie sufficiently stable for general use?
Patrick Bartek wrote: On Fri, 06 Mar 2015, Miles Fidelman wrote: Brian wrote: On Fri 06 Mar 2015 at 09:27:23 -0800, Patrick Bartek wrote: On Fri, 06 Mar 2015, Ken Heard wrote: Thanks everybody for the collected wisdom. So for me now Jessie RC1 is it. FYI: Do daily updates using dist-upgrade, instead of upgrade (or the equivalent with aptitude, if you use that). Things change quickly and sometimes majorly on the path to Stable. You'll want to get ALL those changes -- minor and major. "Upgrade" won't do that. This is recommended by Debian. Once Jessie is Stable, revert to "upgrade" for the most part. I agree with everything but the final sentence. Stable is unlikely to pull in any new packages but if it does you will likely need them. In other words, 'dist-upgrade' should be the norm for stable. Somehow, anything that needs daily updates, or upgrades, does not meet any definition of "stable" that I'm familiar with. As far a Debian is concerned, you have the incorrect definition of "stable." With Debin "Stable" means "unchanging," without serious bugs, not less prone to crash. It's confusing, I agree. I wish a different term had been chosen. I think the question was quite clear as to meaning - the OP asked is Jessie (i.e., Debian stable), stable (in the plain English use of the word) enough for general use. Not confusing at all. Security and bug fixes are a part of every OS and app. I "update" my system database daily, that is I check daily for any "fixes." Some do so weekly. In any case, this may require "upgrading," i.e. something new is installed replacing something old that needs the fix, about every week or two. Sometimes, it can be one tiny library; other times it can be a dozen system files, including the kernel. Well, yes and no. -- Yes: Typical desktop operating systems (e.g., Windows, Mac OS), and applications, "call home" periodically to check for updates, but, -- No: --- in enterprise environments, that's typically disabled - with updates distributed internally on a less frequent basis --- this is particularly true in server and system environments, that are under maintenance -- one doesn't want updates to the O/S to break application software (as it quite often does) Beyond that, pretty much any systems administrator will tell you that "stable" is a pretty well understood concept. It's the point at which: -- most bugs, not caught during product testing, have been caught and fixed -- enough security scrubbing has been done that the code has been relatively well hardened There will always be a few bugs, and there's always the new security exploit around the corner - but with any halfway decent coding and testing practices, those should be few and far between - to the point that an update/upgrade should rarely be necessary. To me, a "stable" system - and mind you, I'm talking about servers here - is one that doesn't need updating or upgrading for months at a time, if at all; except in the cases of: -- deploying new application software that requires a new o/s feature -- responding to a CERT alert about a newly discovered vulnerability Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54fb07c7.1070...@meetinghouse.net
duplicate logrotate configurations for cups
Hi,
I have a desktop computer running Jessie (amd64). When I check for
messages using the 'mail' command, I find many messages like the
following
From
Envelope-to: root@
Delivery-date:
From: root@ (Cron Daemon)
To: root@
Subject: Cron > test -x /usr/sbin/anacron ||
( cd / && run-parts --report /etc/cron.daily )
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Cron-Env:
X-Cron-Env:
X-Cron-Env:
X-Cron-Env:
Date:
/etc/cron.daily/logrotate:
error: cups.dpkg-remove:1 duplicate log entry
for /var/log/cups/access_log
After looking around, I found the culprits
were /etc/logrotate.d/cups-daemon and /etc/logrotate.d/cups.dpkg-remove
cups-daemon:
/var/log/cups/*log {
daily
missingok
rotate 7
sharedscripts
postrotate
invoke-rc.d --quiet cups restart > /dev/null
endscript
compress
delaycompress
notifempty
create
}
cups.dpkg-remove
/var/log/cups/*log {
daily
missingok
rotate 7
sharedscripts
postrotate
if [ -e /var/run/cups/cupsd.pid ]; then
invoke-rc.d --quiet cups force-reload
> /dev/null
sleep 10
fi
endscript
compress
notifempty
create 640 root lpadmin
}
cups-daemon is provided by the cups-daemon package, but dpkg cannot find
the provider for cups.dpkg-remove
I have two questions:
1) Where did /etc/logrotate.d/cups.dpkg-remove come from?
2) This configurations are for the same file, but they do slightly
different things. Which one should I remove?
Regards,
Laverne
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1425748896.15917.12.camel@schrock.email
Re: Jessie sufficiently stable for general use?
On Sat, 07 Mar 2015, Miles Fidelman wrote: > Patrick Bartek wrote: > > On Fri, 06 Mar 2015, Miles Fidelman wrote: > > > >> Brian wrote: > >>> On Fri 06 Mar 2015 at 09:27:23 -0800, Patrick Bartek wrote: > >>> > On Fri, 06 Mar 2015, Ken Heard wrote: > > > Thanks everybody for the collected wisdom. So for me now Jessie > > RC1 is it. > FYI: Do daily updates using dist-upgrade, instead of upgrade (or > the equivalent with aptitude, if you use that). Things change > quickly and sometimes majorly on the path to Stable. You'll want > to get ALL those changes -- minor and major. "Upgrade" won't do > that. This is recommended by Debian. Once Jessie is Stable, > revert to "upgrade" for the most part. > >>> I agree with everything but the final sentence. Stable is unlikely > >>> to pull in any new packages but if it does you will likely need > >>> them. In other words, 'dist-upgrade' should be the norm for > >>> stable. > >>> > >> Somehow, anything that needs daily updates, or upgrades, does not > >> meet any definition of "stable" that I'm familiar with. > > As far a Debian is concerned, you have the incorrect definition of > > "stable." With Debin "Stable" means "unchanging," without serious > > bugs, not less prone to crash. It's confusing, I agree. I wish a > > different term had been chosen. > > I think the question was quite clear as to meaning - the OP asked is > Jessie (i.e., Debian stable), stable (in the plain English use of the > word) enough for general use. Not confusing at all. In my reply to the OP (not the one above to you), I said that Jessie, even as an RC1, was suitable for general use. But that daily update/dist-upgrades were necessary to keep it so as it made its way toward Stable. FWIW, the Jessie Beta1 I installed (terminal only) in a VM months ago has had no problems. And I've dist-upgraded it only twice. I've even converted it to sysvinit. Not even a hiccup. My intent was to ultimately convert to runit and runitinit for testing, but only installed runit. No problems. As far as runitinit, that conversion's been on the backburner for weeks. > > > > [snip] B -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150307095123.02f36...@debian7.boseck208.net
Re: duplicate logrotate configurations for cups
On Sat 07 Mar 2015 at 11:21:36 -0600, Laverne Schrock wrote: > cups-daemon is provided by the cups-daemon package, but dpkg cannot find > the provider for cups.dpkg-remove > > I have two questions: > 1) Where did /etc/logrotate.d/cups.dpkg-remove come from? It looks like you have been using testing for some time. When the cups-daemon package was split off from cups one of the maintainer scripts did this. > 2) This configurations are for the same file, but they do slightly > different things. Which one should I remove? Keep the cups-daemon one. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/07032015190156.4af367d6f...@desktop.copernicus.demon.co.uk
Re: Jessie sufficiently stable for general use?
On Fri 06 Mar 2015 at 18:26:46 -0700, Bob Proulx wrote: > Brian wrote: > > Patrick Bartek wrote: > > > FYI: Do daily updates using dist-upgrade, instead of upgrade (or the > > > equivalent with aptitude, if you use that). Things change quickly and > > > sometimes majorly on the path to Stable. You'll want to get ALL those > > > changes -- minor and major. "Upgrade" won't do that. This is > > > recommended by Debian. Once Jessie is Stable, revert to "upgrade" for > > > the most part. > > > > I agree with everything but the final sentence. Stable is unlikely to > > pull in any new packages but if it does you will likely need them. > > In other words, 'dist-upgrade' should be the norm for stable. > > It isn't one or the other. You need both. They do different things > and for different reasons. > > A normal daily cycle for me on any sytem is usually this sequence. > Note that I am using both 'etckeeper' and have backups and thefore > have no fear of purging an /etc configuration that I might want to > refer to again later. Therefore I always purge instead of remove to > keep the system clean. > > 1. apt-get update > 2. apt-get upgrade > 3. apt-get dist-upgrade > 4. apt-get autoremove --purge > 5. apt-get clean > 6. reportbug --ui=text brokenpackage [Snip] > On a Stable sytem 99.44% of the time only 1 and 2 are needed and I > stop there and jump to clean and then stop. But every BIND9 security > upgrade for example always pulls in new libraries and can't be > upgraded in place. Therefore after the upgrade if there are packages > still pending then I proceed through dist-upgrade and the rest. I > strongly recommend using upgrade first followed by dist-upgrade. > Hopefully reportbug is only rarely needed on Stable. I agree with the general principal expressed in 1, 2 and 3. However, it was stable which was the focus of my remark and we could have something to learn from this as to how upgrades on it work. The Wheezy point releases have no BIND9 updates so, without searching further, I am unable to check that new libraries were installed. Even if they were they would be from stable, which is ok. (I hope there are no shenanagins with backports. which is not part of a stable release). -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/07032015192747.bd4101762...@desktop.copernicus.demon.co.uk
Re: Jessie sufficiently stable for general use?
On Sat 07 Mar 2015 at 09:14:31 -0500, Miles Fidelman wrote: > Well, yes and no. > -- Yes: Typical desktop operating systems (e.g., Windows, Mac OS), > and applications, "call home" periodically to check for updates, Debian doesn't work like that unless it is configured to do so. > but, > -- No: > --- in enterprise environments, that's typically disabled - with > updates distributed internally on a less frequent basis > --- this is particularly true in server and system environments, > that are under maintenance -- one doesn't want updates to the O/S to > break application software (as it quite often does) Breakage in Debian in this regard does not appear to be common. Do you have an example? > Beyond that, pretty much any systems administrator will tell you > that "stable" is a pretty well understood concept. It's the point > at which: > -- most bugs, not caught during product testing, have been caught and fixed > -- enough security scrubbing has been done that the code has been > relatively well hardened Sounds like Debian stable. > There will always be a few bugs, and there's always the new security > exploit around the corner - but with any halfway decent coding and > testing practices, those should be few and far between - to the > point that an update/upgrade should rarely be necessary. Sounds like Debian stable. I hope we are not going to quibble about how many months there are in "months at a time". > To me, a "stable" system - and mind you, I'm talking about servers > here - is one that doesn't need updating or upgrading for months at > a time, if at all; except in the cases of: > -- deploying new application software that requires a new o/s featurea Sounds like Debian stable. > -- responding to a CERT alert about a newly discovered vulnerability Sounds like Debian stable. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/07032015194311.969134aaa...@desktop.copernicus.demon.co.uk
Re: Jessie sufficiently stable for general use?
Brian wrote: On Sat 07 Mar 2015 at 09:14:31 -0500, Miles Fidelman wrote: Well, yes and no. -- Yes: Typical desktop operating systems (e.g., Windows, Mac OS), and applications, "call home" periodically to check for updates, Debian doesn't work like that unless it is configured to do so. Duh The recommendation made here is, however, to do daily update. but, -- No: --- in enterprise environments, that's typically disabled - with updates distributed internally on a less frequent basis --- this is particularly true in server and system environments, that are under maintenance -- one doesn't want updates to the O/S to break application software (as it quite often does) Breakage in Debian in this regard does not appear to be common. Do you have an example? Can't think of a specific example, but it's fairly common to install a package, and find that it pulls in lots of dependencies. Perl applications come to mind as particularly finicky about "requires version xxx or higher of package yyy." Beyond that, pretty much any systems administrator will tell you that "stable" is a pretty well understood concept. It's the point at which: -- most bugs, not caught during product testing, have been caught and fixed -- enough security scrubbing has been done that the code has been relatively well hardened Sounds like Debian stable. Does, doesn't it. Though... I've yet to find a "stable" version of anything (Debian included) that's really wrung out in its initial release. And, I'll repeat, if folks are recommending daily updates to Jessie, then it doesn't sound all that "stable" to me. There will always be a few bugs, and there's always the new security exploit around the corner - but with any halfway decent coding and testing practices, those should be few and far between - to the point that an update/upgrade should rarely be necessary. Sounds like Debian stable. I hope we are not going to quibble about how many months there are in "months at a time". I'll repeat - not if folks are saying it needs daily updates. To me, a "stable" system - and mind you, I'm talking about servers here - is one that doesn't need updating or upgrading for months at a time, if at all; except in the cases of: -- deploying new application software that requires a new o/s featurea Sounds like Debian stable. Same again. -- responding to a CERT alert about a newly discovered vulnerability Sounds like Debian stable. Same again. Which brings us back to the OP's original question, paraphrased slightly: "Is Jessie stable?" (In either the plain English, or the Debian sense of the word.)" To me, I'd answer that two ways: - by the Debian definition, Jessie is "testing" - hence explicitly NOT "stable" - by the plain English definition - if it needs daily updating, then it's NOT "stable" enough for general use Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54fb6b4f.3050...@meetinghouse.net
Re: duplicate logrotate configurations for cups
On Sat, 2015-03-07 at 19:18 +, Brian wrote: > On Sat 07 Mar 2015 at 11:21:36 -0600, Laverne Schrock wrote: > > > cups-daemon is provided by the cups-daemon package, but dpkg cannot find > > the provider for cups.dpkg-remove > > > > I have two questions: > > 1) Where did /etc/logrotate.d/cups.dpkg-remove come from? > > It looks like you have been using testing for some time. When the > cups-daemon package was split off from cups one of the maintainer > scripts did this. The system was setup in early to mid December, so that explanation makes sense. > > 2) This configurations are for the same file, but they do slightly > > different things. Which one should I remove? > > Keep the cups-daemon one. Will do. Thanks for the help. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1425764685.4786.3.camel@schrock.email
Re: Jessie sufficiently stable for general use?
Quoting Miles Fidelman (mfidel...@meetinghouse.net) in a previous posting: > I think the question was quite clear as to meaning - the OP asked is > Jessie (i.e., Debian stable), stable (in the plain English use of the > word) enough for general use. Not confusing at all. Jessie is not Debian stable. Wheezy is Debian stable. Quoting Miles Fidelman (mfidel...@meetinghouse.net): > Brian wrote: > >On Sat 07 Mar 2015 at 09:14:31 -0500, Miles Fidelman wrote: > >>--- in enterprise environments, that's typically disabled - with > >>updates distributed internally on a less frequent basis > >>--- this is particularly true in server and system environments, > >>that are under maintenance -- one doesn't want updates to the O/S to > >>break application software (as it quite often does) > >Breakage in Debian in this regard does not appear to be common. Do you > >have an example? > > Can't think of a specific example, but it's fairly common to install > a package, and find that it pulls in lots of dependencies. Perl > applications come to mind as particularly finicky about "requires > version xxx or higher of package yyy." That's why Debian stable and Debian oldstable have such old versions of software, and the exceptions (like browsers, see 5.2 in https://www.debian.org/releases/stable/i386/release-notes/ch-information.html ) have no role on servers. > >>Beyond that, pretty much any systems administrator will tell you > >>that "stable" is a pretty well understood concept. It's the point > >>at which: > >>-- most bugs, not caught during product testing, have been caught and fixed > >>-- enough security scrubbing has been done that the code has been > >>relatively well hardened > >Sounds like Debian stable. > > Does, doesn't it. Though... I've yet to find a "stable" version of > anything (Debian included) that's really wrung out in its initial > release. And, I'll repeat, if folks are recommending daily updates > to Jessie, then it doesn't sound all that "stable" to me. Jessie is Debian testing and is frozen. Maintainers should be releasing bugfixes thick and fast. Unless you update regularly, you won't know about them and unless you upgrade regularly, you won't get the benefits. Because new versions of software are excluded and bugfixes are being made, then the distribution should only improve with time. So if the OP is running non-servers (he said desktops), and he's happy with the comments from satisfied users of jessie, then I would suggest that "sufficiently stable for such installations" has little to do with your meaning of stable, and nothing to do with Debian's. > >>There will always be a few bugs, and there's always the new security > >>exploit around the corner - but with any halfway decent coding and > >>testing practices, those should be few and far between - to the > >>point that an update/upgrade should rarely be necessary. > >Sounds like Debian stable. > > > >I hope we are not going to quibble about how many months there are in > >"months at a time". > > I'll repeat - not if folks are saying it needs daily updates. > > > > >>To me, a "stable" system - and mind you, I'm talking about servers > >>here - is one that doesn't need updating or upgrading for months at > >>a time, if at all; except in the cases of: > >>-- deploying new application software that requires a new o/s featurea > >Sounds like Debian stable. > > Same again. > > > >>-- responding to a CERT alert about a newly discovered vulnerability > >Sounds like Debian stable. > > > > > Same again. > > Which brings us back to the OP's original question, paraphrased > slightly: "Is Jessie stable?" (In either the plain English, or the > Debian sense of the word.)" To me, I'd answer that two ways: > - by the Debian definition, Jessie is "testing" - hence explicitly > NOT "stable" > - by the plain English definition - if it needs daily updating, then > it's NOT "stable" enough for general use I think that if you going to debate the meanings of words, then you should be precise about which meaning you are using. https://lists.debian.org/debian-user/2015/03/msg00212.html gives a summary of the terms update and upgrade in the Debian sense, as does man apt-get. https://www.debian.org/releases/ gives a summary of the terms stable etc. If you read these, you may perceive that a daily (at least) update is a perfectly sensible course of action for any Debian version. The package lists are updated in a highly efficient manner. You'll see "Hit" in place of "Get" when a file is unchanged, and any transfers are made efficient with diffs. If you're tracking Debian stable on a non-server, then an upgrade on a similar schedule is sensible too. For days/weeks at a time the result will be "Nothing happens". If you're running a server, just add -d and any new packages will be downloaded and not installed. You can then examine the changes log. If you don't update and upgrade (in the Debian sense) frequently, then you're wasting the timely efforts of
Re: Jessie sufficiently stable for general use?
Brian wrote:
> The Wheezy point releases have no BIND9 updates so, without searching
> further, I am unable to check that new libraries were installed. Even
> if they were they would be from stable, which is ok.
This was a recent BIND9 upgrade in Wheezy on 18 Feb 2015.
https://www.debian.org/security/2015/dsa-3162
The BIND package is actually a combined set of libraries plus
executables. They don't have a stable API. Therefore the entire
bundle always needs to be updated. The libraries have the version
number encoded in the name. Therefore it requires dist-upgrade in
order to handle installing bind security releases.
root@despair:/tmp# debdiff bind9_9.8.4.dfsg.P1-6+nmu2+deb7u3_i386.deb
bind9_9.8.4.dfsg.P1-6+nmu2+deb7u4_i386.deb
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
Depends: libbind9-80 (= [-1:9.8.4.dfsg.P1-6+nmu2+deb7u3),-]
{+1:9.8.4.dfsg.P1-6+nmu2+deb7u4),+} libc6 (>= 2.4), libcap2 (>= 2.10), libdns88
(= [-1:9.8.4.dfsg.P1-6+nmu2+deb7u3),-] {+1:9.8.4.dfsg.P1-6+nmu2+deb7u4),+}
libgssapi-krb5-2 (>= 1.6.dfsg.2), libisc84 (=
[-1:9.8.4.dfsg.P1-6+nmu2+deb7u3),-] {+1:9.8.4.dfsg.P1-6+nmu2+deb7u4),+}
libisccc80 (= [-1:9.8.4.dfsg.P1-6+nmu2+deb7u3),-]
{+1:9.8.4.dfsg.P1-6+nmu2+deb7u4),+} libisccfg82 (=
[-1:9.8.4.dfsg.P1-6+nmu2+deb7u3),-] {+1:9.8.4.dfsg.P1-6+nmu2+deb7u4),+}
liblwres80 (= [-1:9.8.4.dfsg.P1-6+nmu2+deb7u3),-]
{+1:9.8.4.dfsg.P1-6+nmu2+deb7u4),+} libssl1.0.0 (>= 1.0.0), libxml2 (>= 2.7.4),
debconf (>= 0.5) | debconf-2.0, netbase, adduser, lsb-base (>= 3.2-14),
bind9utils (= [-1:9.8.4.dfsg.P1-6+nmu2+deb7u3),-]
{+1:9.8.4.dfsg.P1-6+nmu2+deb7u4),+} net-tools
Installed-Size: [-811-] {+936+}
Version: [-1:9.8.4.dfsg.P1-6+nmu2+deb7u3-] {+1:9.8.4.dfsg.P1-6+nmu2+deb7u4+}
Sometimes other things sneak in too. At one time a jpeg library
release linked against another newer library than it had originally
been released with and therefore required a new library that it really
shouldn't have needed. I recall submitting a bug and it was simply
closed.
Bob
signature.asc
Description: Digital signature
