Bug#948263: RFS: ibus-table-myanmar/0.0-1 -- ibus-table input method: Myanmar (dummy package)

2020-01-05 Thread Ko Ko Ye` 
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "ibus-table-myanmar"

 * Package name: ibus-table-myanmar
   Version : 0.0-1
   Upstream Author : kokoye2007 
 * URL : https://github.com/ibus/ibus/wiki
 * License : GPL-3.0
 * Vcs : https://github.com/kokoye2007/ibus-table-myanmar
   Section : utils

It builds those binary packages:

  ibus-table-myanmar - ibus-table input method: Myanmar (dummy package)
  ibus-table-burmese - ibus-table input method: Burmese
  ibus-table-zawgyi - ibus-table input method: Zawgyi

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

  https://mentors.debian.net/package/ibus-table-myanmar

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

  dget -x
https://mentors.debian.net/debian/pool/main/i/ibus-table-myanmar/ibus-table-myanmar_0.0-1.dsc

Changes since the last upload:

   * Debian Revision 1

Regards,

Bug#948262: RFS: ibus-keymagic/1.4-1 -- keymagic engine for IBus

2020-01-05 Thread Ko Ko Ye` 
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "ibus-keymagic"
its multi language support advance keyboard with ibus plugins
they can own keyboard and multi os support.
keymagic.net at you can see many languages and keyboard.
Linux Windows and Mac

Windows and Mac at Keymagic.net
Ubuntu Linux have PPA at ppa:kokoye2007/ppa
other linux distro for ubuntumm.sf.net at uploaded.
also try for other official repo like arch and fedora.
guide on
https://www.youtube.com/playlist?list=PL1EDkyTdWxl5RKymdn9wdNvZ6ADKtUmcQ

Help me for my contribution to perfect and allow into DFSG community.

 * Package name: ibus-keymagic
   Version : 1.4-1
   Upstream Author : kokoye2007 
 * URL : https://keymagic.net
 * License : GPL-2.0+
 * Vcs : https://git.launchpad.net/ibus-keymagic
   Section : utils

It builds those binary packages:

  ibus-keymagic - keymagic engine for IBus
  ibus-keymagic-ayar-phonetic - ibus keymagic ayar-phonetic;
  ibus-keymagic-beolssalba - ibus keymagic beolssalba;
  ibus-keymagic-cessalba - ibus keymagic cessalba;
  ibus-keymagic-ddeolssalba - ibus keymagic ddeolssalba;
  ibus-keymagic-gugeolssalba - ibus keymagic gugeolssalba;
  ibus-keymagic-khmer-nida - ibus keymagic khmer-nida;
  ibus-keymagic-loringian-miu - ibus keymagic loringian-miu;
  ibus-keymagic-malayalam-inscript - ibus keymagic malayalam-inscript;
  ibus-keymagic-malayalam-mozhi - ibus keymagic malayalam-mozhi;
  ibus-keymagic-meolssalba - ibus keymagic meolssalba;
  ibus-keymagic-mon-anonta - ibus keymagic mon-anonta;
  ibus-keymagic-monbur - ibus keymagic monbur;
  ibus-keymagic-mon - ibus keymagic mon;
  ibus-keymagic-myanmar3 - ibus keymagic Myanmar3;
  ibus-keymagic-myanmar3x - ibus keymagic Myanmar3x;
  ibus-keymagic-myansan - ibus keymagic myansan;
  ibus-keymagic-mywin - ibus keymagic mywin;
  ibus-keymagic-ou-khamti - ibus keymagic ou-khamti;
  ibus-keymagic-ou-mon - ibus keymagic ou-mon;
  ibus-keymagic-ou-myanmar - ibus keymagic ou-Myanmar;
  ibus-keymagic-ou-palaung - ibus keymagic ou-palaung;
  ibus-keymagic-ou-pao - ibus keymagic ou-pao;
  ibus-keymagic-ou-shan - ibus keymagic ou-shan;
  ibus-keymagic-ou-taile - ibus keymagic ou-taile;
  ibus-keymagic-ou-taitham - ibus keymagic ou-taitham;
  ibus-keymagic-panglongshan - ibus keymagic panglongshan;
  ibus-keymagic-paoh - ibus keymagic paoh;
  ibus-keymagic-parabaik - ibus keymagic parabaik;
  ibus-keymagic-sunssalba - ibus keymagic sunssalba;
  ibus-keymagic-unimon - ibus keymagic unimon;
  ibus-keymagic-yunghkio - ibus keymagic yunghkio;
  ibus-keymagic-zawgyi - ibus keymagic zawgyi;
  ibus-keymagic-zawgyinonsmart - ibus keymagic zawgyinonsmart;
  ibus-keymagic-zawgyitai - ibus keymagic zawgyitai;
  ibus-keymagic-zawgyiunicode - ibus keymagic zawgyiunicode;
  ibus-keymagic-zgunicode - ibus keymagic zgunicode;
  ibus-keymagic-pyidaungsu - ibus keymagic pyidaungsu;

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

  https://mentors.debian.net/package/ibus-keymagic

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

  dget -x
