Bug#855171: closed by Adam Borowski <kilob...@angband.pl> (Re: Bug#855171: RFS: tlf/1.3.0-1)

2017-02-16 Thread Ervin Hegedüs
Hi Adam,


(I didn't get your mail from you, just through the bug
notification...)

On Fri, Feb 17, 2017 at 02:06:04AM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the sponsorship-requests package:
> 
> #855171: RFS: tlf/1.3.0-1
> 
> It has been closed by Adam Borowski <kilob...@angband.pl>.
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Adam Borowski 
> <kilob...@angband.pl> by
> replying to this email.

> Date: Fri, 17 Feb 2017 03:03:27 +0100
> From: Adam Borowski <kilob...@angband.pl>
> To: 855171-d...@bugs.debian.org
> Subject: Re: Bug#855171: RFS: tlf/1.3.0-1
> 
> On Thu, Feb 16, 2017 at 10:00:43AM +0100, Ervin Hegedüs wrote:
> > > experimental or wait until freeze end.
> > 
> > right - I'll do it.
> 
> And 'ere we go -- uploaded.

thanks for your help,
 
> > > > I can't change it. But I can make it for all systems: for stable,
> > > > testing and sid with same version number. Is that a solution?
> > > You can't update packages in stable or testing.
> 
> Other than targetted fixes for severity:important or higher bugs, that is,
> with a special procedure.

is that the reason, that it could't go to testing?
 
> > Anyway, now what will the next step with Tlf package?
> 
> It's in experimental now, where sadly it will see far less exposure than it
> would in unstable, but an user who wants the new version can still get it.
> 
> Packages don't migrate from experimental, so anywhen between stretch's
> release and buster's freeze you'll have to make an upload to unstable.
> Even a no-change bump will do, but looking at your release frequency, you'll
> have something new by then.

and what should I do for this package would part of the testing
release?

There is the Hamlib package (collection), it's more important to
users can get... And of course, I should make Tlf again.


Thanks,


a.
 



Bug#855171: RFS: tlf/1.3.0-1

2017-02-16 Thread Ervin Hegedüs
Hi,

On Thu, Feb 16, 2017 at 01:53:59PM +0500, Andrey Rahmatullin wrote:
> On Thu, Feb 16, 2017 at 09:50:32AM +0100, Ervin Hegedüs wrote:
> > > > > > > > I'm working on another (hamradio related) package(s)... Also
> > > > > > > > should I wait with them?
> > > > > > > With all packages already existing in testing.
> > > > > > 
> > > > > > I'm sorry, but I don't understand this really...
> > > > > What part of it? The reasons written by Adam above apply to all 
> > > > > packages
> > > > > that exist both in testing and unstable.
> > > > 
> > > > * hamlib - it exists in stable, testing and unstable, but it
> > > >   released a new version with several new features
> > > > * grig   - also exists in all systems, but the package only has
> > > >   a small modification: it has a desktop file...
> > > It doesn't matter what changes will you put in sid. What matters is that
> > > when testing and sid contain different versions of a package it's
> > > impossible to update the package in testing by uploading the update to
> > > sid.
> > 
> > Ok, but what's the solution?
> experimental or wait until freeze end.

right - I'll do it.

> > The Hamlib has a new version number
> The upstream version doesn't matter. The full package version does.

I'ld like to follow the upstream versioning, so that will a new
package version.
 
> > I can't change it. But I can make it for all systems: for stable,
> > testing and sid with same version number. Is that a solution?
> You can't update packages in stable or testing.

ok, thanks.


Anyway, now what will the next step with Tlf package?


Thanks,

Ervin
 



Bug#855171: RFS: tlf/1.3.0-1

2017-02-16 Thread Andrey Rahmatullin
On Thu, Feb 16, 2017 at 09:50:32AM +0100, Ervin Hegedüs wrote:
> > > > > > > I'm working on another (hamradio related) package(s)... Also
> > > > > > > should I wait with them?
> > > > > > With all packages already existing in testing.
> > > > > 
> > > > > I'm sorry, but I don't understand this really...
> > > > What part of it? The reasons written by Adam above apply to all packages
> > > > that exist both in testing and unstable.
> > > 
> > > * hamlib - it exists in stable, testing and unstable, but it
> > >   released a new version with several new features
> > > * grig   - also exists in all systems, but the package only has
> > >   a small modification: it has a desktop file...
> > It doesn't matter what changes will you put in sid. What matters is that
> > when testing and sid contain different versions of a package it's
> > impossible to update the package in testing by uploading the update to
> > sid.
> 
> Ok, but what's the solution?
experimental or wait until freeze end.

