Bug#990693: RFS: fonts-gemunu-libre/1.100+ds-1 -- new interpretation to FM Gamunu font

2021-07-04 Thread Gürkan Myczko

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "fonts-gemunu-libre":

 * Package name: fonts-gemunu-libre
   Version : 1.100+ds-1
   Upstream Author : mooniak Pvt. Ltd 
 * URL : http://mooniak.com/gemunu-libre-font/tests/
 * License : OFL-1.1
 * Vcs : 
https://salsa.debian.org/fonts-team/fonts-gemunu-libre

   Section : fonts

It builds those binary packages:

  fonts-gemunu-libre - new interpretation to FM Gamunu font

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


  https://mentors.debian.net/package/fonts-gemunu-libre/

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


  dget -x 
https://mentors.debian.net/debian/pool/main/f/fonts-gemunu-libre/fonts-gemunu-libre_1.100+ds-1.dsc


Changes since the last upload:

 fonts-gemunu-libre (1.100+ds-1) experimental; urgency=medium
 .
   * New upstream version.
   * d/copyright: updated years, added Files-Exluded and 
Upstream-Contact.

   * d/upstream/metadata: added.
   * d/control: added Rules-Requires-Root.
   * Bump debhelper version to 13, drop d/compat.
   * d/rules: build from glyphs file.
   * d/install: update source.
   * d/watch: added filemangle for repacking.

Regards,
--
  Gürkan Myczko



Re: Missing Hardening Flags (freefem++)

2021-07-04 Thread François Mazen
Hi Andrey,

> Anyway, some (I guess all) of those libs are compiled with ff-c++
> which
> just doesn't pass LDFLAGS from the environment.

Indeed! Patching ff-c++ removed almost all hardening lintian warnings.
I'll track the remaining ones.

> Unrelated to this, the package uses -mmmx -avx, is this an RC bug or
> is
> all code compiled with those flags only enabled at the run time on
> CPUs
> supporting them?

As stated in #924009, the --enable-generic configure option should fix
it. I'll check before releasing the new package.

Thanks a lot for your help!

Best Regards,
François




signature.asc
Description: This is a digitally signed message part


Bug#981702: RFS: privacybadger/2021.2.2-1 -- browser extension automatically learns to block invisible trackers

2021-07-04 Thread John Scott
On Wed, 2021-06-09 at 17:07 +0200, Tobias Frost wrote:
> >     * Friendly takeover back into the WebExt team.
> 
> I can't find any documentation about that have been ACKed by the
> current maintainer. (CCing Jonas so that he can response/confirm, to
> put it on record that this is not an hijack…)
I've attached a digitally signed message from him asserting it's okay.

I've applied for an unblock request with the release team to see about
uploading it to unstable.


Re:_Privacy_Badger_WebExtension_package.mbox
Description: application/mbox


signature.asc
Description: This is a digitally signed message part


Re: Missing Hardening Flags (freefem++)

2021-07-04 Thread Andrey Rahmatullin
On Sun, Jul 04, 2021 at 10:42:06PM +0500, Andrey Rahmatullin wrote:
> Unrelated to this, the package uses -mmmx -avx, is this an RC bug or is
> all code compiled with those flags only enabled at the run time on CPUs
> supporting them?
I see this is already filed as #924009. I'll fix the severity.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Missing Hardening Flags (freefem++)

2021-07-04 Thread Andrey Rahmatullin
On Sun, Jul 04, 2021 at 01:28:05PM +0200, François Mazen wrote:
> > Can you publish the build log or at least make the repo buildable?
> 
> Unless I'm mistaken, the repo is buildable. See salsa CI [1] and
> associated build-log [2].
Not sure how does that work, as gbp requires the upstream/4.9+dfsg.1 tag
which is not pushed.

Anyway, some (I guess all) of those libs are compiled with ff-c++ which
just doesn't pass LDFLAGS from the environment.
The sid version was at least compiled with -Wl,-z,relro -Wl,--as-needed,
because as, I presume, a workaround for that ff-c++ problem these flags
were passed in $CC (which of course is not *that* sane) in
debian/patches/gmm_cxxflags.patch, which is deleted in this version. 
Though even for the sid version blhc still reports lots of missing flags.

Unrelated to this, the package uses -mmmx -avx, is this an RC bug or is
all code compiled with those flags only enabled at the run time on CPUs
supporting them?

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Missing Hardening Flags (freefem++)

2021-07-04 Thread François Mazen
Hello Andrey,

> Can you publish the build log or at least make the repo buildable?

Unless I'm mistaken, the repo is buildable. See salsa CI [1] and
associated build-log [2].
I hope this help to point me in the right direction.

Thanks,
François

[1] https://salsa.debian.org/science-team/freefempp/-/pipelines/264090
[2] https://salsa.debian.org/science-team/freefempp/-/jobs/1721112/raw



signature.asc
Description: This is a digitally signed message part


Re: Missing Hardening Flags (freefem++)

2021-07-04 Thread Andrey Rahmatullin
On Sat, Jul 03, 2021 at 09:59:30PM +0200, François Mazen wrote:
> Dear Mentors,
> 
> I'm updating the freefem++ package to 4.9 release [1] and I get
> hardening-no-bindnow lintian warnings on several binary outputs [2].
> 
> Of course the appropriate variable is set in debian/rules (export
> DEB_BUILD_MAINT_OPTIONS = hardening=+all), see [3]. According to [4] it
> means that some flags like CPPFLAGS/CXXFLAGS/LDFLAGS are overridden
> somewhere in the configuration.
> 
> I can't find where these flags are overridden. Could you please help?
Can you publish the build log or at least make the repo buildable?

-- 
WBR, wRAR


signature.asc
Description: PGP signature