[03:02] <Alison_Chaiken> Greetings, Ubuntu GeniusBar staff.
[03:02] <Alison_Chaiken> I have one Lintian error I just can't figure out.
[03:03] <Alison_Chaiken> lintian complains that my package name should match my shared-object library name.
[03:04] <Alison_Chaiken> But it already does!   When I check what SO library is in the package, I get "libfoo0" and the package is called libfoo0_version.deb.
[03:04] <Alison_Chaiken> Assuredly the main package should not be called foo0_version.deb?
[03:05] <Alison_Chaiken> Maybe the package that contains libfoo0 is not the one it's complaining about, but other packages don't contain libfoo0.
[03:07] <RAOF> Alison_Chaiken: It's easier to discuss things with context; can we have the lintian output & the contents of your package in a pastebin?
[03:07] <Alison_Chaiken> Sure RAOF, pastebin coming up.
[03:11] <Alison_Chaiken> RAOF, here it is: http://pastebin.com/1CmUTUw4
[03:12] <RAOF> That's not a package-name-should-match-SONAME warning?
[03:12] <RAOF> That's saying that you should probably use a .symbols file; which is true, they're quite useful.
[03:13] <Alison_Chaiken> RAOF, without "-i -I" flags for lintian, I get the other warning.
[03:13] <RAOF> (As long as it's C)
[03:13] <Alison_Chaiken> So it's the same error.
[03:13] <RAOF> It's not the same error; can you pastebin the output without “-i -I”?
[03:13] <Alison_Chaiken> Hmm, I guess the SO library is there, but the symbols control file is missing.
[03:14] <Alison_Chaiken> Sure, will take a moment, as I'm building in a Qemu and have to transfer to paste.
[03:15] <Alison_Chaiken> Hmm, you're right: that package doesn't give the error!
[03:15] <Alison_Chaiken> Must be a different package . . .
[03:16] <Alison_Chaiken> Ah, it's the main executable package!
[03:16] <Alison_Chaiken> Paste in one minute.
[03:18] <Alison_Chaiken> RAOF, http://pastebin.com/F08uj7Uu
[03:19] <RAOF> Alison_Chaiken: And does the nobdy package contain libnobdy.so.0?
[03:19] <Alison_Chaiken> I think I get it RAOF: I included libfoo in the main package, and shouldn't have!
[03:20] <Alison_Chaiken> So that library is in two packages, one of which does in fact have (I think) the correct name.
[03:20] <RAOF> Yes; libnobdy0 is the right name for that package.
[03:21] <Alison_Chaiken> So main executable package is called nobdy though, right?
[03:21] <RAOF> It can be called whatever you want, but if the project is called “nobdy” then nobdy seems like a good name ☺
[03:21] <Alison_Chaiken> And then package with libnobdy.so.0.1.11 in it should be called libnobdy0, and libnobdy.so.0.1.11 shouldn't be in nobdy package.
[03:22] <Alison_Chaiken> Amazing how I was stuck on this an hour, and as soon as I annoyed someone else by asking, I saw that the library was in two packages, sigh.
[03:22] <RAOF> That's the way it goes ;)
[03:22] <Alison_Chaiken> I need a stuffed penguin to ask questions.
[03:23] <Alison_Chaiken> A stuffed penguin is charming, but an inflatable penguin is disturbing.   Or is the other way around?
[03:26] <Alison_Chaiken> Another less pressing question is, debuild is giving me a "secret key not available" even though I saw which key to use in ~/.devscripts, which used to solve the problem.
[03:26] <Alison_Chaiken> I have a workaround, but even "source ~/.devscripts" before debuild doesn't work.
[03:27] <Alison_Chaiken> I can't figure out which wrong key debsign as used by debuild uses.
[03:27] <Alison_Chaiken> Or why, apparently, debuild no longer uses the environment in .devscripts.
[03:27] <Alison_Chaiken> I'm using 12.04 in a Qemu.
[03:32] <RAOF> Alison_Chaiken: If you pass -k$YOURKEY to debuild manually, does it work?
[03:33] <Alison_Chaiken> RAOF, I tried that, but it still doesn't work.
[03:34] <Alison_Chaiken> After debuild exits with debsign error, DEBSIGN_KEYID=1234 debsign works!
[03:34] <RAOF> So the problem is not that debuild isn't getting the environment correct, it's that debuild isn't finding the key you've specified. Does your qemu environment *have* that key?
[03:34] <Alison_Chaiken> Yes, gpg --list-keys shows it.
[03:35] <Alison_Chaiken> Cool, I took that SO library out of the main package and now, except for lack of man page, my packages are lintian-clean: yahoo!
[03:35] <Alison_Chaiken> (This has taken me months.)
[03:37] <Alison_Chaiken> debsign is using a directory in /tmp for its work.
[03:37] <RAOF> Does gpg --list-secret-keys show it? You need the private key to sign anything.
[03:37] <Alison_Chaiken> I bet it looks there for the keys when invoked from debuild but since it starts from CWD when I invoke it alone manually, it works.
[03:38] <Alison_Chaiken> Yes, gpg --list-secret-keys and gpg --list-keys both show the key.
[03:38] <Alison_Chaiken> Otherwise, post-debuild manual explicit debsign invocation wouldn't work.
[03:39] <RAOF> You're not doing something odd like running debuild as root?
[03:39] <Alison_Chaiken> It's not that the key isn't there, it's that debsign finds it and debuild doesn't.
[03:39] <Alison_Chaiken> Nope, running debuild as me with default fakeroot stuff.
[03:39] <ScottK> RAOF's question is a key one.
[03:39] <Alison_Chaiken> ScottK, I'm sure I'm doing something odd!
[03:40] <Alison_Chaiken> But as a newb, I haven't screwed much with debuild or debian/control.
[03:40] <ScottK> In any case, if debsign works, you've got a signed package, so it's a win.
[03:40] <Alison_Chaiken> And I'm running as me, not root.   I understand that $HOME is different for root, which means ~/.gpg and ~/.devscripts wouldn't be found.
[03:42] <Alison_Chaiken> And in fact, error message says "Alison Chaiken <alchaiken@gmail.com>": secret key not available
[03:43] <ScottK> What are you putting after -k when you run debuild?
[03:45] <Alison_Chaiken> In .devscripts I have DEBUILD_DPKG_BUILDPACKAGE_OPTS="-k'Alison Chaiken <alchaiken@gmail.com>'"
[03:45] <RAOF> Oh! I didn't know that worked; I've always used my keyid.
[03:46] <Alison_Chaiken> RAOF, it *used to* work!
[03:46] <ScottK> I didn't know that for a long time either.
[03:46] <Alison_Chaiken> Actually, it still sort of works, as the error message has the right ID for me, but it doesn't find the corresponding key.
[03:46] <ScottK> It was a happy day when I discovered it.
[03:46] <Alison_Chaiken> I actually did RTFM, but I missed some of the Clues.
[03:47] <ScottK> Alison_Chaiken: Try -k alchaiken@gmail.com
[03:47] <Alison_Chaiken> fg
[03:47] <ScottK> Also I'd try it directly in the debuild invocation: debuild -k alchaiken@gmail.com
[03:48] <Alison_Chaiken> Will do.
[03:49] <ScottK> When I've had to use -k, I always only used the email address, not including the pretty name.
[03:54] <Alison_Chaiken> ScottK!   That was it dude!
[03:54] <ScottK> Excellent.
[03:55] <ScottK> So, I sort of came in on the middle of this story.  Is this a package you're trying to get into Debian/Ubuntu?
[03:55] <Alison_Chaiken> So "-k'$DEBFULLNAME $DEBEMAIL'" used to work, but now it wants "-k'$DEBEMAIL'" instead.
[03:56] <Alison_Chaiken> Yessir, ScottK.    I work on a project which already has one component in, and the others are now Lintian-clean, except that someone has to write a man page.
[03:56] <Alison_Chaiken> Unfortunately me.
[03:57] <Alison_Chaiken> I will pastebin my .devscripts so that the helpful RAOF can see.
[03:57] <ScottK> I suspect that "Alison Chaiken <alchaiken@gmail.com>" is not '$DEBFULLNAME $DEBEMAIL'.  That's probably  "Alison Chaiken alchaiken@gmail.com"
[03:57] <Alison_Chaiken> Good point, ScottK.   I wasn't actually using the macros.
[03:58] <ScottK> In any case, that's just used to pick the right key, so there's no need to use more than the email address.
[03:59] <Alison_Chaiken> http://pastebin.com/PnKngjiD RAOF now works.
[03:59] <Alison_Chaiken> 9 PM, time for dinner!
[04:00] <Alison_Chaiken> Thanks, motu, for your never-failing help.   This channel and #openembedded have never ever failed me.
[04:00] <ScottK> Alison_Chaiken: BTW, your email address doens't need to be quoted.  It doesn't hurt, but it's not needed either.
[04:00] <Alison_Chaiken> I really appreciate it.
[04:00] <ScottK> You're welcome.
[04:00] <Alison_Chaiken> ScottK, there was a wise man named Murphy . . .
[04:01] <Alison_Chaiken> But I *do* believe you.
[04:02] <ScottK> Glad to help.  And besides, us old folks have to stick together....
[04:02] <Alison_Chaiken> As a penance, every week I go on #pandaboard or Pandaboard mailing list and answer one or two of the most F FAQs.
[04:03] <Alison_Chaiken> So if you want to know why the Pandaboard doesn't work when you plugin your USB mouse, or you can't figure out to tell if HW acceleration of graphics is working on Panda, I'm you're girl.
[04:03] <ScottK> Nice.
[04:03] <Alison_Chaiken> Not really, but let's let Ricardo Salveti and Rob Clark answer hard questions, no?
[04:04] <ScottK> BTW, please help with our developer documentation.  People who've been doing it for a long time are too experienced to write stuff for new people.  Now is when we need your help.
[04:04] <Alison_Chaiken> But I am tired.   "sudo make salmon-salad".
[04:04] <Alison_Chaiken> sudo -k'alchaiken@gmail.com' salmon-salad
[04:04]  * ScottK had salmon salad tonight (really).
[04:04] <ScottK> ;-)
[04:05] <Alison_Chaiken> ScottK, you be da man!   Did you save me any?
[04:05] <ScottK> It's also three hours later here, so it was awhile ago.
[04:05] <Alison_Chaiken> You must be hungry again then.
[04:05] <ScottK> There was a little left, but it'd been sitting on the table for several hours and I figured it wasn't going to survive the trip home.
[04:05] <Alison_Chaiken> 7 AM meeting with darn Europeens, meaning 10 hours from now . . .
[04:06] <ScottK> No.  Not really.  Italian tradition is to stuff the guests full, so I"m still recovering.
[04:06] <Alison_Chaiken> I went to a company picnic.   I arrived late and ate all the leftover grilled chicken and ribs.
[04:06] <ScottK> Nice.
[04:06] <Alison_Chaiken> But I rode a cycling century yesterday and feel entitled.
[04:07] <ScottK> That sounds dangerously like exercise.
[04:07] <Alison_Chaiken> No ribs for dinner though.   And now the TdF is over!   Maybe I'll read a book . . . no write man page.
[04:08] <Alison_Chaiken> Are you a Boston Ubuntun?
[04:08] <ScottK> No.  I live outside Baltimore.
[04:08] <Alison_Chaiken> I'm the only resident of Mountain View, CA who doesn't work at Google.
[04:08] <ScottK> Heh.
[04:08] <Alison_Chaiken> I keep my doors locked at night so the recruiters can't get in.
[04:09] <ScottK> Must be horrible.  I get enough emails from them even this far away.
[04:09] <Alison_Chaiken> The winos on the street and the toddlers in the playpens work for Google now.
[04:10] <Alison_Chaiken> I expect Google recruiters to offer a free personality test any day.
[04:10] <ScottK> Hard to tell.  I'm old enough now that some college graduates look like they're about 12 to me.
[04:10] <Alison_Chaiken> ScottK, the judge isn't going to believe that excuse.   He heard it before.
[04:11] <ScottK> No doubt.
[04:11] <Alison_Chaiken> All right, now I'm genuinely going to look in the fridge.
[04:11]  * ScottK has a look at Debian RC bugs.
[05:12] <ScottK> OK.  Two (fixes) uploaded.  I think I'll call it a night.
[10:15] <frafu> Hi, I am trying to split a debian source into two binaries. Could anybody please tell me whether it is possible to indicate in the package1.install file to put everything from usr/ into it apart the usr/dir1 directory? The usr/dir1 will go into  package2.install. I tried with -usr/dir1 in package1.install, but it does not work.
[10:19] <tumbleweed> no, it's not possible. dh_install copies, it doesn't move
[10:19] <tumbleweed> but you could call dh_install -p package1 -Xusr/dir1 --autodest (I think)
[10:26] <frafu> tumbleweed: thanks for the reply. The package uses python3-distutils-extra and here is the corresponding line in debian/rules:  $$python setup.py install --root=$(CURDIR)/debian/tmp --install-layout=deb; Is there a way I can pass the parameters you indicated to it?
[10:28] <frafu> tumbleweed: setup.py install also does not seem to have an exclude option
[10:31] <tumbleweed> frafu: so, that setup.py install will install to debian/tmp
[10:31] <tumbleweed> that's the usual way we build multi-binary packages
[10:31] <tumbleweed> the upstream build system installs to debian/tmp, we copy from theere into debian/$package...
[10:32] <tumbleweed> what I'm suggesting is that you override dh_install and add a second dh_install call with the parameters I suggested
[10:44] <frafu> tumbleweed: Thanks; it seems to work. Now I wonder, why the original developer overrided dh-auto-install with  $$python setup.py install --root=$(CURDIR)/debian/tmp --install-layout=deb instead of overriding dh_install the way you indicated. Do you have any idea? Could it be because the rules file uses dh $@ --with python3  --without python-support?
[10:47] <tumbleweed> frafu: dh_auto_install drives the upstream's installation mechanism
[10:47] <tumbleweed> i.e. make install
[10:47] <tumbleweed> dh_install is what copies the things that the upstream installed into teh package
[10:47] <tumbleweed> does that make sense?
[10:48] <tumbleweed> If I'm building a python source package that builds python & python3 binary packages
[10:48] <tumbleweed> then I'll often do python setup.py install --root=$(CURDIR)/debian/python-foo
[10:49] <tumbleweed> and python3 setup.py install --root=$(CURDIR)/debian/python3-foo
[10:49] <tumbleweed> (ok, not exactly that, but conceptually similar to that for the purposes of this conversation)
[10:49] <tumbleweed> and then I don't have to do anything with dh_install, my work is already done for me
[10:54] <frafu> I talked to early; "dh_install -p onboard -X/usr/share/onboard/models --autodest" did not help; the models directory is still in the package. It is indeed a package that is prepared for building  python & python3 binary packages. I will try the following: I leave the original dh-auto-install override and I add the dh-install override; will it make sense?
[10:55] <tumbleweed> try stripping the leading /?
[10:55] <tumbleweed> but I'm just guessing there
[10:55] <frafu> ok
[10:55] <tumbleweed> yes, re adding a dh-install override. That's exactly what I'm saying
[11:12] <frafu> tumbleweed: /usr/share/onboard/models is now also missing in the second binary package, as if dh-python did not understand the p option; that option is also missing here: http://manpages.ubuntu.com/manpages/lucid/man1/dh_install.1.html
[11:15] <frafu> The name of the first binary package is included in the name of the second binary package; but I suppose that this is not the problem!? The problem is probably that dh-python does not understand the p switch.
[11:19] <frafu>  /usr/share/onboard/models were previously in both binary packages; now it is in none; I will probably not come around listing explicitely all leave of the directories to go into the binary packages in the package.install files.
[11:21] <frafu> I have to go now; I will probably come back much later today. tumbleweed: thanks for the explanations.
[19:41] <Laney> dear github, where your diff button?
[19:42] <jtaylor> .diff
[19:42] <jtaylor> add it to the ur
[19:42] <jtaylor> l
[19:42] <Laney> wtf
[19:42] <Laney> you are right
[19:43] <ScottK> Appropriately intuitive U/I for a Git based service.
[19:44] <tumbleweed> even better: .patch
[19:44] <tumbleweed> and yes my least favourite github feature