> The Hamlib has a new version number
The upstream version doesn't matter. The full package version does.

> I can't change it. But I can make it for all systems: for stable,
> testing and sid with same version number. Is that a solution?
You can't update packages in stable or testing.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#855171: RFS: tlf/1.3.0-1

2017-02-16 Thread Ervin Hegedüs
Hi,

On Thu, Feb 16, 2017 at 01:47:23PM +0500, Andrey Rahmatullin wrote:
> On Thu, Feb 16, 2017 at 09:41:13AM +0100, Ervin Hegedüs wrote:
> > > > > > I'm working on another (hamradio related) package(s)... Also
> > > > > > should I wait with them?
> > > > > With all packages already existing in testing.
> > > > 
> > > > I'm sorry, but I don't understand this really...
> > > What part of it? The reasons written by Adam above apply to all packages
> > > that exist both in testing and unstable.
> > 
> > * hamlib - it exists in stable, testing and unstable, but it
> >   released a new version with several new features
> > * grig   - also exists in all systems, but the package only has
> >   a small modification: it has a desktop file...
> It doesn't matter what changes will you put in sid. What matters is that
> when testing and sid contain different versions of a package it's
> impossible to update the package in testing by uploading the update to
> sid.

Ok, but what's the solution?

The Hamlib has a new version number, I can't change it. But I can
make it for all systems: for stable, testing and sid with same
version number. Is that a solution?


Regards,

Ervin



Bug#855171: RFS: tlf/1.3.0-1

2017-02-16 Thread Andrey Rahmatullin
On Thu, Feb 16, 2017 at 09:41:13AM +0100, Ervin Hegedüs wrote:
> > > > > I'm working on another (hamradio related) package(s)... Also
> > > > > should I wait with them?
> > > > With all packages already existing in testing.
> > > 
> > > I'm sorry, but I don't understand this really...
> > What part of it? The reasons written by Adam above apply to all packages
> > that exist both in testing and unstable.
> 
> * hamlib - it exists in stable, testing and unstable, but it
>   released a new version with several new features
> * grig   - also exists in all systems, but the package only has
>   a small modification: it has a desktop file...
It doesn't matter what changes will you put in sid. What matters is that
when testing and sid contain different versions of a package it's
impossible to update the package in testing by uploading the update to
sid.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#855171: RFS: tlf/1.3.0-1

2017-02-16 Thread Ervin Hegedüs
Hi Andrey,

On Thu, Feb 16, 2017 at 01:33:25PM +0500, Andrey Rahmatullin wrote:
> On Thu, Feb 16, 2017 at 09:29:02AM +0100, Ervin Hegedüs wrote:
> > > > I'm working on another (hamradio related) package(s)... Also
> > > > should I wait with them?
> > > With all packages already existing in testing.
> > 
> > I'm sorry, but I don't understand this really...
> What part of it? The reasons written by Adam above apply to all packages
> that exist both in testing and unstable.

* hamlib - it exists in stable, testing and unstable, but it
  released a new version with several new features
* grig   - also exists in all systems, but the package only has
  a small modification: it has a desktop file...


Regards,

Ervin



Bug#855171: RFS: tlf/1.3.0-1

2017-02-16 Thread Andrey Rahmatullin
On Thu, Feb 16, 2017 at 09:29:02AM +0100, Ervin Hegedüs wrote:
> > > I'm working on another (hamradio related) package(s)... Also
> > > should I wait with them?
> > With all packages already existing in testing.
> 
> I'm sorry, but I don't understand this really...
What part of it? The reasons written by Adam above apply to all packages
that exist both in testing and unstable.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#855171: RFS: tlf/1.3.0-1

2017-02-16 Thread Ervin Hegedüs
Hi Andrey,

thanks for the helpful answer,

On Thu, Feb 16, 2017 at 12:30:23PM +0500, Andrey Rahmatullin wrote:
> On Thu, Feb 16, 2017 at 08:18:44AM +0100, Ervin Hegedüs wrote:
> > > However, are you sure you want this uploaded to unstable during freeze?  
> > > It
> > > will make it really unpleasant to fix anything targetted at stretch; and
> > > also make the Release Team unhappy.  You don't want them unhappy.
> > > 
> > > Thus, wouldn't experimental be better for now?
> > 
> > I'm really sorry, but I just could make it now... so... what
> > should I do now?
> > 
> > Delete the uploaded package, and wait till the end of the freeze?
> Change the distribution in the changelog, add a line "Upload to
> experimental" and reupload the package.

done - I've changed the distribution to "experimental", and put
the line what you wrote.


> > I'm working on another (hamradio related) package(s)... Also
> > should I wait with them?
> With all packages already existing in testing.

