Hi Andreas Henriksson, On Thu, Jun 18, 2015 at 01:41:53AM +0200, Andreas Henriksson wrote: > Forgot to ask when we spoke earlier, but one last blocker for me > personally would be if there are (still?) problems with building a > profiled package with pbuilder.... I need to be able to build the > package (without using any profile) myself after all. ;) > Do you know the status of build profiles in pbuilder?
The last maintainer upload happened more than two years ago. The BTS has 41 patches including the build profile patch #740577. The last three uploads were NMUs. It seems that pbuilder has bigger problems than missing build profile support. It needs a maintainer. > (Not sure how/if this comment is relevant. If needed algernon will likely > happily add features to dh-exec. Also couldn't simply environment > variable expansion be used? Possibly. I don't see how dh-exec can filter by anything but architectures though. > A comment above this entire block explaining what the purpose is > would be useful though...) Sadly, you are correct in that it is missing. > > + install -d debian/tmp/lib/systemd/system > > + install -m644 sys-utils/fstrim.service.in > > debian/tmp/lib/systemd/system/fstrim.service The primary function is to make the package not FTBFS. These files are installed by util-linux.install and the build errors out when they are missing. This seemed to be the most trivial way to make the build succeed. > I doubt this will work as intended. The *.in files are mangled, not just > renamed and installed. You'll likely want to use something like this > to produce the sys-utils/fstrim.service before installing it: > make PATHFILES=sys-utils/fstrim.service sys-utils/fstrim.service > > That should make sure @sbindir@ gets replaced with /sbin ... At the time creating the hunk, I was aware that not interpolating the .in file would result in different content and considered it ok for documentation files. > (For me personally I wouldn't mind to simplify this into just not shipping > the systemd service examples when building as stage1 profile, but I guess > you want the packages to be 100% equivalent when build with or without > profiles. Even if that is the goal, I'd personally feel safer if the > package was fully rebuilt without profiles after the bootstrapping is done > just in case. I've been bitten by lingering bootstrapping-altered > packages before.) Certainly making staged builds bitidentical is an interesting goal and should be done whenever feasible. Like many rules, it does have exceptions since this requirement is sometimes hard to achieve and its use is limited. Changes to /usr/share/doc are generally considered acceptable for stage1 (because policy mandates that packages must work without /usr/share/doc). Packages need to be rebuilt natively(!) instead of cross and without stages anyway. Feel free to improve upon that hunk. Just without it util-linux stage1 currently FTBFS in stage1. So what's your preference for handling this? Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