https://mentors.debian.net/debian/pool/main/i/ibus-keymagic/ibus-keymagic_1.4-1.dsc

Changes since the last upload:

   * fix gpg key and uscan watch file.
   * lintian check is clean.

Regards,

Bug#948261: RFS: fonts-myanmar/0.0-1 -- Myanmar fonts collection

2020-01-05 Thread Ko Ko Ye` 
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "fonts-myanmar"
pls help me for this sponsor package. i want to contribute debian community
and local community.

 * Package name: fonts-myanmar
   Version : 0.0-1
   Upstream Author : kokoye2007 
 * URL : https://github.com/kokoye2007/fonts-myanmar
 * License : GPL-3.0+
 * Vcs : https://github.com/kokoye2007/fonts-myanmar
   Section : fonts

It builds those binary packages:

  fonts-myanmar - Myanmar fonts collection
  fonts-myanmar-zawgyi - Myanmar font Zawgyi One v2008;
  fonts-myanmar-myanmar3 - Myanmar fonts Myanmar3
  fonts-myanmar-myanmarcensus - Myanmar fonts Myanmar Census
  fonts-myanmar-pyidaungsu - fonts Pyidaungsu
  fonts-myanmar-unicode - Myanmar Unicode fonts
  fonts-myanmar-ayar - Myanmar fonts ayar
  fonts-myanmar-angoun - Myanmar fonts angoun
  fonts-myanmar-chatulight - Myanmar fonts chatulight
  fonts-myanmar-chatu - Myanmar fonts chatu
  fonts-myanmar-gantgaw - Myanmar fonts gantgaw
  fonts-myanmar-khyay - Myanmar fonts khyay
  fonts-myanmar-kuttar - Myanmar fonts kuttar
  fonts-myanmar-nayone - Myanmar fonts nayone
  fonts-myanmar-njaun - Myanmar fonts njaun
  fonts-myanmar-pauklay - Myanmar fonts pauklay
  fonts-myanmar-phetsot - Myanmar fonts phetsot
  fonts-myanmar-phikselsmooth - Myanmar fonts phikselsmooth
  fonts-myanmar-phiksel - Myanmar fonts phiksel
  fonts-myanmar-ponenyet - Myanmar fonts ponenyet
  fonts-myanmar-sabae - Myanmar fonts sabae
  fonts-myanmar-sagar - Myanmar fonts sagar
  fonts-myanmar-sanpya - Myanmar fonts sanpya
  fonts-myanmar-squarelight - Myanmar fonts squarelight
  fonts-myanmar-tagu - Myanmar fonts tagu
  fonts-myanmar-thuriya - Myanmar fonts thuriya
  fonts-myanmar-waso - Myanmar fonts waso
  fonts-myanmar-yinmar - Myanmar fonts yinmar
  fonts-myanmar-myanmarsanspro - Myanmar fonts Myanmar Sans Pro
  fonts-myanmar-namkhone - Myanmar shan fonts Namkhone
  fonts-myanmar-mon - Myanmar mon fonts MON3 Anonta 1

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

  https://mentors.debian.net/package/fonts-myanmar

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

  dget -x
https://mentors.debian.net/debian/pool/main/f/fonts-myanmar/fonts-myanmar_0.0-1.dsc

Changes since the last upload:

   * Initial release (Closes: ##923710)

Regards,

--
  kokoye2007

-- 
---

with regards *Ko Ko Ye`*

