Bug#862875: RFS: libzc/0.3.1-1 [ITP] -- fast zip cracking library

2017-10-15 Thread Adam Borowski 
On Fri, Sep 15, 2017 at 10:47:29PM -0400, Marc Ferland wrote:
> On Mon, Sep 11, 2017 at 4:09 PM, Andrey Rahmatullin  wrote:
> > d/copyright says "License: GPL-3" instead of GPL-3+.
> > lib/pthread_barrier.h and m4/ax_pthread.m4 should have separate entries in
> > d/copyright.
> > Otherwise the package looks good.
> 
> Fixed d/copyright and other warnings reported by 'scan-copyright' with
> latest version:
> 
> https://mentors.debian.net/debian/pool/main/libz/libzc/libzc_0.3.5-1.dsc

The package fails to build on most architectures, with a timeout in the
testsuite:

PASS: pwstream
PASS: file
PASS: basic
PASS: dictionary
PASS: plaintext
PASS: plaintext_password
FAIL: reduce
PASS: bruteforce

   zc 0.3.5: tests/test-suite.log


# TOTAL: 8
# PASS:  7
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: reduce


Running suite(s): reduce
66%: Checks: 3, Failures: 0, Errors: 1
check_reduce.c:60:E:Core:test_can_generate_next_array_from_plaintext:0: (after 
this point) Test timeout expired
FAIL reduce (exit status: 1)


Testsuite summary for zc 0.3.5

# TOTAL: 8
# PASS:  7
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ I was born a dumb, ugly and work-loving kid, then I got swapped on
⠈⠳⣄ the maternity ward.

Re: BTS and unreleased changelog entries

2017-10-15 Thread Adam Borowski 
On Mon, Oct 16, 2017 at 11:54:20AM +1100, Ben Finney wrote:
> Ross Vandegrift  writes:
> > On Sun, Oct 15, 2017 at 12:14:59AM +0200, Mattia Rizzolo wrote:
> > > Rather, I have a counter-question for you: why are you keeping
> > > entries for unreleased uploads in d/changelog? I find it rather
> > > confusing, mostly useless and with no real upsides as opposed to
> > > cohalesce the entries.
> >
> > Good question. I guess I think of a changelog as history - so changes
> > I made on 1.15 go with 1.15 whether it was released or not.
> 
> Thanks for explaining your perspective.
> 
> That perspective, I think, does not match the stated purpose for the
> Debian package changelog: to inform *recipients* of the package about
> changes between *releases* of that package.

It's arguable what to do when the Debian packaging is being used _publicly_
outside Debian.  In that case, I'd say it's reasonable to allow history of
such unofficial releases.

But for your local WIP?  No way.

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ I was born a dumb, ugly and work-loving kid, then I got swapped on
⠈⠳⣄ the maternity ward.

Re: BTS and unreleased changelog entries

2017-10-15 Thread Ben Finney 
Ross Vandegrift  writes:

> On Sun, Oct 15, 2017 at 12:14:59AM +0200, Mattia Rizzolo wrote:
> > Rather, I have a counter-question for you: why are you keeping
> > entries for unreleased uploads in d/changelog? I find it rather
> > confusing, mostly useless and with no real upsides as opposed to
> > cohalesce the entries.
>
> Good question. I guess I think of a changelog as history - so changes
> I made on 1.15 go with 1.15 whether it was released or not.

Thanks for explaining your perspective.

That perspective, I think, does not match the stated purpose for the
Debian package changelog: to inform *recipients* of the package about
changes between *releases* of that package.

So, a further question: Why did “changes made on 1.15” not simply
continue accumulating changes? You say it was not released; that should
mean the changelog entry is not closed, because a changelog entry
documents a *release* of the Debian package.

> But if I think of the changelog as telling others about changes in a
> release, then it makes sense to squash them.

Yes, that's the purpose specified for the Debian package changelog.

I agree with others that, if you want to document history organised
incompatibly with the Debian changelog, you need ot record that history
somewhere else. For example the VCS commit log, or a ‘debian/HISTORY’
file, or something else.

> Either way, I try to avoid it now. So it's really just dealing with
> the previous entries.

For already-released versions you will need to deal with closing those
bugs manually anyway.

> Sounds like I just need one upload to be done with an early enough -v.
> And then avoid keeping unreleased versions around in the future.

Well, definitely keep them around; just continue editing the
“UNRELEASED” changelog entry, until it's time to make a release. After
that, make a new empty changelog entry for continuing development.

