Re: cppcheck: Incorrect minimum version requirement for Depends: on libc

[Nicholas D Steeves]

Hi Joachim,

Joachim Reichel  writes:

> Hi,
>
> On 19.11.21 18:35, Joachim Reichel wrote:
>> I'd appreciate some help with a problem I don't understand.
>> 
>> Bug #1000146 against cppcheck 2.6-1 (in testing and unstable) is about the 
>> fact 
>> that /usr/bin/cppcheck seems to require "libc6 >= 2.32" while the Depends: 
>> line 
>> in the binary package cppcheck contains "libc6 (>= 2.29)".
>
> I debugged this a bit further and found that dpkg-shlibdeps does not take 
> certain symbols into account. Details are in bug #1000421.
>

Nice find!

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#996653: RFS: dynarmic/5+git20211012.cce7e4e+ds-1 [ITP] -- ARMdynamic recompiler

[Bastian Germann]

Control: tags -1 moreinfo

On 23.11.21 21:48, Andrea Pappacoda wrote:

On Tue, 23 Nov 2021 18:13:10 +0100 Andrea Pappacoda  wrote:
 > > FTBFS on arm64:
 >
 > This makes me think that arm64 host support is still incomplete. Until
 > it released as stable by upstream, I think it's better to disable arm64
 > builds.

Or maybe not. Some build issues are probably related to the fact that libzydis-dev does not depend 
on libzycore-dev while it should - this causes Dynarmic to FTBFS also on amd64. Also, libxbyak-dev 
pre-6.00-2 had a small issue that made it impossible to make it discoverable through CMake's 
find_package(). I've uploaded a fixed zydis revision (-3) on Mentors, and tomorrow I'll also work on 
Dynarmic and arm64.


Okay. I have just uploaded the new zydis version.
Please untag moreinfo when you have uploaded a new dynarmic.

Bug#981030: RFS: sctk/2.4.10-20151007-1312Z+dfsg2-4 -- speech recognition scoring toolkit

[Bastian Germann]

Am 22.11.21 um 16:10 schrieb Giulio Paci:

I guess the main reason for this weird behavior is described in (option 
-mfpmath):

https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/x86-Options.html#x86-Options 



and in (option -ffloat-store):

https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/Optimize-Options.html#Optimize-Options 
.


Using -ffloat-store option indeed seems to fix the issue.


However I am wondering:
1) is this the proper solution?
2) is it correct that the compiler does not guarantee the above assumptions?

Do you have any suggestion?


Hi,

I am not very knowlegable about floating point semantics in various compiler 
optimizations,
so unfortunately I do not have any suggestion. Does upstream have an opinion on 
this?

Thanks,
Bastian

Bug#1000324: RFS: ghostwriter/2.1.0-1 -- Distraction-free, themeable Markdown editor

[Nicholas D Steeves]

Hi Sebastien,

Sebastien Chavaux  writes:
>
> Thank you first of all. So it's not that I don't want to maintain git /
> salsa, it's that I'm not comfortable with it, should do a remedial course
> on it.
>

I also found git hard to start out with.  The first thing I noticed that
all documentation seemed to omit was how important it is to set EDITOR
in ~/.bashrc.

Beyond that, here are the three approaches I took:

1. Keep it simple, and use debcommit.  With this approach I assume
whole-repository granularity.  Note that one pitfall with this method is
that you may need to manually run "git status", "git add ./", and "git
remove list of files".  "git add ./" will also add backup-files~, which
is annoying.  To be fair, debcommit+git does support more a more
fine-grained staging and committing workflow, but I never really got
comfortable with it.  One significant advantage to this approach is that
it encourages objective-driven development.  eg: your "* changelog
entry for foo" can be seen as your goal; then you work to accomplish
your goal.
   * uscan
   * dch -v1.0.1
 # Make any change, even as simple as  , then save
   and exit
   * debcommit -a
 # This "opens a new changelog entry" in git history
[a]* Attempt a build
   * If it fails, make changes
   * dch
 # Document the purpose of your changes, save, and exit
   * debcommit -a
   ... cycle back to [a]
   and so on...  Eventually "dch -r", commit, and tag.

2. git-buildpackage a bit more difficult, but still fairly easy to use,
and optionally enables a the opposite workflow, where the changelog is
generated from commit messages.  When this was my primary approach I
manually ran git commands as necessary.

