<bencoh>
hmm ... do you guys use ${shlibs:Depends} when packaging? the recursive deps thing seems pretty silly to me :(
<parazyd>
Yeah you should always use that
<parazyd>
Also ${misc:Depends}
<bencoh>
seriously? :(
<parazyd>
What's the problem?
<bencoh>
I am not sure whether it really links against all those libs at compile time, or if it just resolves recursively
<bencoh>
if the former, then everything is fine
<parazyd>
It generates package dependencies
<parazyd>
Meaning, the deps will be equivalent to what your binary is linked to
<bencoh>
if the latter, then it means that changing a direct dependency would force us to rebuild the end-of-the-chain (consumer) package just to update its dependencies
<Wizzup>
I think debian should do the right thing here
<bencoh>
Wizzup: which is?
<Wizzup>
I don't think it recurses everything
<Wizzup>
you can also see what it resolves too by opening the .deb file I think
<bencoh>
alright
<parazyd>
Yeah they'll be listed in the .deb, in the control file
<bencoh>
according to readelf, the .so really includes all those deps
sunshavi has joined #maemo-leste
<bencoh>
so ... alright then
<uvos>
oh btw can you suppess the unresolved symbol warings that this creates?
<bencoh>
apparently I'm not the only one thinking that something is silly with that link
<uvos>
Wizzup: freemangordon: would have some time to talk about the mce pr rn
<uvos>
if you like
<parazyd>
bencoh: -Wl,--as-needed in ldflags
<bencoh>
parazyd: I have the feeling --as-needed is one of the last things I'd like to enforce by myself when building packages
<bencoh>
considering how it changes linker behavior
<bencoh>
(and dependency order requirements)
<Wizzup>
uvos: I don't have time right now, meetings, can we pick another day this week maybe, or later tonight for me
<uvos>
Wizzup: ok
<uvos>
so it gernerates a huge amount of dpkg-shlibdeps: warning: debian/mce/usr/lib/mce/modules/libinactivity-inhibit.so contains an unresolvable reference to symbol dbus_send_message: it's probably a plugin
<uvos>
would be nice if you could specify that "yes this i a plugin" for eatch module somehow
<Wizzup>
If the binary is really a plugin, then disregard this warning. But there's always the possibility that it's a real library and that programs linking to it are using an RPATH so that the dynamic loader finds it. In that case, the library is broken and needs to be fixed.
<Wizzup>
you could set --warnings to anything but binary
<Wizzup>
although, maybe that's not the name for the warning,weird
<Wizzup>
hm. looks like it cannot silence those
<parazyd>
I wouldn't worry about it
<uvos>
its not a problem
<uvos>
ist just ulgy that the build throws literaly 100s of warnings
<bencoh>
oh and ... looks like dpkg-buildpackage includes .git in the source package ...
<Wizzup>
uvos: yeah, lame though
<bencoh>
I'd have thought it wouldn't, in 2021 :/
<Wizzup>
bencoh: that's weird, it doesn't for me
<Wizzup>
I think?
<bencoh>
do you use dpkg-buildpackage or git-buildpackage?
<bencoh>
oh and, maybe I missed something that should go in debian/whatever
cockroach has joined #maemo-leste
<Wizzup>
I use dpkg-buildpackage
<bencoh>
uh ...
<Wizzup>
uvos: parazyd: I suppose I could make a package that uses the pulse source, and just installs the headers and the pc file (from sfos), if we don't want to re-build/pkg pulse
<Wizzup>
annoying how we have to keep track of more and more :-D
<bencoh>
:]
<parazyd>
If you wanna go a bit weird
<parazyd>
You can apt-get source from the build
<parazyd>
So you pull in the actual corresponding source code from Devuan
<parazyd>
just lmk if you decide to do this, as I need to whitelist it for network in Jenkins
<Wizzup>
probably better not
<bencoh>
Wizzup: do you use -i and/or -I ?
<Wizzup>
bencoh: dpkg-buildpackage -b -uc
<Wizzup>
that's what I use
<bencoh>
hmm
<Wizzup>
so I guess I don't usually generate src pkgs
<bencoh>
ah, right
<Wizzup>
but our CI should not create a source pkg with git in it
<bencoh>
alright
<bencoh>
then everything's fine
<bencoh>
(maybe)
<bencoh>
anyway, time to push that to some server and call it a day (somehow)
<bencoh>
or not ... I just realized we have a workflow guidelines ... time to read that
<Wizzup>
it should be real simple :)
<Wizzup>
(and if not, let us know)
mardy has quit [Ping timeout: 246 seconds]
mardy has joined #maemo-leste
stand has joined #maemo-leste
akossh has quit [Quit: Leaving.]
freemangordon has quit [Ping timeout: 272 seconds]