Spec URL: http://oron.fedorapeople.org/deb-package/debhelper.spec SRPM URL: http://oron.fedorapeople.org/deb-package/debhelper-9.20120909-1.fc20.src.rpm Description: A collection of programs that can be used in a debian/rules file to automate common tasks related to building debian packages. Programs are included to install various files into your package, compress files, fix file permissions, integrate your package with the debian menu system, debconf, doc-base, etc. Most debian packages use debhelper as part of their build process. Fedora Account System Username: oron
* This RR replaces #591190 as it was stalled.
*** Bug 591190 has been marked as a duplicate of this bug. ***
Issues: ======= - Package does not contain duplicates in %files. Note: warning: File listed twice: /usr/share/man/fr/man7/debhelper.fr.7.gz See: http://fedoraproject.org/wiki/Packaging/Guidelines#DuplicateFiles - Package consistently uses macro is (instead of hard-coded directory names). Note: Using both %{buildroot} and $RPM_BUILD_ROOT See: http://fedoraproject.org/wiki/Packaging/Guidelines#macros Rpmlint ------- Checking: debhelper-9.20120909-1.fc17.noarch.rpm debhelper.noarch: E: devel-dependency dpkg-devel debhelper.noarch: W: spelling-error %description -l en_US debconf -> confide debhelper.noarch: W: incoherent-version-in-changelog 9.20120909 ['9.20120909-1.fc17', '9.20120909-1'] 1 packages and 0 specfiles checked; 1 errors, 2 warnings. incoherent-version-in-changelog may be fixed , and dependency dpkg-devel we need dpkg ?
from http://ftp.de.debian.org/debian/pool/main/d/debhelper/ we have a new version http://ftp.de.debian.org/debian/pool/main/d/debhelper/debhelper_9.20130507.tar.gz we should updated isn't it ?
Spec URL: http://oron.fedorapeople.org/deb-package/debhelper.spec SRPM URL: http://oron.fedorapeople.org/deb-package/debhelper-9.20120909-1.fc18.src.rpm for comment #3 * The duplicate file revealed a far bigger issue -- find_lang --with-man only handle single man-page -- replaced with modified logic in our .spec * Updated one $RPM_BUILD_ROOT to %{buildroot} so .spec is consistent * Updated changelog to have consistent version * About "dpkg-devel": - Yes it is needed. It contains all the tools used by the debhelper wrappers like deb-substvars, deb-shlibs, etc. - The dpkg RPM split mirror the Debian package split -- I think w should stay that way. - Is there a standard way to declare -- "this is an rpmlint exception?" for comment #4 * No. The new version belongs to Debian/sid (unstable) * Meanwhile, all my RR are synchonized with Debian/wheezy (the new stable) * On the long run, I think Debian/testing is a better fit for Fedora life-cycle. However, I think we should leave it for now: - Current Debian/jessie (new testing) has just been unfrozen, so not much of a difference. - If someone want to support EPEL, than Debian/stable may be a better starting point. Also: * We still need the new dpkg (rhbz#648384) * And I'm in the process of pushing po-debconf * So maybe we should wait for few days for a final test
(In reply to comment #5) > for comment #3 > * The duplicate file revealed a far bigger issue -- find_lang --with-man > only handle single man-page -- replaced with modified logic in our .spec Should keep comment the original find_lang --with-man, for when find_lang works as we expect. > * Updated one $RPM_BUILD_ROOT to %{buildroot} so .spec is consistent OK > * Updated changelog to have consistent version not complete yet need : -* Thu May 9 2013 Oron Peled <oron.il> - 9.20120909-1.fc18 +* Thu May 9 2013 Oron Peled <oron.il> - 9.20120909-1 > * About "dpkg-devel": > - Yes it is needed. It contains all the tools used by the debhelper > wrappers like deb-substvars, deb-shlibs, etc. > - The dpkg RPM split mirror the Debian package split -- I think w > should stay that way. > - Is there a standard way to declare -- "this is an rpmlint exception?" We need dpkg-devel before finish this review, I think , like others that depend on this one. Also you used tabs instead spaces , with vim we should use set expandtab by default , if you use vim to edit you can do: :set expandtab :retab to fix - s:%{buildroot}:: - s:\(.*/man/\([^/_]\+\).*/man[a-z0-9]\+/[^.]\+\.[a-z0-9].*\):%lang(\2) \1*: - s:^\([^%].*\):: - s:%lang(C) :: - /^$/d - ' > debhelper-mans.lang + s:%{buildroot}:: + s:\(.*/man/\([^/_]\+\).*/man[a-z0-9]\+/[^.]\+\.[a-z0-9].*\):%lang(\2) \1*: + s:^\([^%].*\):: + s:%lang(C) :: + /^$/d + ' > debhelper-mans.lang
(In reply to comment #5) > for comment #3 > * The duplicate file revealed a far bigger issue -- find_lang --with-man > only handle single man-page -- replaced with modified logic in our .spec OK thinking better, rollback the change please, because the duplicate file is just a warning, so is not a big issue, we don't need to be fixed . It is better than this king of scripts . Thanks,
(In reply to comment #5) > for comment #3 > * The duplicate file revealed a far bigger issue -- find_lang --with-man > only handle single man-page -- replaced with modified logic in our .spec OK thinking better, rollback the change please, because the duplicate file is just a warning, so is not a big issue, we don't need to fix it . It is better than this kind of scripts . Thanks,
(I'm still waiting for dpkg bugfix and po-debconf gathering enough karma) Interim SPEC: http://oron.fedorapeople.org/deb-package/debhelper.spec * Changelog version fixed * No more tabs Translated man-pages handling: * The problem is not the duplication, that's just what triggered my research. The problem is that all other translated man-pages will not get a '%lang(..)' tag in the RPM. * Now I cleaned the logic and documented it in the .spec: - We install man-pages manually anyway - So I generate the .lang in the same loop - The 'sed' becomes trivial (no huge regex) - I hope the comments in the .spec are good enough Let's freeze this for few days until po-debconf is in Fedora repositories and dpkg version is updated (any new response from maintainer yet?)
(In reply to comment #6) > > * About "dpkg-devel": > > - Yes it is needed. It contains all the tools used by the debhelper > > wrappers like deb-substvars, deb-shlibs, etc. > > - The dpkg RPM split mirror the Debian package split -- I think w > > should stay that way. > > - Is there a standard way to declare -- "this is an rpmlint exception?" > > We need dpkg-devel before finish this review, I think , like others that > depend on this one. Hi, I made some confusion here , I though we don't have dpkg and pkg-devel , but we have it, the bug #648384 is just to updated dpkg from 1.15.x to 1.16.x . debhelper.noarch: E: devel-dependency dpkg-devel as point out in bug #591192#c1 by Miroslav Suchý This should be safe to ignore, but if you did not make review yet I would maybe suggest to keep Debian original name dpkg-dev. So just a misunderstood of fedora-review .
(In reply to comment #9) > (I'm still waiting for dpkg bugfix and po-debconf gathering enough karma) > > Interim SPEC: http://oron.fedorapeople.org/deb-package/debhelper.spec > > * Changelog version fixed > * No more tabs OK > Translated man-pages handling: > * The problem is not the duplication, that's just what triggered > my research. The problem is that all other translated man-pages > will not get a '%lang(..)' tag in the RPM. > > * Now I cleaned the logic and documented it in the .spec: > - We install man-pages manually anyway > - So I generate the .lang in the same loop > - The 'sed' becomes trivial (no huge regex) > - I hope the comments in the .spec are good enough OK looks good . So no blockers Package approved
* We are still blocked on dpkg-devel >= 1.16.x (bug #648384) * The up-to-date debhelper we review need up-to-date dpkg-devel
(In reply to comment #12) > * We are still blocked on dpkg-devel >= 1.16.x (bug #648384) Is really required dpkg-devel >= 1.16.x ? > * The up-to-date debhelper we review need up-to-date dpkg-devel Other confusion here, dpkg-1.15 is already in repos , why update to 1.16.x needs a review ? is the package so different ?
(In reply to comment #13) > Is really required dpkg-devel >= 1.16.x ? * Yes * You can verify it very easily: - Install dpkg-devel we have in Fedora (1.15.x) - Try to build debhelper > Other confusion here, dpkg-1.15 is already in repos , why update to 1.16.x needs a review ? * No need to review dpkg-devel, just fix bug #648384 (update dpkg-devel) * I just said the the *debhelper* we review need an up-to-date dpkg-devel Hope it's clear now.
(In reply to comment #14) > (In reply to comment #13) > > Is really required dpkg-devel >= 1.16.x ? > > * Yes > * You can verify it very easily: > - Install dpkg-devel we have in Fedora (1.15.x) > - Try to build debhelper I can build debhelper, mock builds the packages on F17, F18, F19 and rawhide.
The all man pages are in wrong place for example for dh : dh.de.1.gz shouldn't be in /usr/share/man/man1/ should be in /usr/share/man/de/man1/ but without "de" like this: /usr/share/man/de/man1/dh.1.gz and not like this: /usr/share/man/de/man1/dh.de.1.gz Also is strange, the fact that builds in F19 and rawhide miss many programs in bin and some man pages diff list_18-i386 list_19-i386 -up -/usr/bin/dh_auto_build -/usr/bin/dh_auto_clean -/usr/bin/dh_auto_configure -/usr/bin/dh_auto_install -/usr/bin/dh_auto_test (..) -/usr/share/man/man1/dh.1.gz -/usr/share/man/man1/dh_auto_build.1.gz (..)
Document why we need dpkg >= 1.16.x: * The problem is not in the build, but in runtime (I wasn't clear enough) * Here is an example: $ dh_auto_clean dh_auto_clean: unable to load build flags: Can't locate Dpkg/BuildFlags.pm in @INC (@INC contains: /usr/local/lib/perl5 /usr/local/share/perl5 /usr/lib/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5 /usr/share/perl5 .) at (eval 3) line 2. BEGIN failed--compilation aborted at (eval 3) line 2. * This perl class doesn't exist at all in dpkg-devel <= 1.15.x * In dpkg >= 1.16.x, all perl classes are packaged in libdpkg-perl * So, I'll fix dependencies as follows: - BuildRequires: dpkg-devel # it pulls libdpkg-perl as well - Requires: libdpkg-perl * And we get one less rpmlint error (about runtime depends on *-devel package) I'll fix this together with fixes from comment #16 and upload new spec/srpm
(In reply to comment #17) If so please replace: BuildRequires: dpkg-devel by BuildRequires: dpkg-devel >= 1.16 and Requires: dpkg-devel by Requires: dpkg-devel >= 1.16
I just want to note. (In reply to comment #18) > and > > Requires: dpkg-devel > by > Requires: dpkg-devel >= 1.16 Citation: (In reply to comment #17) > * So, I'll fix dependencies as follows: > - BuildRequires: dpkg-devel # it pulls libdpkg-perl as well > - Requires: libdpkg-perl There would not runtime requirement of -devel.
Spec URL: http://oron.fedorapeople.org/deb-package/debhelper.spec SRPM URL: http://oron.fedorapeople.org/deb-package/debhelper-9.20120909-1.fc18.src.rpm * Manual pages (In reply to comment #16): - Found a far better solution: install man-pages via dh_installman - Luckily, man-pages layout is FHS compliant in both Fedora/Debian - The debhelper-mans.lang is generated as before (Fedora specific). * Dependencies (In reply to comment #19 and comment 18): - Build-Requires: dpkg-devel # No need for specific version (both dpkg 1.15.x and 1.16.x are OK) - Requires: libdpkg-perl # No need to specify version, libdpkg-perl was added only at 1.16.x # Not a '*-devel' package -- Good. # Minor problem: rpmlint complains about 'noarch' debhelper that depends on 'lib*' package. * So what about rpmlint? - Basically, rpmlint is wrong: the libdpkg-perl contains only pure perl modules (updated bug #648384 so that dpkg.spec correctly marks libdpkg-perl is 'noarch') - Either we surrender to rpmlint and rename libdpkg-perl. IMO it's a bad idea -- better stick to upstream names per Fedora policy. - Or we ignore this rpmlint error (maybe file a bug against rpmlint?) * ... and we are still blocked by bug #648384 -- dpkg too old
Hi, before review , lets fixes things and see you agree ... I change packages names of dpkg in rawhide , because make sense and think it is the fedora way. libdpkg-perl -> dpkg-perl (fedora usually don't start with lib, sometime we may use dpkg-libs or dpkg-perl.libs ) dpkg-devel -> dpkg-dev (devel is a reserved word for headers of dpkg) . and .h .a .so -> dpkg-devel we always could rollback my commits . some answers inline (In reply to comment #20) > Spec URL: http://oron.fedorapeople.org/deb-package/debhelper.spec > SRPM URL: > > http://oron.fedorapeople.org/deb-package/debhelper-9.20120909-1.fc18.src.rpm > > * Manual pages (In reply to comment #16): > - Found a far better solution: install man-pages via dh_installman > - Luckily, man-pages layout is FHS compliant in both Fedora/Debian > - The debhelper-mans.lang is generated as before (Fedora specific). > > * Dependencies (In reply to comment #19 and comment 18): > - Build-Requires: dpkg-devel > # No need for specific version (both dpkg 1.15.x and 1.16.x are OK) will be Build-Requires: dpkg-dev > > - Requires: libdpkg-perl > # No need to specify version, libdpkg-perl was added only at 1.16.x > # Not a '*-devel' package -- Good. OK will be Build-Requires: dpkg-perl > # Minor problem: rpmlint complains about 'noarch' debhelper that > depends on 'lib*' package. this took two commits dpkg-perl can't be noarch because /usr/lib/dpkg/parsechangelog/debian and /usr/lib64/dpkg/parsechangelog/debian , I'm not sure what this parsechangelog/debian do and if shouldn't be in other place than /usr/lib/dpkg/ > * So what about rpmlint? > - Basically, rpmlint is wrong: the libdpkg-perl contains only pure perl > modules (updated bug #648384 so that dpkg.spec correctly marks > libdpkg-perl is 'noarch') dpkg-perl can't be noarch > > - Either we surrender to rpmlint and rename libdpkg-perl. IMO it's a bad > idea -- better stick to upstream names per Fedora policy. > > - Or we ignore this rpmlint error (maybe file a bug against rpmlint?) > > * ... and we are still blocked by bug #648384 -- dpkg too old we have dpkg-1.6 in rawhide , so I could review this bug properly :) Best regards,
errata : where: or dpkg-perl.libs ) should be: or dpkg-perl-libs ) where : Build-Requires: dpkg-perl should be: Requires: dpkg-perl
* Just updated bug #648384 so the information is there. * Your naming is good, so in debhelper: Build-Requires: dpkg-dev Requires: dpkg-perl * However, dpkg-perl IS 'noarch'. Here is a summary: - The /usr/lib/dpkg/parsechangelog/debian is just a perl script - It is in /usr/lib because Debian doesn't have a /usr/libexec
Created attachment 749662 [details] update dependencies of (new) dpkg Hi, we need update dependencies of dpkg , my propose specify dpkg versions >= 1.16.10 to force to use the newer dpkg packages . all rest, seems to me, is OK and ready to be approved. could you apply this patch to the review ?
please
* IMO, there's no need for explicit version forcing: - We already Require "dpkg-perl" which exist *only* in dpkg >= 1.6.x - And "dpkg-perl" Requires "dpkg" with *same* version * Anyway I only wait for the push of final dpkg (e.g: in rawhide), so I can test all these scenarios (including upgrades) before we set these dependencies in stone. Thanks,
(In reply to comment #26) > * IMO, there's no need for explicit version forcing: > - We already Require "dpkg-perl" which exist *only* in dpkg >= 1.6.x > - And "dpkg-perl" Requires "dpkg" with *same* version OK , fine by me > * Anyway I only wait for the push of final dpkg (e.g: in rawhide), so I can > test > all these scenarios (including upgrades) before we set these dependencies > in stone. dpkg is already in rawhide #repoquery --releasever=rawhide --disablerepo=\*updates\* -q dpkg dpkg-0:1.16.10-2.fc20.x86_64
Good, haven't noticed it. So here is the final debhelper (I hope): Spec URL: http://oron.fedorapeople.org/deb-package/debhelper.spec SRPM URL: http://oron.fedorapeople.org/deb-package/debhelper-9.20120909-1.fc20.src.rpm Tested on rawhide, looks OK, waiting for final approval.
Spec URL: http://oron.fedorapeople.org/deb-package/debhelper.spec SRPM URL: http://oron.fedorapeople.org/deb-package/debhelper-9.20120909-1.fc20.src.rpm for: fedora-review -b 961141 INFO: Processing bugzilla bug: 961141 INFO: Getting .spec and .srpm Urls from : 961141 ERROR: 'Cannot find source rpm URL'
Package APPROVED , you may proceed with SCM request.
New Package SCM Request ======================= Package Name: debhelper Short Description: Helper programs for Debian rules Owners: oron Branches: f18 f19 InitialCC:
Git done (by process-git-requests).
Hi, Since we already got debconf, po-debconf and dpkg on testings, you may build debhelper for F19 , I tested with dh-make :) we just need do: cd dh-make fedpkg switch-branch f19 git merge master fedpkg push fedpkg build fedpkg update (please indicate this bug) Thanks,
In reply to comment #33 * Some things cannot be rushed just because we want * debhelper is pushed, but the build obviously failed: http://koji.fedoraproject.org/koji/taskinfo?taskID=5423518 * The reason is very clear -- dpkg >= 1.16.x isn't there yet: https://admin.fedoraproject.org/updates/FEDORA-2013-9094/dpkg-1.16.10-3.fc19 * There's nothing we can do until it's in stable repositories
(In reply to Oron Peled from comment #34) not anymore, dpkg is in updates stable of F19 , Please do a cd debhelper fedpkg switch-branch f19 fedpkg build (to build debhelper finally P)) fedpkg update (please indicate this bug) Thanks,
debhelper-9.20120909-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/debhelper-9.20120909-1.fc19
debhelper-9.20120909-1.fc19 has been pushed to the Fedora 19 testing repository.
debhelper-9.20120909-1.fc19 has been pushed to the Fedora 19 stable repository.
debhelper-9.20120909-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/debhelper-9.20120909-1.fc18
debhelper-9.20120909-1.fc18 has been pushed to the Fedora 18 stable repository.