+95 97989 22022
+95 94500 22022
+95 9731 47907
kokoye2...@gmail.com
kokoye2...@ubuntu.com

skype: kokoye2007
jitsi: kokoye2007

http://ubuntu-mm.net
http://wiki.ubuntu.com/kokoye2007
http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm

Bug#948260: RFS: golang-github-russellhaering-gosaml2/0.3.1-1 [ITP] -- Pure Go implementation of SAML 2.0 (library)

2020-01-05 Thread Christian Barcenas 
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package 
"golang-github-russellhaering-gosaml2".

Additionally, I need the sponsor to push the packaging from my personal repo

  https://salsa.debian.org/cb-guest/golang-github-russellhaering-gosaml2

to the official go-team repository

  https://salsa.debian.org/go-team/packages/golang-github-russellhaering-gosaml2

 * Package name: golang-github-russellhaering-gosaml2
   Version : 0.3.1-1
   Upstream Author : Russell Haering
 * URL : https://github.com/russellhaering/gosaml2
 * License : Apache-2.0
 * Vcs : 
https://salsa.debian.org/go-team/packages/golang-github-russellhaering-gosaml2
   Section : devel

It builds these binary packages:

  golang-github-russellhaering-gosaml2-dev - Pure Go implementation of SAML 2.0 
(library)

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

  https://mentors.debian.net/package/golang-github-russellhaering-gosaml2

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-russellhaering-gosaml2/golang-github-russellhaering-gosaml2_0.3.1-1.dsc

