Re: RFH: pyrit: FTBFS on i386, Python memory corruption?

[Eriberto]

Hi Gianfranco,

Sorry for my delay.

2017-02-22 18:51 GMT-03:00 Gianfranco Costamagna :
>
> seems barriere wasn't so happy with my test...
> Did you open an i386 chroot, right?
> sessionid=$(schroot -b -c sid_i386-dchroot)
>
> The machine is an amd64, so you have to specify the correct chroot to test 
> this :)


Hum... You are right. I didn't specify i386. Sorry again. I was mistaken.

I hope you or someone find a solution. I already changed forensics-extra.

Cheers,

Eriberto

Bug#856151: marked as done (RFS: gexiv2/0.10.4-2)

[Debian Bug Tracking System]

Your message dated Sun, 26 Feb 2017 19:48:08 -0700
with message-id <20170227024808.3j3tmtrvc6mw5...@iris.silentflame.com>
and subject line Re: Bug#856151: RFS: gexiv2/0.10.4-2
has caused the Debian Bug report #856151,
regarding RFS: gexiv2/0.10.4-2
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.)


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

Dear mentors,

I am looking for a sponsor for my package "gexiv2"

 * Package name: gexiv2
   Version : 0.10.4-2
   Upstream Author : Jim Nelson 
 * URL : https://wiki.gnome.org/Projects/gexiv2
 * License : GPL-2+
   Section : libs

It builds those binary packages:

 gir1.2-gexiv2-0.10 - GObject-based wrapper around the Exiv2 library - 
introspection data
 libgexiv2-2 - GObject-based wrapper around the Exiv2 library
 libgexiv2-dev - GObject-based wrapper around the Exiv2 library - development 
file

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

https://mentors.debian.net/package/gexiv2

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gexiv2/gexiv2_0.10.4-2.dsc

More information about gexiv2 can be obtained from 
https://wiki.gnome.org/Projects/gexiv2.

Changes since the last upload:

  * Add patch 0004-get_orientation-Fix-abort-on-Minolta-meta-data.patch.
Fixes an assertion when processing metadata from a not-rotated image
from Minolta cameras. (Closes: 856101)

I am intending to have this in unstable so I can apply for an unblock.

Regards,
 Jason Crain
--- End Message ---
--- Begin Message ---
On Sun, Feb 26, 2017 at 06:46:07PM -0600, Jason Crain wrote:
> On Sun, Feb 26, 2017 at 05:12:44PM -0700, Sean Whitton wrote:
> > I built the package and then ran Lintian.  It produces an error
> > 
> > E: libgexiv2-2:
> > symbols-file-contains-current-version-with-debian-revision on symbol 
> > _ZN5Exiv28XmpdatumaSIlEERS0_RKT_@Base and 1 others
> 
> I noticed that those types of errors showed up in a couple of the buildd
> logs after the last upload.  It's because this is a C++ library that
> exports a C interface.  Most of the C++ symbols are marked as optional
> in the symbols file, but it's hard to catch all of them because they
> vary between architectures.  My long term plan is to copy something I've
> seen in libpoppler-glib and use a regex to mark all C++ symbols as
> optional, but I didn't think in a freeze was a good time to do that.

Thank you for the explanation -- I agree.  Uploaded.

-- 
Sean Whitton


signature.asc
Description: PGP signature
--- End Message ---

Bug#856151: RFS: gexiv2/0.10.4-2

[Jason Crain]

Control: tags -1 - moreinfo

On Sun, Feb 26, 2017 at 05:12:44PM -0700, Sean Whitton wrote:
> I built the package and then ran Lintian.  It produces an error
> 
> E: libgexiv2-2:
> symbols-file-contains-current-version-with-debian-revision on symbol 
> _ZN5Exiv28XmpdatumaSIlEERS0_RKT_@Base and 1 others

I noticed that those types of errors showed up in a couple of the buildd
logs after the last upload.  It's because this is a C++ library that
exports a C interface.  Most of the C++ symbols are marked as optional
in the symbols file, but it's hard to catch all of them because they
vary between architectures.  My long term plan is to copy something I've
seen in libpoppler-glib and use a regex to mark all C++ symbols as
optional, but I didn't think in a freeze was a good time to do that.

Bug#856151: RFS: gexiv2/0.10.4-2

[Sean Whitton]

control: tag -1 +moreinfo