3. Learn to use Magit to exploit the full power of git staging,
reverting, rebasing, 3-way diffing during conflicts, etc.  This is now
my preferred approach, because it enables one to do all the work at
once, then quickly stage specific groups of files and lines from files
(such as changelog) into atomic, self-contained commits.  Getting
comfortable with this approach requires getting comfortable with Emacs,
which might not be something you're interested in.  For what it's worth,
I was initially skeptical, but after a few months found it totally
worthwhile.

Whatever approach you end up taking, I hope you'll one day have an
empowering "Aha!" moment when you realise that your work wasn't wiped
out by a hasty "git reset --hard committish".  eg:
  https://stackoverflow.com/questions/5473/how-can-i-undo-git-reset-hard-head1

Beyond this, it's a bit annoying to have to locally delete a release tag
if your mentor asks for revisions; this includes updating the changelog,
committing, rerunning "dch -r", committing, and retagging.

> I will see how to define the same list of architectures as qtwebengine5. I
> watch this and do it after work.
>

This sounds like a good approach to me :-)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#1000324: RFS: ghostwriter/2.1.0-1 -- Distraction-free, themeable Markdown editor

[Nicholas D Steeves]

P.S. Yes, these methods aren't mutually exclusive; they can be combined.
I was just trying to keep things simple ;-)


signature.asc
Description: PGP signature

Re: cppcheck: Incorrect minimum version requirement for Depends: on libc

[Joachim Reichel]

Hi,

On 19.11.21 18:35, Joachim Reichel wrote:

I'd appreciate some help with a problem I don't understand.

Bug #1000146 against cppcheck 2.6-1 (in testing and unstable) is about the fact 
that /usr/bin/cppcheck seems to require "libc6 >= 2.32" while the Depends: line 
in the binary package cppcheck contains "libc6 (>= 2.29)".


I debugged this a bit further and found that dpkg-shlibdeps does not take 
certain symbols into account. Details are in bug #1000421.


Best regards,
  Joachim

Bug#994556: marked as done (RFS: cpp-httplib/0.9.7+ds-1 [ITP] -- C++ HTTP/HTTPS server and client library)

[Debian Bug Tracking System]

Your message dated Tue, 23 Nov 2021 18:25:12 +0100
with message-id <63835e22-083c-6bc5-12c7-019f01804...@debian.org>
and subject line Re: RFS: cpp-httplib/0.9.7+ds-1 [ITP] -- C++ HTTP/HTTPS server 
and client library
has caused the Debian Bug report #994556,
regarding RFS: cpp-httplib/0.9.7+ds-1 [ITP] -- C++ HTTP/HTTPS server and client 
library
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.)


-- 
994556: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994556
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear mentors,

I am looking for a sponsor for my package "cpp-httplib":

 * Package name: cpp-httplib
   Version : 0.9.4+ds-1
   Upstream Author : Yuji Hirose 
 * URL : https://github.com/yhirose/cpp-httplib
 * License : Expat
 * Vcs : https://github.com/yhirose/cpp-httplib
   Section : libs

It builds those binary packages:

  libcpp-httplib-dev - C++ HTTP/HTTPS server and client library - development
files
  libcpp-httplib0 - C++ HTTP/HTTPS server and client library

To access further information about this package, please visit the following
URL:

  https://mentors.debian.net/package/cpp-httplib/

Alternatively, one can download the package with dget using this command:

  dget -x https://mentors.debian.net/debian/pool/main/c/cpp-httplib/cpp-
httplib_0.9.4+ds-1.dsc

Changes for the initial release:

 cpp-httplib (0.9.4+ds-1) UNRELEASED; urgency=low
 .
   * Initial release. Closes: #994547

Regards,
- --
  Andrea Pappacoda


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQSlw/BqXszDGx3GlQz/yQfijUdG7QUCYUTLcRQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRD/yQfijUdG7Vt+AQDPUIZ5fXlYxJ7INpcAOqydJJgMKVNa
sq4Hqr2rKsIFOQD8DKqcDsxEfetYV5U8XIl/aydnwCpvGOBIBGpAFNyTtgU=
=hS/v
-END PGP SIGNATURE-
--- End Message ---
--- Begin Message ---

Am 23.11.21 um 16:59 schrieb Andrea Pappacoda:
Done, cpp-httplib will now build with OpenSSL 1.1.1 and newer, ever 3.0. I didn't remove the 1.1.1 requirement since 
upstream seems to insist on it quite often and it isn't really worth the effort since 1.1.0 hasn't been in Debian since 
stretch.


Okay. I did not want you to do anything about the lower bound. Uploaded.--- End Message ---