[06:27] <cpaelzer> Hi, was there any change in LP that it started to import comments from RH-BZs this morning
[06:27] <cpaelzer> it seems still going on
[06:27] <cpaelzer> I see many updates to old bugs for these updates
[06:57] <ginggs> cpaelzer: from debian-devel [14:46:22] <cjwatson> FYI, I'm going to be re-enabling the redhat-bugs LP bug tracker soon, so a whole bunch of bugs are going to get comment and status syncs from bugzilla.redhat.com
[06:58] <ginggs> cpaelzer: so that was at about 12:46 UTC on Thursday
[07:06] <cpaelzer> thanks ginggs
[07:06] <cpaelzer> that would match my inbox
[07:07] <cpaelzer> I like the feature in general, just wanted to understand why so many today - that makes sense now - so thanks ginggs for clarifying and thanks cjwatson for the feature
[07:13] <cjwatson> cpaelzer: Yes.  We had somebody who actively wanted it, and it was only disabled due to a temporary problem at the RH end six years ago which we (collectively) forgot to follow up on once they fixed it.
[07:14] <cjwatson> All I did was a bit of cleanup.
[07:50] <wgrant> Well, tbf the temporary problem lasted for about three years
[11:37] <manuelschneid3r> Hi
[11:37] <manuelschneid3r> how do I build a cmae project on launchpad?
[11:37] <manuelschneid3r> the debian/control is automatically generated by cpack
[11:38] <manuelschneid3r> launchpad should just call cmake
[11:39] <cjwatson> Launchpad just calls dpkg-buildpackage; it's up to your packaging to call whatever the upstream build system is.  If you use "dh" (see "man dh") then debhelper will normally make a reasonable guess.
[11:45] <manuelschneid3r> cjwatson, what do you mean by "it's up to your packaging to call whatever the upstream build system is"
[11:46] <cjwatson> manuelschneid3r: Launchpad doesn't know or care whether you use cmake or autotools or anything else.  That's all defined by debian/rules, normally using debhelper to do the hard work.
[11:46] <cjwatson> manuelschneid3r: It is up to debian/rules to do whatever is needed for your package.
[11:52] <cjwatson> manuelschneid3r: http://manpages.ubuntu.com/manpages/xenial/en/man1/dh.1.html has some short examples of rules files.  The first rules file example there should detect cmake without any help, but you can add "--buildsystem=cmake" if it fails for some reason.  You can then add override targets as shown to fix up any cases where the default behaviour is wrong.
[11:53] <cjwatson> manuelschneid3r: And you can test all this locally using (for example) sbuild; none of this is specific to Launchpad.
[11:53]  * cjwatson → lunch
[13:05] <ali1234> supposing that ubuntu-keyring package didn't exist, how could i create the ubuntu-archive-keyring.gpg file using gpg/apt-key?
[13:06] <ali1234> ie by fetching the key from the keyserver
[13:06] <ali1234> i think it should be something like "apt-key adv --keyring /home/al/foo.gpg --no-default-keyring --keyserver keyserver.ubuntu.com --recv <fingerprint>"
[13:06] <ali1234> but i can't quite figure it out
[13:08] <ali1234> nvm, got it...
[13:24] <ali1234> what is the difference between /usr/share/keyrings and /etc/apt/trusted.gpg.d?
[13:27] <cjwatson> the latter is what apt actually looks at; it's configurable and is updated from the packaged (thus basically immutable) files in the former
[13:28] <cjwatson> well, actually /etc/apt/trusted.gpg is the one that's updated from /usr/share/keyrings/
[13:28] <cjwatson> the .d one is there for non-default packages to drop things into
[13:39] <ali1234> so apt shouldn't care about the contents of /usr/share/keyrings?
[13:42] <cjwatson> not directly; some packages' postinsts read files from there and push them into apt config
[13:43] <ali1234> well, that's the problem i am trying to work around
[13:43] <ali1234> i have two broken keyring packages... the first one is broken because it doesn't exist at all
[13:43] <ali1234> the second one is broken because it installs a file into /usr/share/keyrings and then runs "apt-key add" from its postinst
[13:43] <cjwatson> can you explain how this relates to Launchpad?  If it's related to Launchpad then presumably there's a build log somewhere that we could look at
[13:44] <ali1234> oh, i'm in #launchpad?
[13:44] <cjwatson> you are
[13:53] <smoser> is there a debian bug equivalent of 'LP: #XXX'
[13:53] <smoser> in commit messages (git specifically)
[13:55] <cjwatson> smoser: Nothing I can point to as authoritative and consistent.  It's going to depend on what's processing the commit messages.  There do exist commit hooks on Debian git repositories that tag bugs as pending; I believe they generally use "Closes: #XXX", as in Debian changelogs.
[13:56] <smoser> hm ok. i dont crae for that in that its just not namespaced at all.
[13:56] <cjwatson> Not something I can fix for you.
[13:56] <smoser> no its not :)
[13:56] <smoser> thats fine, thanks.
[13:56] <cjwatson> If you aren't pushing to a repository with a relevant commit hook, then it doesn't really matter.
[13:56] <cjwatson> I've been known to use "Debian: #XXX" for instance.
[13:56] <smoser> yeah. thats what i was planning on doing.
[13:56] <smoser> thanks.
[13:57] <cjwatson> np
[23:59] <QwertyChouskie> Quick question
[23:59] <luk3yx> Ask away
[23:59] <QwertyChouskie> Is it possible to make a build recipe that uses both git and bzr repos?