Bug#896685: marked as done (RFS: obkey/1.2.2-1 [ITP])
Your message dated Tue, 11 Sep 2018 04:21:26 + with message-id and subject line closing RFS: obkey/1.2.2-1 [ITP] has caused the Debian Bug report #896685, regarding RFS: obkey/1.2.2-1 [ITP] to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 896685: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896685 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "obkey" * Package name: obkey Version : 1.2.2-1 Upstream Author : luffah * URL : https://github.com/luffah/obkey * License : MIT Section : x11 It builds those binary packages: obkey - Openbox Key Editor To access further information about this package, please visit the following URL: https://mentors.debian.net/package/obkey Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/o/obkey/obkey_1.2.2-1.dsc More information about obkey can be obtained at https://github.com/luffah/obkey. Regards, luffah --- End Message --- --- Begin Message --- Package obkey has been removed from mentors.--- End Message ---
Re: How to make meson accept that `pkg-config --cflags ` has empty result in case only /usr/include is needed
Hi Andrey, On Mon, Sep 10, 2018 at 07:40:45PM +0500, Andrey Rahmatullin wrote: > > is correct behaviour and return code is 0. > You are not running this in a minimal chroot. > > # pkg-config --cflags pbbam > Package zlib was not found in the pkg-config search path. > Perhaps you should add the directory containing `zlib.pc' > to the PKG_CONFIG_PATH environment variable > Package 'zlib', required by 'htslib', not found > > I've submitted #908501 against libhts-dev. Good catch. Meanwhile I've added zlib1g-dev directly to Build-Depends of this package and it turned out that also libhdf5-dev is needed (including an according patch for meson.build. Unfortunately there are remaining issues related to hdf5 lib: ... c++ -Iblasr@sha -I. -I.. -I../ -I/usr/include/hdf5/serial -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c++11 -g -O2 -fdebug-prefix-map=/build/libblasr-5.3.1=. -fstack-protecto In file included from ../hdf/HDFAtom.cpp:1: ../hdf/HDFAtom.hpp: In member function ‘int HDFAtom::Initialize(H5::H5File&, const string&, const string&)’: ../hdf/HDFAtom.hpp:64:44: error: no matching function for call to ‘HDFGroup::Initialize(H5::H5File&, const string&)’ group.Initialize(hdfFile, groupName); ^ In file included from ../hdf/HDFData.hpp:10, from ../hdf/HDFAtom.hpp:12, from ../hdf/HDFAtom.cpp:1: ../hdf/HDFGroup.hpp:28:9: note: candidate: ‘int HDFGroup::Initialize(H5::Group&, std::__cxx11::string)’ int Initialize(H5::Group& fg, std::string groupName); ^~ ../hdf/HDFGroup.hpp:28:9: note: no known conversion for argument 1 from ‘H5::H5File’ to ‘H5::Group&’ ../hdf/HDFGroup.hpp:30:9: note: candidate: ‘int HDFGroup::Initialize(HDFGroup&, std::__cxx11::string)’ int Initialize(HDFGroup& parentGroup, std::string groupName); ^~ ../hdf/HDFGroup.hpp:30:9: note: no known conversion for argument 1 from ‘H5::H5File’ to ‘HDFGroup&’ ... Any idea how to fix this? Kind regards Andreas. -- http://fam-tille.de
Bug#908410: Fwd: Bug#908410: Acknowledgement (RFS: gradle-apt-plugin/0.10-1 [ITP])
Le 10/09/2018 à 18:44, Miroslav Kravec a écrit :
> Thanks! It took some effort, so I'm glad the package is considered to be
> well packaged.
There was just a redundant build dependency on default-jre-headless
(implied by default-jdk), and the ${maven:Depends} variable was useless
because it only works with maven-debian-helper.
> How long does it usually take to get package approved?
It can be very fast or take a few weeks, we never now. It's just a
matter of patience.
Re: Packaging in git and Files-Excluded
Hi, On Sun, Sep 09, 2018 at 12:09:00PM +0200, Birger Schacht wrote: > i'm trying to package a software using git and importing upstream > releases from git tags. There are files in the git tree that have to be > removed to make the package dfsg compliant (what would normally happen > through repackaging). I figured i can just create a git tag > upstrea/0.1.2-ds which does exclude the non dfsg compliant files. But > now i'm not sure how to create that tag- should i create a branch of the > tag, remove the files and tag that branch? Is there a best practice how > that branch should be called? I didn't find anything regarding this > situation in DEP14. As far as I know Files-Excluded is just about repackaging since it is consumed by uscan which is downloading and optionally repackaging a tarball. Is there any reason not to use uscan as intended and than use gbp import-orig --pristine-tar downloaded_repackaged_tarball ? Kind regards Andreas. -- http://fam-tille.de
Bug#908410: Fwd: Bug#908410: Acknowledgement (RFS: gradle-apt-plugin/0.10-1 [ITP])
On Mon, Sep 10, 2018 at 12:39 AM Emmanuel Bourg wrote: > > could you please take a look at this package, and sponsor upload, if > > the packaging correct? > > Uploaded. Thank you for sponsoring upload. Very good packaging, well done! > Thanks! It took some effort, so I'm glad the package is considered to be well packaged. I see, that both packages are still in debian NEW queue: * https://ftp-master.debian.org/new/gradle-apt-plugin_0.10-1.html * https://ftp-master.debian.org/new/picocli_3.5.2-1.html How long does it usually take to get package approved? And, is there any further action needed?
Bug#908061: RFS: rapid-photo-downloader/0.9.11-1
On 2018-09-08 14:37:00, Jörg Frings-Fürst wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hello Antoine, > > many thanks for your review. Hi! A pleasure working with you! > Am Mittwoch, den 05.09.2018, 13:01 -0400 schrieb Antoine Beaupré: >> Control: owner -1 anar...@debian.org >> >> On 2018-09-05 18:39:07, Jörg Frings-Fürst wrote: >> > -BEGIN PGP SIGNED MESSAGE- >> > Hash: SHA512 >> > >> > Package: sponsorship-requests >> > Severity: normal >> > >> > Dear mentors, >> > >> > I am looking for a sponsor for my package "rapid-photo- >> > downloader" >> >> Hi! >> >> As the uploader for the package, I'll be happy to sponsor this. >> >> I've reviewed your changes and they seem mostly good. However, they >> seem >> to omit some changes I've uploaded to the git repository 4 weeks ago: >> >> https://salsa.debian.org/debian/rapid-photo-downloader >> >> ... namely: >> >> > https://salsa.debian.org/debian/rapid-photo-downloader/commit/ff0358a5e0783fb2464391cd06d02021a881ccae >> > https://salsa.debian.org/debian/rapid-photo-downloader/commit/c0027837223b83325d653a59146e16d2206fcccf >> >> Those are necessary (I think?) to completely fix #900709. >> >> With those changes, I'll be happy to do the upload. >> > > Sorry. I have first sync only the release 0.9.9-2. Your commits are now > included. The package is uploaded to mentors[1]. Understood. I had a conflict when merging the code from salsa with yours because you keep the removed patch commented out (I just removed the line) in debian/patches/series. I've also removed the unused patches from debian/patches so we have only this one patch remaining. Another thing that's missing from the above .dsc file is the "python3-colour" Depends. Any idea why that's also missing? I've pushed my resulting merge to salsa for now. >> I would also encourage you to register on salsa.debian.org and upload >> your changes there, as it will make future collaboration easier: it >> would have avoided such confusion, for example. >> > > I do not use salsa because of the existing user restrictions. What do you mean by that? A. -- In a world where Henry Kissinger wins the Nobel Peace Prize, there is no need for satire. - Tom Lehrer
Re: How to make meson accept that `pkg-config --cflags ` has empty result in case only /usr/include is needed
On Mon, Sep 10, 2018 at 04:14:23PM +0200, Andreas Tille wrote: > returns nothing which makes sense. This is for instance the case for > /usr/lib/*/pkgconfig/pbbam.pc of libpbbam-dev and I think that > > $ pkg-config --cflags pbbam > > $ echo $? > 0 > > is correct behaviour and return code is 0. You are not running this in a minimal chroot. # pkg-config --cflags pbbam Package zlib was not found in the pkg-config search path. Perhaps you should add the directory containing `zlib.pc' to the PKG_CONFIG_PATH environment variable Package 'zlib', required by 'htslib', not found I've submitted #908501 against libhts-dev. -- WBR, wRAR signature.asc Description: PGP signature
How to make meson accept that `pkg-config --cflags ` has empty result in case only /usr/include is needed
Hi,
it seems that if a pkg-config file just has
prefix=/usr
includedir=${prefix}/include
Cflags: -I${includedir}
the call
pkg-config --cflags libfoo
returns nothing which makes sense. This is for instance the case for
/usr/lib/*/pkgconfig/pbbam.pc of libpbbam-dev and I think that
$ pkg-config --cflags pbbam
$ echo $?
0
is correct behaviour and return code is 0. However when I try to build
the new package libblasr[1] against this lib I get:
...
Found pkg-config: /usr/bin/pkg-config (0.29)
Determining dependency 'pbbam' with pkg-config executable '/usr/bin/pkg-config'
Called `/usr/bin/pkg-config --modversion pbbam` -> 0
0.18.0
Called `/usr/bin/pkg-config --cflags pbbam` -> 1
meson.build:52:0: ERROR: Could not generate cargs for pbbam:
I have no idea why meson considers the normal behaviour as error neither
do I have a clue how to convince meson to accept this argument.
Any help would be welcome
Andreas.
[1] https://salsa.debian.org/med-team/libblasr
--
http://fam-tille.de
Re: How to package Berkeley Packet Filters
On Sun, Sep 02, 2018 at 11:13:16AM +0200, Gregor Jasny wrote: > Hello Debian Mentors, > > I'm writing because I seek advice on how to properly package Berkeley > Packet Filter objects. I was not able to find prior art in any other > Debian package. > > The v4l-utils source package contains a program called ir-keytable which > could be used to alter in-kernel infrared decoder tables. Recently a new > feature was merged into 4.18 Kernel that allows arbitrary protocol > decoding using the Berkeley Packet Filter: > https://lwn.net/Articles/759188/ > > The ir-keytable source contains some BPF source files that gets compiled > into BPF code using clang: > > $(CLANG) ... -target bpf -O2 -c $< > > The result are the following files: > > debian/ir-keytable/lib/udev/rc_keymaps/protocols/manchester.o > > debian/ir-keytable/lib/udev/rc_keymaps/protocols/grundig.o > > debian/ir-keytable/lib/udev/rc_keymaps/protocols/pulse_length.o > > debian/ir-keytable/lib/udev/rc_keymaps/protocols/rc_mm.o > > debian/ir-keytable/lib/udev/rc_keymaps/protocols/pulse_distance.o > > I'd like to know if you have suggestions how to properly package them. > Where should they stay according to FHS? Should I keep the .o suffix or > should I replace it with something like .bpf? Just wanted to add that there is a generic bpf tool in the linux kernel tree called bpftool. This can be used for loading bpf programs, listing all loaded programs, dump loaded programs, etc. It is very possible that users will want this packaged: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/bpf/bpftool/Documentation/bpftool.rst Now, this program refers to bpf programs as "object file". For example, here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/bpf/bpftool/prog.c#n821 The bpf samples provided in: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/samples/bpf/Makefile Also use .o for bpf programs. Lastely note these presentations: https://blog.linuxplumbersconf.org/2015/ocw/system/presentations/3249/original/bpf_llvm_2015aug19.pdf https://archive.fosdem.org/2016/schedule/event/ebpf/attachments/slides/1159/export/events/attachments/ebpf/slides/1159/ebpf.pdf All of them talk about "clang -O2 -target bpf -o foo.o foo.c", so .o is kind of expected. I suspect ir-keytable is the first package to come across this question, and there will be many more. Thanks, Sean > > Theoretically one could make an ir-keytable-filters package with > Architecture: all and Multi-Arch: foreign but I wonder if it's worth the > effort for 36 KB of data. > > dpkg-shlibdeps seems to have some problems: > > objdump: debian/ir-keytable/lib/udev/rc_keymaps/protocols/pulse_length.o: > > not a dynamic object > > objdump: debian/ir-keytable/lib/udev/rc_keymaps/protocols/pulse_length.o: > > invalid operation > > dpkg-shlibdeps: warning: couldn't parse dynamic symbol definition: no > > symbols > > As well as Lintian: > > E: ir-keytable: binary-from-other-architecture > > lib/udev/rc_keymaps/protocols/grundig.o > > Maybe a .bpf file suffix could help to accept those at certain whitelisted > locations. > > Thanks for your input! > > -Gregor
