Re: Apt pinning.
On Sb, 27 nov 21, 10:57:37, Tim Woodall wrote: > > Also, I don't know if this pin is working with a=stable or it's actually > not doing anything useful any more. I cannot find anything that tells me > how the Pin: line actually matches. For diagnosing pinning `apt policy` (with or without , depending on what you're looking for) is very useful. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Apt pinning.
On Mon 29 Nov 2021 at 17:33:35 (+), Tim Woodall wrote: > On Mon, 29 Nov 2021, The Wanderer wrote: > > > > Is there a reason you're using '+' as your separator? > > > Yes - because, for example, squid I'm building with extra settings so I > want my version to be higher than the corresponding buster/bullseye > version. There is no backporting involved. > > > I think this looks like exactly the sort of scenario which '~' is > > intended for. > > > But I didn't know ~ was different. Indeed, for packages I've backported > and want return to mainline eventually it sounds like what I should be > doing for backported packages. [ … ] > Indeed, sounds perfect. Thank you. I'll have to rework my scripts so I > can choose ~ or + depending on whether I'm backporting a higher version > from a future release or patching the current release. > > I already have config for $source_distribution and $target_distribution > so I might be able to automate the patch version. > > Thats the bit of magic I needed. Thanks! Using these schemes will put your patched versions at the mercy of any other versions entering the repositories: apt will try to upgrade them as soon as a higher version number is seen. You originally wrote "What I want this to do is hold any package in my local repository even if a newer version is present in debian" and "Were a new buster build to happen ([ … ]) I'd want my local version to stay until I patch the new version" which appears to contradict the above. My epoch: method was in answer to your original post, and not the discussion of pinning and upstream-version-debian-revisions that has followed. I illustrated what epochs can do, and I'll leave it at that, because it's unsuitable for what you now appear to need. Cheers, David.
Re: Apt pinning.
On Mon, 29 Nov 2021, The Wanderer wrote: Is there a reason you're using '+' as your separator? Yes - because, for example, squid I'm building with extra settings so I want my version to be higher than the corresponding buster/bullseye version. There is no backporting involved. I think this looks like exactly the sort of scenario which '~' is intended for. But I didn't know ~ was different. Indeed, for packages I've backported and want return to mainline eventually it sounds like what I should be doing for backported packages. $ dpkg --compare-versions 0.4b46-8+tjw10r1 lt 0.4b46-8 && echo "0.4b46-8 is newer" || echo "0.4b46-8 is not newer" 0.4b46-8 is not newer $ dpkg --compare-versions 0.4b46-8~tjw10r1 lt 0.4b46-8 && echo "0.4b46-8 is newer" || echo "0.4b46-8 is not newer" 0.4b46-8 is newer As I understand matters, a version "foo~" will always compare as lower than a version "foo", and this is specifically to make it possible to do fancy things like what you're apparently aiming for here. That won't help you with your current set of local packages - but if you switch to that for any ones you build in the future, it might give you a path to the end state you're hoping for. Indeed, sounds perfect. Thank you. I'll have to rework my scripts so I can choose ~ or + depending on whether I'm backporting a higher version from a future release or patching the current release. I already have config for $source_distribution and $target_distribution so I might be able to automate the patch version. Thats the bit of magic I needed. Thanks!
Re: Apt pinning.
On 2021-11-29 at 11:08, Tim Woodall wrote: > On Sun, 28 Nov 2021, David Wright wrote: > >> I envisaged that what you wanted was: >> >> Debian ver. Task Your ver.Installed (highest) ver. >> 1.0 1.0 >> 1.0 ? 1.0 >> 1.0 patch 1.0 >> 1.0 ? 5:1.05:1.0 >> 2.0 5:1.0 >> 2.0 ? 5:1.0 >> 2.0 patch 5:1.0 >> 2.0 ? 5:2.05:2.0 >> 3.0 5:2.0 >> >> IOW you patch a new version to your specifications at leisure, >> and it will be automatically installed when made available. >> New Debian releases will be ignored while they are unpatched. >> >> If you track the Debian column, and an automatic patch is applied >> successfully and made available, then the process could be self- >> sustaining. >> >> As I don't understand "current", I'm not sure what your -epsilon >> is for. Likewise, I don't understand whether "return to mainline" >> means abandon your versions, or just revisit, say, 3.0 above to >> use your automated patch or come up with a new one. > > The problem comes, for example, where I've backported. > > For make I wanted v4.3 so I built the make from bullseye on buster as > make/oldstable,now 4.3-4.1+tjw10r1 amd64 [installed,automatic] > > And for dump there was a fix that was never added to buster so I have > dump/oldstable,now 0.4b46-8+tjw10r1 > > I've forced a downgrade apt-get install dump=0.4b46-8 which is no > problem, I just have to remember to do it. But I'd prefer to build that > feature into my local repo as/when I create these packages in the > future. Is there a reason you're using '+' as your separator? I think this looks like exactly the sort of scenario which '~' is intended for. $ dpkg --compare-versions 0.4b46-8+tjw10r1 lt 0.4b46-8 && echo "0.4b46-8 is newer" || echo "0.4b46-8 is not newer" 0.4b46-8 is not newer $ dpkg --compare-versions 0.4b46-8~tjw10r1 lt 0.4b46-8 && echo "0.4b46-8 is newer" || echo "0.4b46-8 is not newer" 0.4b46-8 is newer As I understand matters, a version "foo~" will always compare as lower than a version "foo", and this is specifically to make it possible to do fancy things like what you're apparently aiming for here. That won't help you with your current set of local packages - but if you switch to that for any ones you build in the future, it might give you a path to the end state you're hoping for. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Apt pinning.
On Sun, 28 Nov 2021, David Wright wrote: I envisaged that what you wanted was: Debian ver. Task Your ver.Installed (highest) ver. 1.0 1.0 1.0 ? 1.0 1.0 patch 1.0 1.0 ? 5:1.05:1.0 2.0 5:1.0 2.0 ? 5:1.0 2.0 patch 5:1.0 2.0 ? 5:2.05:2.0 3.0 5:2.0 IOW you patch a new version to your specifications at leisure, and it will be automatically installed when made available. New Debian releases will be ignored while they are unpatched. If you track the Debian column, and an automatic patch is applied successfully and made available, then the process could be self- sustaining. As I don't understand "current", I'm not sure what your -epsilon is for. Likewise, I don't understand whether "return to mainline" means abandon your versions, or just revisit, say, 3.0 above to use your automated patch or come up with a new one. The problem comes, for example, where I've backported. For make I wanted v4.3 so I built the make from bullseye on buster as make/oldstable,now 4.3-4.1+tjw10r1 amd64 [installed,automatic] And for dump there was a fix that was never added to buster so I have dump/oldstable,now 0.4b46-8+tjw10r1 I've forced a downgrade apt-get install dump=0.4b46-8 which is no problem, I just have to remember to do it. But I'd prefer to build that feature into my local repo as/when I create these packages in the future. in fact dump was in more of a mess because (I think) I originally backported from sid before I'd started my local repo, so I had different versions on different machines. I started my local repo to avoid this inconsistency. I'd forgotten about the patched version of dump. At least now my buster machines are consistent. For 'current' I was referring to the version in the head of the changelog.
Re: Apt pinning.
On Sun 28 Nov 2021 at 07:13:09 (+), Tim Woodall wrote: > On Sat, 27 Nov 2021, David Wright wrote: > > On Sat 27 Nov 2021 at 19:07:14 (+), Tim Woodall wrote: > > > > > > Yes, I don't think I can do this with a generic pin. Maybe pinning > > > origin "" to -100 might work - not sure if that will uninstall or > > > downgrade (I'll experiment). I think adding explicit pins to my > > > 'bullseye-local-sources' package for these packages I want to downgrade > > > might be my only option. For the two packages I have that I want to > > > downgrade during the update to bullseye it's easy enough to manually fix > > > and I haven't yet had to backport anything to bullseye that won't keep a > > > patched version during the upgrade to Trixy. > > > > > > Thanks for the pointers. > > > > The obvious way to do this would seem to be using an epoch, > > like 5:, to give your package priority over newer versions. > > This is standard practice for self-compiled kernels, because > > newer versions are being released all the time. > > I can see how epochs work when you never want to return to mainline - my > squid packages would be an example (unless debian decides to adopt my > configuration options) but they'd make less sense for things like make > and dump where I've backported and want to return to mainline once the > new version goes to stable. I don't see why. To return to mainline, have you tried using the syntax install myOldPackage- newMainlinePackage+ which should move from one version to another without screwing up the dependencies. > My system for tracking the upstream version and patching it is > semi-automatic (unless any patch fails to apply) and I think trying to > bump epochs would add another place where the automatic process would > fail. You don't bump epochs; you merely make sure that your epoch exceeds that of the Debian versions. None of the three packages you've mentioned so far (linphone make dump) has an epoch in buster or bullseye. > I do use debmultimedia.org and I find the epoch bump annoying because I > can't, for example, drop dmo during the upgrade from buster to bullseye > and (mostly) have it disappear. IIRC I added dmo years ago for mp3 > codecs - it's not needed any more but it's got it's tendrils everywhere > and removing it safely and cleanly is unnecessarily hard. I remember removing dmo when the mainstream Debian packages improved significantly, and any reason for hanging onto dmo evaporated. I certainly didn't accomplish it through any clever use of versioning, but instead using dpkg-query to list package origins, and then dry-run removals to see which Debian packages needed installing as the dmo ones were removed. > I suppose what I really want is a 'minus epsilon' flag to dch which will > generate a changelog that had a version that tests lower than the > current version but higher than all versions that test lower than the > current version. s/current/particular/; because "current" is not a defined concept under the circumstances. It could be your current version, or the Debian version it was patched from, or the most recent Debian version, or some version about to be superceded by a new release (to name but four). > But I cannot see such a patch being accepted, however it is implemented, > and dealing with this once every two years problem of mine is going to > be less effort than maintaining a patched version of devscripts locally > (and dpkg and whomever else compares versions) I envisaged that what you wanted was: Debian ver. Task Your ver.Installed (highest) ver. 1.0 1.0 1.0 ⮧ 1.0 1.0 patch 1.0 1.0 ⮡ 5:1.05:1.0 2.0 5:1.0 2.0 ⮧ 5:1.0 2.0 patch 5:1.0 2.0 ⮡ 5:2.05:2.0 3.0 5:2.0 IOW you patch a new version to your specifications at leisure, and it will be automatically installed when made available. New Debian releases will be ignored while they are unpatched. If you track the Debian column, and an automatic patch is applied successfully and made available, then the process could be self- sustaining. As I don't understand "current", I'm not sure what your -epsilon is for. Likewise, I don't understand whether "return to mainline" means abandon your versions, or just revisit, say, 3.0 above to use your automated patch or come up with a new one. > The following pin rule appears to fix my problem - I'm not sure yet if > it's wise... > > Package: make dump > Pin: release n=bullseye > Pin-Priority: 1001 I can't comment on that, and I notice that Dan couldn't recommend it. > Kernels are a bit of a special case as they don't 'infect' other > packages. Even my dump was holding libreadline7 from buster. True, but I don't see what difference it makes to a package with a multiplicity of
Re: Apt pinning.
Hi, The Wanderer wrote: > an epoch as high as 9: > ii wodim > 9:1.1.11-3.2 Looks like interesting history. https://tracker.debian.org/media/packages/c/cdrkit/changelog-91.1.11-3.2 (when read backwards) shows repeated occasions of what https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly describes as: "Note that the purpose of epochs is [...] to allow us to leave behind serious mistakes." It began in the old cdrecord days obviously to override the peculiar upstream version numbering of cdrecord pre-releases: -- Christian Schwarz Tue, 16 Sep 1997 22:16:57 +0200 cdrecord (1.5a5-1) experimental; urgency=low ... -- Christian Schwarz Sun, 12 Oct 1997 21:59:11 +0200 cdrecord (1:1.5-1) unstable; urgency=low ... * Included epoch in version number. ... There might have been the intention to stay with a version format where chronological sequence and dpkg sorting are in sync. But then a new package maintainer took over and the letters got re-introduced. This became a sorting problem later: -- Erik Andersen Sat, 22 Jan 2000 12:40:27 -0700 cdrecord (1:1.8a40r3-1) frozen unstable; urgency=low ... -- Erik Andersen Mon, 21 Feb 2000 22:29:39 -0700 cdrecord (2:1.8a40-1) frozen unstable; urgency=low ... -- Erik Andersen Tue, 29 Feb 2000 10:02:15 -0700 cdrecord (3:1.8-1) frozen unstable; urgency=low ... -- Erik Andersen Sat, 29 Sep 2001 15:41:11 -0600 cdrtools (4:1.10-1) unstable; urgency=low For a while, the pre-release suffixes were avoided and the "source" version staid with the youngest release. When they came back, a "+" was inserted between the minor version number of the youngest released version and the current pre-release version: -- Eduard Bloch Fri, 6 Sep 2002 20:09:15 +0200 cdrtools (4:1.10+11a31-1) unstable; urgency=low The lower sorting rank of '+' in comparison to '-' solved the problem with the pre-release suffixes. Then came the big fork of cdrtools into cdrkit with new version numbers (and an even better separator for "pre1"): -- Eduard Bloch Mon, 4 Sep 2006 01:24:22 +0200 cdrkit (5:1.0~pre1-1) unstable; urgency=low This could have been the epoch to be used up to today. But then Knoppix was caught with having installed a cdrecord package with epoch 8. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=35#32 So the current epoch became 9. -- Eduard Bloch Sat, 30 Dec 2006 16:45:31 +0100 cdrkit (9:1.1.0-1) unstable; urgency=low The Wanderer wrote: > I don't see any of 10 or above. None to be expected from cdrkit. The lack of further substantial development quite surely ended this dramedy. (I doubt that its final maintainer would be willing to change its epoch just to please people who installed a non-Debian package of it.) Have a nice day :) Thomas
Re: Apt pinning.
On 2021-11-28 at 00:03, David Wright wrote: > Epochs are unaffected by any such considerations: they override the > whole versioning system. BTW I can't recall seeing an official Debian > epoch as high as 2: though someone will probably correct me. Oh, it certainly happens. Even just on my own system, I see 184 epochs of 2 or higher: $ dpkg -l "*" | grep "\b[2-9]:[0-9]" | wc -l 184 and even one set of packages with an epoch as high as 9: ~$ dpkg -l "*" | grep "\b9:[0-9]" ii cdrkit-doc 9:1.1.11-3.2 all Documentation for the cdrkit package suite ii genisoimage 9:1.1.11-3.2 amd64Creates ISO-9660 CD-ROM filesystem images ii wodim 9:1.1.11-3.2 amd64command line CD/DVD writing tool though I don't see any of 10 or above. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Apt pinning.
On Sat, 27 Nov 2021, David Wright wrote: On Sat 27 Nov 2021 at 19:07:14 (+), Tim Woodall wrote: Yes, I don't think I can do this with a generic pin. Maybe pinning origin "" to -100 might work - not sure if that will uninstall or downgrade (I'll experiment). I think adding explicit pins to my 'bullseye-local-sources' package for these packages I want to downgrade might be my only option. For the two packages I have that I want to downgrade during the update to bullseye it's easy enough to manually fix and I haven't yet had to backport anything to bullseye that won't keep a patched version during the upgrade to Trixy. Thanks for the pointers. The obvious way to do this would seem to be using an epoch, like 5:, to give your package priority over newer versions. This is standard practice for self-compiled kernels, because newer versions are being released all the time. I can see how epochs work when you never want to return to mainline - my squid packages would be an example (unless debian decides to adopt my configuration options) but they'd make less sense for things like make and dump where I've backported and want to return to mainline once the new version goes to stable. My system for tracking the upstream version and patching it is semi-automatic (unless any patch fails to apply) and I think trying to bump epochs would add another place where the automatic process would fail. I do use debmultimedia.org and I find the epoch bump annoying because I can't, for example, drop dmo during the upgrade from buster to bullseye and (mostly) have it disappear. IIRC I added dmo years ago for mp3 codecs - it's not needed any more but it's got it's tendrils everywhere and removing it safely and cleanly is unnecessarily hard. Kernels are a bit of a special case as they don't 'infect' other packages. Even my dump was holding libreadline7 from buster. I suppose what I really want is a 'minus epsilon' flag to dch which will generate a changelog that had a version that tests lower than the current version but higher than all versions that test lower than the current version. But I cannot see such a patch being accepted, however it is implemented, and dealing with this once every two years problem of mine is going to be less effort than maintaining a patched version of devscripts locally (and dpkg and whomever else compares versions) The following pin rule appears to fix my problem - I'm not sure yet if it's wise... Package: make dump Pin: release n=bullseye Pin-Priority: 1001 Tim
Re: Apt pinning.
On Sat 27 Nov 2021 at 19:07:14 (+), Tim Woodall wrote: > On Sat, 27 Nov 2021, Dan Ritter wrote: > > Tim Woodall wrote: > > > Can anyone tell me exactly what this Pin line I have actually does - or > > > even better point me to a webpage that has more than "if you want to do > > > this use this" type of example? > > > > > > (FTAOD I know that this isn't right and is inconsistent but before I > > > start changing it I want to really understand what it's currently doing) > > > > > > I have a local repository: > > > > > > Codename: buster > > > Components: main > > > Date: Thu, 25 Nov 2021 19:42:12 + > > > Description: Debs for local installing > > > Label: local debs > > > Origin: local debs > > > Suite: oldstable > > > > > > And I have a pin (which I've failed to update since bullseye became > > > stable hence the a=stable) > > > > > > Package: * > > > Pin: release o=local debs,a=stable,n=buster,l=local debs,c=main,b=amd64 > > > Pin-Priority: 900 > > > > man apt_preferences # go ahead and read it, it's well-organized > > > > Many thanks. I think I've been lucky and stumbled into something that > worked for me but isn't very robust. > > I've never set a default release, I've never added (except for sources) > sources.list entries other than for things I've wanted installed. So the > 900 worked. > > Need to think about whether I want to change that - I cannot immediately > see how it improves things for me but it might make sense to change if > that's what everybody else does. It will undoubtedly cause me > head-scratching when I upgrade to Trixy and it doesn't work... > > > > > I'm trying to solve a (minor) problem I'm having during upgrades from > > > buster to bullseye where I've backported make from bullseye to buster. > > > So on my buster systems I have: > > > make/oldstable,now 4.3-4.1+tjw10r1 amd64 [installed] > > > > > > while once I've upgraded to bullseye I want to "downgrade" from my > > > backported package to make 4.3-4.1 and then continue to track bullseye. > > > > You will need a priority over 1000. > > > > I don't recommend this, but you get to keep all the pieces. > > > > Yes, I don't think I can do this with a generic pin. Maybe pinning > origin "" to -100 might work - not sure if that will uninstall or > downgrade (I'll experiment). I think adding explicit pins to my > 'bullseye-local-sources' package for these packages I want to downgrade > might be my only option. For the two packages I have that I want to > downgrade during the update to bullseye it's easy enough to manually fix > and I haven't yet had to backport anything to bullseye that won't keep a > patched version during the upgrade to Trixy. > > Thanks for the pointers. The obvious way to do this would seem to be using an epoch, like 5:, to give your package priority over newer versions. This is standard practice for self-compiled kernels, because newer versions are being released all the time. Should you chance upon https://wiki.debian.org/Teams/Dpkg/FAQ, note that those exhortations apply to packages being placed into shared repositories, not to personal usage like yours. > > > When debian went from v2.2 potato to v3 woody, would this pin stop > > > working? Because woody would be stable and potato oldstable at that > > > point. Epochs are unaffected by any such considerations: they override the whole versioning system. BTW I can't recall seeing an official Debian epoch as high as 2: though someone will probably correct me. Cheers, David.
Re: Apt pinning.
On Sat, 27 Nov 2021, Dan Ritter wrote: Tim Woodall wrote: Can anyone tell me exactly what this Pin line I have actually does - or even better point me to a webpage that has more than "if you want to do this use this" type of example? (FTAOD I know that this isn't right and is inconsistent but before I start changing it I want to really understand what it's currently doing) I have a local repository: Codename: buster Components: main Date: Thu, 25 Nov 2021 19:42:12 + Description: Debs for local installing Label: local debs Origin: local debs Suite: oldstable And I have a pin (which I've failed to update since bullseye became stable hence the a=stable) Package: * Pin: release o=local debs,a=stable,n=buster,l=local debs,c=main,b=amd64 Pin-Priority: 900 man apt_preferences # go ahead and read it, it's well-organized Many thanks. I think I've been lucky and stumbled into something that worked for me but isn't very robust. I've never set a default release, I've never added (except for sources) sources.list entries other than for things I've wanted installed. So the 900 worked. Need to think about whether I want to change that - I cannot immediately see how it improves things for me but it might make sense to change if that's what everybody else does. It will undoubtedly cause me head-scratching when I upgrade to Trixy and it doesn't work... I'm trying to solve a (minor) problem I'm having during upgrades from buster to bullseye where I've backported make from bullseye to buster. So on my buster systems I have: make/oldstable,now 4.3-4.1+tjw10r1 amd64 [installed] while once I've upgraded to bullseye I want to "downgrade" from my backported package to make 4.3-4.1 and then continue to track bullseye. You will need a priority over 1000. I don't recommend this, but you get to keep all the pieces. Yes, I don't think I can do this with a generic pin. Maybe pinning origin "" to -100 might work - not sure if that will uninstall or downgrade (I'll experiment). I think adding explicit pins to my 'bullseye-local-sources' package for these packages I want to downgrade might be my only option. For the two packages I have that I want to downgrade during the update to bullseye it's easy enough to manually fix and I haven't yet had to backport anything to bullseye that won't keep a patched version during the upgrade to Trixy. Thanks for the pointers. Tim.
Re: Apt pinning.
Tim Woodall wrote: > Can anyone tell me exactly what this Pin line I have actually does - or > even better point me to a webpage that has more than "if you want to do > this use this" type of example? > > (FTAOD I know that this isn't right and is inconsistent but before I > start changing it I want to really understand what it's currently doing) > > I have a local repository: > > Codename: buster > Components: main > Date: Thu, 25 Nov 2021 19:42:12 + > Description: Debs for local installing > Label: local debs > Origin: local debs > Suite: oldstable > > And I have a pin (which I've failed to update since bullseye became > stable hence the a=stable) > > Package: * > Pin: release o=local debs,a=stable,n=buster,l=local debs,c=main,b=amd64 > Pin-Priority: 900 man apt_preferences # go ahead and read it, it's well-organized P >= 1000 causes a version to be installed even if this constitutes a downgrade of the package 990 <= P < 1000 causes a version to be installed even if it does not come from the target release, unless the installed version is more recent 500 <= P < 990 causes a version to be installed unless there is a version available belonging to the target release or the installed version is more recent 100 <= P < 500 causes a version to be installed unless there is a version available belonging to some other distribution or the installed version is more recent 0 < P < 100 causes a version to be installed only if there is no installed version of the package P < 0 prevents the version from being installed > What I want this to do is hold any package in my local repository even > if a newer version is present in debian. My local repository has patched > packages for various reasons - e.g. > linphone/oldstable,now 3.12.0-3+tjw10r1 amd64 [installed] Then 990...1000 is what you want. > I don't even know whether the options on that Pin line are AND or ORed > together. The example on the webpage has: > > Package: * > Pin: release v=2.2*,a=stable,c=main,o=Debian,l=Debian > Pin-Priority: 1001 > > When debian went from v2.2 potato to v3 woody, would this pin stop > working? Because woody would be stable and potato oldstable at that > point. All the conditions must match. However, "stable" changes, whereas "woody" does not". > I'm trying to solve a (minor) problem I'm having during upgrades from > buster to bullseye where I've backported make from bullseye to buster. > So on my buster systems I have: > make/oldstable,now 4.3-4.1+tjw10r1 amd64 [installed] > > while once I've upgraded to bullseye I want to "downgrade" from my > backported package to make 4.3-4.1 and then continue to track bullseye. You will need a priority over 1000. I don't recommend this, but you get to keep all the pieces. -dsr-
Apt pinning.
Can anyone tell me exactly what this Pin line I have actually does - or even better point me to a webpage that has more than "if you want to do this use this" type of example? (FTAOD I know that this isn't right and is inconsistent but before I start changing it I want to really understand what it's currently doing) I have a local repository: Codename: buster Components: main Date: Thu, 25 Nov 2021 19:42:12 + Description: Debs for local installing Label: local debs Origin: local debs Suite: oldstable And I have a pin (which I've failed to update since bullseye became stable hence the a=stable) Package: * Pin: release o=local debs,a=stable,n=buster,l=local debs,c=main,b=amd64 Pin-Priority: 900 What I want this to do is hold any package in my local repository even if a newer version is present in debian. My local repository has patched packages for various reasons - e.g. linphone/oldstable,now 3.12.0-3+tjw10r1 amd64 [installed] linphonec in buster has a bug that causes a core on answering a call. I've applied the patch locally. Were a new buster build to happen (unlikely now but not impossible if there's a serious security issue found) I'd want my local version to stay until I patch the new version. This pin has worked successfully for me throughout buster's lifetime - however when looking at it now to correct that a=stable I noticed that https://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html suggests that I should be pinning at 990, not 900. Also, I don't know if this pin is working with a=stable or it's actually not doing anything useful any more. I cannot find anything that tells me how the Pin: line actually matches. I don't even know whether the options on that Pin line are AND or ORed together. The example on the webpage has: Package: * Pin: release v=2.2*,a=stable,c=main,o=Debian,l=Debian Pin-Priority: 1001 When debian went from v2.2 potato to v3 woody, would this pin stop working? Because woody would be stable and potato oldstable at that point. I'm trying to solve a (minor) problem I'm having during upgrades from buster to bullseye where I've backported make from bullseye to buster. So on my buster systems I have: make/oldstable,now 4.3-4.1+tjw10r1 amd64 [installed] while once I've upgraded to bullseye I want to "downgrade" from my backported package to make 4.3-4.1 and then continue to track bullseye. I'm trying to work out what Pin line I want (ideally generic rather than package specific - dump has exactly the same feature) but at the same time I do not want my buster systems to install squid 4.6-1+deb10u7 (should it ever be created) over my patched 4.6-1+deb10u6+tjw10r1 but instead hold my patched package until I patch deb10u7. (ditto bullseye where I have squid/stable,now 4.13-10+tjw11r1) For now I just manually apt-get install make=4.3-4.1 to fix it. But if make built on buster had failed to work on bullseye then my package could have made a mess of the upgrade if any packages are using make during configuation. Tim.
Re: [resolu] Re: apt pinning: j'y comprends rien !
Je pense que ta configuration tombe en marche par accident mais risque de ne pas fonctionner pas dans d'autres cas moins spécifiques ;-) - firefox et firefox-l10n* sont des paquets qui n'existent que dans le dépôt unstable (j'ai pas vérifié, je suppose qu'il n'est pas non plus empaqueté chez Marillat) - c'est firefox-esr et firefox-esr-l10n* qui figurent dans les autres dépôts Debian - donc dans ce cas précis les priorités n'ont pas une grosse importance Contre-exemple: prends le paquet linux-image-amd64 et supposons que pour ce paquet spécifique tu souhaites suivre unstable plutôt que testing. Il est à l'heure actuelle en 5.10.13 en testing et 5.10.19 en unstable. Si tu adoptes le même paramétrage que celui que tu as adopté pour Firefox, tu vas rester avec le 5.10.13 de testing :-)
Re: apt pinning: j'y comprends rien !
Le 04/03/2021 à 00:52, Gaëtan Perrier a écrit : Moi je veux l'inverse: que ceux de dmo ne soient pas prioritaires par rapport à testing Debian (sauf pour quelques paquets). Justement non, ce n'est pas l'inverse :-) Toujours rapporté à l'exemple précédent, pour ce que tu souhaites, tu dois définir deux choses distinctes: - en début de fichier des préférences spécifiques avec des priorités 900installer - en fin de fichier des préférences génériques avec des priorités 0ceux-ci ne soient installés *que* lorsqu'ils constituent des dépendances absolument nécessaires d'autres paquets que tu souhaites installer.
Re: [resolu] Re: apt pinning: j'y comprends rien !
Le jeudi 04 mars 2021 à 01:30 +0100, Gaëtan Perrier a écrit : > > Par contre synaptic semble ne pas prendre en compte les preferences ainsi > définies ... > Pour synaptic ça se passe dans /var/lib/synaptic/preferences J'ai donc créé un lien vers le fichier dans /etc/apt et ça fonctionne. Gaëtan signature.asc Description: This is a digitally signed message part
[resolu] Re: apt pinning: j'y comprends rien !
J'ai compris mon erreur ! J'avais mis un espace en début des lignes Pin: car je trouvais que c'était plus lisible d'avoir seulement les lignes Package complètement à gauche. Sauf du coup ces lignes Pin ne sont pas prises en compte ! Donc en enlevant la distri par défaut dans apt.conf et avec ceci dans les preferences ça fait ce que je souhaite ! :) --- Package: * Pin: origin www.deb-multimedia.org Pin-Priority: 10 Package: firefox firefox-l10n* Pin: release o=Debian,a=unstable Pin-Priority: 800 Package: * Pin: release a=testing Pin-Priority: 900 Package: * Pin: release a=unstable Pin-Priority: 800 Package: * Pin: release o=Debian Pin-Priority: -10 --- Par contre synaptic semble ne pas prendre en compte les preferences ainsi définies ... Merci pour vos conseils. Gaëtan signature.asc Description: This is a digitally signed message part
Re: apt pinning: j'y comprends rien !
Le mercredi 03 mars 2021 à 23:27 +0100, didier gaumet a écrit : > Le 03/03/2021 à 21:52, Gaëtan Perrier a écrit : > [...] > > Euh là je ne sais pas ça vient de la page man: > > > > --- > > - > > Méthode pour suivre Testing ou Unstable > > Le fichier des préférences suivant affecte une priorité haute aux > > versions des paquets > > appartenant à la distribution testing, une priorité moindre aux > > versions > > appartenant à la > > distribution unstable et une priorité prohibitivement basse aux > > versions > > appartenant à > > d'autres distributions Debian. > > > > Package: * > > Pin: release a=testing > > Pin-Priority: 900 > > > > Package: * > > Pin: release a=unstable > > Pin-Priority: 800 > > > > Package: * > > Pin: release o=Debian > > Pin-Priority: -10 > > --- > > - > > 1) le cas détaillé ici est celui où il n'y a pas de version par défaut > dans apt.conf (la page man de apt_preferences expose les différences des > priorités qui sont affectées suivant qu'un version par défaut est > définie ou non). Suivant que tu définis ou non une version par défaut > dans apt.conf, tu ne dois pas affecter les mêmes priorités numériques > (sans version par défaut la priorité de base est 500, avec, elle est de > 990). ok j'ai essayé en enlevant la distro par défaut dans apt.conf et en mettant les règles de l'exemple => tout est à 500. Les règles n'ont pas été prises en compte ... Si je mets seulement la distri par défaut j'ai 990 pour testing et 500 pour le reste. > > > J'ai essayé de mettre la règle pour dmo en premier mais sans changement. > > Toujours rapporté à l'exemple ci-dessus, si tu veux installer le > paquet foo de Marillat, tu dois créer une règle pour ce paquet en début > de fichier, avec aussi (comme firefox d'unstable) une priorité 800 En fin de fichier tu laisses ta règle générale Marillat avec une > priorité inférieure à 800. > ça ne marche pas ... Ma conclusion du jour est que le fichier preferences ou les fichiers dans preferences.d ne sont pas pris en compte ... Gaëtan signature.asc Description: This is a digitally signed message part
Re: apt pinning: j'y comprends rien !
Le mercredi 03 mars 2021 à 23:34 +0100, didier gaumet a écrit : > Le 03/03/2021 à 23:27, didier gaumet a écrit : > > j'aurais dû me relire avant de poster, prière de corriger: > > [...] > > installer firefox de unstable, il te faut paramétrer une règle firefox > > d'unstable avec une priorité 800 [...] > > si tu veux installer le > > paquet foo de Marillat, tu dois créer une règle pour ce paquet en début > > de fichier, avec aussi (comme firefox d'unstable) une priorité 800 [...] > > dans les 2 cas c'est 900 souhaites installer depuis unstable ou Marillat soit supérieure à ceux > de testing > Moi je veux l'inverse: que ceux de dmo ne soient pas prioritaires par rapport à testing Debian (sauf pour quelques paquets). Gaëtan signature.asc Description: This is a digitally signed message part
Re: apt pinning: j'y comprends rien !
Le 03/03/2021 à 23:27, didier gaumet a écrit : j'aurais dû me relire avant de poster, prière de corriger: [...] installer firefox de unstable, il te faut paramétrer une règle firefox d'unstable avec une priorité 800 [...] si tu veux installer le paquet foo de Marillat, tu dois créer une règle pour ce paquet en début de fichier, avec aussi (comme firefox d'unstable) une priorité 800 [...] dans les 2 cas c'est 900souhaites installer depuis unstable ou Marillat soit supérieure à ceux de testing
Re: apt pinning: j'y comprends rien !
Le 03/03/2021 à 21:52, Gaëtan Perrier a écrit : [...] Euh là je ne sais pas ça vient de la page man: Méthode pour suivre Testing ou Unstable Le fichier des préférences suivant affecte une priorité haute aux versions des paquets appartenant à la distribution testing, une priorité moindre aux versions appartenant à la distribution unstable et une priorité prohibitivement basse aux versions appartenant à d'autres distributions Debian. Package: * Pin: release a=testing Pin-Priority: 900 Package: * Pin: release a=unstable Pin-Priority: 800 Package: * Pin: release o=Debian Pin-Priority: -10 1) le cas détaillé ici est celui où il n'y a pas de version par défaut dans apt.conf (la page man de apt_preferences expose les différences des priorités qui sont affectées suivant qu'un version par défaut est définie ou non). Suivant que tu définis ou non une version par défaut dans apt.conf, tu ne dois pas affecter les mêmes priorités numériques (sans version par défaut la priorité de base est 500, avec, elle est de 990). 2) après consultation de la page man, l'exemple ci-dessus signifie que si par exemple dans ton sources.list tu as paramétré stable, testing, unstable et experimental, la règle générale sera de privilégier les paquets de testing par rapport à ceux de unstable et de totalement interdire ceux de stable et experimental. Si dans ce cas tu veux installer firefox de unstable, il te faut paramétrer une règle firefox d'unstable avec une priorité 800installé. Cette règle spécifique à un paquet doit figurer en début de fichier avant les règles générales 3) la priorité -10 de l'exemple ci-dessus me semble confirmer que le mécanisme Debian des préférences s'arrête à la première condition remplie (Debian Testing correspond à a=testing ET o=Debian) J'ai essayé de mettre la règle pour dmo en premier mais sans changement. Toujours rapporté à l'exemple ci-dessus, si tu veux installer le paquet foo de Marillat, tu dois créer une règle pour ce paquet en début de fichier, avec aussi (comme firefox d'unstable) une priorité 800 En fin de fichier tu laisses ta règle générale Marillat avec une priorité inférieure à 800.
Re: apt pinning: j'y comprends rien !
Le mardi 02 mars 2021 à 13:09 +0100, didier gaumet a écrit : > De ce que je comprends (mais j'ai peut-être pas tout compris, > apt_preferences m'a déjà surpris par le passé): > > - Les priorités négatives impliquent que tu forces l'interdiction > inconditionnelle d'installation des paquets qui en sont affectés (y > compris ceux dont l'absence risque de casser le système) > - C'est l'inverse des priorités supérieures ou égales à 1000 avec > lesquelles tu forces l'installation inconditionnelle des paquets qui en > sont affectés, même si cela risque de casser ton système (si tu veux > faire un downgrade global d'une distro Debian, tu en passes par là > (c'est risqué)) > > Donc quand tu déclares une Testing par défaut dans apt.conf (équivalant > à 990) et que tu déclares une priorité 800 pour le firefox de Unstable, > ce dernier ne peut être installé (c'est bien ce que tu recherches? > installer un firefox Unstable dans ta Testing?). Oui je cherche à installer le firefox de sid sur testing. > De même, lorsque tu déclares en priorité -10 des paquets o=Debian ça > doit probablement signifier sur ton système que seuls les paquets > Marillat sont installables (ils ont une priorité 990 si tu as paramétré > ton sources.list avec Marillat Testing) Euh là je ne sais pas ça vient de la page man: Méthode pour suivre Testing ou Unstable Le fichier des préférences suivant affecte une priorité haute aux versions des paquets appartenant à la distribution testing, une priorité moindre aux versions appartenant à la distribution unstable et une priorité prohibitivement basse aux versions appartenant à d'autres distributions Debian. Package: * Pin: release a=testing Pin-Priority: 900 Package: * Pin: release a=unstable Pin-Priority: 800 Package: * Pin: release o=Debian Pin-Priority: -10 > > Je pense aussi qu'il est mieux de commencer l'écriture du fichier > apt_preferences par les cas particuliers pour aller vers le cas général: > lorsqu'un paquet est testé par rapport à ces préférences, il est > possible que le test s'arrête dès la première condition remplie > J'ai essayé de mettre la règle pour dmo en premier mais sans changement. Gaëtan signature.asc Description: This is a digitally signed message part
Re: apt pinning: j'y comprends rien !
De ce que je comprends (mais j'ai peut-être pas tout compris, apt_preferences m'a déjà surpris par le passé): - Les priorités négatives impliquent que tu forces l'interdiction inconditionnelle d'installation des paquets qui en sont affectés (y compris ceux dont l'absence risque de casser le système) - C'est l'inverse des priorités supérieures ou égales à 1000 avec lesquelles tu forces l'installation inconditionnelle des paquets qui en sont affectés, même si cela risque de casser ton système (si tu veux faire un downgrade global d'une distro Debian, tu en passes par là (c'est risqué)) Donc quand tu déclares une Testing par défaut dans apt.conf (équivalant à 990) et que tu déclares une priorité 800 pour le firefox de Unstable, ce dernier ne peut être installé (c'est bien ce que tu recherches? installer un firefox Unstable dans ta Testing?). De même, lorsque tu déclares en priorité -10 des paquets o=Debian ça doit probablement signifier sur ton système que seuls les paquets Marillat sont installables (ils ont une priorité 990 si tu as paramétré ton sources.list avec Marillat Testing) Je pense aussi qu'il est mieux de commencer l'écriture du fichier apt_preferences par les cas particuliers pour aller vers le cas général: lorsqu'un paquet est testé par rapport à ces préférences, il est possible que le test s'arrête dès la première condition remplie
Re: apt pinning: j'y comprends rien !
Le mardi 02 mars 2021 à 10:30 +0100, didier gaumet a écrit : > En fait j'ai l'impression que tu te trompes sur les priorités, en > considérant qu'un nombre faible signifie une priorité élevée, alors que > c'est l'inverse ;-) > > C'est ta détermination de priorités -10 pour o=Debian et 800 pour > firefox d'unstable avec une distribution Testing à 990 qui me le > laissent supposer... > > Extrait de la page man d'apt_preferences: > [...] > Méthode d'interprétation des priorités par APT > Les priorités (P) indiquées dans le fichier des préférences > doivent être des entiers positifs ou négatifs. Ils sont interprétés à > peu près > comme suit : > > P >= 1000 > cette priorité entraîne l'installation du paquet même s'il > s'agit d'un retour en arrière. > > 990 <= P < 1000 > la version sera installée, même si elle n'appartient pas à > la distribution par défaut ; mais elle ne sera pas installée si la version > installée est plus récente. > > 500 <= P < 990 > La version sera installée, sauf s'il existe une version > appartenant à la distribution par défaut ou si la version installée est plus > récente. > > 100 <= P < 500 > la version sera installée, sauf s'il existe une version > appartenant à une autre distribution ou si la version installée est plus > récente. > > 0 < P < 100 > la version sera installée si aucune version du paquet n'est > installée. > > P < 0 > cette priorité empêche l'installation de la version. > > P = 0 > a un comportement indéfini, ne pas l'utiliser. > [...] > Non j'ai bien compris que plus P est élevé plus c'est prioritaire. C'est pour ça que pour dmo j'ai mis 10. Je me suis basé sur cette manpage qui d'ailleurs manque de cohérence car dans la passage que tu indiques ça semble dire que P doit-être > 0 mais pourtant ensuite dans les exemple il y a des valeurs négatives ... Gaëtan signature.asc Description: This is a digitally signed message part
Re: apt pinning: j'y comprends rien !
Le mardi 02 mars 2021 à 02:57 +0100, Jérémy Prego a écrit : > > > > Package: * > > Pin: release o=Unofficial Multimedia Packages,a=testing > > Pin: origin *.deb-multimedia.org > > Pin-Priority: 10 > je ne suis pas convaincu qu'il est bien d'avoir deux pin pour une même > règle :) c'est peut être pour ça que ça ne fonctionne pas ... > J'ai essayé avec seulement l'une ou l'autre et ça ne change rien ... Gaëtan signature.asc Description: This is a digitally signed message part
Re: apt pinning: j'y comprends rien !
En fait j'ai l'impression que tu te trompes sur les priorités, en considérant qu'un nombre faible signifie une priorité élevée, alors que c'est l'inverse ;-) C'est ta détermination de priorités -10 pour o=Debian et 800 pour firefox d'unstable avec une distribution Testing à 990 qui me le laissent supposer... Extrait de la page man d'apt_preferences: [...] Méthode d'interprétation des priorités par APT Les priorités (P) indiquées dans le fichier des préférences doivent être des entiers positifs ou négatifs. Ils sont interprétés à peu près comme suit : P >= 1000 cette priorité entraîne l'installation du paquet même s'il s'agit d'un retour en arrière. 990 <= P < 1000 la version sera installée, même si elle n'appartient pas à la distribution par défaut ; mais elle ne sera pas installée si la version installée est plus récente. 500 <= P < 990 La version sera installée, sauf s'il existe une version appartenant à la distribution par défaut ou si la version installée est plus récente. 100 <= P < 500 la version sera installée, sauf s'il existe une version appartenant à une autre distribution ou si la version installée est plus récente. 0 < P < 100 la version sera installée si aucune version du paquet n'est installée. P < 0 cette priorité empêche l'installation de la version. P = 0 a un comportement indéfini, ne pas l'utiliser. [...]
Re: apt pinning: j'y comprends rien !
Le 02/03/2021 à 02:35, Gaëtan Perrier a écrit : > Le mardi 02 mars 2021 à 01:47 +0100, Jérémy Prego a écrit : >> bonjour, >> >> Le 02/03/2021 à 00:48, Gaëtan Perrier a écrit : >>> Bonjour, >>> >>> Je suis en testing, j'ai plusieurs dépôts sources dont deb-multimedia.org >>> J'aimerai ne prendre que certains paquets dans ce dépôt et j'aimerai aussi >>> ne >>> prendre que quelques paquets dans sid. >>> Dans /etc/apt/apt.conf j'ai >>> >>> APT::Default-Release "testing"; >> Pour moi, le souci est là. vu que les paquets deb-multimedia tu les >> récupère aussi sous testing du dépots deb-multimedia, ils ont la même >> priorité. tu devrais retirer cette ligne et faire tout par le fichier >> preferences ou au moins modifier le fichier comme je le propose plus bas. > > Si je désactive cette ligne le reste semble ne plus du tout être pris en > compte > ... (voir plus bas) > >>> Ensuite j'ai donc créé un fichier mypref dans /etc/apt/preferences.d/. Dans >>> celui-ci j'ai mis en partant de ce que j'ai trouvé dans le man: >>> >>> Package: * >>> Pin: release a=testing >>> Pin-Priority: 990 >> ça non plus c'est pas bon, la règle est trop large. pour que ça prenne >> que le testing de debian, tu devrai plutôt faire: >> Package: * >> Pin: release o=Debian,n=testing >> Pin-Priority: 990 > pourquoi "n=testing" alors que apt policy indique "a=testing" ? parce que je me suis trompé :) c'est bien o=Debian,a=testing >> bien qu'à mon sens, ça ne soit pas nécessaire, si tu te contente de >> descendre les autres dépots, le debian testing restera la priorité > si je retire Default-release et aussi cette règle c'est unstable qui prend le > dessus ... > >>> Package: firefox firefox-l10n* >>> Pin: release a=unstable >>> Pin-Priority: 800 >> ici aussi ne pas hésiter a bien dire de quel dépots tu souhaites que >> soit récupérer ton logiciel, surtout si le logiciel peut venir de >> plusieurs dépots s'appelant aussi unstable. afin de t'aider pour savoir >> quoi mettre, tu peux t'aider de la commande "apt policy". ça t'affichera >> toutes les valeurs que tu peux compilé pour un dépots; généralement en >> utiliser deux, ça suffit pour bien localiser le dépots que tu cherches à >> sibler >> > Donc en m'appuyant sur apt policy et tes commentaires j'ai viré le apt.conf et > modifié mypref comme ceci: > > Package: firefox firefox-l10n* > Pin: release o=Debian,a=unstable > Pin-Priority: 800 > > Package: * > Pin: release o=Unofficial Multimedia Packages,a=testing > Pin: origin *.deb-multimedia.org > Pin-Priority: 10 je ne suis pas convaincu qu'il est bien d'avoir deux pin pour une même règle :) c'est peut être pour ça que ça ne fonctionne pas ... > Résultat apt policy met tout à 500 et unstable et dmo prennent le dessus. > > Gaëtan > > > >
Re: apt pinning: j'y comprends rien !
Le mardi 02 mars 2021 à 01:47 +0100, Jérémy Prego a écrit : > bonjour, > > Le 02/03/2021 à 00:48, Gaëtan Perrier a écrit : > > Bonjour, > > > > Je suis en testing, j'ai plusieurs dépôts sources dont deb-multimedia.org > > J'aimerai ne prendre que certains paquets dans ce dépôt et j'aimerai aussi > > ne > > prendre que quelques paquets dans sid. > > Dans /etc/apt/apt.conf j'ai > > > > APT::Default-Release "testing"; > Pour moi, le souci est là. vu que les paquets deb-multimedia tu les > récupère aussi sous testing du dépots deb-multimedia, ils ont la même > priorité. tu devrais retirer cette ligne et faire tout par le fichier > preferences ou au moins modifier le fichier comme je le propose plus bas. Si je désactive cette ligne le reste semble ne plus du tout être pris en compte ... (voir plus bas) > > Ensuite j'ai donc créé un fichier mypref dans /etc/apt/preferences.d/. Dans > > celui-ci j'ai mis en partant de ce que j'ai trouvé dans le man: > > > > Package: * > > Pin: release a=testing > > Pin-Priority: 990 > ça non plus c'est pas bon, la règle est trop large. pour que ça prenne > que le testing de debian, tu devrai plutôt faire: > Package: * > Pin: release o=Debian,n=testing > Pin-Priority: 990 pourquoi "n=testing" alors que apt policy indique "a=testing" ? > > bien qu'à mon sens, ça ne soit pas nécessaire, si tu te contente de > descendre les autres dépots, le debian testing restera la priorité si je retire Default-release et aussi cette règle c'est unstable qui prend le dessus ... > > Package: firefox firefox-l10n* > > Pin: release a=unstable > > Pin-Priority: 800 > ici aussi ne pas hésiter a bien dire de quel dépots tu souhaites que > soit récupérer ton logiciel, surtout si le logiciel peut venir de > plusieurs dépots s'appelant aussi unstable. afin de t'aider pour savoir > quoi mettre, tu peux t'aider de la commande "apt policy". ça t'affichera > toutes les valeurs que tu peux compilé pour un dépots; généralement en > utiliser deux, ça suffit pour bien localiser le dépots que tu cherches à > sibler > Donc en m'appuyant sur apt policy et tes commentaires j'ai viré le apt.conf et modifié mypref comme ceci: Package: firefox firefox-l10n* Pin: release o=Debian,a=unstable Pin-Priority: 800 Package: * Pin: release o=Unofficial Multimedia Packages,a=testing Pin: origin *.deb-multimedia.org Pin-Priority: 10 Résultat apt policy met tout à 500 et unstable et dmo prennent le dessus. Gaëtan signature.asc Description: This is a digitally signed message part
Re: apt pinning: j'y comprends rien !
bonjour, Le 02/03/2021 à 00:48, Gaëtan Perrier a écrit : > Bonjour, > > Je suis en testing, j'ai plusieurs dépôts sources dont deb-multimedia.org > J'aimerai ne prendre que certains paquets dans ce dépôt et j'aimerai aussi ne > prendre que quelques paquets dans sid. > Dans /etc/apt/apt.conf j'ai > > APT::Default-Release "testing"; Pour moi, le souci est là. vu que les paquets deb-multimedia tu les récupère aussi sous testing du dépots deb-multimedia, ils ont la même priorité. tu devrais retirer cette ligne et faire tout par le fichier preferences ou au moins modifier le fichier comme je le propose plus bas. > Ensuite j'ai donc créé un fichier mypref dans /etc/apt/preferences.d/. Dans > celui-ci j'ai mis en partant de ce que j'ai trouvé dans le man: > > Package: * > Pin: release a=testing > Pin-Priority: 990 ça non plus c'est pas bon, la règle est trop large. pour que ça prenne que le testing de debian, tu devrai plutôt faire: Package: * Pin: release o=Debian,n=testing Pin-Priority: 990 bien qu'à mon sens, ça ne soit pas nécessaire, si tu te contente de descendre les autres dépots, le debian testing restera la priorité > Package: firefox firefox-l10n* > Pin: release a=unstable > Pin-Priority: 800 ici aussi ne pas hésiter a bien dire de quel dépots tu souhaites que soit récupérer ton logiciel, surtout si le logiciel peut venir de plusieurs dépots s'appelant aussi unstable. afin de t'aider pour savoir quoi mettre, tu peux t'aider de la commande "apt policy". ça t'affichera toutes les valeurs que tu peux compilé pour un dépots; généralement en utiliser deux, ça suffit pour bien localiser le dépots que tu cherches à sibler > Package: * > Pin: release a=unstable > Pin-Priority: 800 > > Package: * > Pin: origin *.deb-multimedia.org > Pin-Priority: 10 > > Package: * > Pin: release o=Debian > Pin-Priority: -10 > Résultat c'est aussi efficace que de pisser dans un violon. > Les paquets venant de deb-multimedia.org prennent le dessus. Par exemple: > > apt-cache policy vlc > vlc: > Installé : 3.0.12-2 > Candidat : 1:3.0.12-dmo2 > Table de version : > 1:3.0.12-dmo2 990 > 990 http://www.deb-multimedia.org testing/main amd64 Packages > *** 3.0.12-2 990 > 990 http://ftp.debian.org/debian testing/main amd64 Packages > 500 http://ftp.debian.org/debian sid/main amd64 Packages > 100 /var/lib/dpkg/status > > Je ne comprends pas pourquoi le paquet venant de dmo a un pinning de 990 ? > > Gaëtan Jerem
apt pinning: j'y comprends rien !
Bonjour, Je suis en testing, j'ai plusieurs dépôts sources dont deb-multimedia.org J'aimerai ne prendre que certains paquets dans ce dépôt et j'aimerai aussi ne prendre que quelques paquets dans sid. Dans /etc/apt/apt.conf j'ai APT::Default-Release "testing"; Ensuite j'ai donc créé un fichier mypref dans /etc/apt/preferences.d/. Dans celui-ci j'ai mis en partant de ce que j'ai trouvé dans le man: Package: * Pin: release a=testing Pin-Priority: 990 Package: firefox firefox-l10n* Pin: release a=unstable Pin-Priority: 800 Package: * Pin: release a=unstable Pin-Priority: 800 Package: * Pin: origin *.deb-multimedia.org Pin-Priority: 10 Package: * Pin: release o=Debian Pin-Priority: -10 Résultat c'est aussi efficace que de pisser dans un violon. Les paquets venant de deb-multimedia.org prennent le dessus. Par exemple: apt-cache policy vlc vlc: Installé : 3.0.12-2 Candidat : 1:3.0.12-dmo2 Table de version : 1:3.0.12-dmo2 990 990 http://www.deb-multimedia.org testing/main amd64 Packages *** 3.0.12-2 990 990 http://ftp.debian.org/debian testing/main amd64 Packages 500 http://ftp.debian.org/debian sid/main amd64 Packages 100 /var/lib/dpkg/status Je ne comprends pas pourquoi le paquet venant de dmo a un pinning de 990 ? Gaëtan signature.asc Description: This is a digitally signed message part
Re: [apt-pinning] always install given package and its deps from unstable
On Jo, 16 ian 20, 10:15:59, Greg Wooledge wrote: > On Thu, Jan 16, 2020 at 05:09:36PM +0200, Andrei POPESCU wrote: > > Well, 'apt upgrade' is not allowed to install new packages anyway, > > Actually, it is. You're thinking of apt-get. Ugh, right. Thanks for the correction. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: [apt-pinning] always install given package and its deps from unstable
On Thu, Jan 16, 2020 at 05:09:36PM +0200, Andrei POPESCU wrote: > Well, 'apt upgrade' is not allowed to install new packages anyway, Actually, it is. You're thinking of apt-get.
Re: [apt-pinning] always install given package and its deps from unstable
On Jo, 16 ian 20, 08:22:53, The Wanderer wrote:
> On 2020-01-16 at 04:38, Andrei POPESCU wrote:
> >
> > This should work with the same technique used for backports: pin
> > unstable to priority 100 (the same priority as installed packages).
> >
> > New packages must be installed with '-t sid', already installed packages
> > will be upgraded as needed.
>
> What will then happen if a new version of firefox grows a dependency on
> a new package, which is only available (at suitable version, anyway) in
> sid?
>
> The "and its deps" criterion is what makes this tricky, I think.
Well, 'apt upgrade' is not allowed to install new packages anyway, so it
will just not upgrade the package and will inform the user ("packages
have been held back").
One should then be able to fix it with 'apt install -t sid PACKAGE',
which is allowed to pull in dependencies, from the other suite if
necessary.
Not sure what happens on 'apt full-upgrade' though.
My recommendation (for any kind of system) would be to use it only as a
last resort and carefully examine what it is about to do. aptitude's
-v/--verbose is very useful in such cases, because it also shows package
versions.
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
signature.asc
Description: PGP signature
Re: [apt-pinning] always install given package and its deps from unstable
On 2020-01-16 at 04:38, Andrei POPESCU wrote: > On Mi, 15 ian 20, 12:12:53, Samuel Henrique wrote: > >> Hello people, >> >> These days I'm wondering what's the correct approach to have the >> following behaviour: >> >> * Using Testing >> * Always install firefox (or some other packages) and its deps from the >> unstable repository >> * Keep downloading upgrades of these packages from unstable >> * Don't install anything else from unstable unless the I'm using "apt -t >> sid install" > > This should work with the same technique used for backports: pin > unstable to priority 100 (the same priority as installed packages). > > New packages must be installed with '-t sid', already installed packages > will be upgraded as needed. What will then happen if a new version of firefox grows a dependency on a new package, which is only available (at suitable version, anyway) in sid? The "and its deps" criterion is what makes this tricky, I think. > Disclaimer: mixing packages from different releases is inherently > dangerous. If above breaks you get to keep all pieces. Yeah, that's why I don't just test this to find out so that I can answer my own question; I don't currently have a machine I'm willing to risk. I've gotten one machine into a state which, if not necessarily unfixable without a reinstall, was still more trouble to try to fix than I wanted to, by tracking testing + sid; nowadays I track stable + testing instead. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: [apt-pinning] always install given package and its deps from unstable
On Mi, 15 ian 20, 12:12:53, Samuel Henrique wrote: > Hello people, > > These days I'm wondering what's the correct approach to have the > following behaviour: > > * Using Testing > * Always install firefox (or some other packages) and its deps from the > unstable repository > * Keep downloading upgrades of these packages from unstable > * Don't install anything else from unstable unless the I'm using "apt -t > sid install" This should work with the same technique used for backports: pin unstable to priority 100 (the same priority as installed packages). New packages must be installed with '-t sid', already installed packages will be upgraded as needed. Beware: if a package exists in unstable but not testing it will be installed without '-t sid'. Disclaimer: mixing packages from different releases is inherently dangerous. If above breaks you get to keep all pieces. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
[apt-pinning] always install given package and its deps from unstable
Hello people, These days I'm wondering what's the correct approach to have the following behaviour: * Using Testing * Always install firefox (or some other packages) and its deps from the unstable repository * Keep downloading upgrades of these packages from unstable * Don't install anything else from unstable unless the I'm using "apt -t sid install" I've tried somethings in the past, like using apt pinning to set everything from unstable to -1, and firefox to something else, but it doesn't seems to work exactly how I intended to. I don't remember the details about what exactly didn't work*, so I would like to get some examples of people who are accomplishing the same and how they have chosen to do so, as opposed to debug my scenario. * If I remember correctly, I still needed to use "-t sid" to install firefox in that case, I don't remember what priority I was setting though. -- Samuel Henrique
Re: apt pinning: find out from which system version is a package
On Fri 03 May 2019 at 23:09:58 (+0200), Emanuel Berg wrote: > tomas wrote: > > >> That's some heavy parsing, only I don't get > >> it to work. I get "no such file or directory: > >> " from the first, apt-cache-dump invocation. > > > > This is because it's spelt "apt-cache dump", > > I guess ;-) > > No, then it says "zsh: command not found:" :) Unless you paste something that shows what you actually did, I don't see that this reply advances the thread. I've no idea whether using zsh instead of bash has any syntactical implications. If binaries such as apt-cache and dpkg-query are inaccessible, that's for you to fix. AFAIK their packages are either essential or important. I presume you realise that "$Unique1" is a temporary file. Because I create them with mktemp, I have to redirect using >> rather than > to circumvent bash's noclobber. Finally, my script fragment was designed to yield information in bulk, ie for all packages, because your OP contained 'dpkg -l'. But having now seen your optimal requirement for '$ from-what-release foo', my script is probably overkill. Cheers, David.
Re: apt pinning: find out from which system version is a package
tomas wrote: >> That's some heavy parsing, only I don't get >> it to work. I get "no such file or directory: >> " from the first, apt-cache-dump invocation. > > This is because it's spelt "apt-cache dump", > I guess ;-) No, then it says "zsh: command not found:" :) -- underground experts united http://user.it.uu.se/~embe8573
Re: apt pinning: find out from which system version is a package
On Fri 03 May 2019 at 03:46:50 (+0200), Emanuel Berg wrote:
> David Wright wrote:
>
> > $ apt-cache dump | grep -A 2 '^Package:' | grep -B 2 '^ File:' | sed -e
> > 'N;N;s/\n/ /g;s/ \+/ /g;N' | grep -v '^--' | sort >> "$Unique1"
> > $ dpkg-query -W -f '^Package: ${Package} \n' | grep --file=- "$Unique1" |
> > sort
>
> That's some heavy parsing,
You wrote "no worries, I can make a zsh function and have them next to
each other" so I guess you're up to it …
> only I don't get it
> to work. I get "no such file or directory: "
> from the first, apt-cache-dump invocation.
… but I advise that you cut and paste.
> Maybe do a shell function of it (whatever shell
> you prefer)?
Don't think that I type this stuff into the command line itself.
This is just one part of a bash function that writes five files
to an archive, the output from dpkg -l, just the package names,
packages and versions, apt-show-versions, and the process above
which is named "origins".
These files can then be inspected, diffed etc, at leisure even
while the host concerned is not running.
> Also I don't understand where the argument
> goes? Where is ${Package} defined, even tho it
> didn't (for me) even get that far?
It's nothing to do with bash, as it's protected by '',
but see man dpkg-query just above 'EXIT STATUS'.
Cheers,
David.
Re: apt pinning: find out from which system version is a package
On Fri, May 03, 2019 at 03:46:50AM +0200, Emanuel Berg wrote:
> David Wright wrote:
>
> > $ dpkg-query -W -f '^Package: ${Package} \n' | grep --file=- "$Unique1" |
> > sort
> Also I don't understand where the argument
> goes? Where is ${Package} defined, even tho it
> didn't (for me) even get that far?
It's in single quotes, not double quotes. Therefore it is NOT expanded
by the shell. The shell passes that string verbatim to the dpkg-query
command.
So the question becomes, what does ${Package} mean to dpkg-query?
Therefore, we consult the man page:
Package information can be included by inserting variable
referencestopackagefieldsusingthe syntax
“${field[;width]}”. [...]
The following fields are recognized [...]:
[...]
Maintainer
Origin
Package
Pre-Depends
[...]
And there you go.
Re: apt pinning: find out from which system version is a package
On Fri, May 03, 2019 at 03:30:13AM +0200, Emanuel Berg wrote: > Optimally I'd like it like this: > > $ from-what-release w3m-el-snapshot > testing The problem here is the packaging system does not KNOW from which source a package came, after it is installed. The best you can do is try to guess. If the installed version of the package happens to match up with one of the CURRENT package lists, then you could report that. Otherwise, if the version string contains "+deb9u" then it probably came from a stretch security update. Likewise, if it contains "+deb8u" then it probably came from a jessie security update. And so on. If none of those things happens to be true, then there's really no way to know.
Re: apt pinning: find out from which system version is a package
On Fri, May 03, 2019 at 03:46:50AM +0200, Emanuel Berg wrote:
> David Wright wrote:
>
> > $ apt-cache dump | grep -A 2 '^Package:' | grep -B 2 '^ File:' | sed -e
> > 'N;N;s/\n/ /g;s/ \+/ /g;N' | grep -v '^--' | sort >> "$Unique1"
> > $ dpkg-query -W -f '^Package: ${Package} \n' | grep --file=- "$Unique1" |
> > sort
>
> That's some heavy parsing, only I don't get it
> to work. I get "no such file or directory: "
> from the first, apt-cache-dump invocation.
^^^
This is because it's spelt "apt-cache dump", I guess ;-)
Cheers
-- t
signature.asc
Description: Digital signature
Re: apt pinning: find out from which system version is a package
Toni Mas wrote: > apt-show-versions script are useful as well. > apt-show-versions is a package itself. It sure is and it sure is exactly what I'm looking for with no need to parse the output to get it exactly to the point: $ apt-show-versions w3m-el-snapshot w3m-el-snapshot:all/testing 1.4.632+0.20181112-2 uptodate -- underground experts united http://user.it.uu.se/~embe8573
Re: apt pinning: find out from which system version is a package
One can also do it like this: $ aptitude versions w3m-el-snapshot Package w3m-el-snapshot: p 1.4.569+0.20170110-1 stable 500 i 1.4.632+0.20181112-2 testing 800 -- underground experts united http://user.it.uu.se/~embe8573
Re: apt pinning: find out from which system version is a package
Francisco M Neto wrote: >> But is there a way to find out/confirm from >> which release is a certain pack? > > You're looking for apt-cache policy. [...] > > $ apt-cache policy gnome-core > gnome-core: > Installed: 1:3.30+1 > Candidate: 1:3.30+1 > Version table: > *** 1:3.30+1 900 > 900 http://sft.if.usp.br/debian buster/main amd64 Packages > 800 http://sft.if.usp.br/debian sid/main amd64 Packages > 100 /var/lib/dpkg/status > 1:3.22+3 400 > 400 http://sft.if.usp.br/debian stretch/main amd64 Packages Right, now I see it! Alexander V Makartsev already told me this, but I got distracted by the _first_ thing he showed me :$ Like a jab in boxing, if thrown good enough, it makes you not see the cross coming from behind... OK, well then, thank you both! -- underground experts united http://user.it.uu.se/~embe8573
Re: apt pinning: find out from which system version is a package
David Wright wrote:
> $ apt-cache dump | grep -A 2 '^Package:' | grep -B 2 '^ File:' | sed -e
> 'N;N;s/\n/ /g;s/ \+/ /g;N' | grep -v '^--' | sort >> "$Unique1"
> $ dpkg-query -W -f '^Package: ${Package} \n' | grep --file=- "$Unique1" | sort
That's some heavy parsing, only I don't get it
to work. I get "no such file or directory: "
from the first, apt-cache-dump invocation.
Maybe do a shell function of it (whatever shell
you prefer)?
Also I don't understand where the argument
goes? Where is ${Package} defined, even tho it
didn't (for me) even get that far?
--
underground experts united
http://user.it.uu.se/~embe8573
Re: apt pinning: find out from which system version is a package
Alexander V. Makartsev wrote: > You can check what branches have the package > you want with "rmadison" command. > > Example: > $ sudo apt install devscripts > $ rmadison linux-image-amd64 > linux-image-amd64 | 3.16+63+deb8u2 | oldstable | amd64, i386 > linux-image-amd64 | 4.9+80+deb9u7 | stable | amd64 > linux-image-amd64 | 4.19+104~bpo9+1 | stretch-backports | amd64 > linux-image-amd64 | 4.19+104 | testing | amd64 > linux-image-amd64 | 4.19+104 | unstable | amd64 > > You can check what package will be installed with "apt-cache" command. > Example: > $ apt-cache policy linux-image-amd64 > linux-image-amd64: > Installed: 4.15+91~bpo9+1 > [...] Priviet and good answer! Still two invocations, but no worries, I can make a zsh function and have them next to each other, and then drop the unnecessary stuff :) Thank you! -- underground experts united http://user.it.uu.se/~embe8573
Re: apt pinning: find out from which system version is a package
Jonas Smedegaard wrote: > Add file > /etc/apt/apt.conf.d/99aptitude-list-suite-local > eith the following one-line content: > > aptitude::UI::Package-Display-Format "%c%a%M%S %p %Z %t %v %V"; > > ...and install and use aptitude in fullscreen > mode (i.e. start it with no non-option > arguments). No lack of hacker points in this answer but I don't like fullscreen shell tools, that's actually the opposite of what I like with the shell. Optimally I'd like it like this: $ from-what-release w3m-el-snapshot testing Still, thank you for the answer. -- underground experts united http://user.it.uu.se/~embe8573
Re: apt pinning: find out from which system version is a package
apt-show-versions script are useful as well. apt-show-versions is a package itself. Toni Mas Missatge de Francisco M Neto del dia dl., 29 d’abr. 2019 a les 23:10: > > Greetings! > > > On Mon, 2019-04-29 at 05:30 +0200, Emanuel Berg wrote: > > But is there a way to find out/confirm from > > which release is a certain pack? > > You're looking for apt-cache policy. > > Example: > > == > > $ apt-cache policy gnome-core > gnome-core: > Installed: 1:3.30+1 > Candidate: 1:3.30+1 > Version table: > *** 1:3.30+1 900 > 900 http://sft.if.usp.br/debian buster/main amd64 Packages > 800 http://sft.if.usp.br/debian sid/main amd64 Packages > 100 /var/lib/dpkg/status > 1:3.22+3 400 > 400 http://sft.if.usp.br/debian stretch/main amd64 Packages > > == > > > -- > []'s, > > Francisco M Neto > > GPG: 4096R/D692FBF0
Re: apt pinning: find out from which system version is a package
Greetings! On Mon, 2019-04-29 at 05:30 +0200, Emanuel Berg wrote: > But is there a way to find out/confirm from > which release is a certain pack? You're looking for apt-cache policy. Example: == $ apt-cache policy gnome-core gnome-core: Installed: 1:3.30+1 Candidate: 1:3.30+1 Version table: *** 1:3.30+1 900 900 http://sft.if.usp.br/debian buster/main amd64 Packages 800 http://sft.if.usp.br/debian sid/main amd64 Packages 100 /var/lib/dpkg/status 1:3.22+3 400 400 http://sft.if.usp.br/debian stretch/main amd64 Packages == -- []'s, Francisco M Neto GPG: 4096R/D692FBF0 signature.asc Description: This is a digitally signed message part
Re: apt pinning: find out from which system version is a package
On Mon 29 Apr 2019 at 05:30:30 (+0200), Emanuel Berg wrote:
> With apt pinning [1], in /etc/apt/preferences ,
> I have learned that one can have certain packs
> from another release than the rest of the
> system, seemlessly (?) with apt-get and the
> other tools, for example like this for
> w3m-el-snapshot:
>
> Package: *
> Pin: release a=testing
> Pin-Priority: -10
>
> Package: w3m-el-snapshot
> Pin: release a=testing
> Pin-Priority: 800
>
> But is there a way to find out/confirm from
> which release is a certain pack? I know about
> 'aptitude show' but save for the version, which
> I suppose one could Google and compare (poor
> man's solution IMO), it doesn't seem to say
> what I can see.
>
> Neither does 'dpkg -l'.
>
> So is there a way to do this with shell tool(s)?
apt-show-versions can give you a good idea. Occasionally,
and after major upgrades, I archive the output of:
$ apt-cache dump | grep -A 2 '^Package:' | grep -B 2 '^ File:' | sed -e
'N;N;s/\n/ /g;s/ \+/ /g;N' | grep -v '^--' | sort >> "$Unique1"
$ dpkg-query -W -f '^Package: ${Package} \n' | grep --file=- "$Unique1" | sort
Cheers,
David.
Re: apt pinning: find out from which system version is a package
On 29.04.2019 10:35, Jonas Smedegaard wrote: > Quoting Emanuel Berg (2019-04-29 05:30:30) >> With apt pinning [1], in /etc/apt/preferences , >> I have learned that one can have certain packs >> from another release than the rest of the >> system, seemlessly (?) with apt-get and the >> other tools, for example like this for >> w3m-el-snapshot: >> >> Package: * >> Pin: release a=testing >> Pin-Priority: -10 >> >> Package: w3m-el-snapshot >> Pin: release a=testing >> Pin-Priority: 800 >> >> But is there a way to find out/confirm from >> which release is a certain pack? I know about >> 'aptitude show' but save for the version, which >> I suppose one could Google and compare (poor >> man's solution IMO), it doesn't seem to say >> what I can see. >> >> Neither does 'dpkg -l'. >> >> So is there a way to do this with shell >> tool(s)? > Add file /etc/apt/apt.conf.d/99aptitude-list-suite-local > eith the following one-line content: > > aptitude::UI::Package-Display-Format "%c%a%M%S %p %Z %t %v %V"; > > ...and install and use aptitude in fullscreen mode (i.e. start it with > no non-option arguments). > > - Jonas > You can check what branches have the package you want with "rmadison" command. Example: $ sudo apt install devscripts $ rmadison linux-image-amd64 linux-image-amd64 | 3.16+63+deb8u2 | oldstable | amd64, i386 linux-image-amd64 | 4.9+80+deb9u7 | stable | amd64 linux-image-amd64 | 4.19+104~bpo9+1 | stretch-backports | amd64 linux-image-amd64 | 4.19+104 | testing | amd64 linux-image-amd64 | 4.19+104 | unstable | amd64 You can check what package will be installed with "apt-cache" command. Example: $ apt-cache policy linux-image-amd64 linux-image-amd64: Installed: 4.15+91~bpo9+1 Candidate: 4.19+104~bpo9+1 Version table: 4.19+104~bpo9+1 100 100 https://mirror.yandex.ru/debian stretch-backports/main amd64 Packages *** 4.15+91~bpo9+1 100 100 /var/lib/dpkg/status 4.9+80+deb9u7 500 500 https://mirror.yandex.ru/debian stretch/main amd64 Packages 4.9+80+deb9u6 500 500 http://security.debian.org/debian-security stretch/updates/main amd64 Packages -- With kindest regards, Alexander. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org ⠈⠳⣄
Re: apt pinning: find out from which system version is a package
Quoting Emanuel Berg (2019-04-29 05:30:30) > With apt pinning [1], in /etc/apt/preferences , > I have learned that one can have certain packs > from another release than the rest of the > system, seemlessly (?) with apt-get and the > other tools, for example like this for > w3m-el-snapshot: > > Package: * > Pin: release a=testing > Pin-Priority: -10 > > Package: w3m-el-snapshot > Pin: release a=testing > Pin-Priority: 800 > > But is there a way to find out/confirm from > which release is a certain pack? I know about > 'aptitude show' but save for the version, which > I suppose one could Google and compare (poor > man's solution IMO), it doesn't seem to say > what I can see. > > Neither does 'dpkg -l'. > > So is there a way to do this with shell > tool(s)? Add file /etc/apt/apt.conf.d/99aptitude-list-suite-local eith the following one-line content: aptitude::UI::Package-Display-Format "%c%a%M%S %p %Z %t %v %V"; ...and install and use aptitude in fullscreen mode (i.e. start it with no non-option arguments). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
apt pinning: find out from which system version is a package
With apt pinning [1], in /etc/apt/preferences , I have learned that one can have certain packs from another release than the rest of the system, seemlessly (?) with apt-get and the other tools, for example like this for w3m-el-snapshot: Package: * Pin: release a=testing Pin-Priority: -10 Package: w3m-el-snapshot Pin: release a=testing Pin-Priority: 800 But is there a way to find out/confirm from which release is a certain pack? I know about 'aptitude show' but save for the version, which I suppose one could Google and compare (poor man's solution IMO), it doesn't seem to say what I can see. Neither does 'dpkg -l'. So is there a way to do this with shell tool(s)? TIA [1] https://wiki.debian.org/AptPreferences -- underground experts united http://user.it.uu.se/~embe8573
Apt-Pinning Preferences ignored when Ign InRelease Files
I have a 3rd Party Repository added to apt sources, pinned via apt preferences so that Stable = 800, Testing = -1 apt-cache policy shows that this is the case. Several months of usage has also confirmed that it is working as intended. Recently, I ran apt-get update while my network connection was down. All of the InRelease/Release files were Ign. Connectivity was restored while update was in progress. update completed successfully with no errors/warnings. When I ran dist-ugprade, all of the packages from Testing were proposed as candidates. apt-cache policy showed that all repositories were pinned to 500. policy also revealed that the 3rd Party Repositories were missing all of their Release "tags", ie origin, codename, etc. which is why their pins were ignored. When update was run again, the Release files were downloaded and upgrade showed no new packages. 1. Why weren't the Release tags from the previous successful authenticated download used? 2. Why weren't there any messages indicating that the Release files were not complete? 3. Is there any way to enforce that Release files must be Hit or downloaded and not Ign? Thanks!
Apt pinning breaks apt-get update when net is temporarily down
Hi, yesterday I noticed something strange in the behavior of apt-get on my debian Jessie system. When I do apt-get update apt-get dist-upgrade the system is reported as up to date, no upgrades available - fine. Now I tried and simulated a temporarily broken internet connection (just to see what happens, because I worked on a script that is supposed to update the package database as a cron job) with a simple ifdown eth0, then ran apt-get update again, which of course threw a bunch of errors and finally exited (as I found later to my surprise with return code 0, but this is not the point). I was quite stunned then, when a subsequent apt-get dist-upgrade reported some 30 upgradable packages. After I established the network connection again and repeated apt-get update the system was up to date again. So far, so odd. Investigating the upgrades apt-get suggested in offline mode, I found that it were all packages from jessie-backports. Next thing I tried was a quick test with an old Laptop I have with an outdated LMDE install (which is basically Jessie as testing without many upgrades for 1 1/2 years or so), just to make sure the problem is not somewhere in the configuration of my desktop machine. So I added jessie-backports to the laptop's sources.list and got more or less the same result, up-to-date when online, a bunch of pending upgrades when offline. So finally I went back to my desktop machine and tried to add the debian testing repo and use pinning for it as described at https://wiki.debian.org/AptPreferences . Same result, only more dramatically looking; when online, apt-get update apt-get dist-upgrade report some 20 pending upgrades, repeating the procedure without network they suggest more than 1100 upgrades, which looks a lot like a whole system upgrade to testing. So this seems like pinning has no effect altogether when the network connection is down, I can hardly believe that this is supposed to be normal, is it? Or may there actually be such a bug in apt-get? Certainly this is not much trouble when the updates are handled manually, but looks it rather bad to me, when cron jobs are involved. Any insights are much appreciated. Thanks in advance, and best regards Michael .-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-. --- ... .--. . .-. Men will always be men -- no matter where they are. -- Harry Mudd, Mudd's Women, stardate 1329.8 -- 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/20150615011451.6464d5fab34f5a0a79ff9...@freenet.de
Re: apt-pinning, strange behavior
On 10/10/13 22:06, Dmitrii Kashin wrote: berenger.mo...@neutralite.org writes: In the same priority range, the package which will be installed is the one with the highest priority, so it is fine to have one set of package with 500 ( or I could take 600 or any other value ) for low priority, and the other at 900 ( or 800 or... ), so that the version with 900 will be installed against the lower one, even if the lower one is more recent. Oh... Truely? I thought differently and was sure I am right. I just skimmed again through apt_preferences man page, but did not find such examples or explanations. Where's it documented? For reference, the section in apt_preferences(5) that documents this is: APT then applies the following rules, listed in order of precedence, to determine which version of a package to install. · Never downgrade unless the priority of an available version exceeds 1000. (Downgrading is installing a less recent version of a package in place of a more recent version. Note that none of APT's default priorities exceeds 1000; such high priorities can only be set in the preferences file. Note also that downgrading a package can be risky.) · Install the highest priority version. · If two or more versions have the same priority, install the most recent one (that is, the one with the higher version number). · If two or more versions have the same priority and version number but either the packages differ in some of their metadata or the --reinstall option is given, install the uninstalled one. As you can see, it uses the priority first, and then the version number. -- 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/53107035.1040...@zoho.com
Re: apt-pinning, strange behavior
berenger.mo...@neutralite.org writes: Le 10.10.2013 23:06, Dmitrii Kashin a écrit : berenger.mo...@neutralite.org writes: In the same priority range, the package which will be installed is the one with the highest priority, so it is fine to have one set of package with 500 ( or I could take 600 or any other value ) for low priority, and the other at 900 ( or 800 or... ), so that the version with 900 will be installed against the lower one, even if the lower one is more recent. Oh... Truely? I thought differently and was sure I am right. Maybe you are right, but in that case, how would you explain the behavior I had if a package of a priority of 500 is considered to have the same priority as a package with 900 ? ;) My opinion was that priorities are used to determine which package of equal versions should be installed. And there is not difference if packages have different versions: only one with a higher version will be installed. Exception is different priority range for theese packages. But truely, in this case why do we have such a wide range of priorities? So I'm inclined to agree with you. I just skimmed again through apt_preferences man page, but did not find such examples or explanations. Where's it documented? I must admit, that I only base my words on old readings and experimentations. It also seems logic: what would be the interest to have so wide ranges of numbers oterwise? Yes-yes-yes. This thought visited my mind too. Maybe I'm wrong, but what I have seen those days tends to prove that I am not. I think you are right too, but it will be well to find where this behavior is correctly described. Unfortunately I have not seen good preferences documentation at the current time. pgpZj47UatBfq.pgp Description: PGP signature
Re: apt-pinning, strange behavior
Le 09.10.2013 19:28, Dmitrii Kashin a écrit : berenger.mo...@neutralite.org writes: Since I had to reinstall from my last kernel error, I decided to stay with stable on that computer, but I need some softwares in less outdated versions, like development libraries or i3 ( this one is not a need but a question of comfort, I admit ), so I want to use apt-pining. I have set all packages from stable to a priority of 900 and testing packages with 500. But tzdata wants to upgrade, for an unknown reason. Certainly it wants. According to apt_preferences(5): Yes, it wants, because I did not specified the priority for the release stable-updates. This is what apt-cache policy pointed, and once fixed, my problem disappeared, and I finally understood that obvious issue. You should use priority of =990 for the target release. In the same priority range, the package which will be installed is the one with the highest priority, so it is fine to have one set of package with 500 ( or I could take 600 or any other value ) for low priority, and the other at 900 ( or 800 or... ), so that the version with 900 will be installed against the lower one, even if the lower one is more recent. Explicitly making it to a priority of 900 for stable fixes that, but I can not understand why it is needed? You have just set this priority to the whole stable repository. This should not work at all. Maybe it will be sane to show us how you set pins? Here are the 2 versions, first the one which really works ( in the hope I did not forget something, since I have enabled stable-updates, stable/updates, stable and testing. So I am not sure about the stable/updates one. Not used to stable.): Package: * Pin: release a=stable Pin-Priority: 800 Package: * Pin: release a=stable-updates Pin-Priority: 900 Package: * Pin: release a=testing Pin-Priority: 500 Package: i3-wm i3 Pin: release a=testing Pin-Priority: 900 #i3 dependencies Package: gir1.2-glib-2.0 libc-dev-bin libc6 libc6-dev libgirepository-1.0-1 libglib2.0-0 libpango1.0-0 locales python-gi Pin: release a=testing Pin-Priority: 900 Package: clang Pin: release a=testing Pin-Priority: 900 #clang dependencies Package: libclang-common-dev libgcc1 libgomp1 libitm1 libquadmath0 libstdc++6 libobjc4 Pin: release a=testing Pin-Priority: 900 The one which with tzdata updated to testing: Package: * Pin: release a=stable Pin-Priority: 900 Package: * Pin: release a=testing Pin-Priority: 500 Package: i3-wm i3 Pin: release a=testing Pin-Priority: 900 #i3 dependencies Package: gir1.2-glib-2.0 libc-dev-bin libc6 libc6-dev libgirepository-1.0-1 libglib2.0-0 libpango1.0-0 locales python-gi Pin: release a=testing Pin-Priority: 900 Package: clang Pin: release a=testing Pin-Priority: 900 #clang dependencies Package: libclang-common-dev libgcc1 libgomp1 libitm1 libquadmath0 libstdc++6 libobjc4 Pin: release a=testing Pin-Priority: 900 PS: I think I should probably send the package-specific priorities and their dependencies into specific files in preferences.d/ but I'll do that when I'll have a real lot of packages that I need updated. 2 packages ( 3 in fact, I do not show opera here, to stay with the original situation ) can be kept in one file without making it unmaintainable. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dff77b2e59cff8911bd3f6c405f5...@neutralite.org
Re: apt-pinning, strange behavior
berenger.mo...@neutralite.org writes: In the same priority range, the package which will be installed is the one with the highest priority, so it is fine to have one set of package with 500 ( or I could take 600 or any other value ) for low priority, and the other at 900 ( or 800 or... ), so that the version with 900 will be installed against the lower one, even if the lower one is more recent. Oh... Truely? I thought differently and was sure I am right. I just skimmed again through apt_preferences man page, but did not find such examples or explanations. Where's it documented? Yes, it wants, because I did not specified the priority for the release stable-updates. This is what apt-cache policy pointed, and once fixed, my problem disappeared, and I finally understood that obvious issue. Glad for you. PS: I think I should probably send the package-specific priorities and their dependencies into specific files in preferences.d/ Yes, it's a good practice. I do so. But mostly in order to set negative priorities. pgpPtARO8Mur6.pgp Description: PGP signature
Re: apt-pinning, strange behavior
Le 10.10.2013 23:06, Dmitrii Kashin a écrit : berenger.mo...@neutralite.org writes: In the same priority range, the package which will be installed is the one with the highest priority, so it is fine to have one set of package with 500 ( or I could take 600 or any other value ) for low priority, and the other at 900 ( or 800 or... ), so that the version with 900 will be installed against the lower one, even if the lower one is more recent. Oh... Truely? I thought differently and was sure I am right. Maybe you are right, but in that case, how would you explain the behavior I had if a package of a priority of 500 is considered to have the same priority as a package with 900 ? ;) I just skimmed again through apt_preferences man page, but did not find such examples or explanations. Where's it documented? I must admit, that I only base my words on old readings and experimentations. It also seems logic: what would be the interest to have so wide ranges of numbers oterwise? Maybe I'm wrong, but what I have seen those days tends to prove that I am not. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85a4a2725fc50736dcf02195d33b1...@neutralite.org
Re: apt-pinning, strange behavior
On Wed, 09 Oct 2013 00:12:46 +0200 berenger.mo...@neutralite.org wrote: Le 08.10.2013 22:42, Sven Joachim a écrit : On 2013-10-08 19:06 +0200, berenger.mo...@neutralite.org wrote: Since I had to reinstall from my last kernel error, I decided to stay with stable on that computer, but I need some softwares in less outdated versions, like development libraries or i3 ( this one is not a need but a question of comfort, I admit ), so I want to use apt-pining. I have set all packages from stable to a priority of 900 and testing packages with 500. But tzdata wants to upgrade, for an unknown reason. Explicitly making it to a priority of 900 for stable fixes that, but I can not understand why it is needed? I don't know either, but apt-cache policy tzdata should explain it. Cheers, Sven Thanks for the hint, I had forgotten about apt-cache policy. I finally understood, why the update was on the run: tzdata: Installé : 2013d-0wheezy1 Candidat : 2013d-1 Table de version : 2013d-1 0 500 http://ftp2.fr.debian.org/debian/ testing/main amd64 Packages *** 2013d-0wheezy1 0 500 http://ftp2.fr.debian.org/debian/ stable-updates/main amd64 Packages 100 /var/lib/dpkg/status 2013c-0wheezy1 0 900 http://ftp2.fr.debian.org/debian/ stable/main amd64 Packages Version 2013d-0wheezy1 had the same priority as testing one so testing was installed because more recent. Now, I wonder why I have 3 versions of that package listed when I only have 2 sources enabled? Could it be because of stable, stable/updates and stable-updates repositories? ( I am not used to stable, so I do not have the updates repos usually ) And also why I have a wheezy version with a priority of 500... I can not even find the 2013d-0wheezy1 in debian packages... The answer to your question is in files /var/lib/apt/lists/*_Release. You can notice the difference: Suite: stable Suite: stable-updates -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131009111749.45e87...@eunet.rs
Re: apt-pinning, strange behavior
Le 09.10.2013 11:17, Marko Randjelovic a écrit : On Wed, 09 Oct 2013 00:12:46 +0200 berenger.mo...@neutralite.org wrote: Le 08.10.2013 22:42, Sven Joachim a écrit : On 2013-10-08 19:06 +0200, berenger.mo...@neutralite.org wrote: Since I had to reinstall from my last kernel error, I decided to stay with stable on that computer, but I need some softwares in less outdated versions, like development libraries or i3 ( this one is not a need but a question of comfort, I admit ), so I want to use apt-pining. I have set all packages from stable to a priority of 900 and testing packages with 500. But tzdata wants to upgrade, for an unknown reason. Explicitly making it to a priority of 900 for stable fixes that, but I can not understand why it is needed? I don't know either, but apt-cache policy tzdata should explain it. Cheers, Sven Thanks for the hint, I had forgotten about apt-cache policy. I finally understood, why the update was on the run: tzdata: Installé : 2013d-0wheezy1 Candidat : 2013d-1 Table de version : 2013d-1 0 500 http://ftp2.fr.debian.org/debian/ testing/main amd64 Packages *** 2013d-0wheezy1 0 500 http://ftp2.fr.debian.org/debian/ stable-updates/main amd64 Packages 100 /var/lib/dpkg/status 2013c-0wheezy1 0 900 http://ftp2.fr.debian.org/debian/ stable/main amd64 Packages Version 2013d-0wheezy1 had the same priority as testing one so testing was installed because more recent. Now, I wonder why I have 3 versions of that package listed when I only have 2 sources enabled? Could it be because of stable, stable/updates and stable-updates repositories? ( I am not used to stable, so I do not have the updates repos usually ) And also why I have a wheezy version with a priority of 500... I can not even find the 2013d-0wheezy1 in debian packages... The answer to your question is in files /var/lib/apt/lists/*_Release. You can notice the difference: Suite: stable Suite: stable-updates Thanks. I did not thought that it would be considered as a different repo, which is absent from http://packages.debian.org but it explains the behavior I have. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1a5f89a7d2f551b1158e86eecc6df...@neutralite.org
Re: apt-pinning, strange behavior
berenger.mo...@neutralite.org writes: Since I had to reinstall from my last kernel error, I decided to stay with stable on that computer, but I need some softwares in less outdated versions, like development libraries or i3 ( this one is not a need but a question of comfort, I admit ), so I want to use apt-pining. I have set all packages from stable to a priority of 900 and testing packages with 500. But tzdata wants to upgrade, for an unknown reason. Certainly it wants. According to apt_preferences(5): 500 = P 990 causes a version to be installed unless there is a version available belonging to the target release or the installed version is more recent As you see, both pins are in the same range, so there are managed by the same rules. You should use priority of =990 for the target release. Explicitly making it to a priority of 900 for stable fixes that, but I can not understand why it is needed? You have just set this priority to the whole stable repository. This should not work at all. Maybe it will be sane to show us how you set pins? pgpLgC4869UAx.pgp Description: PGP signature
apt-pinning, strange behavior
Since I had to reinstall from my last kernel error, I decided to stay with stable on that computer, but I need some softwares in less outdated versions, like development libraries or i3 ( this one is not a need but a question of comfort, I admit ), so I want to use apt-pining. I have set all packages from stable to a priority of 900 and testing packages with 500. But tzdata wants to upgrade, for an unknown reason. Explicitly making it to a priority of 900 for stable fixes that, but I can not understand why it is needed? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/28f8d241e1c1bcf2f24cb2073969d...@neutralite.org
Re: apt-pinning, strange behavior
On 2013-10-08 19:06 +0200, berenger.mo...@neutralite.org wrote: Since I had to reinstall from my last kernel error, I decided to stay with stable on that computer, but I need some softwares in less outdated versions, like development libraries or i3 ( this one is not a need but a question of comfort, I admit ), so I want to use apt-pining. I have set all packages from stable to a priority of 900 and testing packages with 500. But tzdata wants to upgrade, for an unknown reason. Explicitly making it to a priority of 900 for stable fixes that, but I can not understand why it is needed? I don't know either, but apt-cache policy tzdata should explain it. Cheers, Sven -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878uy3o5p3@turtle.gmx.de
Re: apt-pinning, strange behavior
Le 08.10.2013 22:42, Sven Joachim a écrit : On 2013-10-08 19:06 +0200, berenger.mo...@neutralite.org wrote: Since I had to reinstall from my last kernel error, I decided to stay with stable on that computer, but I need some softwares in less outdated versions, like development libraries or i3 ( this one is not a need but a question of comfort, I admit ), so I want to use apt-pining. I have set all packages from stable to a priority of 900 and testing packages with 500. But tzdata wants to upgrade, for an unknown reason. Explicitly making it to a priority of 900 for stable fixes that, but I can not understand why it is needed? I don't know either, but apt-cache policy tzdata should explain it. Cheers, Sven Thanks for the hint, I had forgotten about apt-cache policy. I finally understood, why the update was on the run: tzdata: Installé : 2013d-0wheezy1 Candidat : 2013d-1 Table de version : 2013d-1 0 500 http://ftp2.fr.debian.org/debian/ testing/main amd64 Packages *** 2013d-0wheezy1 0 500 http://ftp2.fr.debian.org/debian/ stable-updates/main amd64 Packages 100 /var/lib/dpkg/status 2013c-0wheezy1 0 900 http://ftp2.fr.debian.org/debian/ stable/main amd64 Packages Version 2013d-0wheezy1 had the same priority as testing one so testing was installed because more recent. Now, I wonder why I have 3 versions of that package listed when I only have 2 sources enabled? Could it be because of stable, stable/updates and stable-updates repositories? ( I am not used to stable, so I do not have the updates repos usually ) And also why I have a wheezy version with a priority of 500... I can not even find the 2013d-0wheezy1 in debian packages... -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/9dc2fe2bca18a98dd48abc1de5313...@neutralite.org
Re: apt pinning for deb-multimedia does not work
On 21.06.2013 15:04, Andrei POPESCU wrote: I think we didn't understand priorities correctly. Let's see again what the fine manual (apt_preferences(5)) says: […] As per above output you have 6:9.3-1 installed, which is more recent than 6:0.8.6-1. Because of this apt wants to jump directly to the higher version from dmo (apt will not downgrade unless the priority is higher than 1000). Does this make sense? Oh yes, that was the crux of the matter. The apt-cache policy output is a bit confusing in my opinion (sooo many numbers…), and the man page does not say anything about how to interpret it… Anyways, thanks for the hint, the following pinning works as expected: Package: * Pin: release o=Unofficial Multimedia Packages Pin-Priority: 450 Package: libav* Pin: release o=Unofficial Multimedia Packages Pin-Priority: -1 Cheers, Roland -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/kqda5u$gnc$1...@ger.gmane.org
Re: apt pinning for deb-multimedia does not work
On Jo, 20 iun 13, 20:13:06, Andrei POPESCU wrote: On Ma, 18 iun 13, 18:00:37, Roland Hieber wrote: But nevertheless, apt still assigns a prio of 500: Actually it doesn't, 500 is the priority of the source, the package itself has 250 (the number behind the version). $ apt-cache policy libavdevice53 libavdevice53: Installed: 6:9.3-1 Candidate: 7:0.10.3-dmo1 Package pin: 7:0.10.3-dmo1 Version table: 7:0.10.3-dmo1 250 500 http://debian-multimedia.informatik.uni-erlangen.de/debian-multimedia/ testing/main amd64 Packages *** 6:9.3-1 250 100 /var/lib/dpkg/status 6:0.8.6-1 250 500 http://debian.tu-bs.de/debian/ wheezy/main amd64 Packages However, if I change the pinning to Package: *, everything works as expected (for all packages of course, but I don't need that :P) Is this a PEBCAK, or is this a bug in apt? I think we didn't understand priorities correctly. Let's see again what the fine manual (apt_preferences(5)) says: How APT Interprets Priorities Priorities (P) assigned in the APT preferences file must be positive or negative integers. They are interpreted as follows (roughly speaking): [...] 500 = P 990 causes a version to be installed unless there is a version available belonging to the target release or the installed version is more recent As per above output you have 6:9.3-1 installed, which is more recent than 6:0.8.6-1. Because of this apt wants to jump directly to the higher version from dmo (apt will not downgrade unless the priority is higher than 1000). Does this make sense? Solution: uninstall 6:9.3-1 and apt will then prefer the Debian version. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: apt pinning for deb-multimedia does not work
On Ma, 18 iun 13, 18:00:37, Roland Hieber wrote: Hi, I want to pin the libav* packages from deb-multimedia so they get a lower priority than the libav packages in the default Debian repos. My sources.list looks like this: $ cat /etc/apt/sources.list /etc/apt/sources.list.d/*list # deb [arch=amd64,i386] http://debian.tu-bs.de/debian/ wheezy main contrib non-free deb [arch=amd64,i386] http://debian.tu-bs.de/debian/ wheezy main contrib Side note: you don't need to add the architecture to sources.list, apt will automatically use all architectures configured with dpkg. My preferences look like this: $ cat /etc/apt/preferences.d/*.pref Package: libavdevice53 Pin: release o=Unofficial Multimedia Packages Pin-Priority: 250 (/etc/apt/preferences is empty and Unofficial Multimedia Packages is what http://debian-multimedia.informatik.uni-erlangen.de/debian-multimedia/dists/testing/Release says for the Origin: header) Looks good to me. But nevertheless, apt still assigns a prio of 500: $ apt-cache policy libavdevice53 libavdevice53: Installed: 6:9.3-1 Candidate: 7:0.10.3-dmo1 Package pin: 7:0.10.3-dmo1 Version table: 7:0.10.3-dmo1 250 500 http://debian-multimedia.informatik.uni-erlangen.de/debian-multimedia/ testing/main amd64 Packages *** 6:9.3-1 250 100 /var/lib/dpkg/status 6:0.8.6-1 250 500 http://debian.tu-bs.de/debian/ wheezy/main amd64 Packages However, if I change the pinning to Package: *, everything works as expected (for all packages of course, but I don't need that :P) Is this a PEBCAK, or is this a bug in apt? It's certainly strange. Are you sure there's no typo in the file (i.e. you copy-pasted and not copied the contents to the e-mail)? Could you please also attach the output of: apt-cache policy apt-cache policy libavdevice53:amd64 apt-cache policy libavdevice53:i386 Which one is your main architecture (dpkg --print-architecture)? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: apt pinning for deb-multimedia does not work
Hi, Dňa 20.06.2013 19:13 Andrei POPESCU wrote / napísal(a): On Ma, 18 iun 13, 18:00:37, Roland Hieber wrote: My preferences look like this: $ cat /etc/apt/preferences.d/*.pref Package: libavdevice53 Pin: release o=Unofficial Multimedia Packages Pin-Priority: 250 I was bothering with the release too, but without success. Finally this works for me (for all deb-multimedia packages): Package: * Pin: origin *.deb-multimedia.org Pin-Priority: 200 regards -- Slavko http://slavino.sk signature.asc Description: OpenPGP digital signature
apt pinning for deb-multimedia does not work
Hi, I want to pin the libav* packages from deb-multimedia so they get a lower priority than the libav packages in the default Debian repos. My sources.list looks like this: $ cat /etc/apt/sources.list /etc/apt/sources.list.d/*list # deb [arch=amd64,i386] http://debian.tu-bs.de/debian/ wheezy main contrib non-free deb [arch=amd64,i386] http://debian.tu-bs.de/debian/ wheezy main contrib non-free deb-src http://debian.tu-bs.de/debian/ wheezy main contrib non-free deb [arch=amd64,i386] http://security.debian.org/ wheezy/updates main contrib non-free deb-src http://security.debian.org/ wheezy/updates main contrib non-free deb [arch=amd64,i386] http://ftp5.gwdg.de/pub/linux/debian/debian/ wheezy-proposed-updates main contrib non-free deb-src http://ftp5.gwdg.de/pub/linux/debian/debian/ wheezy-proposed-updates main contrib non-free deb http://debian-multimedia.informatik.uni-erlangen.de/debian-multimedia testing main deb-src http://debian-multimedia.informatik.uni-erlangen.de/debian-multimedia testing main My preferences look like this: $ cat /etc/apt/preferences.d/*.pref Package: libavdevice53 Pin: release o=Unofficial Multimedia Packages Pin-Priority: 250 (/etc/apt/preferences is empty and Unofficial Multimedia Packages is what http://debian-multimedia.informatik.uni-erlangen.de/debian-multimedia/dists/testing/Release says for the Origin: header) But nevertheless, apt still assigns a prio of 500: $ apt-cache policy libavdevice53 libavdevice53: Installed: 6:9.3-1 Candidate: 7:0.10.3-dmo1 Package pin: 7:0.10.3-dmo1 Version table: 7:0.10.3-dmo1 250 500 http://debian-multimedia.informatik.uni-erlangen.de/debian-multimedia/ testing/main amd64 Packages *** 6:9.3-1 250 100 /var/lib/dpkg/status 6:0.8.6-1 250 500 http://debian.tu-bs.de/debian/ wheezy/main amd64 Packages However, if I change the pinning to Package: *, everything works as expected (for all packages of course, but I don't need that :P) Is this a PEBCAK, or is this a bug in apt? More info: $ apt-cache policy apt apt: Installed: 0.9.7.9 Candidate: 0.9.7.9 Version table: *** 0.9.7.9 0 500 http://debian.tu-bs.de/debian/ wheezy/main amd64 Packages 100 /var/lib/dpkg/status $ apt-config dump APT ; APT::Architecture amd64; APT::Build-Essential ; APT::Build-Essential:: build-essential; APT::Install-Recommends 1; APT::Install-Suggests 0; APT::Authentication ; APT::Authentication::TrustCDROM true; APT::NeverAutoRemove ; APT::NeverAutoRemove:: ^firmware-linux.*; APT::NeverAutoRemove:: ^linux-firmware$; APT::NeverAutoRemove:: ^linux-image.*; APT::NeverAutoRemove:: ^kfreebsd-image.*; APT::NeverAutoRemove:: ^linux-restricted-modules.*; APT::NeverAutoRemove:: ^linux-ubuntu-modules-.*; APT::NeverAutoRemove:: ^gnumach$; APT::NeverAutoRemove:: ^gnumach-image.*; APT::Never-MarkAuto-Sections ; APT::Never-MarkAuto-Sections:: metapackages; APT::Never-MarkAuto-Sections:: restricted/metapackages; APT::Never-MarkAuto-Sections:: universe/metapackages; APT::Never-MarkAuto-Sections:: multiverse/metapackages; APT::Never-MarkAuto-Sections:: oldlibs; APT::Never-MarkAuto-Sections:: restricted/oldlibs; APT::Never-MarkAuto-Sections:: universe/oldlibs; APT::Never-MarkAuto-Sections:: multiverse/oldlibs; APT::Architectures ; APT::Architectures:: amd64; APT::Architectures:: i386; APT::Compressor ; APT::Compressor::. ; APT::Compressor::.::Name .; APT::Compressor::.::Extension ; APT::Compressor::.::Binary ; APT::Compressor::.::Cost 1; APT::Compressor::gzip ; APT::Compressor::gzip::Name gzip; APT::Compressor::gzip::Extension .gz; APT::Compressor::gzip::Binary gzip; APT::Compressor::gzip::Cost 2; APT::Compressor::gzip::CompressArg ; APT::Compressor::gzip::CompressArg:: -9n; APT::Compressor::gzip::UncompressArg ; APT::Compressor::gzip::UncompressArg:: -d; APT::Compressor::bzip2 ; APT::Compressor::bzip2::Name bzip2; APT::Compressor::bzip2::Extension .bz2; APT::Compressor::bzip2::Binary bzip2; APT::Compressor::bzip2::Cost 3; APT::Compressor::bzip2::CompressArg ; APT::Compressor::bzip2::CompressArg:: -9; APT::Compressor::bzip2::UncompressArg ; APT::Compressor::bzip2::UncompressArg:: -d; APT::Compressor::xz ; APT::Compressor::xz::Name xz; APT::Compressor::xz::Extension .xz; APT::Compressor::xz::Binary xz; APT::Compressor::xz::Cost 4; APT::Compressor::xz::CompressArg ; APT::Compressor::xz::CompressArg:: -6; APT::Compressor::xz::UncompressArg ; APT::Compressor::xz::UncompressArg:: -d; APT::Compressor::lzma ; APT::Compressor::lzma::Name lzma; APT::Compressor::lzma::Extension .lzma; APT::Compressor::lzma::Binary xz; APT::Compressor::lzma::Cost 5; APT::Compressor::lzma::CompressArg ; APT::Compressor::lzma::CompressArg:: --format=lzma; APT::Compressor::lzma::CompressArg:: -9; APT::Compressor::lzma::UncompressArg ; APT::Compressor::lzma::UncompressArg:: --format=lzma; APT::Compressor::lzma::UncompressArg:: -d; APT::CompressorName ; APT::CompressorExtension .; APT::CompressorBinary ; APT::CompressorCost 100;
trouble getting apt-pinning to work
I'm on debian stable (squeeze), but would like to be able to install a few packages from testing (wheezy). I tried to set up apt pinning, but it doesn't seem to work quite right. When I apt-get install something now, it all comes from wheezy even if there are squeeze versions of the package. It's almost like the preferences file isn't getting read. Is there anything wrong with the configuration below? Is there any way to get apt to spit out it's internal model of the priorities so I can verify that everything is actually getting loaded? /etc/apt/preferences: Package: * Pin: release a=squeeze Pin-Priority: 700 Package: * Pin: release a=wheezy Pin-Priority: 650 /etc/apt/sources.list: # Debian packages for squeeze deb http://ftp-mirror.internap.com/pub/debian/ squeeze main contrib # Wheezy deb http://ftp-mirror.internap.com/pub/debian/ wheezy main contrib -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadoo-jzgl6umhr_wnfbbay3jhzevhyvoktgxxyzdarx2bgj...@mail.gmail.com
Re: trouble getting apt-pinning to work
Further troubleshooting info: I ran apt-get policy and it appears my preferences aren't getting picked up. Does anyone know why this might happen, or what can be done to force the preferences file to reload? apt-cache policy Package files: 100 /var/lib/dpkg/status release a=now 500 http://ftp-mirror.internap.com/pub/debian/ wheezy/contrib amd64 Packages release o=Debian,a=testing,n=wheezy,l=Debian,c=contrib origin ftp-mirror.internap.com 500 http://ftp-mirror.internap.com/pub/debian/ wheezy/main amd64 Packages release o=Debian,a=testing,n=wheezy,l=Debian,c=main origin ftp-mirror.internap.com 500 http://ftp-mirror.internap.com/pub/debian/ squeeze/contrib amd64 Packages release v=6.0.6,o=Debian,a=stable,n=squeeze,l=Debian,c=contrib origin ftp-mirror.internap.com 500 http://ftp-mirror.internap.com/pub/debian/ squeeze/main amd64 Packages release v=6.0.6,o=Debian,a=stable,n=squeeze,l=Debian,c=main origin ftp-mirror.internap.com Pinned packages: On Thu, Nov 8, 2012 at 4:07 PM, Brendan Miller catph...@catphive.net wrote: I'm on debian stable (squeeze), but would like to be able to install a few packages from testing (wheezy). I tried to set up apt pinning, but it doesn't seem to work quite right. When I apt-get install something now, it all comes from wheezy even if there are squeeze versions of the package. It's almost like the preferences file isn't getting read. Is there anything wrong with the configuration below? Is there any way to get apt to spit out it's internal model of the priorities so I can verify that everything is actually getting loaded? /etc/apt/preferences: Package: * Pin: release a=squeeze Pin-Priority: 700 Package: * Pin: release a=wheezy Pin-Priority: 650 /etc/apt/sources.list: # Debian packages for squeeze deb http://ftp-mirror.internap.com/pub/debian/ squeeze main contrib # Wheezy deb http://ftp-mirror.internap.com/pub/debian/ wheezy main contrib -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADOO-JxOjzs8oVP3T_RU8kMEsfprEe+frdh+f8iNk=bgfa2...@mail.gmail.com
Re: trouble getting apt-pinning to work
Ok, after spending some more time with the manpages, I figured out my own problem: Pin: release a=wheezy Should have been: Pin: release n=wheezy Apparently it makes a distinction between the code name, and release type like stable or testing. On Thu, Nov 8, 2012 at 4:15 PM, Brendan Miller catph...@catphive.net wrote: Further troubleshooting info: I ran apt-get policy and it appears my preferences aren't getting picked up. Does anyone know why this might happen, or what can be done to force the preferences file to reload? apt-cache policy Package files: 100 /var/lib/dpkg/status release a=now 500 http://ftp-mirror.internap.com/pub/debian/ wheezy/contrib amd64 Packages release o=Debian,a=testing,n=wheezy,l=Debian,c=contrib origin ftp-mirror.internap.com 500 http://ftp-mirror.internap.com/pub/debian/ wheezy/main amd64 Packages release o=Debian,a=testing,n=wheezy,l=Debian,c=main origin ftp-mirror.internap.com 500 http://ftp-mirror.internap.com/pub/debian/ squeeze/contrib amd64 Packages release v=6.0.6,o=Debian,a=stable,n=squeeze,l=Debian,c=contrib origin ftp-mirror.internap.com 500 http://ftp-mirror.internap.com/pub/debian/ squeeze/main amd64 Packages release v=6.0.6,o=Debian,a=stable,n=squeeze,l=Debian,c=main origin ftp-mirror.internap.com Pinned packages: On Thu, Nov 8, 2012 at 4:07 PM, Brendan Miller catph...@catphive.net wrote: I'm on debian stable (squeeze), but would like to be able to install a few packages from testing (wheezy). I tried to set up apt pinning, but it doesn't seem to work quite right. When I apt-get install something now, it all comes from wheezy even if there are squeeze versions of the package. It's almost like the preferences file isn't getting read. Is there anything wrong with the configuration below? Is there any way to get apt to spit out it's internal model of the priorities so I can verify that everything is actually getting loaded? /etc/apt/preferences: Package: * Pin: release a=squeeze Pin-Priority: 700 Package: * Pin: release a=wheezy Pin-Priority: 650 /etc/apt/sources.list: # Debian packages for squeeze deb http://ftp-mirror.internap.com/pub/debian/ squeeze main contrib # Wheezy deb http://ftp-mirror.internap.com/pub/debian/ wheezy main contrib -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadoo-jw4nweul5lnlhh3wqu-8otbqdg49sp24a3e0tlb2b9...@mail.gmail.com
Re: trouble getting apt-pinning to work
On Thu, Nov 8, 2012 at 7:07 PM, Brendan Miller catph...@catphive.net wrote: I'm on debian stable (squeeze), but would like to be able to install a few packages from testing (wheezy). I tried to set up apt pinning, but it doesn't seem to work quite right. When I apt-get install something now, it all comes from wheezy even if there are squeeze versions of the package. It's almost like the preferences file isn't getting read. Is there anything wrong with the configuration below? Is there any way to get apt to spit out it's internal model of the priorities so I can verify that everything is actually getting loaded? /etc/apt/preferences: Package: * Pin: release a=squeeze Pin-Priority: 700 Package: * Pin: release a=wheezy Pin-Priority: 650 a=stable and a=testing, or (AFAIK, new in squeeze) n=squeeze and n=wheezy. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=SywmBsFWojZM_Tx5UPu5_rB=kajosgicl346-88sph...@mail.gmail.com
apt-pinning
Hi, I have a machine with Wheezy installed, unfortunately I can't use PHP5.4 due to a third party script which isn't compatible yet. So I added the Squeeze-Sources in my apt sources.list and installed PHP5.3 from Squeeze. I also created the file php in /etc/apt/preferences.d/ containing: Package: php* Pin: release n=squeeze Pin-Priority: 900 Package: libapache2-mod-php5 Pin: release n=squeeze Pin-Priority: 900 But when I check the policy it doesn't seem to work: apt-cache policy php5 php5: Installed: 5.3.3-7+squeeze13 Candidate: 5.4.4-2 Version table: 5.4.4-2 0 500 ftp://mirror.manitu.net/debian/ wheezy/main amd64 Packages *** 5.3.3-7+squeeze13 0 500 http://security.debian.org/ squeeze/updates/main amd64 Packages 100 /var/lib/dpkg/status 5.3.3-7+squeeze8 0 500 ftp://mirror.manitu.net/debian/ squeeze/main amd64 Packages I tried to lower the priority for the wheezy packages: Package: php* Pin: release n=wheezy Pin-Priority: -10 Package: libapache2-mod-php5 Pin: release n=wheezy Pin-Priority: -10 I also tried pinning to Pin: version 5.3.* but that didn't helped either. To prevent upgrading I used echo php-mail-mime hold | dpkg --set-selections etc. for now, but sooner or later I will have to run a apt-get dist-upgrade and it would be nice if I hasn't to upgrade first and do a rollback for PHP afterwards. Thanks in advance. Bye. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50067475.2020...@concepts-and-training.de
Re: apt-pinning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 18.07.2012 11:31, Denis Witt wrote: Hi, I have a machine with Wheezy installed, unfortunately I can't use PHP5.4 due to a third party script which isn't compatible yet. So I added the Squeeze-Sources in my apt sources.list and installed PHP5.3 from Squeeze. I also created the file php in /etc/apt/preferences.d/ containing: Package: php* Pin: release n=squeeze Pin-Priority: 900 Package: libapache2-mod-php5 Pin: release n=squeeze Pin-Priority: 900 But when I check the policy it doesn't seem to work: apt-cache policy php5 php5: Installed: 5.3.3-7+squeeze13 Candidate: 5.4.4-2 Version table: 5.4.4-2 0 500 ftp://mirror.manitu.net/debian/ wheezy/main amd64 Packages *** 5.3.3-7+squeeze13 0 500 http://security.debian.org/ squeeze/updates/main amd64 Packages 100 /var/lib/dpkg/status 5.3.3-7+squeeze8 0 500 ftp://mirror.manitu.net/debian/ squeeze/main amd64 Packages I tried to lower the priority for the wheezy packages: Package: php* Pin: release n=wheezy Pin-Priority: -10 Package: libapache2-mod-php5 Pin: release n=wheezy Pin-Priority: -10 I also tried pinning to Pin: version 5.3.* but that didn't helped either. To prevent upgrading I used echo php-mail-mime hold | dpkg --set-selections etc. for now, but sooner or later I will have to run a apt-get dist-upgrade and it would be nice if I hasn't to upgrade first and do a rollback for PHP afterwards. Thanks in advance. Bye. Hi, I think that you should replace n=squeeze with a=squeeze in /etc/apt/preferences.d/php. If that doesn't work, I don't know what works, but someone else might know on this list. PS. I didn't trim the original message, because I was unsure what I can trim without removing anything important. - -- Mika Suomalainen NOTICE! I am on mobile broadband with very limited time, so I cannot read emails very much. The best time to contact me is probably weekends when I have better connectivity with good luck. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Homepage: http://mkaysi.github.com/ Comment: gpg --keyserver pool.sks-keyservers.net --recv-keys 82A46728 Comment: Public key: http://mkaysi.github.com/PGP/key.txt Comment: Fingerprint = 24BC 1573 B8EE D666 D10A AA65 4DB5 3CFE 82A4 6728 Comment: Why do I (clear)sign emails? http://git.io/6FLzWg Comment: Please send plaintext instead of HTML. http://git.io/TAc0cg Comment: Please don't toppost. http://git.io/7-VB3g Comment: Please remove PGP lines in replies. http://git.io/nvHrDg Comment: Charset of this message should be UTF-8. Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJQBoOMAAoJEE21PP6CpGcoMOMP+wRloBk6u/NLIHGBEBj9uNlH NIg0lnk4rZla9PJZelzhDOIFmrwno3TwObTX0RHGakMuiRf8Eh8/WSDS+YkNevEU ga2+BOLwCQEcLYZv8th2T9zzlROrnO5O+GVU51LPTrWxswH23Ln7w9RjFz526qrQ IJH79anmPiOXc23j6KeRzl8MbBihvrVsXK6yM+66ZzPUyRTZBCKd16dXHoC2/R2k XXCY25PlHIfVmPGd/N4tqfJIfFvnZMusBZwy1gRLc14ONUzFSZWvyMfY6sRVrO/p CMhtLWehf+PgNNG54LsbdT63L7DAtdLgYm2Flf5TCU79Wd37JjXQE0WZeJq5REo3 WgZHHFA7Ew0fVTaQQXkF1EmwARVEDRM846Ir2C63Wf+kHBv+C+/azTCKyXIyFKfc Rdm34SFmCrCDqEmg613UPWPqlhnQmcP8a+/QvLPke3n1iD6bS/dK/CFJf6aP7WKw p/WHcZ5tDuzNIyH2ZDo9q8MD5yDiiPbmqTzVoaLjUjBfEJba4EBPB1FQjEO4cEN5 Zpod7yqVsinP1W5BKuE5vQ1YcetnARZtXN9EBMqZeYUDEdgThql+aPGJ8nEeVgSv XCk+vlkq9PgeRE73pS4ckq89cuna17zvEokRgBzPnvTyz1saMGITiAt2E6JTaJFC bJOY3VZFVWtpQK7bs8GF =lwqw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50068394.4090...@hotmail.com
Re: apt-pinning
On 18.07.2012 11:36, Mika Suomalainen wrote: I think that you should replace n=squeeze with a=squeeze in /etc/apt/preferences.d/php. Hi Mika, according to apt-cache policy the n is fine: 500 http://security.debian.org/ squeeze/updates/main amd64 Packages release v=6.0,o=Debian,a=stable,n=squeeze,l=Debian-Security,c=main origin security.debian.org Anyway, I tried it with a also but I didn't mention it as it was by accident during my first try. What makes me wonder is that apt-cache policy doesn't show any entries below Pinned packages:. I also tried using /etc/apt/preferences instead of /etc/apt/preferences.d/php, but nothing changes. Bye. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5006903b.7090...@concepts-and-training.de
Re: [SOLVED] apt-pinning
On 18.07.2012 10:31, Denis Witt wrote: I also created the file php in /etc/apt/preferences.d/ containing: Package: php* Pin: release n=squeeze Pin-Priority: 900 Package: libapache2-mod-php5 Pin: release n=squeeze Pin-Priority: 900 I got it working. apt obviously dislikes leading spaces. Package: php* Pin: release n=squeeze Pin-Priority: 1001 Package: libapache2-mod-php* Pin: release n=squeeze Pin-Priority: 1001 is working fine. %-/ I'm still a bit confused about the output of apt-cache policy, because it doesn't really changed (only the Candidate part): apt-cache policy php5 php5: Installed: 5.3.3-7+squeeze13 Candidate: 5.3.3-7+squeeze13 Package pin: 5.4.4-2 Version table: 5.4.4-2 -10 500 ftp://mirror.manitu.net/debian/ wheezy/main amd64 Packages *** 5.3.3-7+squeeze13 -10 500 http://security.debian.org/ squeeze/updates/main amd64 Packages 100 /var/lib/dpkg/status 5.3.3-7+squeeze8 -10 500 ftp://mirror.manitu.net/debian/ squeeze/main amd64 Packages But even if I use apt-get dist-upgrade the PHP-Packages will remain the Squeeze ones. When I use apt-cache policy without parameter it shows the pinning: Pinned packages: ... php5 - 5.4.4-2 ... Bye. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50069288.3000...@concepts-and-training.de
Re: Apt-pinning confusion
On Tue, 27 Mar 2012 15:36:07 +, Camaleón wrote: On Tue, 27 Mar 2012 14:01:12 +, Ramon Hofer wrote: On Tue, 27 Mar 2012 15:23:25 +0300, Andrei POPESCU wrote: On Ma, 27 mar 12, 12:07:08, Ramon Hofer wrote: Thanks for the explanation! So why didn't they just update the version that won't receive any updates? The new version changed ABI[1], which means all modules compiled against bpo.1 need to be recompiled for bpo.2. [1] http://en.wikipedia.org/wiki/Application_binary_interface So the ABI is about the same as a module? Like the one I had to compile (jme.ko [1]) to get the network up? Mmm, not quite so although it shares the same essence. In brief, to my understanding, kernel ABI helps developers to keep track for module changes that need to be recompiled and thus avoiding to recompile them all. When that happens, it is exposed by incrementing the last number of the package (in this example, bpo.1 → bpo.2). Thanks for your explanation! Aha, so instead of recompiling the modules a new kernel version is installed and with it the modules. I thought the module files could just be replaced when the kernel is updated... [1] http://lists.debian.org/debian-user/2012/02/msg02240.html Still I don't understand why that kernel update couldn't trigger the recompilation of the new modules. Maybe there's a reason why they are held separately? They are treated as two different packages because they are indeed two different packages providing different modules. What you need to keep the kernel package updated to the latest available version in the backports is the kernel metapackage (linux-image-686- pae), as this will trigger the most recent version. Thanks alot! I somehow missed that metapackage. Thanks again Ramon -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jl1hh0$pft$1...@dough.gmane.org
Re: Apt-pinning confusion
On Mon, 26 Mar 2012 13:40:47 +, Camaleón wrote: On Sun, 25 Mar 2012 18:59:42 +, Ramon Hofer wrote: On Sat, 24 Mar 2012 14:07:41 +, Camaleón wrote: Btw what's the difference between linux-image-3.2.0-0.bpo.1-686-pae and linux-image-3.2.0-0.bpo.2-686-pae and why are both in the backports repos. I was looking at packages.debian.org but couldn't find any explenation. Is there a place where I could find more infos? AFAICT, the last number in .bpo.1/.bpo.2 indicates a revision. A higher number means is the latest one. More info: 5.6.12 Version http://www.debian.org/doc/debian-policy/ch-controlfields.html Thanks for the info! I was just thinking if it would be better to switch from linux- image-3.2.0-0.bpo.1-686-pae on another machine to linux- image-3.2.0-0.bpo.2-686-pae? But maybe the difference isn't immense so I probably shouldn't change the running system :-) Best regards Ramon -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jks5o7$8ao$1...@dough.gmane.org
Re: Apt-pinning confusion
On Ma, 27 mar 12, 10:45:27, Ramon Hofer wrote: I was just thinking if it would be better to switch from linux- image-3.2.0-0.bpo.1-686-pae on another machine to linux- image-3.2.0-0.bpo.2-686-pae? But maybe the difference isn't immense so I probably shouldn't change the running system :-) The bpo.1 is likely to disappear from backports very soon and not receive any security support as of the point bpo.2 was uploaded (the Kernel Team can't support more than one version in backports). Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: Apt-pinning confusion
On Tue, 27 Mar 2012 15:00:55 +0300, Andrei POPESCU wrote: On Ma, 27 mar 12, 10:45:27, Ramon Hofer wrote: I was just thinking if it would be better to switch from linux- image-3.2.0-0.bpo.1-686-pae on another machine to linux- image-3.2.0-0.bpo.2-686-pae? But maybe the difference isn't immense so I probably shouldn't change the running system :-) The bpo.1 is likely to disappear from backports very soon and not receive any security support as of the point bpo.2 was uploaded (the Kernel Team can't support more than one version in backports). Thanks for the explanation! So why didn't they just update the version that won't receive any updates? Best regards Ramon -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jksahc$8ao$2...@dough.gmane.org
Re: Apt-pinning confusion
On Ma, 27 mar 12, 12:07:08, Ramon Hofer wrote: Thanks for the explanation! So why didn't they just update the version that won't receive any updates? The new version changed ABI[1], which means all modules compiled against bpo.1 need to be recompiled for bpo.2. [1] http://en.wikipedia.org/wiki/Application_binary_interface Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: Apt-pinning confusion
On Tue, 27 Mar 2012 15:23:25 +0300, Andrei POPESCU wrote: On Ma, 27 mar 12, 12:07:08, Ramon Hofer wrote: Thanks for the explanation! So why didn't they just update the version that won't receive any updates? The new version changed ABI[1], which means all modules compiled against bpo.1 need to be recompiled for bpo.2. [1] http://en.wikipedia.org/wiki/Application_binary_interface So the ABI is about the same as a module? Like the one I had to compile (jme.ko [1]) to get the network up? [1] http://lists.debian.org/debian-user/2012/02/msg02240.html Still I don't understand why that kernel update couldn't trigger the recompilation of the new modules. Maybe there's a reason why they are held separately? Best regards Ramon -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jksh78$j7d$1...@dough.gmane.org
Re: Apt-pinning confusion
On Tue, 27 Mar 2012 14:01:12 +, Ramon Hofer wrote: On Tue, 27 Mar 2012 15:23:25 +0300, Andrei POPESCU wrote: On Ma, 27 mar 12, 12:07:08, Ramon Hofer wrote: Thanks for the explanation! So why didn't they just update the version that won't receive any updates? The new version changed ABI[1], which means all modules compiled against bpo.1 need to be recompiled for bpo.2. [1] http://en.wikipedia.org/wiki/Application_binary_interface So the ABI is about the same as a module? Like the one I had to compile (jme.ko [1]) to get the network up? Mmm, not quite so although it shares the same essence. In brief, to my understanding, kernel ABI helps developers to keep track for module changes that need to be recompiled and thus avoiding to recompile them all. When that happens, it is exposed by incrementing the last number of the package (in this example, bpo.1 → bpo.2). [1] http://lists.debian.org/debian-user/2012/02/msg02240.html Still I don't understand why that kernel update couldn't trigger the recompilation of the new modules. Maybe there's a reason why they are held separately? They are treated as two different packages because they are indeed two different packages providing different modules. What you need to keep the kernel package updated to the latest available version in the backports is the kernel metapackage (linux-image-686- pae), as this will trigger the most recent version. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jksmp7$di0$1...@dough.gmane.org
Re: Apt-pinning confusion
On Sun, 25 Mar 2012 18:59:42 +, Ramon Hofer wrote: On Sat, 24 Mar 2012 14:07:41 +, Camaleón wrote: (...) Wow... no need to re-install :-), just be sure about the steps you're doing. Whether in doubt, launch aptitude and try from there, it usually provides insightful information when having to deal with different/mixed sources. Thanks again for your help, Camaleón! I now was able to install the backports kernel, nvidia-glx and add wheezy alsa. The packages which I need for building xbmc are most from squeeze, some from backports and some from wheezy. I was just trying to install each package from squeeze. If it didn't work I went for backports but most of them can't be found there so I went for wheezy. Glad you finally got it working without reinstalling. Btw what's the difference between linux-image-3.2.0-0.bpo.1-686-pae and linux-image-3.2.0-0.bpo.2-686-pae and why are both in the backports repos. I was looking at packages.debian.org but couldn't find any explenation. Is there a place where I could find more infos? AFAICT, the last number in .bpo.1/.bpo.2 indicates a revision. A higher number means is the latest one. More info: 5.6.12 Version http://www.debian.org/doc/debian-policy/ch-controlfields.html Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jkprku$4vf$3...@dough.gmane.org
Re: Apt-pinning confusion
On Sat, 24 Mar 2012 14:46:27 +, Ramon Hofer wrote: On Fri, 23 Mar 2012 12:15:10 +, Ramon Hofer wrote: So I thought I'd go with Stable, the kernel from backports and alsa from testing. Unfortunately this doesn't work. I suppose my problem are wrong apt- preferences numbers or something like this. Could it be that it's not possible to have the squeeze-backports kernel, wheezy alsa-utils and any build-essential installed at the same time is not possible? What makes you think that? Here's the output of apt-get install build-essential and apt-get -t wheezy install alsa-utils. http://pastebin.com/raw.php?i=njV7phnL $ sudo apt-get install build-essential That went good. sudo apt-get -t wheezy install alsa-utils The following packages have unmet dependencies: libc6-dev : Breaks: gcc-4.4 ( 4.4.6-4) but 4.4.5-8 is to be installed E: Broken packages $ apt-cache policy gcc-4.4 gcc-4.4: Installed: 4.4.5-8 Candidate: 4.4.5-8 Version table: 4.4.7-1 0 600 http://ftp.ch.debian.org/debian/ wheezy/main i386 Packages *** 4.4.5-8 0 990 http://ftp.ch.debian.org/debian/ squeeze/main i386 Packages 100 /var/lib/dpkg/status Mmm, my guess (as I told you earlier in the first post) is that maybe you are being too wide with your pinning configuration and thus allowing other packages for being upgraded. You can cherry pick the packages you want to get for wheezy (e.g., alsa- utils) and keep the rest of the libraries stick to squeeze (gcc-4.4). There can be situations where this is not possible and you require to upgrade the libraries as well but better having a message warning, stop and decide what to do than worry. So I switched to the wheezy build essential. It deinstalled the 2.6 headers. Then I was able to install alsa-utils from wheezy. But when I want to install a dependency from xbmc libcurl4-gnutls-dev I have to install pkg-config which remove build-essential again. Maybe it's easier for me to switch to Wheezy and install the libbost package from Squeeze. I would consider installing wheezy, you will get less headches and most recent packages. You can do a parallel install (or use a VM) and see how it goes. Or am I missing something? I don't know if this can be done with a fine-grained pinning configuration, let's see what others suggest. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jkn29n$q88$1...@dough.gmane.org
Re: Apt-pinning confusion
On Fri, Mar 23, 2012 at 12:15:10PM +, Ramon Hofer wrote: Hi all I'm trying to put the MythTV PVR XBMC version on my Shuttle box. I need a newer alsa version than the one from Squeeze because the stable version doesn't see the soundcard. So I wanted to install alsa from testing. And because I use a SSD I thought it would be a good idea to use the squeeze-backports kernel. It might make your life a little bit easier to forget about pinning and just put this in you /etc/apt/apt.conf file: APT::Default-Release stable; That will prevent your system from upgrading to Wheezy on you, but it'll allow you to install files from wheezy (provided wheezy is in your sources.list). -Rob -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120325141008.ga24...@aurora.owens.net
Re: Apt-pinning confusion
On Sun, 25 Mar 2012 10:10:08 -0400, Rob Owens wrote: On Fri, Mar 23, 2012 at 12:15:10PM +, Ramon Hofer wrote: Hi all I'm trying to put the MythTV PVR XBMC version on my Shuttle box. I need a newer alsa version than the one from Squeeze because the stable version doesn't see the soundcard. So I wanted to install alsa from testing. And because I use a SSD I thought it would be a good idea to use the squeeze-backports kernel. It might make your life a little bit easier to forget about pinning and just put this in you /etc/apt/apt.conf file: APT::Default-Release stable; That will prevent your system from upgrading to Wheezy on you, but it'll allow you to install files from wheezy (provided wheezy is in your sources.list). This makes it much easier. Thanks alot for the tipp :-) Best regards Ramon -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jknp5a$o5n$1...@dough.gmane.org
Re: Apt-pinning confusion
On Sat, 24 Mar 2012 14:07:41 +, Camaleón wrote: On Sat, 24 Mar 2012 13:14:47 +, Ramon Hofer wrote: On Fri, 23 Mar 2012 18:55:13 +, Camaleón wrote: What do you think it would be better to completely go with testing. Testing is currently quite stable but there are significant differences between wheezy and squeeze, like the gnome environment. I think this won't make any difference for me because I will only use the base system with xorg and xbmc without any window manager. Oh, that will make things easier (in the event you want to go with testing) :-) I'm not going to make any comments about pinning because I've never used but just a question: have you considered in using pinning only for the packages you want to be kept for a specific flavour? That is, being more selective to avoid additional problems or messing up too many packages. This sounds good. I thought I can do that by installing via apt-get -t wheezy alsa-utils. Yes, if you manually specify in that way it's even safer. (...) Unfortunately I don't have synaptic. I only have the terminal since I don't want to use any window manager for xbmc. Aptitude can be a good replacement for Synaptic. I can't as well install build-essential. There are many dependencies which usually are solved automatically. I think this is something that shouldn't be. When I want to install build- essential it asks for libc6-dev which depends on libc but a newer version is to be installed: http://pastebin.com/raw.php?i=FCBUeaVg $ sudo apt-get -t squeeze-backports install build-essential It seems as if I made a mess because there already is a libc6 package from testing installed. Mmm, I can't see such that package available for the backports :-? Your first plan seems good, it may just need to be polished a bit :-) Ok, thanks. I will try to again maybe with a clean install again. Like that the mess with the package dependencies should be gone. Wow... no need to re-install :-), just be sure about the steps you're doing. Whether in doubt, launch aptitude and try from there, it usually provides insightful information when having to deal with different/mixed sources. Thanks again for your help, Camaleón! I now was able to install the backports kernel, nvidia-glx and add wheezy alsa. The packages which I need for building xbmc are most from squeeze, some from backports and some from wheezy. I was just trying to install each package from squeeze. If it didn't work I went for backports but most of them can't be found there so I went for wheezy. Btw what's the difference between linux-image-3.2.0-0.bpo.1-686-pae and linux-image-3.2.0-0.bpo.2-686-pae and why are both in the backports repos. I was looking at packages.debian.org but couldn't find any explenation. Is there a place where I could find more infos? Best regards Ramon -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jknpuu$o5n$2...@dough.gmane.org
Re: Apt-pinning confusion
On Fri, 23 Mar 2012 18:55:13 +, Camaleón wrote: On Fri, 23 Mar 2012 12:15:10 +, Ramon Hofer wrote: I'm trying to put the MythTV PVR XBMC version on my Shuttle box. I need a newer alsa version than the one from Squeeze because the stable version doesn't see the soundcard. So I wanted to install alsa from testing. And because I use a SSD I thought it would be a good idea to use the squeeze-backports kernel. What do you think it would be better to completely go with testing. Testing is currently quite stable but there are significant differences between wheezy and squeeze, like the gnome environment. I think this won't make any difference for me because I will only use the base system with xorg and xbmc without any window manager. There are two reasons why I didn't want to do this: First I need to compile the jme module manually to be able to use the network interface. So I thought the less changes to the kernel makes me less often compile that module again. My wild guess is that wheezy kernel is not going to change much since now (3.2.12 is the current one) and IIRC, wheezy will be relased with this (3.2.x) branch but well... this can change at any time so yes, you will have to recompile the kernel module for every kernel change. Ok, so at least I don't have to expect kernel changes every day :-) Second the XBMC version I want to install needs libboost version 1.47 or older. Any specific reason for you to stick with a specific version of XBMC? :-? Yes, I want to use xbmc as a frontend for mythtv. And there's a branch of xbmc pvr that can connect to mythbackend: http://forum.xbmc.org/showthread.php?tid=110694 Unfortunately this doesn't work. I suppose my problem are wrong apt- preferences numbers or something like this. Here's my sources.list: http://pastebin.com/5SQhvDqw And apt preferences: http://pastebin.com/VcndLA6C (tip: when sending a pastebin link, I prefer to use the raw mode, it reads better, i.e.: http://pastebin.com/raw.php?i=VcndLA6C) Didn't know that. Thanks for the tip I will post it like this from now on :-) I'm not going to make any comments about pinning because I've never used but just a question: have you considered in using pinning only for the packages you want to be kept for a specific flavour? That is, being more selective to avoid additional problems or messing up too many packages. This sounds good. I thought I can do that by installing via apt-get -t wheezy alsa-utils. And here's the error I get when I try to install linux-headers-686-pae from squeeze-backports: http://pastebin.com/RcAPE36t The following packages have unmet dependencies: linux-headers-686-pae : Depends: linux-headers-3.2.0-0.bpo.2-686-pae but it is not going to be installed E: Broken packages Mmm... linux-headers-686-pae is a metapackage that has to pull linux- headers-3.2.0-0.bpo.2-686-pae automatically, I would open Sypatic to see what's going on with this although manually installing linux- headers-3.2.0-0.bpo.2-686-pae in addition to the metacpake should work. I installed the two metapackages linux-headers-686-pae and linux- image-686-pae so that I always have the newest backport kernel with the matching headers. Unfortunately I don't have synaptic. I only have the terminal since I don't want to use any window manager for xbmc. I can't as well install build-essential. There are many dependencies which usually are solved automatically. I think this is something that shouldn't be. When I want to install build- essential it asks for libc6-dev which depends on libc but a newer version is to be installed: http://pastebin.com/raw.php?i=FCBUeaVg It seems as if I made a mess because there already is a libc6 package from testing installed. Yesterday I had the problem with alsa but today witchcraft made the problem with alsa disappear but the one with the kernel header and as well build-essential appear. Is this really a problem of the apt pinning numbers? Or what can you suggest me to do? Maybe stick with the stable kernel and compile alsa from source? Your first plan seems good, it may just need to be polished a bit :-) Ok, thanks. I will try to again maybe with a clean install again. Like that the mess with the package dependencies should be gone. Best regards Ramon -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jkkhc7$k3p$1...@dough.gmane.org
Re: Apt-pinning confusion
On Sat, 24 Mar 2012 13:14:47 +, Ramon Hofer wrote: On Fri, 23 Mar 2012 18:55:13 +, Camaleón wrote: What do you think it would be better to completely go with testing. Testing is currently quite stable but there are significant differences between wheezy and squeeze, like the gnome environment. I think this won't make any difference for me because I will only use the base system with xorg and xbmc without any window manager. Oh, that will make things easier (in the event you want to go with testing) :-) I'm not going to make any comments about pinning because I've never used but just a question: have you considered in using pinning only for the packages you want to be kept for a specific flavour? That is, being more selective to avoid additional problems or messing up too many packages. This sounds good. I thought I can do that by installing via apt-get -t wheezy alsa-utils. Yes, if you manually specify in that way it's even safer. (...) Unfortunately I don't have synaptic. I only have the terminal since I don't want to use any window manager for xbmc. Aptitude can be a good replacement for Synaptic. I can't as well install build-essential. There are many dependencies which usually are solved automatically. I think this is something that shouldn't be. When I want to install build- essential it asks for libc6-dev which depends on libc but a newer version is to be installed: http://pastebin.com/raw.php?i=FCBUeaVg $ sudo apt-get -t squeeze-backports install build-essential It seems as if I made a mess because there already is a libc6 package from testing installed. Mmm, I can't see such that package available for the backports :-? Your first plan seems good, it may just need to be polished a bit :-) Ok, thanks. I will try to again maybe with a clean install again. Like that the mess with the package dependencies should be gone. Wow... no need to re-install :-), just be sure about the steps you're doing. Whether in doubt, launch aptitude and try from there, it usually provides insightful information when having to deal with different/mixed sources. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jkkkfd$7bd$6...@dough.gmane.org
Re: Apt-pinning confusion
On Fri, 23 Mar 2012 12:15:10 +, Ramon Hofer wrote: So I thought I'd go with Stable, the kernel from backports and alsa from testing. Unfortunately this doesn't work. I suppose my problem are wrong apt- preferences numbers or something like this. Could it be that it's not possible to have the squeeze-backports kernel, wheezy alsa-utils and any build-essential installed at the same time is not possible? Here's the output of apt-get install build-essential and apt-get -t wheezy install alsa-utils. http://pastebin.com/raw.php?i=njV7phnL So I switched to the wheezy build essential. It deinstalled the 2.6 headers. Then I was able to install alsa-utils from wheezy. But when I want to install a dependency from xbmc libcurl4-gnutls-dev I have to install pkg-config which remove build-essential again. Maybe it's easier for me to switch to Wheezy and install the libbost package from Squeeze. Or am I missing something? Best regards Ramon -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jkkmo2$81t$1...@dough.gmane.org
Apt-pinning confusion
Hi all I'm trying to put the MythTV PVR XBMC version on my Shuttle box. I need a newer alsa version than the one from Squeeze because the stable version doesn't see the soundcard. So I wanted to install alsa from testing. And because I use a SSD I thought it would be a good idea to use the squeeze-backports kernel. What do you think it would be better to completely go with testing. There are two reasons why I didn't want to do this: First I need to compile the jme module manually to be able to use the network interface. So I thought the less changes to the kernel makes me less often compile that module again. Second the XBMC version I want to install needs libboost version 1.47 or older. So I thought I'd go with Stable, the kernel from backports and alsa from testing. Unfortunately this doesn't work. I suppose my problem are wrong apt- preferences numbers or something like this. Here's my sources.list: http://pastebin.com/5SQhvDqw And apt preferences: http://pastebin.com/VcndLA6C And here's the error I get when I try to install linux-headers-686-pae from squeeze-backports: http://pastebin.com/RcAPE36t The following packages have unmet dependencies: linux-headers-686-pae : Depends: linux-headers-3.2.0-0.bpo.2-686-pae but it is not going to be installed E: Broken packages Yesterday I had the problem with alsa but today witchcraft made the problem with alsa disappear but the one with the kernel header and as well build-essential appear. Is this really a problem of the apt pinning numbers? Or what can you suggest me to do? Maybe stick with the stable kernel and compile alsa from source? Best regards Ramon -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jkhpge$2h0$1...@dough.gmane.org
Re: Apt-pinning confusion
On Fri, 23 Mar 2012 12:15:10 +, Ramon Hofer wrote: Hi all I'm trying to put the MythTV PVR XBMC version on my Shuttle box. I need a newer alsa version than the one from Squeeze because the stable version doesn't see the soundcard. So I wanted to install alsa from testing. And because I use a SSD I thought it would be a good idea to use the squeeze-backports kernel. What do you think it would be better to completely go with testing. Testing is currently quite stable but there are significant differences between wheezy and squeeze, like the gnome environment. There are two reasons why I didn't want to do this: First I need to compile the jme module manually to be able to use the network interface. So I thought the less changes to the kernel makes me less often compile that module again. My wild guess is that wheezy kernel is not going to change much since now (3.2.12 is the current one) and IIRC, wheezy will be relased with this (3.2.x) branch but well... this can change at any time so yes, you will have to recompile the kernel module for every kernel change. Second the XBMC version I want to install needs libboost version 1.47 or older. Any specific reason for you to stick with a specific version of XBMC? :-? So I thought I'd go with Stable, the kernel from backports and alsa from testing. Sounds reasonable. Unfortunately this doesn't work. I suppose my problem are wrong apt- preferences numbers or something like this. Here's my sources.list: http://pastebin.com/5SQhvDqw And apt preferences: http://pastebin.com/VcndLA6C (tip: when sending a pastebin link, I prefer to use the raw mode, it reads better, i.e.: http://pastebin.com/raw.php?i=VcndLA6C) I'm not going to make any comments about pinning because I've never used but just a question: have you considered in using pinning only for the packages you want to be kept for a specific flavour? That is, being more selective to avoid additional problems or messing up too many packages. And here's the error I get when I try to install linux-headers-686-pae from squeeze-backports: http://pastebin.com/RcAPE36t The following packages have unmet dependencies: linux-headers-686-pae : Depends: linux-headers-3.2.0-0.bpo.2-686-pae but it is not going to be installed E: Broken packages Mmm... linux-headers-686-pae is a metapackage that has to pull linux- headers-3.2.0-0.bpo.2-686-pae automatically, I would open Sypatic to see what's going on with this although manually installing linux- headers-3.2.0-0.bpo.2-686-pae in addition to the metacpake should work. Yesterday I had the problem with alsa but today witchcraft made the problem with alsa disappear but the one with the kernel header and as well build-essential appear. Is this really a problem of the apt pinning numbers? Or what can you suggest me to do? Maybe stick with the stable kernel and compile alsa from source? Your first plan seems good, it may just need to be polished a bit :-) Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jkiguh$ld4$1...@dough.gmane.org
apt pinning (Re: Boot problem after crashed update)
Javier Barroso (javibarr...@gmail.com on 2011-05-12 19:11 +0200): Other possible solution would be pinning all packages from sid to their current version (upgrading glibc with the bug, of course), and removing sid from sources.list, and again wait, but this time you could upgrade your system. But I'm not sure if you can have a package pinned when the version is not in your repositories from sources.list (Can anyone clarify this ?) You can, but with limitations. For non-version pins, apt needs the release file so that won't work if you remove it from sources.list. So a pin like this: package: libc6 pin: version 2.11.* pin-priority: 900 Will still work without the release file, but package: libc6 pin: release a=testing pin-priority: 900 Will not work if there is no testing release in the apt cache. I would suggest for the OP to create staged pins for all suites (see below). This is what I do on all systems to prevent all hell from breaking loose when I add the wrong suite in sources.list :) Of course, simply setting APT::Default-Release is a simpler solution but it will only work if you stick to a single suite. In this specific example, setting Default-Release would have prevented libc6 from upgrading from stable to unstable, but once libc6-2.13 hits testing, there is nothing preventing apt from installing libc6-2.14 when it enters unstable. Hope this is useful to anyone, Arno aschuring@neminis:~$ cat /etc/apt/preferences.d/10releases # Always mark Debian stable as a prime candidate Package: * Pin: release o=Debian,a=stable Pin-Priority: 900 # slightly preferred release: Debian testing Package: * Pin: release o=Debian,a=testing Pin-Priority: 600 # lower priority of unstable, to allow auto-migration to testing Package: * Pin: release o=Debian,a=unstable Pin-Priority: 300 # all other Debian releases: allow upgrades, but low priority Package: * Pin: release o=Debian Pin-Priority: 200 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110512235135.51285...@neminis.loos.site
apt pinning question
I thought I had a pretty good grasp of pinning, but I can't understand the following behavior. What I'm trying to do is, for a particular package, always install the newest package version from either my local archive OR lenny-backports. My local archive is oldstable (same as lenny), and I have no target release defined. sources.list: deb http://mymirror/debian lenny main contrib non-free deb http://mymirror/debian-security lenny/updates main contrib non-free deb http://mymirror/debian-backports lenny-backports main contrib non deb http://mymirror/debian-browncs lenny local preferences: Package: * Pin: release a=oldstable Pin-Priority: 750 Package: * Pin: release a=lenny-backports Pin-Priority: 80 Package: dovecot-imapd Pin: release a=lenny-backports Pin-Priority: 750 % apt-cache policy dovecot-imapd dovecot-imapd: Installed: (none) Candidate: 1:1.2.15-1~bpo50+1 Package pin: 1:1.2.15-1~bpo50+1 Version table: 1:1.2.15-1~bpo50+1+browncs 750 750 http://mymirror lenny/local Packages 1:1.2.15-1~bpo50+1 750 80 http://mymirror lenny-backports/main Packages 1:1.0.15-2.3+lenny1 750 750 http://mymirror lenny/main Packages 750 http://mymirror lenny/updates/main Packages The priorities are equal, but the older version from lenny-backports is the candidate. I would expect the newer version to be installed. This looks broken to me. John -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110330200045.ga20...@cs.brown.edu
Re: apt pinning question
On 2011-03-30 15:00:45 John Bazik wrote:
My local archive is oldstable (same as lenny), and I have no target
release defined.
sources.list:
deb http://mymirror/debian lenny main contrib non-free
deb http://mymirror/debian-security lenny/updates main contrib non-free
deb http://mymirror/debian-backports lenny-backports main contrib non
deb http://mymirror/debian-browncs lenny local
preferences:
Package: *
Pin: release a=oldstable
Pin-Priority: 750
Package: *
Pin: release a=lenny-backports
Pin-Priority: 80
Package: dovecot-imapd
Pin: release a=lenny-backports
Pin-Priority: 750
% apt-cache policy dovecot-imapd
dovecot-imapd:
Installed: (none)
Candidate: 1:1.2.15-1~bpo50+1
Package pin: 1:1.2.15-1~bpo50+1
Version table:
1:1.2.15-1~bpo50+1+browncs 750
750 http://mymirror lenny/local Packages
1:1.2.15-1~bpo50+1 750
80 http://mymirror lenny-backports/main Packages
1:1.0.15-2.3+lenny1 750
750 http://mymirror lenny/main Packages
750 http://mymirror lenny/updates/main Packages
The priorities are equal, but the older version from lenny-backports
is the candidate. I would expect the newer version to be installed.
This looks broken to me.
Looks broken to me, as well. Perhaps this is worth a bug report? At the very
least the output is confusing.
Nothing in /etc/apt/preferences.d? What's the output of (apt-cache policy |
awk 'BEGIN { p = 0 } /^Pinned packages:/ { p = 1 } { if (p) print }')?
I'm thinking that, despite the output, that the general-form Pins are not
actually being applied to the dovecore-impad package (independent of
version), since a specific-form pins matched the package name. Because of
that, the internal (and not displayed!) priority for dovecot-
imapd_1:1.2.15-1~bpo50+1+browncs is actually 500.
(I've always been a bit irked at how priorities are displayed.)
Try adding this to your preferences:
Package: dovecot-imapd
Pin: release a=oldstable
Pin-Priority: 750
If that works, that provides evidence it is as I feared. Having any package-
name match in any specific-form prevents application of all general-form to
packages with that name. I think that is one valid interpretation of the
documentation:
If any specific-form records match an available package version then the
first such record determines the priority of the package version. Failing
that, if any general-form records match an available package version then the
first such record determines the priority of the package version. -- (man 5
apt_preferences)
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/
signature.asc
Description: This is a digitally signed message part.