-- 
 \   “Come on, if your religion is so vulnerable that a little bit |
  `\   of disrespect is going to bring it down, it's not worth |
_o__)   believing in, frankly.” —Terry Gilliam, 2005-01-18 |
Ben Finney

Bug#878682: marked as done (RFS: bitz-server/1.0.0-5)

2017-10-15 Thread Debian Bug Tracking System 
Your message dated Sun, 15 Oct 2017 21:55:17 +0200
with message-id <20171015195517.usimvxzsn4nhv...@angband.pl>
and subject line Re: Bug#878682: RFS: bitz-server/1.0.0-5
has caused the Debian Bug report #878682,
regarding RFS: bitz-server/1.0.0-5
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.)


-- 
878682: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878682
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 "bitz-server"


   Package name: bitz-server
   Version : 1.0.0-4
   Upstream Author : Uditha Atukorala 
   URL : https://github.com/uditha-atukorala/bitz-server
   License : GPL-3+
   Section : net

  It builds those binary packages:

   bitz-server - ICAP server (RFC 3507) implementation in C++
 bitz-server-doc - ICAP server (RFC 3507) implementation in C++ (Documentation)
 libicap-dev - ICAP server (RFC 3507) implementation in C++ (development files)
 libicap1   - ICAP server (RFC 3507) implementation in C++ (library files)



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

  https://mentors.debian.net/package/bitz-server


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

dget -x 
https://mentors.debian.net/debian/pool/main/b/bitz-server/bitz-server_1.0.0-5.dsc
git: 
https://anonscm.debian.org/cgit/collab-maint/bitz-server.git?h=release%2F1.0.0-5

  
  Changes since the last upload:

  * Renew symbols files.



  Regards,
   Jörg Frings-Fürst


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB
Wire:  @joergfringsfuerst
Skype: joergpenguin
Ring:  jff

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


signature.asc
Description: This is a digitally signed message part
--- End Message ---
--- Begin Message ---
On Sun, Oct 15, 2017 at 08:55:58PM +0200, Jörg Frings-Fürst wrote:
>Package name: bitz-server
>Version : 1.0.0-4

>   Changes since the last upload:
> 
>   * Renew symbols files.

Unyay C++ symbols.

✓

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ I was born a dumb, ugly and work-loving kid, then I got swapped on
⠈⠳⣄ the maternity ward.--- End Message ---

Bug#878682: RFS: bitz-server/1.0.0-5

2017-10-15 Thread Jörg Frings-Fürst 
Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "bitz-server"


   Package name: bitz-server
   Version : 1.0.0-4
   Upstream Author : Uditha Atukorala 
   URL : https://github.com/uditha-atukorala/bitz-server
   License : GPL-3+
   Section : net

  It builds those binary packages:

   bitz-server - ICAP server (RFC 3507) implementation in C++
 bitz-server-doc - ICAP server (RFC 3507) implementation in C++ (Documentation)
 libicap-dev - ICAP server (RFC 3507) implementation in C++ (development files)
 libicap1   - ICAP server (RFC 3507) implementation in C++ (library files)



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

  https://mentors.debian.net/package/bitz-server


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

dget -x 
https://mentors.debian.net/debian/pool/main/b/bitz-server/bitz-server_1.0.0-5.dsc
git: 
https://anonscm.debian.org/cgit/collab-maint/bitz-server.git?h=release%2F1.0.0-5

  
  Changes since the last upload:

  * Renew symbols files.



  Regards,
   Jörg Frings-Fürst


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB
Wire:  @joergfringsfuerst
Skype: joergpenguin
Ring:  jff

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

Re: BTS and unreleased changelog entries

2017-10-15 Thread Ross Gammon 
On 10/15/2017 05:36 AM, Ross Vandegrift wrote:
> Good question.  I guess I think of a changelog as history - so changes I
> made on 1.15 go with 1.15 whether it was released or not.  But if I
> think of the changelog as telling others about changes in a release,
> then it makes sense to squash them.

It sounds like you need to maintain your packages in a Version Control
system (e.g. git).

That will give you plenty of history about your changes/tests/debugging.

As you say, the changelog is for telling others what changed between
releases.

Cheers,

Ross



signature.asc
Description: OpenPGP digital signature

Re: Bug#869926: RFS: oprofile/1.2.0-1 [ITP]

2017-10-15 Thread Andrey Rahmatullin 
On Sat, Oct 14, 2017 at 11:15:53PM -0300, Roberto Oliveira wrote:
> > > Thanks Roberto.
> > >
> > > wRar, do you still any concern about this package?
> > Nope, uploaded. Thank you Roberto.
> 
> Thanks for uploading the package!
> 
> I saw in ftp-master [1] that the package was built but it is only
> showing for amd64, however the package architecture is linux-any.
While the package is in NEW it's not built anywhere.

-- 
WBR, wRAR


signature.asc
Description: PGP signature