Re: making backports I have built recognised as providing correct package
Hello Craig, On 2/20/19, Craig Sanders via luv-main wrote: > On Wed, Feb 20, 2019 at 08:11:16PM +1100, Mark Trickett wrote: >> Aha, another piece of using apt-get. It is brilliant, but also a very >> steep >> learning curve. It would be very good to have a good cheat sheet in a >> printable form. > > $ apt-get --help > apt 1.8.0~rc3 (amd64) > Usage: apt-get [options] command >apt-get [options] install|remove pkg1 [pkg2 ...] >apt-get [options] source pkg1 [pkg2 ...] > > apt-get is a command line interface for retrieval of packages > and information about them from authenticated sources and > for installation, upgrade and removal of packages together > with their dependencies. > > Most used commands: > update - Retrieve new lists of packages > upgrade - Perform an upgrade > install - Install new packages (pkg is libc6 not libc6.deb) > reinstall - Reinstall packages (pkg is libc6 not libc6.deb) > remove - Remove packages > purge - Remove packages and config files > autoremove - Remove automatically all unused packages > dist-upgrade - Distribution upgrade, see apt-get(8) > dselect-upgrade - Follow dselect selections > build-dep - Configure build-dependencies for source packages > clean - Erase downloaded archive files > autoclean - Erase old downloaded archive files > check - Verify that there are no broken dependencies > source - Download source archives > download - Download the binary package into the current directory > changelog - Download and display the changelog for the given package That is a good summary, but what I (and probably others) would find very useful is a more expanded "cheat sheet" with good examples that we can extrapolate from. When I taught myself basic Postscript, I needed a cookbook of examples, the reference manual is good, but to generic in the descriptions of how to do. I still need to comprehend the standard prelude and postscripts portions that are usual. For that, I need more detail than the reference manual, and probably also some intro to Level 3, while what I have is Level 2. > See apt-get(8) for more information about the available commands. > Configuration options and syntax is detailed in apt.conf(5). > Information about how to configure sources can be found in sources.list(5). > Package and version choices can be expressed via apt_preferences(5). > Security details are available in apt-secure(8). > This APT has Super Cow Powers. Again, I am still looking for something a it more verbose, better explaining the detail, rather than just a summary. It is also why I would like a regional interest group relatively local, getting together and learning through group efforts and practice. >> I am now considering two installs on the computer, one stable, the other >> sid, and dual booting to get the scanning. As there is one normal user, I >> should be able to set up a shared home partition and the one user in each >> install sharing the one home directory structure. That way, I still have >> a >> usable system for most things, but can get at the stuff in sid at need. > > That seems overly complicated but it should work. the only thing to be wary > of > is to make sure that your user has the same UID and GID on both systems > (which > should be the default, as debian makes users with UIDs starting from 1000) I really do not want to not have a usable system now I need to use it to send in time cards. I am also (reluctantly) using Internet banking and having to depend on it. I tend to be working hours that preclude using storefront services to pay rates, electricity and Telstra, and more recently, ATO payments. Some I can pay on line with a Mastercard, some I need to use BPay from the bank site. > You probably don't even need a separate /home partition. You could just > mount > the stable system (e.g. as /stable) and symlink /home/mark on the sid system > to /stable/home/mark. Provided that sid does not have a regression or other issue that corrupts the disk, it has happened. For that reason, would have the sid install have a home on that hard drive, and not access the stable or testing. Then use the stable to transfer the files, or else use a USB stick. > Personally, I'd just upgrade to sid. I've never considered the stable > release > to be anything special, its main use to me is providing an installer to > build > new systems with (that then get immediately upgraded to sid). > > I'm biased, though: I've been using debian unstable since the 90s. BTW, the > only reason why "unstable" is called "unstable" is because a CD distributor > in 1994 or 1995 jumped the gun and released a "Debian 1.0" CD before it was > ready. The name was deliberately chosen to be scary enough to discourage > anyone from doing the same thing again...it doesn't mean that it's flaky or > crash-prone. My first copy of Linux was floppys that I never had the space to try, then Yggdrasil on CD with the drivers
Re: making backports I have built recognised as providing correct package
On Wed, Feb 20, 2019 at 08:11:16PM +1100, Mark Trickett wrote: > Aha, another piece of using apt-get. It is brilliant, but also a very steep > learning curve. It would be very good to have a good cheat sheet in a > printable form. $ apt-get --help apt 1.8.0~rc3 (amd64) Usage: apt-get [options] command apt-get [options] install|remove pkg1 [pkg2 ...] apt-get [options] source pkg1 [pkg2 ...] apt-get is a command line interface for retrieval of packages and information about them from authenticated sources and for installation, upgrade and removal of packages together with their dependencies. Most used commands: update - Retrieve new lists of packages upgrade - Perform an upgrade install - Install new packages (pkg is libc6 not libc6.deb) reinstall - Reinstall packages (pkg is libc6 not libc6.deb) remove - Remove packages purge - Remove packages and config files autoremove - Remove automatically all unused packages dist-upgrade - Distribution upgrade, see apt-get(8) dselect-upgrade - Follow dselect selections build-dep - Configure build-dependencies for source packages clean - Erase downloaded archive files autoclean - Erase old downloaded archive files check - Verify that there are no broken dependencies source - Download source archives download - Download the binary package into the current directory changelog - Download and display the changelog for the given package See apt-get(8) for more information about the available commands. Configuration options and syntax is detailed in apt.conf(5). Information about how to configure sources can be found in sources.list(5). Package and version choices can be expressed via apt_preferences(5). Security details are available in apt-secure(8). This APT has Super Cow Powers. > I am now considering two installs on the computer, one stable, the other > sid, and dual booting to get the scanning. As there is one normal user, I > should be able to set up a shared home partition and the one user in each > install sharing the one home directory structure. That way, I still have a > usable system for most things, but can get at the stuff in sid at need. That seems overly complicated but it should work. the only thing to be wary of is to make sure that your user has the same UID and GID on both systems (which should be the default, as debian makes users with UIDs starting from 1000) You probably don't even need a separate /home partition. You could just mount the stable system (e.g. as /stable) and symlink /home/mark on the sid system to /stable/home/mark. Personally, I'd just upgrade to sid. I've never considered the stable release to be anything special, its main use to me is providing an installer to build new systems with (that then get immediately upgraded to sid). I'm biased, though: I've been using debian unstable since the 90s. BTW, the only reason why "unstable" is called "unstable" is because a CD distributor in 1994 or 1995 jumped the gun and released a "Debian 1.0" CD before it was ready. The name was deliberately chosen to be scary enough to discourage anyone from doing the same thing again...it doesn't mean that it's flaky or crash-prone. IMO, obsessing over the "stable" release of debian misses one of the best and most important features of debian - it's a constantly updating distribution with new and updated stuff every day. This occasionally (rarely) causes problems but a) as long as you're careful and don't let apt uninstall stuff you don't want it to, it's no big deal and b) those problems are almost always easily fixedback in the 90s there were occasionally some huge problems, but not since the transition from libc5 to libc6 in 1998 (which required a very precise and complicated upgrade procedure. I wrote a script called autoup.sh to completely automate the procedure, taking into account the vagaries and bugs reported by many people at the time. This was before apt existed, which automates the kind of dependency resolution I had to do in my script: my script was a one-off hard-coded hack, while apt analyses the deps etc and arrives at a solution) The biggest problem with sid these days is the constant churn of KDE and Qt packages (and, to a lesser extent, gnome). I've found that the best way to avoid problems there is to use 'apt-mark' to hold the few KDE & Qt apps I use (okular, qdfview, calibre) so that they don't get auto-uninstalled due to versioned dependencies (doing that causes the KDE and/or Qt packages to not get upgraded if that would cause the help packages to be removed). craig -- craig sanders ___ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
Re: making backports I have built recognised as providing correct package
Hello Craig,
Not ignoring, just two rather long days of work, Traffic Control, an
hour or a little less to the yard, then an hour to the work site, and
the same returning, with more than 12 hours between arriving at the
yard and getting back for two days. Thankfully shorter today.
On 2/17/19, Craig Sanders via luv-main wrote:
> On Sun, Feb 17, 2019 at 05:59:54PM +1100, Mark Trickett wrote:
>> This is the issue, I will have to remove and rebuild the tiff packages.
>> The
>> relevant lines are :-
>>
>> libtiff5 (=${binary:version}),
>> libtiffxx5 (=$binary:version})
>>
>> Is there a way to alter these to add the "~backport" item? or should I
>> remove the "~backport" item from the version of the whole in the changelog
>> file?
>
> it's probably easiest to just rebuild these pacakages as "4.0.10-4" without
> the "~backport"
>
> it probably won't even make any difference anyway - by the time you
> dist-upgrade to the next debian release, libtiff* will probably have been
> upgraded a few times. if not, you could always manually force the official
> debian packages to be installed with "apt-get --reinstall install libtiff5
> libtiffxx5 ...".
Aha, another piece of using apt-get. It is brilliant, but also a very
steep learning curve. It would be very good to have a good cheat sheet
in a printable form.
I am now considering two installs on the computer, one stable, the
other sid, and dual booting to get the scanning. As there is one
normal user, I should be able to set up a shared home partition and
the one user in each install sharing the one home directory structure.
That way, I still have a usable system for most things, but can get at
the stuff in sid at need.
Regards,
Mark Trickett
> craig
>
> --
> craig sanders
> ___
> luv-main mailing list
> luv-main@luv.asn.au
> https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
>
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
Re: making backports I have built recognised as providing correct package
On Sun, Feb 17, 2019 at 05:59:54PM +1100, Mark Trickett wrote:
> This is the issue, I will have to remove and rebuild the tiff packages. The
> relevant lines are :-
>
> libtiff5 (=${binary:version}),
> libtiffxx5 (=$binary:version})
>
> Is there a way to alter these to add the "~backport" item? or should I
> remove the "~backport" item from the version of the whole in the changelog
> file?
it's probably easiest to just rebuild these pacakages as "4.0.10-4" without
the "~backport"
it probably won't even make any difference anyway - by the time you
dist-upgrade to the next debian release, libtiff* will probably have been
upgraded a few times. if not, you could always manually force the official
debian packages to be installed with "apt-get --reinstall install libtiff5
libtiffxx5 ...".
craig
--
craig sanders
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
Re: making backports I have built recognised as providing correct package
Hello Craig,
On 2/17/19, Craig Sanders via luv-main wrote:
> On Sun, Feb 17, 2019 at 04:59:46PM +1100, Mark Trickett wrote:
>> Even with one of the backports, it produced multiple debs, and one of
>> those
>> depends on two others, and adding the "~backport" tag in the
>
> it's not a "tag", it's part of the version string for the package you built.
I regard the "~backport" as a tag on the version string, a component
that I call a tag, but I understand it becomes part of the version.
> For most Depends: entries, the version isn't important - as long as the
> package is installed, the dependency will be satisfied. But some
> dependencies
> are versioned and require an exactly = or >= match to a specific version of
> a package.
This is the issue, I will have to remove and rebuild the tiff
packages. The relevant lines are :-
libtiff5 (=${binary:version}),
libtiffxx5 (=$binary:version})
Is there a way to alter these to add the "~backport" item? or should I
remove the "~backport" item from the version of the whole in the
changelog file?
>> I built tiff-4.0.10, and libtiff-dev depends on libtiff5 and libtiffxx5
>> (version = 4.0.10-4 versus 4.0.10-4~backport). Without those all
>> installed,
>> dpkg-buildpackage will not build sane-backends-1.0.27.
>
> If you've built and installed libtiffxx5 version "4.0.10-4~backport" and
> sane-backends or some other source package depends on "4.0.10-4", then edit
> the debian/control file for that package to change the dependency to version
> "4.0.10-4~backport".
If it were just a straight string, not a problem, but then maybe for
my backport, that would suffice instead of picking the version from
the binary, else look at putting the backport mention in there.
> versioned dependencies have to either be an exact match for the version
> string
> (when the dep specifies "=") or greater-than-or-equal-to a specific version
> string (when the dep specifies ">=").
i did not expect this, but it makes sense, just the "right"' way to
deal with it. Yes, it is on my system and not propagated, but doing
the right way will reduce other problems later. that is why I do stick
with the Debian package management.
> with some packages, you might also see versioned Conflicts lines that have
> "="
> or "<=".
>
> craig
Again many thanks. These little hiccups are a good learning exercise,
although frustrating.
Regards,
Mark Trickett
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
Re: making backports I have built recognised as providing correct package
On Sun, Feb 17, 2019 at 04:59:46PM +1100, Mark Trickett wrote: > Even with one of the backports, it produced multiple debs, and one of those > depends on two others, and adding the "~backport" tag in the it's not a "tag", it's part of the version string for the package you built. For most Depends: entries, the version isn't important - as long as the package is installed, the dependency will be satisfied. But some dependencies are versioned and require an exactly = or >= match to a specific version of a package. > I built tiff-4.0.10, and libtiff-dev depends on libtiff5 and libtiffxx5 > (version = 4.0.10-4 versus 4.0.10-4~backport). Without those all installed, > dpkg-buildpackage will not build sane-backends-1.0.27. If you've built and installed libtiffxx5 version "4.0.10-4~backport" and sane-backends or some other source package depends on "4.0.10-4", then edit the debian/control file for that package to change the dependency to version "4.0.10-4~backport". versioned dependencies have to either be an exact match for the version string (when the dep specifies "=") or greater-than-or-equal-to a specific version string (when the dep specifies ">="). with some packages, you might also see versioned Conflicts lines that have "=" or "<=". craig -- craig sanders ___ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
making backports I have built recognised as providing correct package
Hello all, Again more thanks to Craig. I have built and installed several backports, but the one I am still trying for will not yet build. It does not see the backports I did build and install as providing the dependencies, yet. I suspect that I may need to alter something in the dependencies thhat I backport built, or is it possible to alter the dependencies requirements in the backport built with dpkg-buildpackage. Even with one of the backports, it produced multiple debs, and one of those depends on two others, and adding the "~backport" tag in the changelog stalls the one that depends on the other two. Maybe did not need the backport tag, but on the other hand, I do want such indication. I built tiff-4.0.10, and libtiff-dev depends on libtiff5 and libtiffxx5 (version = 4.0.10-4 versus 4.0.10-4~backport). Without those all installed, dpkg-buildpackage will not build sane-backends-1.0.27. Regards, Mark Trickett ___ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