I'm sorry, but I don't understand this really...


Regards,

a.



Bug#855171: RFS: tlf/1.3.0-1

2017-02-15 Thread Andrey Rahmatullin
On Thu, Feb 16, 2017 at 08:18:44AM +0100, Ervin Hegedüs wrote:
> > However, are you sure you want this uploaded to unstable during freeze?  It
> > will make it really unpleasant to fix anything targetted at stretch; and
> > also make the Release Team unhappy.  You don't want them unhappy.
> > 
> > Thus, wouldn't experimental be better for now?
> 
> I'm really sorry, but I just could make it now... so... what
> should I do now?
> 
> Delete the uploaded package, and wait till the end of the freeze?
Change the distribution in the changelog, add a line "Upload to
experimental" and reupload the package.

> I'm working on another (hamradio related) package(s)... Also
> should I wait with them?
With all packages already existing in testing.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#855171: RFS: tlf/1.3.0-1

2017-02-15 Thread Ervin Hegedüs
Hi Adam,

On Thu, Feb 16, 2017 at 01:40:32AM +0100, Adam Borowski wrote:
> On Tue, Feb 14, 2017 at 11:17:46PM +0100, Ervin Hegedüs wrote:
> > I am looking for a sponsor for my package "tlf"
> > 
> > Package name: tlf
> > Version : 1.3.0-1
> 
> > Changes since the last upload:
> > 
> >   * New upstream version.
> >   * Added native Fldigi interface depend libs to control file.
> >   * Added new uploader to control file.
> >   * Added native Fldigi interface switch to rules file.
> >   * Changed upstream location in README.source file.
> >   * Removed watch file.
> >   * Removed previous patches/spelling-fixes.patch - all of them
> > were applied in upstream.
> >   * Added new patches/spelling-fixes.patch, based on the
> > lintian's messages.
> >   * Added all copyright owners from sources.
> 
> Looks good.

thanks,

> However, are you sure you want this uploaded to unstable during freeze?  It
> will make it really unpleasant to fix anything targetted at stretch; and
> also make the Release Team unhappy.  You don't want them unhappy.
> 
> Thus, wouldn't experimental be better for now?

I'm really sorry, but I just could make it now... so... what
should I do now?

Delete the uploaded package, and wait till the end of the freeze?

I'm working on another (hamradio related) package(s)... Also
should I wait with them?


Regards,


a. 



Bug#855171: RFS: tlf/1.3.0-1

2017-02-15 Thread Adam Borowski
On Tue, Feb 14, 2017 at 11:17:46PM +0100, Ervin Hegedüs wrote:
> I am looking for a sponsor for my package "tlf"
> 
> Package name: tlf
> Version : 1.3.0-1

> Changes since the last upload:
> 
>   * New upstream version.
>   * Added native Fldigi interface depend libs to control file.
>   * Added new uploader to control file.
>   * Added native Fldigi interface switch to rules file.
>   * Changed upstream location in README.source file.
>   * Removed watch file.
>   * Removed previous patches/spelling-fixes.patch - all of them
> were applied in upstream.
>   * Added new patches/spelling-fixes.patch, based on the
> lintian's messages.
>   * Added all copyright owners from sources.

Looks good.

However, are you sure you want this uploaded to unstable during freeze?  It
will make it really unpleasant to fix anything targetted at stretch; and
also make the Release Team unhappy.  You don't want them unhappy.

Thus, wouldn't experimental be better for now?


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11



Bug#855171: RFS: tlf/1.3.0-1

2017-02-14 Thread Ervin Hegedüs
Package: sponsorship-requests
Severity: normal 

Dear mentors,

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

Package name: tlf
Version : 1.3.0-1
Upstream Author : Ervin Hegedus 
URL : www.hs-mittweida.de/tb/tlf-1.3.0.tar.gz
License : GPL-2+
Section : hamradio

It builds those binary packages:

  tlf   - console based ham radio contest logger

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

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


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

  dget -x https://mentors.debian.net/debian/pool/main/t/tlf/tlf_1.3.0-1.dsc

More information about tlf can be obtained from
https://tlf.github.io.


Changes since the last upload:

  * New upstream version.
  * Added native Fldigi interface depend libs to control file.
  * Added new uploader to control file.
  * Added native Fldigi interface switch to rules file.
  * Changed upstream location in README.source file.
  * Removed watch file.
  * Removed previous patches/spelling-fixes.patch - all of them
were applied in upstream.
  * Added new patches/spelling-fixes.patch, based on the
lintian's messages.
  * Added all copyright owners from sources.



Regards,
Ervin Hegedüs

-- 
I � UTF-8