Dear Jason,

Thank you for fixing the changelog.

I built the package and then ran Lintian.  It produces an error

E: libgexiv2-2:
symbols-file-contains-current-version-with-debian-revision on symbol 
_ZN5Exiv28XmpdatumaSIlEERS0_RKT_@Base and 1 others

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#856198: RFS: entropybroker/2.9-0.1 [RC] [NMU]

[Thorsten Alteholz]

On Sun, 26 Feb 2017, Gianfranco Costamagna wrote:

I am looking for a sponsor for my package "entropybroker"


This is rather strange.


BTW since Thorsten is the maintainer, and he is active, an NMU for a bug opened 
some
hours ago would be *totally* unappropriate.


Indeed, it is also the wrong solution.


Thorsten, of course the package is up to you, and the review is just in case you say 
"go
ahead and sponsor it" :)


On the contrary I say: Thanks for the work, but no thanks.

  Thorsten

Bug#856198: RFS: entropybroker/2.9-0.1 [RC] [NMU]

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

>I am looking for a sponsor for my package "entropybroker"



I can sponsor it if you get

1) an unblock bug approved
or
2) a targeted fixes for the RC bug.

I admit, the new release is mostly a "fix manpage, merge debian patches, fix rc 
bug, release"

but I would like to hear Release Team before giving a sign/upload

thanks for the patch and the nice work,


BTW since Thorsten is the maintainer, and he is active, an NMU for a bug opened 
some
hours ago would be *totally* unappropriate.
I'm owning the bug and tagging it moreinfo to avoid people accidentally 
sponsoring it :)

Thorsten, of course the package is up to you, and the review is just in case 
you say "go
ahead and sponsor it" :)
(my bad, I reviewed the package before looking at the RC bug and Maintainer 
field, and
it was too late to delete the email :p)


Gianfranco

Bug#845710: removed Vcs fields

[Tim Kuijsten]

On Fri, Feb 17, 2017 at 11:36:57PM +0900, Roger Shimizu wrote:
> On Thu, Feb 9, 2017 at 10:59 PM, Tim Kuijsten  wrote:
> > The Vcs-* links are removed since the debian directory is not included in 
> > the official repo.
> 
> I guess you misunderstand Sean's words.
> 
> There're two types of Vcs:
>  - upstream Vcs, which should not contain debian/ folder. (but if it
> contains debian/, it should still have way to work out)
>  - debian packaing Vcs, which Sean requested you to make
> 
> BTW. Vcs-* in d/control file is the 2nd type listed above.
> So please create one with your packaging files, and add the Vcs info
> back to d/control.

For the sake of simplicity I have added the debian directory to my main 
repository. Hope this is good enough.

-Tim

> Thanks!
> 
> Cheers,
> -- 
> Roger Shimizu, GMT +9 Tokyo
> PGP/GPG: 4096R/6C6ACD6417B3ACB1

Re: Packaging a gui app

[matt jones]

Thanks for the tips on this. I am brand new to packaging Debian products. The 
product I am working on packaging is 
https://github.com/keepassxreboot/keepassxc. My main goal with packaging it is 
because I am a big fan of it and I keep my systems clean so I want a pure 
Debian package that I can install. Hopefully others will find it useful as 
well. I am following the new maintainers guide for now and I don’t see anything 
too taxing in it beyond the work needed and the care that needs to be taken to 
make sure it is done right.

Right now I am still at the make sure it installs cleanly stage. I spun up a 
clean Jessie box in vagrant and have been hammering at the upstream install 
instructions to ensure they are valid for building from source rather than 
using the pre-built packages. Thanks for tips on this, I had completely forgort 
about connecting to a remote server.

-- 
Matt Jones @CaffeinatedEng


On 2/26/17, 11:15 AM, "Christian Seiler"  wrote:

On 02/26/2017 04:52 PM, The Wanderer wrote:
> On 2017-02-26 at 10:47, Ghislain Vaillant wrote:
> 
>> On Sun, 2017-02-26 at 10:15 -0500, matt jones wrote:
>>
>>> I am packaging a gui that has dependencies for qt and such. How do
>>> I go about ensuring that X is available as well? Do I list that as
>>> a dependency as well. The upstream maintainers don’t call it out
>>> specifically but it is understood. Links to docs are always
>>> welcome.
>>
>> Usually, the toolkit your application depends on (here Qt), will
>> bring the necessary dependencies for you. So you don't need to care
>> about X.
> 
> I recall that historically the rule was "you don't depend on having X
> packages installed" regardless, on the grounds that it is or was
> possible to connect to an X instance running on a different machine (it
> is called "the X server", after all) - but I don't spot that in current
> policy, and I do seem to remember reading discussion about repealing
> that rule on the grounds that doing this hasn't actually _worked_ in
> modern X for years if not longer.

