Bug#988484: Bug#974678: ITP: openh264 -- H.264 encoding and decoding
Bastian Germann writes: > Am 02.06.21 um 17:33 schrieb Tobias Frost: >> Is this RFS package now a downloader or the library itself? > > It's both. The -dev package is created from the source files and > resides in main. The library package contains the downloader as a > postinst script, which checks the known SHA256 hashes. > There are some example userspace tools available in the package which > could potentially be packaged in an additional package. I left this > for a later version. > > There is also a chance that reproducible build might be implemented: > https://github.com/cisco/openh264/issues/893 > When that works, the package could build the lib, verify the resulting > hashes, and throw away the built binary. That way we could be sure not > to have any additions to the downloaded library that are not available > as source. > > I think, as Cisco provides the patent license, having the downloader > in contrib (for some architectures) is better than having the built > library in main (for all compiling architectures). We could also > provide both. Any thoughts? As I understand Debian Policy, downloading anything during postinst is discouraged, if not banned. So it would be best to avoid it. In terms of the patent license, I do not think that x264 has any special dispensation. So just directly building and packaging openh264 should not open Debian to any significant additional liability. But as always, the FTP masters will be the final arbiter of that. Cheers, Walter
Re: C++ help needed for centrifuge
Andreas Tille <andr...@an3as.eu> wrote:
> Hi,
>
> On Sat, Nov 25, 2017 at 01:39:03PM -0800, Walter Landry wrote:
>> > In file included from centrifuge_build.cpp:27:0:
>> > bt2_idx.h: In static member function 'static std::pair<Ebwt*,
>> > Ebwt*> Ebwt::fromStrings(const
>> > EList<std::__cxx11::basic_string >&, bool, int, int, bool,
>> > int32_t, int32_t, int32_t, const string&, bool, index_t, index_t, index_t,
>> > int, uint32_t, bool, bool, bool)':
>> > bt2_idx.h:1053:3: warning: 'template class std::auto_ptr' is
>> > deprecated [-Wdeprecated-declarations]
>>
>> This is only a warning, so you can ignore it. If you are feeling
>> ambitious, the recommended fix is to replace all auto_ptr's with
>> unique_ptr's and copies with moves().
>
> I've applied this in
>
>
> https://anonscm.debian.org/cgit/debian-med/centrifuge.git/tree/debian/patches/fix_auto_ptr_usage_in_gcc-7.patch
I think that is OK. If I were in charge of this code, I would convert
it from pointers to value semantics, but that would be a much larger
change.
>> Apparently, clang-modernize can
>> do this automatically.
>
> In what package can I find clang-modernize (apt-file search did not find
> anything - but I'm currently not on my development machine).
Sorry. It has been renamed to clang-tidy.
> Unfortunately I've hit another issue:
>
> ...
> classifier.h:428:54: error: the value of 'rank' is not usable in a constant
> expression
> while((uint8_t)_hitMap[i].rank < rank) {
> ^~~~
> classifier.h:424:21: note: 'uint8_t rank' is not const
> uint8_t rank = 0;
> ^~~~
That is mysterious to me. Is that the first error?
Walter Landry
Re: C++ help needed for centrifuge
Andreas Tille <andr...@an3as.eu> wrote: > Hi, > > I started packaging centrifuge[1] and hit a build error which > is most probably caused by gcc-7 incompatibility: > > ... > In file included from centrifuge_build.cpp:27:0: > bt2_idx.h: In static member function 'static std::pair<Ebwt*, > Ebwt*> Ebwt::fromStrings(const > EList<std::__cxx11::basic_string >&, bool, int, int, bool, int32_t, > int32_t, int32_t, const string&, bool, index_t, index_t, index_t, int, > uint32_t, bool, bool, bool)': > bt2_idx.h:1053:3: warning: 'template class std::auto_ptr' is > deprecated [-Wdeprecated-declarations] This is only a warning, so you can ignore it. If you are feeling ambitious, the recommended fix is to replace all auto_ptr's with unique_ptr's and copies with moves(). Apparently, clang-modernize can do this automatically. Walter Landry
Re: No idea how to fix abs arguments in nanopolish
Andreas Tille <andr...@an3as.eu> wrote: > Hi, > > to fix bug #853568 I tried a patch (gcc-7.patch) to fix abs() arguments > in nanopolish[1] but I have no idea how to deal with this: > > ... > g++ -o src/hmm/nanopolish_pore_model_set.o -c -g -O2 > -fdebug-prefix-map=/build/nanopolish-0.5.0=. -fstack-protector-strong > -Wformat -Werror=format-security -g -O3 -std=c++11 -fopenmp -Wdate-t > src/common/nanopolish_variant.cpp: In function 'std::vector > extract_variants(const string&, const string&)': > src/common/nanopolish_variant.cpp:32:69: error: call of overloaded > 'abs(std::__cxx11::basic_string::size_type)' is ambiguous > size_t difference = std::abs(reference.size() - haplotype.size()); The result of subtracting two size_t's is still a size_t, which is unsigned. So you need to cast it to a signed type. The correct type is ptrdiff_t. http://en.cppreference.com/w/cpp/types/ptrdiff_t The line then becomes size_t difference = std::abs(static_cast(reference.size() - haplotype.size())); Or you could do it in two lines ptrdiff_t diff_signed (reference.size() - haplotype.size()); size_t difference = std::abs(diff_signed); Cheers, Walter Landry
Re: Preferred source: a fundamental question was Re: - #859130 ITP: lina
Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote: > For those not versant with assembler. The binary that is generated is > supposed to be byte for byte the same with both assemblers. If not it > is a bug. The sources are equivalent, the binaries are the same, it > really is the same program. > > Note, that I could not have told that I use an internal representation > and nobody could have guessed (nor benefited.) > > So is the .s accepted as source conform Debian policies? Unpopular or obscure source formats can still be the preferred source. Presumably you use this internal representation for a good reason. If it helps you, it can help others. Cheers, Walter Landry
Re: C++ help needed for psortb
Andreas Tille <andr...@an3as.eu> wrote: > hmm-binding.cpp: In member function ‘void HMM::init(char*, int, int)’: > hmm-binding.cpp:245:20: error: ‘CUT_NONE’ was not declared in this scope >thresh.autocut = CUT_NONE; > ^~~~ > Makefile:346: recipe for target 'hmm-binding.o' failed It is difficult to know without spending more time, but I would try changing this to thresh.autocut = threshold_s::CUT_NONE; Cheers, Walter Landry
ITP's not showing up on debian-devel?
Hi Everyone, I recently posted two ITP's http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843325 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843570 The confirmation message said that they would be forwarded to debian-devel, but it has been a while and I do not see either of them there. Did I mess something up in the ITP, is there some moderation queue, or are my emails getting eaten? Thank you, Walter Landry
Re: Bug#570621: Parsing output = derivative work?
Miriam Ruiz mir...@debian.org wrote: In general, I wouldn't consider parsing the output of another program to de a derivative work. In general, I do agree with Miriam that parsing the output of another program does not make a derivative work. But just to give an example of where it does happen, git is largely comprised of many small utilities that communicate over pipes and command-line arguments. Cheers, Walter Landry wlan...@caltech.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110308.092322.148477719412830956.wal...@geodynamics.org
Re: upstream has license which is an edited GPL
Ben Finney [EMAIL PROTECTED] wrote: Stanislav Maslovski [EMAIL PROTECTED] writes: I was going to package CDDE [1] but noticed that upstream ships it with a license file which is GPL v.2 without the preamble and the appendix […] I have e-mailed the upstream explaining that changing GPL and removing its copyright is not allowed The copyright license on the document containing the GPL says: = Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. = So, even if they preserve the copyright notice, they still may not redistribute changed copies of the GPL document. Only verbatim copies may be redistributed. Not quite. From http://www.fsf.org/licensing/licenses/gpl-faq.html#ModifyGPL Can I modify the GPL and make a modified license? You can use the GPL terms (possibly modified) in another license provided that you call your license by another name and do not include the GPL preamble, and provided you modify the instructions-for-use at the end enough to make it clearly different in wording and not mention GNU (though the actual procedure you describe may be similar). Cheers, Walter Landry [EMAIL PROTECTED]
Re: [Pkg-alsa-devel] RFS: alsa-tools
Marco d'Itri [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Do we have to split the alsa-tools source into two packages, one free and one non-free/contrib? It will make it a bit harder. No. Unfortunately, that is not the case. All of the source for packages in main must satisfy the DFSG. For example, if there are some non-free, but distributable, files in the original tar ball, those have to be taken out and a new original tar ball made. Regards, Walter Landry [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