Changes since the last upload:

   * Initial release (Closes: #948190)
   * Backport patch for AuthnRequest ordering (upstream bug #45).

Regards,

--
  Christian Barcenas

Re: Understand Debian Keyring

2020-01-05 Thread John Scott 
On January 5, 2020 12:34:53 PM EST, Wookey  wrote:
>On 2020-01-05 10:01 -0500, Tong Sun wrote:
>> Now, before I redo the upload (and get it stuck again), let me try to
>> understand the situation --
>> 
>> The reason it was stuck might be because my key was *considered*
>> expired. The problem is, I renewed it two or three weeks ago, and sent
>> it to pgp &
>> Ubuntu key servers.
>> 
>> The mentors.debian.net accepted my (renewed) key, but ftp-master
>> didn't. Might that my key on ftp-master.debian.org is somehow not
>> refreshed? Anyway, I tried to fix the issue by refreshing my key to
>> keyring.debian.org. However, on reading https://keyring.debian.org/, I
>> stated to wonder that if it good enough *now*:
>> 
>> > We will include your changed key in our next keyring push (which happens 
>> > approx. monthly).
>> 
>> What does it really mean? Shall I need to wait a month before uploading 
>> again?
>
>One thing is check that you are signing the packages with the new key
>and not the old one (not sure if 'renewing' counts as a new key or
>not?). If both are around (gpg -K will show available secret keys),
>it's very easy to sign with the wrong one, and then ftp-master quietly
>throws away your packages without telling you.
>
>I know this because I've had this problem for some time (my machine
>defaults to using the wrong key despite having default-key set in
>.gnupg/gpg.conf so I have to sign with an expicit key (debsign -k)).
> 
>Wookey

He said his key was expired, so in this context renewing his key means bumping 
the expiration date. That won't be a problem

Bug#947965: RFS: antimony/0.9.3-1.1 [NMU, RC] -- Computer-aided design CAD tool

2020-01-05 Thread Adam Borowski 
On Thu, Jan 02, 2020 at 09:14:54PM +0100, Håvard Flaget Aasen wrote:
>  * Package name: antimony
>Version : 0.9.3-1.1

> Changes since the last upload:
> 
>* Non-maintainer upload.
>  .
>[ Tiago Bortoletto Vaz ]
>* Add MPL-2.0 notice to debian/copyright.
>* Add Boost license notice to debian/copyright.
>  .
>[ Håvard Flaget Aasen ]
>* Explicit build-dependency on dh-python. closes: #947326
>* Use new CMake discovery for python and boost::python. closes: #947479
>  - Patch from Ubuntu.
>* This package embeds python3, and is only built against the default
>  version. Change build-dependency to python3-dev.
>  - Patch from Ubuntu.

Hi!
Have you followed the NMU procedure?  It includes posting the debdiff to at
least one of bugs that are the cause of the NMU; the primary reason is to
make it easy for the maintainer to apply your changes to a VCS.

Also, there's now a syntax error in debian/copyright: the Boost-1.0 section
has two "License:" fields.  It looks like the second one is meant to be a
continuation of the first, thus removing the second header would be enough.

> This package fails with piupart, but i believe it can be traced back to this
> bug: #897040 in fontconfig. If it makes any difference.

fontconfig is known-broken, and piuparts had problems on its own recently.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#948246: RFS: dbview/1.0.4-2 [QA] -- View dBase III files

2020-01-05 Thread Sudip Mukherjee 
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: dbview
   Version : 1.0.4-2
   Upstream Author : Martin Schulze 
 * URL : https://www.infodrom.org/projects/dbview
 * License : GPL-2.0+
 * Vcs : None
   Section : misc

It builds those binary packages:

  dbview - View dBase III files

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dbview/dbview_1.0.4-2.dsc

Changes since the last upload:

   * QA upload.
   * Mark QA as maintainer
   * Update Standards-Version to 4.4.1
   * Update compat level to 12
   * Remove NMU-Disclaimer
   * Simplify d/rules
   * Add -g in Makefile for dbg package
   * Add support for DESTDIR in Makefile
   * Move to source format 3.0
   * Update copyright file


-- 
Regards
Sudip

Bug#948194: RFS: jcc/3.6-1 [ITA] -- generator for a Python extension from Java classes (transitional)

2020-01-05 Thread Adam Borowski 
On Sun, Jan 05, 2020 at 01:37:20AM -0300, Emmanuel Arias wrote:
>  * Package name: jcc
>Version : 3.6-1

> It builds those binary packages:
> 
>   python-jcc - generator for a Python extension from Java classes (Python 2)
>   python3-jcc - generator for a Python extension from Java classes (Python 3)
>   jcc - generator for a Python extension from Java classes (transitional)

[Note: a trip through binNEW is required.]

> Changes since the last upload:
> 
>[ Emmanuel Arias ]
>* New upstream version 3.6
>* New maintainer (Closes: #922568):
>  - Add myself to Maintainer field on d/control.
>* Bump debhelper to 12 (from 9.2):
>  - Update debhelper to debhelper-compat on d/control Build-Depends.
>* Update Vcs-* repository to salsa repository.
>* Add myself on debian/* files copyright on d/copyright.
>* Bump Standard-Version to 4.4.1
>* d/control: add autopkgtest-pkg-python

Hi!
The package has three RC bugs filed against it, and you don't close any of
them.  These are:
#875579 FTBFS with Java 9: library path guessed wrong
#885955 FTBFS: /usr/bin/ld: cannot find -ljvm
-- both of these are fixed in your upload, but without closing them, the
   package won't be allowed back in

#936761 jcc: Python2 removal in sid/bullseye
-- as there are no reverse {,B-}Rdependencies, there's nothing to preserve
   compatibility for, thus it'd be enough to drop the python-jcc package
   (which you try to introduce!) -- it's not needed, and as the next Debian
   release will not feature Python2[1], would need to be removed shortly
   anyway


Meow!

[1]. Or, if removal doesn't succeed, Python2 will be trimmed to a stub.
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Re: Understand Debian Keyring

2020-01-05 Thread Wookey 
On 2020-01-05 10:01 -0500, Tong Sun wrote:
> Now, before I redo the upload (and get it stuck again), let me try to
> understand the situation --
> 
> The reason it was stuck might be because my key was *considered*
> expired. The problem is, I renewed it two or three weeks ago, and sent
> it to pgp &
> Ubuntu key servers.
> 
> The mentors.debian.net accepted my (renewed) key, but ftp-master
> didn't. Might that my key on ftp-master.debian.org is somehow not
> refreshed? Anyway, I tried to fix the issue by refreshing my key to
> keyring.debian.org. However, on reading https://keyring.debian.org/, I
> stated to wonder that if it good enough *now*:
> 
> > We will include your changed key in our next keyring push (which happens 
> > approx. monthly).
> 
> What does it really mean? Shall I need to wait a month before uploading again?

One thing is check that you are signing the packages with the new key
and not the old one (not sure if 'renewing' counts as a new key or
not?). If both are around (gpg -K will show available secret keys),
it's very easy to sign with the wrong one, and then ftp-master quietly
throws away your packages without telling you.

I know this because I've had this problem for some time (my machine
defaults to using the wrong key despite having default-key set in
.gnupg/gpg.conf so I have to sign with an expicit key (debsign -k)).
 
Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#944876: marked as done (RFS: boogie 2.4.1-0.1 -- verifiable programming language [NMU, RC])

2020-01-05 Thread Debian Bug Tracking System 
Your message dated Sun, 5 Jan 2020 18:35:43 +0100
with message-id <99529bb8-6306-c113-c812-ab53e1916...@arcor.de>
and subject line Re: RFS: boogie 2.4.1-0.1 -- verifiable programming language 
[NMU, RC]
has caused the Debian Bug report #944876,
regarding RFS: boogie 2.4.1-0.1 -- verifiable programming language [NMU, RC]
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.)


-- 
944876: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944876
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: bba...@mit.edu

Dear mentors,

I am looking for a sponsor for an upload of the 'boogie' package.

My changes are summarized in the latest changelog entry:

  boogie (2.4.1-0.1) unstable; urgency=medium

* Non-maintainer upload.
* New upstream release.
* Update debian/watch file.
* Update debian/copyright.
* Change Priority to optional in debian/control.
* Upgrade to debhelper compat level 12.
* Update build dependencies (Closes: #927171).
* Upgrade to Standards-Version 4.4.1.
* Fix debian/rules to make the new version build.
* Enable autopkgtest package testing, and add mccarthy-{91,92} tests.
* Update Vcs-Git and Vcs-Browser fields in debian/control.

   -- Fabian Wolff   Sat, 16 Nov 2019 19:16:48 +0100

The current maintainer is looking for someone to adopt the package (#903142)
and has not made any attempt to keep the package in shape even after it had
been removed from testing, so I don't think he will object to this NMU. But
I have added him in the X-Debbugs-CC header just to be sure.

The Git repository that the Vcs-Git and Vcs-Browser fields point to does not
exist yet, but I've already sent a request on debian-mentors for someone to
create it for me and give me access to it. Once this has happened, I will
push my changes there; in the meantime, the package can be found here:

  https://salsa.debian.org/wolff-guest/boogie

And also on Mentors:

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

Thank you for your help!

Best regards,
Fabian
--- End Message ---
--- Begin Message ---
On Thu, 02 Jan 2020 12:39:57 +0100 Tobias Frost  wrote:
> Control: tags -1 moreinfo
> 
> Tagging moreinfo as currently not actionable (needs an update from
> Fabian)

I have actually already found a sponsor and the package has been uploaded;
the bug just hasn't been closed yet.

Sorry for the confusion!--- End Message ---

Re: Understand Debian Keyring

2020-01-05 Thread Roger Shimizu 
On Mon, Jan 6, 2020 at 12:02 AM Tong Sun
 wrote:
>
> On Sat, Jan 4, 2020 at 7:56 PM Paul Wise wrote:
>
> > > How to delete my package from ftp.upload.debian.org?
> >
> > Usually that means using dcut (from devscripts), but in this case the
> > package is no longer in the upload queue so you cannot remove it from
> > there.
> > . . .
>
> Thanks a lot for the explanation.
>
> Now, before I redo the upload (and get it stuck again), let me try to
> understand the situation --
>
> The reason it was stuck might be because my key was *considered*
> expired. The problem is, I renewed it two or three weeks ago, and sent
> it to pgp &
> Ubuntu key servers.
>
> The mentors.debian.net accepted my (renewed) key, but ftp-master
> didn't. Might that my key on ftp-master.debian.org is somehow not
> refreshed? Anyway, I tried to fix the issue by refreshing my key to
> keyring.debian.org. However, on reading https://keyring.debian.org/, I
> stated to wonder that if it good enough *now*:

Yes, mentors.debian.net may accept your key update in short time, but
for debian keyring it's not the same case.

> > We will include your changed key in our next keyring push (which happens 
> > approx. monthly).
>
> What does it really mean? Shall I need to wait a month before uploading again?

Yes, and keyring updates "monthly" means it may take about two months
for your key update in the worst case.

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

Bug#948226: RFS: svxlink/19.09.1-1 [requires NEW] -- Advanced repeater controller

2020-01-05 Thread Felix Lechner 
Package: sponsorship-requests
Severity: normal

Dear mentors,

This package is in Debian, but requires a trip through NEW.

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

 * Package name: svxlink
   Version : 19.09.1-1
   Upstream Author : Tobias Blomberg 
 * URL : http://www.svxlink.org/
 * License : GPL-2+
 * Vcs : None
   Section : hamradio

It builds those binary packages:

  libasyncaudio-dev - AsyncAudio library for SvxLink (development files)
   libasyncaudio1.6 - AsyncAudio library for SvxLink
   libasynccore-dev - AsyncCore library for SvxLink (development files)
   libasynccore1.6 - AsyncCore library for SvxLink
   libasynccpp-dev - AsyncCpp library for SvxLink (development files)
   libasynccpp1.6 - AsyncCpp library for SvxLink
   libasyncqt-dev - AsyncQt library for SvxLink (development files)
   libasyncqt1.6 - AsyncQt library for SvxLink
   libecholib-dev - EchoLib library for SvxLink (development files)
   libecholib1.3 - EchoLib library for SvxLink
   qtel  - Graphical client for the EchoLink® protocol
   qtel-icons - Icons for graphical client for the EchoLink® protocol
   remotetrx  - Remote controller for radio transceivers
   svxlink-calibration-tools - Calibration tools for SvxLink amateur radio suite
   svxlink-gpio - GPIO control scripts SvxLink amateur radio server
   svxlink-server - Voice-over-IP server for ham radio operators
   svxreflector - Conference server for SvxLink amateur radio servers

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/svxlink/svxlink_19.09.1-1.dsc

Changes since the last upload:

   * New upstream release.
   * Added Build-Depends: libcurl4-gnutls-dev.
   * Refreshed patches.
   * Removed patch fixing gpio scripts incorporated upstream.
   * Switched to debhelper-compat in d/control instead of d/compat.
   * Bumped Standards-Version to 4.4.1,
   * Added Rules-Requires-Root: no to d/control.
   * Set shared object version to 1.6 for
   - libasynccore
   - libasyncqt
   - libasyncaudio
   - libasynccpp
   * Fix spelling in manpage for ModuleTrx.conf.

Regards,

--
  Felix Lechner

Bug#948141: RFS: libcloud/2.8.0-1 -- unified Python interface into the cloud (Python3 version)

2020-01-05 Thread Håvard Flaget Aasen 





I'm pretty sure this package doesn't support Python 2 anymore.  Python3.4
would also require mixing Debian releases three releases apart.

Thus, while _upstream_ may support ancient Python versions, Debian packaging
doesn't.  I'd suggest just axing this line.



You are of course correct. I will push a fix to the repo immediately.

Thanks for all the sponsoring, it's really appreciated.

Håvard

Bug#948141: marked as done (RFS: libcloud/2.8.0-1 -- unified Python interface into the cloud (Python3 version))

2020-01-05 Thread Debian Bug Tracking System 
Your message dated Sun, 5 Jan 2020 16:19:22 +0100
with message-id <20200105151922.ga17...@angband.pl>
and subject line Re: Bug#948141: RFS: libcloud/2.8.0-1 -- unified Python 
interface into the cloud (Python3 version)
has caused the Debian Bug report #948141,
regarding RFS: libcloud/2.8.0-1 -- unified Python interface into the cloud 
(Python3 version)
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.)


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

 * Package name: libcloud
   Version : 2.8.0-1
   Upstream Author : d...@libcloud.apache.org
 * URL : https://libcloud.apache.org/
 * License : Apache-2.0
 * Vcs : https://salsa.debian.org/python-team/modules/libcloud
   Section : python

It builds those binary packages:

  python3-libcloud - unified Python interface into the cloud (Python3 
version)


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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libc/libcloud/libcloud_2.8.0-1.dsc


Changes since the last upload:

   * Team upload
   * New upstream version 2.8.0
   * Add Rules-Requires-Root
   * Update package description.

Regards,
Håvard
--- End Message ---
--- Begin Message ---
On Sat, Jan 04, 2020 at 03:52:19PM +0100, Håvard Flaget Aasen wrote:
>  * Package name: libcloud
>Version : 2.8.0-1

> Changes since the last upload:
> 
>* Team upload
>* New upstream version 2.8.0
>* Add Rules-Requires-Root
>* Update package description.

Hi!
Generally, this upload looks good (and I've just sponsored it), but the long
desc is untrue:

+++ libcloud-2.8.0/debian/control
-  * Supports Python 2.5, Python 2.6, Python 2.7, PyPy and Python 3
+  * Supports Python 2.7, PyPy and Python 3.4 or newer.

I'm pretty sure this package doesn't support Python 2 anymore.  Python3.4
would also require mixing Debian releases three releases apart.

Thus, while _upstream_ may support ancient Python versions, Debian packaging
doesn't.  I'd suggest just axing this line.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.--- End Message ---

Understand Debian Keyring

2020-01-05 Thread Tong Sun 
On Sat, Jan 4, 2020 at 7:56 PM Paul Wise wrote:

> > How to delete my package from ftp.upload.debian.org?
>
> Usually that means using dcut (from devscripts), but in this case the
> package is no longer in the upload queue so you cannot remove it from
> there.
> . . .

Thanks a lot for the explanation.

Now, before I redo the upload (and get it stuck again), let me try to
understand the situation --

The reason it was stuck might be because my key was *considered*
expired. The problem is, I renewed it two or three weeks ago, and sent
it to pgp &
Ubuntu key servers.

The mentors.debian.net accepted my (renewed) key, but ftp-master
didn't. Might that my key on ftp-master.debian.org is somehow not
refreshed? Anyway, I tried to fix the issue by refreshing my key to
keyring.debian.org. However, on reading https://keyring.debian.org/, I
stated to wonder that if it good enough *now*:

> We will include your changed key in our next keyring push (which happens 
> approx. monthly).

What does it really mean? Shall I need to wait a month before uploading again?

Re: How to delete my package from ftp.upload.debian.org

2020-01-05 Thread Tong Sun 
On Sat, Jan 4, 2020 at 7:56 PM Paul Wise wrote:

> > 
> > Package has already been uploaded to ftp-master on ftp.upload.debian.org
> > Nothing more to do for dbab_1.3.3-1_source.changes
> > 
>
> This error message is solely based on the files on your local system,
> if you want to reupload the same .changes filename, you will need to
> delete the corresponding .upload file.
>
> Please also file a bug/patch against the upload tool that you are
> using, it should have a better error message for this situation or
> have a confirmation prompt or something.

Thanks a lot for the clear explanation. will do...

Re: Bug#946959: RFS: coreboot/4.10-1 -- Coreboot firmware utilities

2020-01-05 Thread Steffen Möller 

Hello,

On 05.01.20 02:01, John Scott wrote:

The package is in great shape. The only challenge to getting the package in
the archive seems to be the copyright file. Coreboot's README says

Some files are licensed under the "GPL (version 2, or any later version)",
and some files are licensed under the "GPL, version 2". For some parts,
which were derived from other projects, other (GPL-compatible) licenses may

apply. Please check the individual source files for details.

debian/copyright says most files are GPL 2+, but it my digging indicates the
majority are GPL 2 only, and I think I saw additional licenses too.

I believe upstream has recently expressed desire to make listings files with
respective licenses and/or using SPDX identifiers, rather than their lengthy
headers in the source. If that's true, checking out the Git version might help
you parse the licenses.

Speaking of which, you repacked Coreboot with the contents of 3rdparty/
removed. As a Libreboot user I thought I understood why, but as best as I can
tell those files are free. On Coreboot's downloads page they appear to
distribute the blobs separately which is news to me.

For 3rd party tools there should be separate packages that a coreboot
packages
depends on or recommonds/suggests to install along. Removing 3rdparty is
the right thing to do.

If there really is a problem with those files I would appreciate your letting
me know what I missed. Otherwise I hope you can avoid the repacking trouble in
the future.

Lastly, a small enhancement is to add a debian/watch file so that tools can
check for and utilize new upstream versions automagically. I plan to send a
Salsa merge request with details shortly.

I hope my feedback is useful for you to help your package.


I am one of those "wished to be" coreboot users. Cannot test, but could
help with
sponsoring. There are other DDs closer to coreboot, so, use me as you
see fit.

Steffen

Bug#948204: RFS: zope.configuration/4.3.1-1 [QA] -- Zope Configuration Markup Language (ZCML)

2020-01-05 Thread Håvard Flaget Aasen 

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "zope.configuration"

 * Package name: zope.configuration
   Version : 4.3.1-1
   Upstream Author : Zope Foundation and Contributors 
 * URL : https://pypi.python.org/pypi/zope.configuration
 * License : Zope-2.1
 * Vcs : None
   Section : zope

It builds those binary packages:

  python3-zope.configuration - Zope Configuration Markup Language (ZCML)

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


  https://mentors.debian.net/package/zope.configuration

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

  dget -x 
https://mentors.debian.net/debian/pool/main/z/zope.configuration/zope.configuration_4.3.1-1.dsc


Changes since the last upload:

   * QA upload
   * New upstream release
   * d/control
 - Change Priority from extra to optional
 - Change to debhelper-comapt
 - Bump debhelper to 12
 - Update Standards-Version to 4.4.1
 - Use secure URI on homepage
 - Add Rules-Requires-Root: no
 - Change testsuite to autopkgtest-pkg-python
 - Add version control on python3-zope.schema
   * d/watch
 - Use secure URI
   * d/copyright
 - Use secure URI
 - Remove Files-Excluded, files is no longer included in source
   * Set upstream metadata fields: Bug-Database, Repository,
  Repository-Browse.
   * Disable upstream testsuite.

Regards,
Håvard

Bug#945588: RFS: lutris/0.5.4-1 -- open source gaming platform for GNU/Linux

2020-01-05 Thread Stephan Lachnit 
> I'm not a DD and can't sponsor packages, but I hope my feedback can be helpful
> for you.

Doesn't matter, thanks for the review!


> I see Lutris bundles python-distro. This is available in Debian, so the
> package should use it rather than installing a bundled copy. Debian's
> Winetricks should be used also.

Can you give me some for information about python-distro? Meaning where it is 
in Lutris? Maybe I'll make an upstream PR, but I'm short on time till end of 
this month.
I'm also aware of the winetricks problem and already did an PR do add the 
option to use system winetricks. I think Lutris should either provide a full 
winetricks, or remove its own (isn't used by default anyway afaik), but depends 
on weather the upstream author is interested in that and is commited to 
frequently updated the shipped winetricks. Hasn't been the case before I did it 
lately.

> Since Winetricks is in contrib, depending or recommending it means that Lutris
> needs to go to contrib or non-free also.

Well kinda not, since winetricks in Debian suggests unrar-nonfree,
while Lutris doesn't. Anyway, Lutris shouldn't really ship winetricks by 
default imho.

> Lutris's description mentions Linux. Does it use any Linux-specific
> functionality, or should it build and work on other kenels like the Hurd and
> kFreeBSD also? If so the Architecture: any is fine.

Didn't remember if I tried all or any, but it didn't work. I'll try it again 
once I'll start packing lutris again, and will do an upstream PR to remove the 
GNU/Linux mentioning, but I won't change the description from upstream.


> I see from the TODO and your GitHub issue that you're aware of the copyright
> problems, but as the package currently stands it's not suitable even for non-
> free.

Yeah I already thought they would be highly problematic and I didn't invest the 
time yet to read everything and compare to the DFSG, also I don't even have 
enough knowledge to do so.

> That's problematic and I don't see any 'explicit authorization,' so I've
> reported this issue upstream at https://github.com/lutris/lutris/issues/2573
> and hope it will be taken care of.

Yeah I could see that this won't work out. Also I don't think it's necessary, 
we can just create a DFSG-compliant package and strip all the svgs out. Why all 
of them? Because even the CC0-1.0 svgs have some logos which could cause 
copyright problems (like the steam logo for example). What has to be done for 
this though is some upstream work to not cause an error if the svgs are 
missing, but show a blank logo instead. Don't know if it even throws an error 
right now but don't have the time to really test it rn.

> With respect to the Debian-specific parts, the packaging looks good and I hope
> my feedback helps you tackle your last few challenges.

Thanks again! I hope I'll get a cleaner DFSG-compliant package once the next 
version is released, and hopefully someone will sponsor it then. Tbh I wasn't 
really that active to find a sponsor, since 5.4 released without my big 
upstream change to improve packaging and was be a mess to review. Anyway, if 
you want to keep track I'll create a new todo-list on 
https://github.com/lutris/lutris/issues/2553

Stephan