I'm not saying it works great, and X forwarding has its problems, but
in general from my experience most programs do still work when forwarded
via X11. Heck, even Firefox works. And I know plenty of people that use
X11 forwarding in various ways (though not necessarily Firefox). Even
OpenGL stuff works, it just falls back to software rendering via Mesa in
that case.

>From my POV, packaging a GUI application is simple in general:

 - dh_shlibdeps will take care of all the dependencies via shared
   libraries (e.g. Qt) automatically, so you don't have to care about
   that directly

 - if you require certain plugins for a library you are using to be
   available, Depend: or Recommend: those packages (depending on how
   fatal their non-availability is)

 - if you need some framework such as KDE, Depend: on that (for
   example, KDE5 packages typically require a Depends: kde-runtime)

 - if you require a DBus bus to be around, Depend: dbus-x11
   (or Recommend: it if the non-availability is non-fatal)

 - if the package contains any scripts, make sure that any tools
   required from those scripts are in your dependencies (since they
   won't be auto-detected at build time)

Regards,
Christian

Re: Attempt to build BioD blocked by undeaD and missing module string (Was: How to build D source)

[Andreas Tille]

Hi,

On Sun, Feb 26, 2017 at 05:10:11PM +0100, Matthias Klumpp wrote:
> >> I just added "dub run" to debian/rules.
> >
> > I think you want "dub build" instead.
> 
> Yes, `dub build` is the right thing to do,

Fine.

> but in general I would
> strongly recommend to not use dub at all for Debian packaging.
> It has a lot of issues which make it a pain to work with in the
> context of Debian packaging, some of the issues are summarized at
> https://gist.github.com/ximion/fe6264481319dd94c8308b1ea4e8207a
> 
> I did packaging with dub once, a d/rules file would look similar to
> this: 
> https://anonscm.debian.org/git/pkg-packagekit/appstream-generator.git/tree/debian/rules?id=60dcc4c6e716f8ddbcf549f40bad0f5b800cb398
> 
> No package in Debian uses dub however, because it creates long-term
> maintenance pain. The much better option is to submit a patch upstream
> to build with either Automake, cmake or Meson. I strongly recommend
> Meson here, because Meson configuration is very easy to write and it's
> D support is already there (while it needs to be added to cmake with a
> lot of macros, and Automake is just annoying to use in general).
> 
> Here is an example for a simple Meson build configuration for a very
> small static D library:
> https://github.com/repeatedly/mustache-d/commit/4e694202b02014871a767782606bacaf1422a3e2

I'd fully trust your insight here but I admit Meson is totally new to me
and crafting a Meson control file for a library without having any idea
about D is a bit over my current status of knowledge.  So I either need
to use what upstream provides or ask here for help.

> > Ah, I was looking at upstream git master which contains this dependency
> > in dub.json:
> > "dependencies": {
> > "undead": "~>1.0.6"
> > },
> >
> >> bio/bam/bai/indexing.d(38,8): Error: module string is in file 
> >> 'core/std/c/string.d' which cannot be read
> >>
> >> This seems to be critical.  Do you have any hint?
> >
> > Maybe this PR would help?
> > https://github.com/biod/BioD/pull/23
> 
> Which D compiler do you use for building? LDC or GDC? I would
> recommend LDC here, since it supports the latest D runtime and
> standard library versions, while GDC is lagging behind a lot.
> The ideal solution here would be to port BioD away from using
> deprecated stuff, but I am not sure how feasible this is - would be
> nice to at least ask upstream on whether they accept patches for it.
> Otherwise, undeaD needs to be in Debian first.

I admit I have no idea how to do this.  Its the first time I see D code
at all.  May be it would be even better if the Debian D team could
package BioD which I need for some other package as a pre-dependency.
 
Kind regards

  Andreas. 

-- 
http://fam-tille.de

Re: Packaging a gui app

[Christian Seiler]

On 02/26/2017 04:52 PM, The Wanderer wrote:
> On 2017-02-26 at 10:47, Ghislain Vaillant wrote:
> 
>> On Sun, 2017-02-26 at 10:15 -0500, matt jones wrote:
>>
>>> I am packaging a gui that has dependencies for qt and such. How do
>>> I go about ensuring that X is available as well? Do I list that as
>>> a dependency as well. The upstream maintainers don’t call it out
>>> specifically but it is understood. Links to docs are always
>>> welcome.
>>
>> Usually, the toolkit your application depends on (here Qt), will
>> bring the necessary dependencies for you. So you don't need to care
>> about X.
> 
> I recall that historically the rule was "you don't depend on having X
> packages installed" regardless, on the grounds that it is or was
> possible to connect to an X instance running on a different machine (it
> is called "the X server", after all) - but I don't spot that in current
> policy, and I do seem to remember reading discussion about repealing
> that rule on the grounds that doing this hasn't actually _worked_ in
> modern X for years if not longer.

I'm not saying it works great, and X forwarding has its problems, but
in general from my experience most programs do still work when forwarded
via X11. Heck, even Firefox works. And I know plenty of people that use
X11 forwarding in various ways (though not necessarily Firefox). Even
OpenGL stuff works, it just falls back to software rendering via Mesa in
that case.

>From my POV, packaging a GUI application is simple in general:

 - dh_shlibdeps will take care of all the dependencies via shared
   libraries (e.g. Qt) automatically, so you don't have to care about
   that directly

 - if you require certain plugins for a library you are using to be
   available, Depend: or Recommend: those packages (depending on how
   fatal their non-availability is)

 - if you need some framework such as KDE, Depend: on that (for
   example, KDE5 packages typically require a Depends: kde-runtime)

 - if you require a DBus bus to be around, Depend: dbus-x11
   (or Recommend: it if the non-availability is non-fatal)

 - if the package contains any scripts, make sure that any tools
   required from those scripts are in your dependencies (since they
   won't be auto-detected at build time)

Regards,
Christian

Re: [Pkg-d-devel] Attempt to build BioD blocked by undeaD and missing module string (Was: How to build D source)

[Matthias Klumpp]

Hello!

2017-02-26 15:19 GMT+01:00 James Cowgill :
> Hi,
>
> On 26/02/17 07:03, Andreas Tille wrote:
>> On Sat, Feb 25, 2017 at 10:01:17PM +, James Cowgill wrote:
>>> On 25/02/17 21:31, Andreas Tille wrote:
 I intend to package BioD[1] but I have no idea how to build the D code
 (and run the unit tests).  Considering BioD is a library I might need
 something like a dynamic lib and a development package, but may be this
 is different for D than in C.
>>>
>>> It looks like it uses "dub" as it's build system. Dub is packaged but
>>> has no users in the archive so you probably want to talk to the D
>>> language maintainers about it first to see what the correct way to
>>> handle this is.
>>
>> I just added "dub run" to debian/rules.
>
> I think you want "dub build" instead.

Yes, `dub build` is the right thing to do, but in general I would
strongly recommend to not use dub at all for Debian packaging.
It has a lot of issues which make it a pain to work with in the
context of Debian packaging, some of the issues are summarized at
https://gist.github.com/ximion/fe6264481319dd94c8308b1ea4e8207a

I did packaging with dub once, a d/rules file would look similar to
this: 
https://anonscm.debian.org/git/pkg-packagekit/appstream-generator.git/tree/debian/rules?id=60dcc4c6e716f8ddbcf549f40bad0f5b800cb398

No package in Debian uses dub however, because it creates long-term
maintenance pain. The much better option is to submit a patch upstream
to build with either Automake, cmake or Meson. I strongly recommend
Meson here, because Meson configuration is very easy to write and it's
D support is already there (while it needs to be added to cmake with a
lot of macros, and Automake is just annoying to use in general).

Here is an example for a simple Meson build configuration for a very
small static D library:
https://github.com/repeatedly/mustache-d/commit/4e694202b02014871a767782606bacaf1422a3e2

At time, D stuff in Debian (with the exception of LDC itself) uses
either Meson or Automake.

>>> I notice it depends on undead which will need packaging first.
>>
>> There are two kinds of messages:
>>
>> bio/bam/bai/indexing.d(33,8): Deprecation: module std.stream is deprecated - 
>> It will be removed from Phobos in October 2016. If you still need it, go to 
>> https://github.com/DigitalMars/undeaD
>>
>> This is what James seems to refer to - I'm not sure whether this is
>> critical for the build here.  I'd be willing to package undead if needed
>> but I'd prefer if some more skilled people would do so.
>
> Ah, I was looking at upstream git master which contains this dependency
> in dub.json:
> "dependencies": {
> "undead": "~>1.0.6"
> },
>
>> bio/bam/bai/indexing.d(38,8): Error: module string is in file 
>> 'core/std/c/string.d' which cannot be read
>>
>> This seems to be critical.  Do you have any hint?
>
> Maybe this PR would help?
> https://github.com/biod/BioD/pull/23

Which D compiler do you use for building? LDC or GDC? I would
recommend LDC here, since it supports the latest D runtime and
standard library versions, while GDC is lagging behind a lot.
The ideal solution here would be to port BioD away from using
deprecated stuff, but I am not sure how feasible this is - would be
nice to at least ask upstream on whether they accept patches for it.
Otherwise, undeaD needs to be in Debian first.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: Packaging a gui app

[The Wanderer]

On 2017-02-26 at 10:47, Ghislain Vaillant wrote:

> On Sun, 2017-02-26 at 10:15 -0500, matt jones wrote:
> 
>> I am packaging a gui that has dependencies for qt and such. How do
>> I go about ensuring that X is available as well? Do I list that as
>> a dependency as well. The upstream maintainers don’t call it out
>> specifically but it is understood. Links to docs are always
>> welcome.
> 
> Usually, the toolkit your application depends on (here Qt), will
> bring the necessary dependencies for you. So you don't need to care
> about X.

I recall that historically the rule was "you don't depend on having X
packages installed" regardless, on the grounds that it is or was
possible to connect to an X instance running on a different machine (it
is called "the X server", after all) - but I don't spot that in current
policy, and I do seem to remember reading discussion about repealing
that rule on the grounds that doing this hasn't actually _worked_ in
modern X for years if not longer.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Packaging a gui app

[Ghislain Vaillant]

On Sun, 2017-02-26 at 10:15 -0500, matt jones wrote:
> I am packaging a gui that has dependencies for qt and such. How do I go about 
> ensuring that X is available as well? Do I list that as a dependency as well. 
> The upstream maintainers don’t call it out specifically but it is understood. 
> Links to docs are always welcome.

Usually, the toolkit your application depends on (here Qt), will bring
the necessary dependencies for you. So you don't need to care about X.

Ghis

Re: Packaging a gui app

[Zoltan Gyarmati]

Dear Matt,

libqt5gui5 is already depending on the needed X libraries, so unless
your app is doing something tricky, you don't need to care about this.
But we can tell more if we see the application in question...


Regards,

Zoltan Gyarmati
https://zgyarmati.de

On 02/26/2017 04:15 PM, matt jones wrote:
>
> I am packaging a gui that has dependencies for qt and such. How do I
> go about ensuring that X is available as well? Do I list that as a
> dependency as well. The upstream maintainers don’t call it out
> specifically but it is understood. Links to docs are always welcome.
>
>  
>
> Thanks!
>
>  
>
> -- 
>
> Matt Jones @CaffeinatedEng
>
> Senior Infrastructure Engineer - Yieldbot Inc. 
>
> Co-Organizer - Boston Infrastructure Coders
> 
>
> Organizer - Metrowest Golang Meetup
> 
>
> https://linkedin.com/in/mattyjones
>
>  
>
>  
>



signature.asc
Description: OpenPGP digital signature

Re: Packaging a gui app

[Zoltan Gyarmati]

Dear Matt,

libqt5gui5 is already depending on the needed X libraries, so unless
your app is doing something tricky, you don't need to care about this.
But we can tell more if we see the application in question...


Regards,

Zoltan Gyarmati
https://zgyarmati.de

On 02/26/2017 04:15 PM, matt jones wrote:
>
> I am packaging a gui that has dependencies for qt and such. How do I
> go about ensuring that X is available as well? Do I list that as a
> dependency as well. The upstream maintainers don’t call it out
> specifically but it is understood. Links to docs are always welcome.
>
>  
>
> Thanks!
>
>  
>
> -- 
>
> Matt Jones @CaffeinatedEng
>
> Senior Infrastructure Engineer - Yieldbot Inc. 
>
> Co-Organizer - Boston Infrastructure Coders
> 
>
> Organizer - Metrowest Golang Meetup
> 
>
> https://linkedin.com/in/mattyjones
>
>  
>
>  
>

Packaging a gui app

[matt jones]

I am packaging a gui that has dependencies for qt and such. How do I go about 
ensuring that X is available as well? Do I list that as a dependency as well. 
The upstream maintainers don’t call it out specifically but it is understood. 
Links to docs are always welcome.

 

Thanks!

 

-- 

Matt Jones @CaffeinatedEng

Senior Infrastructure Engineer - Yieldbot Inc.

Co-Organizer - Boston Infrastructure Coders

Organizer - Metrowest Golang Meetup

https://linkedin.com/in/mattyjones

 

 

Re: Attempt to build BioD blocked by undeaD and missing module string (Was: How to build D source)

[James Cowgill]

Hi,

On 26/02/17 07:03, Andreas Tille wrote:
> On Sat, Feb 25, 2017 at 10:01:17PM +, James Cowgill wrote:
>> On 25/02/17 21:31, Andreas Tille wrote:
>>> I intend to package BioD[1] but I have no idea how to build the D code
>>> (and run the unit tests).  Considering BioD is a library I might need
>>> something like a dynamic lib and a development package, but may be this
>>> is different for D than in C.
>>
>> It looks like it uses "dub" as it's build system. Dub is packaged but
>> has no users in the archive so you probably want to talk to the D
>> language maintainers about it first to see what the correct way to
>> handle this is.
> 
> I just added "dub run" to debian/rules.

I think you want "dub build" instead.

>> I notice it depends on undead which will need packaging first.
> 
> There are two kinds of messages:
> 
> bio/bam/bai/indexing.d(33,8): Deprecation: module std.stream is deprecated - 
> It will be removed from Phobos in October 2016. If you still need it, go to 
> https://github.com/DigitalMars/undeaD
> 
> This is what James seems to refer to - I'm not sure whether this is
> critical for the build here.  I'd be willing to package undead if needed
> but I'd prefer if some more skilled people would do so.

Ah, I was looking at upstream git master which contains this dependency
in dub.json:
"dependencies": {
"undead": "~>1.0.6"
},

> bio/bam/bai/indexing.d(38,8): Error: module string is in file 
> 'core/std/c/string.d' which cannot be read
> 
> This seems to be critical.  Do you have any hint?

Maybe this PR would help?
https://github.com/biod/BioD/pull/23

None of these errors or warnings happen for me with the latest upstream
git.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#856151: RFS: gexiv2/0.10.4-2

[Jason Crain]

Control: tags -1 - moreinfo

On Sat, Feb 25, 2017 at 07:03:33PM -0700, Sean Whitton wrote:
> You are missing a # before the number of the bug you are closing in your
> changelog.

I've fixed the changelog entry.  I think I got it wrong because I
misread the gbp documentation on meta tags.  Fixed and reploaded to
mentors:

https://mentors.debian.net/debian/pool/main/g/gexiv2/gexiv2_0.10.4-2.dsc

Bug#856198: RFS: entropybroker/2.9-0.1 [RC] [NMU]

[Fabrice Dagorn]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "entropybroker"

 * Package name: entropybroker
   Version : 2.9-0.1
   Upstream Author : Folkert van Heusden
 * URL : https://www.vanheusden.com/entropybroker/
 * License : AGPL V3
   Section : utils

It builds those binary packages:

  entropybroker - infrastructure for distributing random numbers (entropy data)

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

 https://mentors.debian.net/package/entropybroker


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

  dget -x 
https://mentors.debian.net/debian/pool/main/e/entropybroker/entropybroker_2.9-0.1.dsc

Changes since the last upload:

  * Non-maintainer upload.
  * new upstream version : 2.9
  * 100% cpu use fixes (Closes: #856187)
  * remove patches merged upstream


Regards,
 Fabrice Dagorn

Bug#851756: telegram-desktop/1.0.12-1

[Mattia Rizzolo]

Hi,

sorry it took me some time to get to this, I've been hooked up by some
real life stuff...

On Mon, Feb 20, 2017 at 11:35:18PM +0300, Коля Гурьев wrote:
> Oh, but they have released a new version today.

few minutes/hours after this they released another one too, it seems :P
They took the whole "release early, release often" thing a bit too
seriously, IMHO u.U

> And also, how can I turn verbose CMake output off? I fear to miss an
> important GCC warning. But I don't want to interrupt compilation in this
> case.

umh, TBH I wouldn't know.  We usually *love* very verbose builds.
Outputting the whole gcc command is usually a good idea, as there are
tools checking the build logs for the presence of certain build flags
(see blhc and bls).
I *think* you could pass an extra -DCMAKE_VERBOSE_MAKEFILE=OFF to
verride the previous -DCMAKE_VERBOSE_MAKEFILE=ON passed by debhelper,
but if you want it, I'd like if you could put it behind a check for the
presence of a variable or something so you can do it only in your
system, so others keep getting the full log.
Besides, in case of failure the gcc call is priceless!

> > It's not a techinical thing, but more political, actually.  I want to
> > decide the license of what I write.
> > But what you did before was ok.
> 
> Well, I'm completely confused, sorry, then I brought it back.

If you want to say that licensing/copyright is a complicated mess,
you're right :)

> > This still need to take care of:
> > 
> > * spelling-error-in-binary (please upstream the fix)
> > * spelling-error-in-manpage
> > * desktop-entry-lacks-keywords-entry (please upstream the fix)
> 
> I'll make a pull request to upstream for fix keywords and encoding fields in
> .desktop file. It seems spelling errors in binary are related to log
> strings, those are not showed in user interface.

ACK, that's the right place to fix those :)

> As you perhaps noticed, my knowledge of English is not very well, and I
> don't know what the problem with the manpage.

Ack.  Yes, that "allow to" → "allow one to" is a bit tricky.
I sent you a PR for that.

> > > Hmm... It seems to be working. But lintian sill warnings about
> > > hardening-no-fortify-functions.
> > 
> > That usually means that something doesn't respect
> > CFLAGS/CXXFLAGS/CPPFLAGS & friends
> 
> Maybe this is a false positive...

I doubt it, very rarely it is…
But anyway, this is not important, let it be for an undefined future.

> > git check:
> > * pristine-tar is not pushed/updated (after some check, if you have
> >   pristine-tar-commit=True doing a `gbp buildpackage…` it does commit it
> >   by itself, in some cases.…)
> > * you have a lot of branch, including a "master" (which is HEAD) and a
> >   "debian", but it seems latter is abbandoned, and the actual
> >   debianization is on "master".  can you clean it up a bit?
> > * you have a weird looking tag tmp-old-debian
> > * you might want or not to push the upstream branch in your repo, your
> >   call, but if you don't let me suggest you don't call the debianization
> >   branch "master" ("debian" is cool, but please change HEAD).
> > * there is not upstream tag pushed for the last upstreams
> 
> I deleted all old branches, renamed current master to debian and pushed all
> new tags (I keep forgetting to run git push --tags ¯\_(ツ)_/¯ ).

Nice!

> I can't understand why pristine-tar is necessary if I could download an
> original tarball using uscan (or manually).

You probably little.  The gain for me is quite relevant, as for example
right now I'm connected through a 3G modem with limited bandwitdh; using
pristine-tar allowed me to download few KBs and get a several MB tarball
out; probably I could have lived by downloading the tarball anew, but it
is for example priceless while working on libreoffice-dictionaries,
where the tarballs are 70+ MB with very small changes across versions.
It mostly is a tool to help coworkers, but in the past it came handy
also for me, in a moment where I wanted to build several past versions
of a program and instead of downloading hundreds of MBs of tarballs I
could just `pristine-tar checkout` them out.

BTW, the name you used for the tarball you committed is unfortunate, as
a tool named `origtargz` (from devscripts) can detect it.  It would be
nice if you could commit the renamed/symlinked one made by
$srcname_$ver.orig.tar.gz
that you surely have around somehow, given that you need it to actually
build the package.

> Pristine-tar seems to commit binary blobs into git repo. Why, in
> thunder?

AFAIK It commits the small delta that there is between what
`git archive` produces and the actual tarball.  It should always be
pretty small.  Besides, the repository is already full of binary blobs,
with all those images :P

> What the profit if I still musta download the tarball?

You must download the tarball only once, to fill it in, then never
again.
pristine-tar came handy recently to me while switching computers, where
I cloned all repositories, and I didn't