Bug#905734: found #905734 hplip/3.17.10
That worked! Although it took some time to figure out how to build using backports. Evidently, there is some folklore involved. I was even able to make a version for the raspberry pi! Thank You. On Wed, Dec 12, 2018 at 3:24 PM Didier 'OdyX' Raboud wrote: > Dear Paul, > > Le vendredi, 7 décembre 2018, 16.15:01 h CET Paul Elliott a écrit : > > I just downloaded it. It won't build under stretch. All the builds shown > in > > the logs are under sid or experimental. > > It does under stretch-backports (aka stretch + backports) > > > https://buildd.debian.org/status/package.php?p=hplip&suite=stretch-backports > > To build, it needs debhelper and dh-autoreconf from backports indeed. > > > Correct me if I am wrong, but if you build under sid, it won't run under > > stretch, because the libraries linked against won't be the same. > > Exactly. Different release suites produce differently linked software. > > > I don't think it will help stretch users. > > Stretch users don't get updated software, ONLY security fixes. > > Stretch users who enabled backports can get an hplip that was built > against > stretch libraries that can be installed on stretch hosts. > > You seem to want a source hplip from unstable that builds without > modifications in stable. That's not something I'm interested in providing > and > a very unusual requirement for Debian packages. > > You also seem to want binary hplip packages that, when built in unstable, > can > be installed on stretch hosts. That neither is something I'm interested in > providing, _also_ an unusual requirement, and that cannot be easily > guaranteed. > > Finally, this bug was about "Unable to backport package hplip on > stretch". It > is not a requirement for unstable packages to build without changes on > stable. > So I made minimal changes (thanks to inputs from this bug) to be able to > build > hplip in stretch-backports, AND I uploaded this modified package to the > stretch-backports suite. It is now accessible in the Debian-standard way > to > get backported packages on stable. There's nothing more I can (or will) > do. > > EOD for me. > > Cheers, > OdyX
Bug#905734: found #905734 hplip/3.17.10
Dear Paul, Le vendredi, 7 décembre 2018, 16.15:01 h CET Paul Elliott a écrit : > I just downloaded it. It won't build under stretch. All the builds shown in > the logs are under sid or experimental. It does under stretch-backports (aka stretch + backports) https://buildd.debian.org/status/package.php?p=hplip&suite=stretch-backports To build, it needs debhelper and dh-autoreconf from backports indeed. > Correct me if I am wrong, but if you build under sid, it won't run under > stretch, because the libraries linked against won't be the same. Exactly. Different release suites produce differently linked software. > I don't think it will help stretch users. Stretch users don't get updated software, ONLY security fixes. Stretch users who enabled backports can get an hplip that was built against stretch libraries that can be installed on stretch hosts. You seem to want a source hplip from unstable that builds without modifications in stable. That's not something I'm interested in providing and a very unusual requirement for Debian packages. You also seem to want binary hplip packages that, when built in unstable, can be installed on stretch hosts. That neither is something I'm interested in providing, _also_ an unusual requirement, and that cannot be easily guaranteed. Finally, this bug was about "Unable to backport package hplip on stretch". It is not a requirement for unstable packages to build without changes on stable. So I made minimal changes (thanks to inputs from this bug) to be able to build hplip in stretch-backports, AND I uploaded this modified package to the stretch-backports suite. It is now accessible in the Debian-standard way to get backported packages on stable. There's nothing more I can (or will) do. EOD for me. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#905734: found #905734 hplip/3.17.10
But upon request, packages can be adapted to target specific suites; that's precisely what *-backports suites are. That's why I uploaded a _modified_ hplip 3.18.10+dfsg0-3 to the `stretch-backports` suite. That upload was accepted today and is in the process of being built for all architectures. https://buildd.debian.org/status/package.php?p=hplip&suite=stretch-backports Stretch users will be able to get the latest hplip by using the `stretch- backports` suite additionally to their standard APT setup. I just downloaded it. It won't build under stretch. All the builds shown in the logs are under sid or experimental. Correct me if I am wrong, but if you build under sid, it won't run under stretch, because the libraries linked against won't be the same. I don't think it will help stretch users. Thank you for reading this email. On Thu, Dec 6, 2018 at 1:23 PM Didier 'OdyX' Raboud wrote: > Le jeudi, 6 décembre 2018, 19.03:57 h CET Paul Elliott a écrit : > > You guys must be developing under sid, and never checking that your > > releases will actually build under the various stable releases. > > Exactly. And it allows removing _a lot_ of unneeded complexity. As hplip > packager, I provide new upstream releases tailored towards the _next_ > stable > release. The "staging" area for this is `unstable`. It will then migrate > to > `testing` (aka `buster`). > > Backporting these new upstream releases is a _different_ and _additional_ > work. There's absolutely zero requirement for packages uploaded to > `unstable` > to build without modifications on other releases. > > > But your branches are still named for the various stable versions, > > that is, debian/stretch-backports, debian/stretch, > debian/jessie-backports, > > debian/jessie. > > Yes. These build on the corresponding target suites. They don't > necessarily > integrate the latest upstream releases (nor should they). > > > But you never check that these commits will actually build for these > > versions. > > No, we don't. Doing so would be _a lot_ of unneeded work. > > But upon request, packages can be adapted to target specific suites; > that's > precisely what *-backports suites are. That's why I uploaded a _modified_ > hplip 3.18.10+dfsg0-3 to the `stretch-backports` suite. That upload was > accepted today and is in the process of being built for all architectures. > > > https://buildd.debian.org/status/package.php?p=hplip&suite=stretch-backports > > Stretch users will be able to get the latest hplip by using the `stretch- > backports` suite additionally to their standard APT setup. > > Cheers, > OdyX
Bug#905734: found #905734 hplip/3.17.10
Le jeudi, 6 décembre 2018, 19.03:57 h CET Paul Elliott a écrit : > You guys must be developing under sid, and never checking that your > releases will actually build under the various stable releases. Exactly. And it allows removing _a lot_ of unneeded complexity. As hplip packager, I provide new upstream releases tailored towards the _next_ stable release. The "staging" area for this is `unstable`. It will then migrate to `testing` (aka `buster`). Backporting these new upstream releases is a _different_ and _additional_ work. There's absolutely zero requirement for packages uploaded to `unstable` to build without modifications on other releases. > But your branches are still named for the various stable versions, > that is, debian/stretch-backports, debian/stretch, debian/jessie-backports, > debian/jessie. Yes. These build on the corresponding target suites. They don't necessarily integrate the latest upstream releases (nor should they). > But you never check that these commits will actually build for these > versions. No, we don't. Doing so would be _a lot_ of unneeded work. But upon request, packages can be adapted to target specific suites; that's precisely what *-backports suites are. That's why I uploaded a _modified_ hplip 3.18.10+dfsg0-3 to the `stretch-backports` suite. That upload was accepted today and is in the process of being built for all architectures. https://buildd.debian.org/status/package.php?p=hplip&suite=stretch-backports Stretch users will be able to get the latest hplip by using the `stretch- backports` suite additionally to their standard APT setup. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#905734: found #905734 hplip/3.17.10
Yes, by cherry-picking 7f8981e96 Add --no-parallel to dh and dh_auto_build to fix building on stable you can make everything up to and including 3.17.10+repack0-6 build! But at 3.18.4+repack0-1 and above fails to build because of Bump debhelper compat to 11 Stretch does not have debhelper v11 support. You guys must be developing under sid, and never checking that your releases will actually build under the various stable releases. But your branches are still named for the various stable versions, that is, debian/stretch-backports, debian/stretch, debian/jessie-backports, debian/jessie. But you never check that these commits will actually build for these versions. This is very confusing. Paul Elliott On Sun, Nov 25, 2018 at 2:28 PM Uwe Kleine-König wrote: > Hello Paul, > > On 11/24/18 10:08 AM, Paul Elliott wrote: > > 3.17.7 and 3.17.10 fail to build because of this bug, if you build with > > "sbuild -d stretch hplip_3.17.10+repack0-7.dsc" > > > > I have determined that the commit that causes this problem is: > > 7dbf1595d Migrate to debhelper 10, cleanup debian/rules > > given that the package compiles just fine when parallel building is > disabled I bet that the relevant part of 7dbf1595d is the migration to > debhelper 10. The debhelper manpage specifies for "--parallel, > --no-parallel": > > If neither option is specified, debhelper currently defaults to > --parallel in compat 10 (or later) and --no-parallel otherwise. > > Best regards > Uwe > > >
Bug#905734: found #905734 hplip/3.17.10
Hello Paul, On 11/24/18 10:08 AM, Paul Elliott wrote: > 3.17.7 and 3.17.10 fail to build because of this bug, if you build with > "sbuild -d stretch hplip_3.17.10+repack0-7.dsc" > > I have determined that the commit that causes this problem is: > 7dbf1595d Migrate to debhelper 10, cleanup debian/rules given that the package compiles just fine when parallel building is disabled I bet that the relevant part of 7dbf1595d is the migration to debhelper 10. The debhelper manpage specifies for "--parallel, --no-parallel": If neither option is specified, debhelper currently defaults to --parallel in compat 10 (or later) and --no-parallel otherwise. Best regards Uwe signature.asc Description: OpenPGP digital signature
