unstripped-static-library
Hi mentors, I've already checked with my mentor, but he said he isn't a expert in libraries. And here I can improve my english. I maintain libgphoto2 and lintian now says that the package has "unstripped-static-library" (.a files). We (me and my mentor) believe that this message can be ignored. Can someone take a look and confirm this ? I alert: this is an experimental tag. Just in case you don't waste time with this kind of tag. The package is at mentors: https://mentors.debian.net/package/libgphoto2 http://mentors.debian.net/debian/pool/main/libg/libgphoto2/libgphoto2_2.5.8-2.dsc regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: unstripped-static-library
Hi Alex,
Thanks for answering. And the details!
continue
On Sat, 3 Oct 2015 08:45:48 +0800
Alex Vong wrote:
> Hi Herbert,
>
> I am not a mentor. I think the static library striping is done by
> dh_strip, the detection code looks like this:
> # Is it a static library, and not a debug library?
> if (m/lib.*\.a$/ && ! m/.*_g\.a$/) {
> # Is it a binary file, or something else (maybe a linker
> # script on Hurd, for example? I don't use file, because
> # file returns a variety of things on static libraries.
> if (-B $_) {
> push @static_libs, $fn;
> return;
> }
> }
>
> While the lintian warnings look like this:
> X: libgphoto2-dev: unstripped-static-library
> usr/lib/x86_64-linux-gnu/libgphoto2/2.5.8/adc65.a(adc65.o)
>
> It seems the static libraries built does not have the prefix ``lib'',
> so dh_strip does not detect it as a static library. I am not sure if
> this is intended.
Yes, I saw the manpage of dh_strip and what I
understood is you can exclude (-X) but you
can not determinate which file to strip.
>
> I think the solution for now will be to add the following to ``rule'':
> override_dh_strip:
> dh_strip
> find . -name '*.a' \( \! -name '*_g.a' \) \
> -exec strip --strip-debug \
> --remove-section=.comment \
> --remove-section=.note {} \;
And where I put the stripped part ? I mean, how
to direct the result to a -dbg package or something ?
Using a debian/*.install file ?
regards,
>
> This is according to the striping code in dh_strip:
> if (@static_libs) {
> my $strip_help = qx{$strip 2>&1};
> my @opts = ('--strip-debug', '--remove-section=.comment',
> '--remove-section=.note');
> if (index($strip_help, '--enable-deterministic-archives') > -1) {
> # NB: The short variant (-D) is broken in Jessie
> # (binutils/2.25-3)
> push(@opts, '--enable-deterministic-archives');
> }
> foreach (@static_libs) {
> doit($strip, @opts, $_);
> }
> }
>
> Feel free to discuss.
>
> Cheers,
> Alex
>
> On 03/10/2015, Herbert Parentes Fortes Neto wrote:
> > Hi mentors,
> >
> > I've already checked with my mentor, but he
> > said he isn't a expert in libraries. And
> > here I can improve my english.
> >
> > I maintain libgphoto2 and lintian now says
> > that the package has "unstripped-static-library"
> > (.a files). We (me and my mentor) believe that
> > this message can be ignored.
> >
> > Can someone take a look and confirm this ? I alert:
> > this is an experimental tag. Just in case you don't
> > waste time with this kind of tag.
> >
> > The package is at mentors:
> > https://mentors.debian.net/package/libgphoto2
> > http://mentors.debian.net/debian/pool/main/libg/libgphoto2/libgphoto2_2.5.8-2.dsc
> >
> >
> > regards,
> > --
> > Herbert Parentes Fortes Neto (hpfn)
> >
> >
--
Herbert Parentes Fortes Neto (hpfn)
Re: unstripped-static-library
> >
> > While the lintian warnings look like this:
> > X: libgphoto2-dev: unstripped-static-library
> > usr/lib/x86_64-linux-gnu/libgphoto2/2.5.8/adc65.a(adc65.o)
> >
> > It seems the static libraries built does not have the prefix ``lib'',
> > so dh_strip does not detect it as a static library. I am not sure if
> > this is intended.
> >
> > I think the solution for now will be to add the following to ``rule'':
> > override_dh_strip:
> > dh_strip
> > find . -name '*.a' \( \! -name '*_g.a' \) \
> > -exec strip --strip-debug \
> > --remove-section=.comment \
> > --remove-section=.note {} \;
The solution works. No lintian message about that now.
If you want to see the package:
https://mentors.debian.net/package/libgphoto2
http://mentors.debian.net/debian/pool/main/libg/libgphoto2/libgphoto2_2.5.8-2.dsc
regards,
--
Herbert Parentes Fortes Neto (hpfn)
Re: unstripped-static-library
Hi Alex, > > First, according to the policy manual, we should support "nostrip" in > "DEB_BUILD_OPTIONS", so we should probably wrap the rule with: > ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS))) > some override_dh_strip stuff... > endif Just put a blank 'override_dh_strip', doing nothing right ? > <https://reproducible.debian.net/rb-pkg/unstable/amd64/gthumb.html> > reports gthumb is unreproducible because "Files have varying > permissions because of different umasks" . It would be great to look > into it if you have extra times. > I looked this again. I did a 'grep -r umask' into gthumb-XX.orig and I only see the use of it (the changes) by the upstream for tmp stuff . In ltmain.sh and install-sh. "not to create temps with too-generous modes.". The upstream also says something about FreeBSD. I see 133, 22, 077 values. I don't know what to do about that. regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: unstripped-static-library
Hi Alex,
> >> First, according to the policy manual, we should support "nostrip" in
> >> "DEB_BUILD_OPTIONS", so we should probably wrap the rule with:
> >> ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))
> >> some override_dh_strip stuff...
> >> endif
> >
> > Just put a blank 'override_dh_strip', doing nothing right ?
> >
> I mean the following:
> ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))
> override_dh_strip:
> dh_strip
> find . -name '*.a' \( \! -name '*_g.a' \) \
> -exec strip --strip-debug \
> --remove-section=.comment \
> --remove-section=.note {} \;
> endif
>
> so that the debugging symbol are striped only if "nostrip" is not present.
> You can see
> <https://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-options>
> for more details.
Yes, doesn't need two override. Thanks to clarify this.
I will redo the package.
> >
> >> <https://reproducible.debian.net/rb-pkg/unstable/amd64/gthumb.html>
> >> reports gthumb is unreproducible because "Files have varying
> >> permissions because of different umasks" . It would be great to look
> >> into it if you have extra times.
> >>
> >
> > I looked this again. I did a 'grep -r umask' into gthumb-XX.orig
> > and I only see the use of it (the changes) by the upstream for
> > tmp stuff . In ltmain.sh and install-sh. "not to create temps
> > with too-generous modes.". The upstream also says something
> > about FreeBSD.
> >
> > I see 133, 22, 077 values.
> >
> > I don't know what to do about that.
> >
> Thanks for the extra info! I am new to the reproducible stuff as well.
> I will look into it later. The nondeterminism is introduced by a
> recent upload since this only affect unstable but not testing.
>
Ok.
Nice to talk to you.
regards,
--
Herbert Parentes Fortes Neto (hpfn)
ldconfig in a post(rm|inst) script
Hi, Lintian informs about the use of ldconfig in postrm script of libgphoto2. It says even where to put the cmd. Good! What I understood reading the manpage is to put the cmd without options is enough. Is like this: libgphoto2-6.postrm remove) rm -f /usr/share/hal/fdi/information/20thirdparty/$PACKAGE.fdi || true rm -f /usr/share/hal/fdi/information/10freedesktop/10-camera-$PACKAGE.fdi || true rm -f /usr/share/hal/fdi/information/10freedesktop/10-camera-$PACKAGE-device.fdi || true ldconfig ;; Lintian is quiet now. Debian-policy (8.1.1) says that postinst script also have to call ldconfig. But lintian is not complaining about postinst not having it. https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-ldconfig I put the cmd in libgphoto2-6.postinst: case "$1" in configure) # remove old fdi files rm -f /usr/share/hal/fdi/information/10freedesktop/10-camera-$PACKAGE.fdi rm -f /usr/share/hal/fdi/information/20thirdparty/$PACKAGE.fdi rm -f /usr/share/hal/fdi/information/10freedesktop/10-camera-$PACKAGE-device.fdi ldconfig ;; Doubts: - follow the policy and put ldconfig in postinst script even with lintian saying nothing about this ?. - run the cmd without options on both cases ? Since everything seems to be in standard place. - I received a email (debian-devel) about 'debhelper/9.20151004' "dh_makeshlibs is now using triggers rather than maintainer scripts to invoke ldconfig." "* Lintian in untable + testing is already aware of this * Lintian has /not yet/ been backported. Lintian from backports still (incorrectly) reports this an issue." I have debhelper 9.20151005 and lintian 2.5.37 At mentors site, QA information there is a message about 'postinst-must-call-ldconfig' for libgphoto2-port12. It doesn't have a postinst script. Mentors site: https://mentors.debian.net/package/libgphoto2 http://mentors.debian.net/debian/pool/main/libg/libgphoto2/libgphoto2_2.5.8-2.dsc regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: unstripped-static-library
Hi Alex,
> Hi Herbert,
>
> I have opened a bug report on the reproducibility matter, feel free to
> continue the discussion there
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801083>.
>
> Cheers,
> Alex
Ok.
regards
>
> On 06/10/2015, Herbert Parentes Fortes Neto wrote:
> > Hi Alex,
> >
> >
> >> >> First, according to the policy manual, we should support "nostrip" in
> >> >> "DEB_BUILD_OPTIONS", so we should probably wrap the rule with:
> >> >> ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))
> >> >> some override_dh_strip stuff...
> >> >> endif
> >> >
> >> > Just put a blank 'override_dh_strip', doing nothing right ?
> >> >
> >> I mean the following:
> >> ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))
> >> override_dh_strip:
> >> dh_strip
> >> find . -name '*.a' \( \! -name '*_g.a' \) \
> >> -exec strip --strip-debug \
> >> --remove-section=.comment \
> >> --remove-section=.note {} \;
> >> endif
> >>
> >> so that the debugging symbol are striped only if "nostrip" is not
> >> present.
> >> You can see
> >> <https://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-options>
> >> for more details.
> >
> > Yes, doesn't need two override. Thanks to clarify this.
> > I will redo the package.
> >
> >> >
> >> >> <https://reproducible.debian.net/rb-pkg/unstable/amd64/gthumb.html>
> >> >> reports gthumb is unreproducible because "Files have varying
> >> >> permissions because of different umasks" . It would be great to look
> >> >> into it if you have extra times.
> >> >>
> >> >
> >> > I looked this again. I did a 'grep -r umask' into gthumb-XX.orig
> >> > and I only see the use of it (the changes) by the upstream for
> >> > tmp stuff . In ltmain.sh and install-sh. "not to create temps
> >> > with too-generous modes.". The upstream also says something
> >> > about FreeBSD.
> >> >
> >> > I see 133, 22, 077 values.
> >> >
> >> > I don't know what to do about that.
> >> >
> >> Thanks for the extra info! I am new to the reproducible stuff as well.
> >> I will look into it later. The nondeterminism is introduced by a
> >> recent upload since this only affect unstable but not testing.
> >>
> > Ok.
> >
> > Nice to talk to you.
> >
> >
> > regards,
> > --
> > Herbert Parentes Fortes Neto (hpfn)
> >
--
Herbert Parentes Fortes Neto (hpfn)
Re: ldconfig in a post(rm|inst) script
Hi Mattia, On 10/05/2015 05:52 PM, Mattia Rizzolo wrote: > On Mon, Oct 05, 2015 at 03:56:57PM -0300, Herbert Parentes Fortes Neto wrote: >> Lintian informs about the use of ldconfig >> in postrm script of libgphoto2. It says even >> where to put the cmd. Good! > > before all, be aware that usually lib maintainers don't need to do this > explicetely, since debhelper takes care of adding it itself. The problem is lintian complaining about the cmd is missing. > >> What I understood reading the manpage is to >> put the cmd without options is enough. Is >> like this: >> >> libgphoto2-6.postrm >> remove) >> rm -f /usr/share/hal/fdi/information/20thirdparty/$PACKAGE.fdi || true >> rm -f >> /usr/share/hal/fdi/information/10freedesktop/10-camera-$PACKAGE.fdi || true >> rm -f >> /usr/share/hal/fdi/information/10freedesktop/10-camera-$PACKAGE-device.fdi >> || true >> ldconfig >> ;; >> >> Lintian is quiet now. > > Wait, what's this? > > debhelper takes care of all of this, the old version added a bunch of > code replacing the '#DEBHELPER#' string, the new one adds a dpkg trigger. So I can remove the file, right ? > >> Debian-policy (8.1.1) says that postinst script also >> have to call ldconfig. But lintian is not complaining >> about postinst not having it. > > because the built package does have it, it's a binary check, not a > source check (=you need to run lintian on the built package) Lintian runs at the end of the build. What I'm trying to say is: lintian complain about the cmd is missing on postrm and not not in postinst. > >> https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-ldconfig >> >> I put the cmd in libgphoto2-6.postinst: >> case "$1" in >> configure) >> # remove old fdi files >> rm -f >> /usr/share/hal/fdi/information/10freedesktop/10-camera-$PACKAGE.fdi >> rm -f /usr/share/hal/fdi/information/20thirdparty/$PACKAGE.fdi >> rm -f >> /usr/share/hal/fdi/information/10freedesktop/10-camera-$PACKAGE-device.fdi >> ldconfig If I can remove postrm script, I can remove this one too, right ? regards, Herbert >> ;; >> >> >> >> Doubts: >> - follow the policy and put ldconfig in postinst script >>even with lintian saying nothing about this ?. > > You must follow the debian policy, period. > But be aware of what you're doing, debhelper does this thing for you, > but you're expect to already know it. > > In this case this is a bit of exception of following so pedantically the > policy, since the recent dh change, dunno if the process to alter that > bit is already started > >> - run the cmd without options on both cases ? Since >>everything seems to be in standard place. > > that's the standard thing, yes. > >> - I received a email (debian-devel) about 'debhelper/9.20151004' >>"dh_makeshlibs is now using triggers rather than maintainer >> scripts to invoke ldconfig." >> "* Lintian in untable + testing is already aware of this >> * Lintian has /not yet/ been backported. Lintian from >>backports still (incorrectly) reports this an issue." >> >>I have debhelper 9.20151005 and lintian 2.5.37 > > everything as I said, then := > >> At mentors site, QA information there is a message about >> 'postinst-must-call-ldconfig' for libgphoto2-port12. It >> doesn't have a postinst script. > > because it misses a backport and mentors.d.n runs stable, as that very > mail said. > >> Mentors site: >> https://mentors.debian.net/package/libgphoto2 >> http://mentors.debian.net/debian/pool/main/libg/libgphoto2/libgphoto2_2.5.8-2.dsc >
Re: ldconfig in a post(rm|inst) script
Hi Jakub, > * Herbert Parentes Fortes Neto , 2015-10-06, 09:33: > >>>libgphoto2-6.postrm > >>>remove) > >>> rm -f /usr/share/hal/fdi/information/20thirdparty/$PACKAGE.fdi || true > >>> rm -f > >>> /usr/share/hal/fdi/information/10freedesktop/10-camera-$PACKAGE.fdi || > >>> true > >>> rm -f > >>> /usr/share/hal/fdi/information/10freedesktop/10-camera-$PACKAGE-device.fdi > >>> || true > >>> ldconfig > >>> ;; > >>> > >>>Lintian is quiet now. > >> > >>Wait, what's this? > >> > >>debhelper takes care of all of this, the old version added a bunch of > >>code replacing the '#DEBHELPER#' string, the new one adds a dpkg > >>trigger. > > > >So I can remove the file, right ? > > debhelper takes care of calling ldconfig, but of course it won't rm any > files for you. Thanks. > > BTW, you almost certainly don't want to ignore errors by using these "|| > true" things. What errors if using 'rm -f', right ? regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: ldconfig in a post(rm|inst) script
On Tue, 6 Oct 2015 22:42:25 +0800 Alex Vong wrote: > Hi Herbert, > > On 06/10/2015, Herbert Parentes Fortes Neto wrote: > > Hi Alex, > > > > > >> >> >>> rm -f > >> >> >>> /usr/share/hal/fdi/information/10freedesktop/10-camera-$PACKAGE-device.fdi > >> >> >>> || true > > > >> > What errors if using 'rm -f', right ? > >> > > >> What do you mean by that? Could you please explain further? > > > > Using 'rm -f' doesn't return a error. > > > > if I do (TESTE doesn't exist) : > > > > $rm -f TESTE; echo $? > > 0 > > > > > > $rm TESTE; echo $? > > 1 > > not found > > > Yes, that's why Jakub suggested you almost always shouldn't be using > ``|| true'' since using ``-f'' suffices. Also ``|| true'' may shadow a > real problem. Ok, it is not in postinst and I will remove from postrm. regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: ldconfig in a post(rm|inst) script
Hi Alex, > >> >>>rm -f > >> >>> /usr/share/hal/fdi/information/10freedesktop/10-camera-$PACKAGE-device.fdi > >> >>> || true > > What errors if using 'rm -f', right ? > > > What do you mean by that? Could you please explain further? Using 'rm -f' doesn't return a error. if I do (TESTE doesn't exist) : $rm -f TESTE; echo $? 0 $rm TESTE; echo $? 1 not found regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: ldconfig in a post(rm|inst) script
Hi Mattia, > On Tue, Oct 06, 2015 at 04:10:20PM +0200, Jakub Wilk wrote: > > * Herbert Parentes Fortes Neto , 2015-10-06, 09:33: > > >>>libgphoto2-6.postrm > > >>>remove) > > >>> rm -f /usr/share/hal/fdi/information/20thirdparty/$PACKAGE.fdi || true > > >>> rm -f > > >>> /usr/share/hal/fdi/information/10freedesktop/10-camera-$PACKAGE.fdi || > > >>> true > > >>> rm -f > > >>> /usr/share/hal/fdi/information/10freedesktop/10-camera-$PACKAGE-device.fdi > > >>> || true > > >>> ldconfig > > >>> ;; > > > > debhelper takes care of calling ldconfig, but of course it won't rm any > > files for you. > > > > BTW, you almost certainly don't want to ignore errors by using these "|| > > true" things. > > Also, to me it looks really weird removing /usr/share/hal/* files. > > According to my `apt-cache file` search (with a quite old cache, > admittely, I'm currently not in a good enough network to update it) no > packages shipt those file (well, maybe the first if $PACKAGE is right, > which I don't think is the case?) > > % apt-file search /usr/share/hal > barry-util: /usr/share/hal/fdi/information/10freedesktop/10-blackberry.fdi > barry-util: /usr/share/hal/fdi/policy/10osvendor/19-blackberry-acl.fdi > libmtp-common: /usr/share/hal/fdi/information/20thirdparty/20-libmtp9.fdi > libsane-common: /usr/share/hal/fdi/preprobe/10osvendor/20-libsane.fdi > ntfs-3g: /usr/share/hal/fdi/policy/10osvendor/25-ntfs-3g-policy.fdi > > What are those files you're removing there? > Good point. I also search[0] and found nothing that libgphoto2 should mess with. [0] - https://packages.debian.org/search?suite=sid&arch=any&mode=path&searchon=contents&keywords=.fdi Sorry if you receive much email directly. The email to mentors was returning and I resending it. I noted that to late. I upload the package to mentors. http://mentors.debian.net/package/libgphoto2 http://mentors.debian.net/debian/pool/main/libg/libgphoto2/libgphoto2_2.5.8-2.dsc The debian/changelog is like this: * debian/control: - set debhelper version >= 9.20151005. To be sure not use ldconfig on post(rm|inst) scripts. Thanks Mattia Rizzolo * debian/rules: - var SHLIBS updated to 2.5.7 - override for dh_strip to stop "unstripped-static-library" Thanks Alex Vong. * debian/libgphoto2-6.postrm: - remove the '|| true'. Thanks Jakub Wilk and Alex Vong * debian/upstream/signing-key.asc: - right key now. I put a version for debhelper because lintian still complain about ldconfig. regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: unstripped-static-library
Hi Michael, > 02.10.2015 22:18, Herbert Parentes Fortes Neto (hpfn) wrote: > > Hi mentors, > > > > I maintain libgphoto2 and lintian now says > > that the package has "unstripped-static-library" > > (.a files). We (me and my mentor) believe that > > this message can be ignored. > > BTW, why do you include static library to start with? > I don't know why the previous maintainer set '--enable-static'. I find nothing saying to do this. regards, -- Herbert Parentes Fortes Neto (hpfn)
Bug#788418: New upload in mentors
Hi Ghislain, > Alright, I have uploaded a new candidate package on mentors. > > However, the lintian on mentors shows an error that I cannot reproduce > locally on my gbp build. The error is the following: > > postinst-must-call-ldconfig > > and makes no-sense to me, as I am not doing anything much differently > from the previous upload. Besides, my local lintian does not show it. > > Thoughts? Your local lintian is 'sid' ? If so, it is a different version of mentors, I believe. I asked the same question days ago. And debhelper on sid should take care of it. regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: Problem uploading gccintro-es
Hi, > > I've upload my debian package gccintro-es with dput, my dput.cfg is: > > [mentors] > fqdn = mentors.debian.net > incoming = /upload > method = http > allow_unsigned_uploads = 0 > progress_indicator = 2 > # Allow uploads for UNRELEASED packages > allowed_distributions = .* > > The upload process was successful and now says: > > $ dput mentors gccintro-es_1.0-1_amd64.changes > Package has already been uploaded to mentors on mentors.debian.net > Nothing more to do for gccintro-es_1.0-1_amd64.changes > > How can I see my debian package? > > In http://mentors.debian.net/packages/index doesn't appear. What's > happenning? > > lintian doesn't report errors or warnings in my package. > Did you received the email from mentors confirming ? regards, -- Herbert Parentes Fortes Neto (hpfn)
restart a git repository
Hi, I made a repository for libcdk5 and named it libcdk5. I believe it is a wrong name. It should be cdk. I created a cdk repository at git.debian.org and did some tries to do a merge without success. It is a mess right now. To remove the cdk.git and restart from zero I only have to go to git.debian.org and 'rm -fr cdk.git/' ? Instead of do a merge I think just 'git remote set-url' will be enough. regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: restart a git repository
Hi Gianfranco, > Hi, > I think libcdk5 is the correct name, because the package is src:libcdk5. > > src:cdk is another package. > https://packages.qa.debian.org/c/cdk.html > https://packages.qa.debian.org/libc/libcdk5.html > > I would avoid this confusion. Yes, in this case will be confusing. But let me share a point of view. The upstream tarball is cdk too. The package was libcdk at the beginning and then libcdk5. The 5 is about the ABI I believe. When the ABI change, it will be changed too. Suggestions ? regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: restart a git repository
Hi, > >Yes, in this case will be confusing. But let me > >share a point of view. > > > >The upstream tarball is cdk too. The package > >was libcdk at the beginning and then libcdk5. The 5 > >is about the ABI I believe. When the ABI change, it > >will be changed too. > > > >Suggestions ? > My suggestion is to call it libcdk (the source name) > and build a libcdk5 library > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=352961 > > it was removed the libcdk but just because of a SONAME bump. > > In my opinion the src name shouldn't change, just the library > should. > > BTW even libcdk5 might be fine, as long as they don't change soname too > often. > > but unfortunately cdk is misleading to me. > > what do you think about this? > > (please note: I don't have a strong opinion about this, but since we can't > have > cdk as source name, we should change it anyway) I started think about this because of this bug[0]. To close it I would build the libcdk5(-dev) and libcdkw5(-dev) packages and more a package with common files. Even that way libcdk5 and libcdkw5 must conflict because /usr/include/cdk have common files (just one is different, cdk_config.h if I remember correct). [0] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=382294 As the upstream tarball is cdk I thought cdk-common. As is not possible, the package with common files would be libcdk-common ? regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: restart a git repository
Ok. > > Hi > I would talk with pkg-java folks on this matter > > https://packages.debian.org/sid/all/libcdk-java/filelist > their package has a libcdk-java library, so they might want to change their > source package to libcdk and let you use cdk again. > > Honestly libcdk-common sound weird when we have a libcdk-java there. > > So please try to solve with them first, because this kind of namespace > collisions are usually bad for the end users experience > > (If you read under the lines you can get my personal opinion, but it has been > some time since my last contribution on that team, so I won't share it as > java team member) > > cheers, > > G. > > -- > Il mar 3 nov 2015 18:32 CET, Herbert Parentes Fortes Neto ha scritto: > > >Hi, > > > >> >Yes, in this case will be confusing. But let me > >> >share a point of view. > >> > > >> >The upstream tarball is cdk too. The package > >> >was libcdk at the beginning and then libcdk5. The 5 > >> >is about the ABI I believe. When the ABI change, it > >> >will be changed too. > >> > > >> >Suggestions ? > >> My suggestion is to call it libcdk (the source name) > >> and build a libcdk5 library > >> > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=352961 > >> > >> it was removed the libcdk but just because of a SONAME bump. > >> > >> In my opinion the src name shouldn't change, just the library > >> should. > >> > >> BTW even libcdk5 might be fine, as long as they don't change soname too > >> often. > >> > >> but unfortunately cdk is misleading to me. > >> > >> what do you think about this? > >> > >> (please note: I don't have a strong opinion about this, but since we can't > >> have > >> cdk as source name, we should change it anyway) > > > >I started think about this because of this bug[0]. To > >close it I would build the libcdk5(-dev) and libcdkw5(-dev) > >packages and more a package with common files. Even that > >way libcdk5 and libcdkw5 must conflict because /usr/include/cdk > >have common files (just one is different, cdk_config.h if > >I remember correct). > > > >[0] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=382294 > > > >As the upstream tarball is cdk I thought cdk-common. As > >is not possible, the package with common files would be > >libcdk-common ? > > > > > >regards, > >-- > >Herbert Parentes Fortes Neto (hpfn) > > > -- Herbert Parentes Fortes Neto (hpfn)
webcamoid - NEW
Hi, I'm packaging a app like that from the scratch for the first time. The information about hardening for qmake in the wiki[0] should be updated, IMHO. QMAKE_CPPFLAGS doesn't work. And everything can be done in debian/rules. The example I found in debian/rules[1] of zeal debian package. [0] - https://wiki.debian.org/Hardening [1] - http://anonscm.debian.org/cgit/collab-maint/zeal.git/tree/debian/rules The package is almost done. I don't know how to deal with: '── usr ├── lib │ └── x86_64-linux-gnu └── qt5 └── qml │ └── QbQml │ ├── libQbQml.so │ └── qmldir And webcamoid-xx/share: effects.xml icons mainpipeline.json qml ts I don't know where to put them (package and location). It seems that the libraries are lowercase. I did a lot of patches to put the library (libqb6) in lower case. But the plugins an LibQbQML still in upper case. I don't know if is necessary. And I didn't found out how to do that. Can someone take a look on my work ? As I know that the job is not done yet, I don't want to send a RFS. http://mentors.debian.net/package/webcamoid http://mentors.debian.net/debian/pool/main/w/webcamoid/webcamoid_6.2.0-1.dsc regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: webcamoid - NEW
Hi Gianfranco, > I maintain a qt5 package, and my packaging seems more "clean" > > https://sources.debian.net/src/qviaggiatreno/2013.7.3-8/debian/ > > (of course I don't provide a library, so the split should be done by you) > > and I'm not even sure this easy packaging will fit your needs > (I see some differences in pro files) > > let me know if it helps or not :) > It is really more simple. But debian/rules do not hardening. I liked to see that the .desktop file can be on webcamoid.install. debian/copyright needs some changes. I will remake the package and them I come back. regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: webcamoid - NEW
Hi, I create another package for QbQml ? ── usr ├── lib │ └── x86_64-linux-gnu └── qt5 └── qml │ └── QbQml │ ├── libQbQml.so │ └── qmldir Probably everything goes to /usr/share but I don't know exactly where. webcamoid-xx/share: effects.xml icons/ mainpipeline.json qml/ ts/ And I found another one: Qb/Plugins/FaceDetect/ has a png file The package at mentors: http://mentors.debian.net/package/webcamoid http://mentors.debian.net/debian/pool/main/w/webcamoid/webcamoid_6.2.0-1.dsc regards, Herbert
Re: webcamoid - NEW
Hi, I just uploaded the packages to mentors: Uploading to mentors (via ftp to mentors.debian.net): Uploading webcamoid_6.2.0-1.dsc: done. Uploading webcamoid_6.2.0.orig.tar.gz: done. Uploading webcamoid_6.2.0-1.debian.tar.xz: done. Uploading libqb6-dev_6.2.0-1_amd64.deb: done. Uploading libqb6_6.2.0-1_amd64.deb: done. Uploading qb-plugins_6.2.0-1_amd64.deb: done. Uploading qbqml_6.2.0-1_amd64.deb: done. Uploading webcamoid-data_6.2.0-1_all.deb: done. Uploading webcamoid_6.2.0-1_amd64.deb: done. Uploading webcamoid_6.2.0-1_amd64.changes: done. webcamoid-xx/share: effects.xml icons/ mainpipeline.json qml/ ts/ I believe that icons/ and ts/ are in good places. I set the localedir (ts/) in debian/rules and DATADIR is /usr/share. icons/ is under /usr/share/webcamoid. The others are not in the package. Should be ? Can someone take a look ? http://mentors.debian.net/package/webcamoid http://mentors.debian.net/debian/pool/main/w/webcamoid/webcamoid_6.2.0-1.dsc regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: webcamoid - NEW
Hi, I had forgotten to run cowbuilder. I ran it today. It fails to build. If someone is reviewing the package, let me fix the error first. regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: webcamoid - NEW
Hi, > wonderful, it was on my radar, I'll wait for a new ping then :) > One package was missing. cowbuilder is running soft now. http://mentors.debian.net/package/webcamoid http://mentors.debian.net/debian/pool/main/w/webcamoid/webcamoid_6.2.0-1.dsc regards, -- Herbert Parentes Fortes Neto (hpfn)
.symbols or shlibs file
Hi, I maintain a package which provides a .symbols file. But it uses a dh_makeshlibs in debian/rules[0]. override_dh_makeshlibs: dh_makeshlibs -plibgphoto2-$(major) \ -V 'libgphoto2-$(major) (>= $(SHLIBS))' \ -X/usr/lib/$(DEB_HOST_MULTIARCH)/libgphoto2/ dh_makeshlibs -plibgphoto2-port12 \ -V 'libgphoto2-port12(>= $(SHLIBS))' \ -X/usr/lib/$(DEB_HOST_MULTIARCH)/libgphoto2_port/ [0] - http://anonscm.debian.org/cgit/pkg-phototools/libgphoto2.git/tree/debian/rules Am I confusing or the package uses the two systems ? What I understand about what the policy says is you choose one of them (for c++ maybe shlibs is better). regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: webcamoid - NEW
Hi, I did two more fixes: - debian/control - debian/webcamoid-data It is a c++ software. The .symbols file is not that big, so I'm using it instead of shlibs. http://mentors.debian.net/package/webcamoid http://mentors.debian.net/debian/pool/main/w/webcamoid/webcamoid_6.2.0-1.dsc regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: .symbols or shlibs file
Hi Jakub, > * Herbert Parentes Fortes Neto , 2015-11-26, 12:15: > >I maintain a package which provides a .symbols file. But it uses a > >dh_makeshlibs in debian/rules[0]. > > > >override_dh_makeshlibs: > > dh_makeshlibs -plibgphoto2-$(major) \ > > -V 'libgphoto2-$(major) (>= $(SHLIBS))' \ > > -X/usr/lib/$(DEB_HOST_MULTIARCH)/libgphoto2/ > > dh_makeshlibs -plibgphoto2-port12 \ > > -V 'libgphoto2-port12(>= $(SHLIBS))' \ > > -X/usr/lib/$(DEB_HOST_MULTIARCH)/libgphoto2_port/ > > > >[0] - > >http://anonscm.debian.org/cgit/pkg-phototools/libgphoto2.git/tree/debian/rules > > > >Am I confusing or the package uses the two systems ? > > It does. Vast majority of packages that have DEBIAN/symbols also have > DEBIAN/shlibs, because dh_makeshlibs generates both of them. If you have > DEBIAN/symbols, DEBIAN/shlibs is probably not very useful, but it > doesn't hurt either. > > That said, I wonder if there's any point in passing -V to dh_makeshlibs > if the package uses symbols. It doesn't seem useful. > I will remove these 'dh_makeshlibs' entries from the debian/rules file. Thanks for replying. regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: .symbols or shlibs file
Hi, I didn't understand how this work. The package has 2 .symbols files. One was updated when the ABI was changed (2.5.7). I forgot about the other. So I made new .symbols files for the last version (2.5.9). ABI-compatible. I removed the 'override_dh_makeshlibs' and now 'dpkg-gensymbols' is warning that: dpkg-gensymbols: warning: new libraries appeared in the symbols file: dpkg-gensymbols: warning: debian/libgphoto2-6/DEBIAN/symbols doesn't match completely debian/libgphoto2-6.symbols dpkg-gensymbols: warning: debian/libgphoto2-port12/DEBIAN/symbols doesn't match completely debian/libgphoto2-port12.symbols How 'new libraries', 'doesn't match completely' ? I made new files for this version. 2 commands as it is on the wiki. At the end, lintian: E: libgphoto2-6: symbols-file-contains-current-version-with-debian-revision on symbol camera_abilities@Base and 191 others E: libgphoto2-port12: symbols-file-contains-current-version-with-debian-revision on symbol gp_port_library_list@Base and 17 others regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: .symbols or shlibs file
> * Herbert Parentes Fortes Neto , 2015-11-29, 16:12: > >I removed the 'override_dh_makeshlibs' and now 'dpkg-gensymbols' is > >warning that: > > I certainly didn't advocate removing this override. A little rush of mine. > > The override passed -X options to dh_makeshlibs. They are needed to > prevent debhelper from treating private libraries like if they were > shared libraries (see bug #205142). Ok. > > >dpkg-gensymbols: warning: new libraries appeared in the symbols file: > > > >dpkg-gensymbols: warning: debian/libgphoto2-6/DEBIAN/symbols > > doesn't match completely debian/libgphoto2-6.symbols > > > >dpkg-gensymbols: warning: debian/libgphoto2-port12/DEBIAN/symbols > > doesn't match completely debian/libgphoto2-port12.symbols > > > >How 'new libraries', 'doesn't match completely'? > > Now that the -X options are gone, dh_makeshlibs tries to generate > symbols for the private libraries, but they are not in debian/*.symbols, > hence the warnings. Thanks to clarify that. > > >I made new files for this version. 2 commands as it is on the wiki. > > Which wiki page do you have in mind? https://wiki.debian.org/UsingSymbolsFiles The 2.5.9-2 seems to be ok (on sid). This chat would result in 2.5.9-3. [from previous email] > That said, I wonder if there's any point in passing -V to dh_makeshlibs > if the package uses symbols. It doesn't seem useful. The option started to be used in version 2.4.1-1 (2008), I believe. From debian/changelog: * New upstream release (Closes: #480127): - Not bumping shlibs, no new symbol. - To achieve this, use two dh_makeshlibs calls (one for libgphoto2-port0 and one for libgphoto2-$(major), and provide with the last upstream version sharing the same ABI. Using 2.4.0 here although some former versions might have been specified. That shouldn't make any difference from a testing migration point of view. Do you know when the .symbols file started to be in use ? I did a build without the '-V' option. I don't see errors messages. My objective is to do a clean on the package control files (e.g. it had maintainer scripts doing nothing for some years). regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: .symbols or shlibs file
Hi Jakub, > * Herbert Parentes Fortes Neto , 2015-11-30, 16:50: > >>That said, I wonder if there's any point in passing -V to > >>dh_makeshlibs if the package uses symbols. It doesn't seem useful. > > > >The option started to be used in version 2.4.1-1 (2008), > >I believe. From debian/changelog: > > > >* New upstream release (Closes: #480127): > > - Not bumping shlibs, no new symbol. > > - To achieve this, use two dh_makeshlibs calls (one for > > libgphoto2-port0 and one for libgphoto2-$(major), and provide with > > the last upstream version sharing the same ABI. Using 2.4.0 here > > although some former versions might have been specified. That > > shouldn't make any difference from a testing migration point of > > view. > > > >Do you know when the .symbols file started to be in use ? > > Symbol files wasn't very popular in 2008 yet. According to the > changelog, they were added much later: > > | libgphoto2 (2.4.10.1-1) experimental; urgency=low > | [...] > | [ David Paleino ] > | [...] > | * Added symbols files > | [...] > | > | -- David Paleino Thu, 11 Nov 2010 19:19:03 +0100 :) > > I suppose -V should have been removed then. > Ok, I will do that. Thanks to look at that. regards, -- Herbert Parentes Fortes Neto (hpfn)
mentors site - not trusted
Hi, I'm trying to login at mentors and Iceweasel says something like: Not trusted. Some change happened ? regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: mentors site - not trusted
Em 23-12-2015 18:23, Ben Finney escreveu: Herbert Fortes (hpfn) writes: I'm trying to login at mentors and Iceweasel says something like: Rather than “something like” the message, can you cut and paste the *exact* message? Also, please show which exact URL you are using that gives the error message. The link on the right side - login: http://mentors.debian.net/login I don't have the message in english, but is saying that the certificate is invalid. I have the error code: sec_error_unknown_issuer. I tried with Opera and it complains too. regards, Herbert
Re: mentors site - not trusted
Hi, > > The link on the right side - login: > > http://mentors.debian.net/login > > > > I don't have the message in english, but is > > saying that the certificate is invalid. > > > > I have the error code: sec_error_unknown_issuer. > > > > I tried with Opera and it complains too. > > > Hi.. I'm a lurker here hoping to learn how to help you all by osmosis > of your interactions on this list. I just played along and went to the > above site. Received this on Iceweasel: > > +++ > mentors.debian.net uses an invalid security certificate. The > certificate is not trusted because the issuer certificate is unknown. > (Error code: sec_error_unknown_issuer) > +++ > > I don't know if it has any bearing or not but, during a recent near > daily upgrade, I just accidentally happened to actually "see and > (almost) grasp the significance" that ca-certificates was upgraded in > the last few days. A quick grep through /var/log/apt shows that was > just the 20th (~3 days ago per my term.log). Would that maybe play any > part in this? > > PS I happen to be on Sid Unstable... > Thanks for the aditional info. regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: how to delete those packaging warnings
Hi, > Hi all, >I try to package a software bcloud, but I got many warnings that I want to > delete. But I search little response from google. So I ask in this mailing > list. >The warning is shown in the following url: > https://github.com/mudongliang/DebPackaging/blob/master/README.md > > Use lintian-info --tags message to get infos about the warnnings. Ex: lintian-info --tags invalid-short-name-in-dep5-copyright Let's see if I can help a little more. If you put your name on debian/control these are fixed. You will sign the package, so a gpg key is needed. https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Maintainer W: bcloud source: changelog-should-mention-nmu W: bcloud source: source-nmu-has-incorrect-version-number 3.8.2-1 It is necessary to put the text of the license in the debian/copyright. W: bcloud source: missing-license-paragraph-in-dep5-copyright gplv3 (paragraph at line 5) Use GPL-3. Check if is GPL-3+ (any later version at the end of first paragraph) W: bcloud source: invalid-short-name-in-dep5-copyright gplv3 (paragraph at line 5) It seems is a new package. You should open a ITP bug 'intent to package'. And put the number you receive by email in debian/changelog. W: bcloud: new-package-should-close-itp-bug W: bcloud: duplicate-changelog-files usr/share/doc/bcloud/HISTORY.gz usr/share/doc/bcloud/changelog.gz debian/copyright take care of this. The file is not needed. W: bcloud: extra-license-file usr/share/doc/bcloud/LICENSE.gz Write a manpage for bcloud-gui. txt2man can help. W: bcloud: binary-without-manpage usr/bin/bcloud-gui Have fun. regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: webcamoid - NEW
Hi, Gianfranco > Hi, the package was already in new queue, and got accepted yesterday. > > Please move your fixes in a -2 revision and ping me when done. > > > and please start from the -1 version in experimental > Eriberto got time and is helping. Thanks to paying attention with the package. regards, -- Herbert Parentes Fortes Neto (hpfn)
sagan fails on *-i386
Hi, > I did a NMU for sagan package. > > It fails on *-i386[0]. > > - i386 and kfreebsd: > > parsers/sagan-strstr/strstr_sse2.S:399: Error: bad register name `%rax' > parsers/sagan-strstr/strstr_sse2.S:404: Error: bad register name `%r8)' > parsers/sagan-strstr/strstr_sse2.S:405: Error: bad register name `%rax' > Makefile:522: recipe for target 'sagan-strstr_sse2.o' failed > make[3]: *** [sagan-strstr_sse2.o] Error 1 > make[3]: Leaving directory '/«PKGBUILDDIR»/src' > Makefile:390: recipe for target 'all-recursive' failed > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory '/«PKGBUILDDIR»' > Makefile:331: recipe for target 'all' failed > make[1]: *** [all] Error 2 > make[1]: Leaving directory '/«PKGBUILDDIR»' > dh_auto_build: make -j1 returned exit code 2 > debian/rules:37: recipe for target 'build-arch' fai > > - hurd-i386: > sagan build-depends on missing: > - hurd-i386:libprelude-dev > [0] - https://buildd.debian.org/status/package.php?p=sagan > I just tried on my pc (chroot) and it fails. > The last gcc line is: > gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I/usr/include/json-c -Wdate-time > -D_FORTIFY_SOURCE=2 -g -O2 -fstack- > protector-strong -Wformat -Werror=format-security -c -o sagan-strstr_sse2.o > `test -f 'parsers/sagan-strstr/ > strstr_sse2.S' || echo './'`parsers/sagan-strstr/strstr_sse2.S I checked the file: # less src/parsers/sagan-strstr/strstr_sse2.S This "hooks" in the "Sagan_strstr" function for CPUs supporting SSE2 # ./configure --help | grep -i sse --build=BUILD configure for building on BUILD [guessed] CCASassembler compiler command (defaults to CC) CCASFLAGS assembler compiler flags (defaults to CFLAGS) I don't know how to fix this. regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: sagan fails on *-i386
Thanks Gianfranco > Hi Herbert > > > >I don't know how to fix this. > > > me neither, but looking at the source github code seems this one the > responsible commit > https://github.com/beave/sagan/commit/c85c738b29cc30e7faaf5bf503e7850a5a63b1b4 > > and I fail to see an upstream issue. > This seems affecting many i386 architectures (including kfreebsd-i386) > > BTW 1.0.0~RC4 was completely fine > https://launchpad.net/ubuntu/+source/sagan/1.0.0~RC4-0ubuntu1 > > I hope this helps > (at least to identify if build flags have changed or the code just need to be > fixed) > > cheers, > > Gianfranco > -- Herbert Parentes Fortes Neto (hpfn)
debian/control: Multi-Arch: no
Hi, libcdk5-dev was rejected by ftp-masters because it has 'Multi-Arch: no' on debian/control. "Multi-Arch: no support in Debian is broken (#768353)" https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768353 I followed lintian's info: https://lintian.debian.org/tags/old-style-config-script.html The script (cdk5-config) seems to be used by one package[0]. I've already sent a bugreport to the maintainer. [0] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813914 What should I do next ? regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: debian/control: Multi-Arch: no
Hi, Thanks for replying. regards, -- Herbert Parentes Fortes Neto (hpfn)
Re: debian/control: Multi-Arch: no
> * Herbert Fortes , 2016-02-11, 11:20: > >The script (cdk5-config) seems to be used by one package[0]. > >I've already sent a bugreport to the maintainer. > > > >[0] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813914 > > I don't believe libcdk-perl uses cdk5-config at the moment. In the build > log[1] I see: > > checking if you want to use cdk5-config for C flags... no > checking if you want to use cdkw5-config for C flags... no Thanks for make it clear. > > But, more importantly, libcdk5-dev doesn't provide pkg-config metadata, > so this bug wouldn't be actionable anyway... It was a silly action. > > There's also gphoto2, which seems to have a code to call cdk5-config in > the configure script, but it looks broken[2]: > > checking cdk/cdk.h usability... no > checking cdk/cdk.h presence... no > checking for cdk/cdk.h... no > ... > Interactive config support:no (http://dickey.his.com/cdk/cdk.html) > > (This is despite gphoto2 build-depending on libcdk5-dev.) The path for cdk.h was changed. I'm putting it on "right" place again. Thanks for pointing the error > > >What should I do next ? > > Close #813914 and be happy. Just done. > > Then, at your leisure, you might want to talk to CDK upstream about > providing pkg-config metadata. > > > [1] > https://buildd.debian.org/status/fetch.php?pkg=libcdk-perl&arch=i386&ver=20150928-1%2Bb1&stamp=1450371324 > [2] > https://buildd.debian.org/status/fetch.php?pkg=gphoto2&arch=i386&ver=2.5.9-2&stamp=1449769286 > I will do that. regards, -- Herbert Parentes Fortes Neto (hpfn)
