Bug#884740: RFS: pokemmo-installer/1.4.5-1 [ITP] -- Installer and Launcher for the PokeMMO emulator

[Carlos Donizete Froes]

Hi Tobias,

Renamed the source package and binary package for 'pokemmo-installer', as 
mentioned earlier.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886606

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ - https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀   2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780

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

Bug#886606: RFS: pokemmo-installer/1.4.5-1 [ITP] -- Installer and Launcher for the PokeMMO emulator

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "pokemmo-installer"

 * Package name: pokemmo-installer
   Version : 1.4.5-1
   Upstream Author : Carlos Donizete Froes 
 * URL : https://github.com/coringao/pokemmo-installer
 * License : GPL-3+
   Section : games

  It builds those binary packages:

  pokemmo-installer - Installer and Launcher for the PokeMMO emulator

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

  https://mentors.debian.net/package/pokemmo-installer

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pokemmo-installer/pokemmo-installer_1.4.5-1.dsc

  This package is from the previous version of "pokemmo/1.4.3-1", follows the 
Debian Bug report logs.

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884740

  Changes since the last upload:

  **changelog version: 1.4.5**
   * Updated desktop file
   * Updated the readme description
   * Changed program name for 'PokeMMO Installer'
   * Rename the binary package to 'pokemmo-installer'
   * Updated executable script main
   * Rename the manpage to 'pokemmo-installer.6'
   * Updated the description of the manpage

  Regards,
   Carlos Donizete Froes

Bug#886597: RFS: fcitx/1:4.2.9.5-1~exp1 -- Flexible Input Method Framework

[Boyuan Yang]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: pkg-ime-de...@lists.alioth.debian.org a...@debian.org

Dear mentors and pkg-ime team members,

I'm looking for a sponsor for package "fcitx" as a team upload into 
experimental.
This would initiate a micro-transition around libfcitx-gclient and I'd like to
see new packages get through NEW queue first.

Already received ACK from original package uploader about the transition. (in 
CC-list).

 * Package name: fcitx
   Version : 1:4.2.9.5-1~exp1
   Upstream Author : Weng Xuetian 
 * URL : https://fcitx-im.org/
 * License : GPL-2+
   Section : utils

  It builds those binary packages:

 fcitx - Flexible Input Method Framework
 fcitx-bin  - Flexible Input Method Framework - essential binaries
 fcitx-data - Flexible Input Method Framework - essential data files
 fcitx-frontend-all - Flexible Input Method Framework - frontends metapackage
 fcitx-frontend-gtk2 - Flexible Input Method Framework - GTK+ 2 IM Module 
frontend
 fcitx-frontend-gtk3 - Flexible Input Method Framework - GTK+ 3 IM Module 
frontend
 fcitx-frontend-qt4 - Flexible Input Method Framework - Qt4 IM Module frontend
 fcitx-libs - Flexible Input Method Framework - metapackage for libraries
 fcitx-libs-dev - Flexible Input Method Framework - library development files
 fcitx-module-dbus - Flexible Input Method Framework - D-Bus module and IPC 
frontend
 fcitx-module-kimpanel - Flexible Input Method Framework - KIMPanel protocol 
module
 fcitx-module-lua - Flexible Input Method Framework - Lua module
 fcitx-module-x11 - Flexible Input Method Framework - X11 module and XIM 
frontend
 fcitx-modules - Flexible Input Method Framework - core modules
 fcitx-pinyin - Flexible Input Method Framework - classic Pinyin engine
 fcitx-qw   - Flexible Input Method Framework - QuWei engine
 fcitx-table - Flexible Input Method Framework - table engine
 fcitx-table-all - Flexible Input Method Framework - tables metapackage
 fcitx-table-bingchan - Flexible Input Method Framework - Bingchan table
 fcitx-table-cangjie - Flexible Input Method Framework - Cangjie table
 fcitx-table-dianbaoma - Flexible Input Method Framework - Dianbaoma table
 fcitx-table-erbi - Flexible Input Method Framework - Erbi table
 fcitx-table-wanfeng - Flexible Input Method Framework - Wanfeng table
 fcitx-table-wbpy - Flexible Input Method Framework - WubiPinyin table
 fcitx-table-wubi - Flexible Input Method Framework - Wubi table
 fcitx-table-ziranma - Flexible Input Method Framework - Ziranma table
 fcitx-tools - Flexible Input Method Framework - various tools
 fcitx-ui-classic - Flexible Input Method Framework - Classic user interface
 gir1.2-fcitx-1.0 - GObject introspection data for fcitx
 libfcitx-config4 - Flexible Input Method Framework - configuration support 
library
 libfcitx-core0 - Flexible Input Method Framework - library of core functions
 libfcitx-gclient1 - Flexible Input Method Framework - D-Bus client library for 
Glib
 libfcitx-qt0 - Flexible Input Method Framework - Meta package for Qt library
 libfcitx-utils0 - Flexible Input Method Framework - utility support library

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

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/f/fcitx/fcitx_4.2.9.5-1~exp1.dsc

  Debomatic build:


http://debomatic-amd64.debian.net/distribution#experimental/fcitx/4.2.9.5-1~exp1/buildlog

  Git packaging repo:

https://anonscm.debian.org/git/pkg-ime/fcitx.git (in "master" branch)

  Changes since the last upload:

 fcitx (1:4.2.9.5-1~exp1) experimental; urgency=medium
 .
   * Team upload.
   * New upstream release.
   * Drop binary package fcitx-module-quickphrase-editor, fcitx-qt5
 will provide it instead.
   * Bump Standards-Version to 4.1.3. (no changes needed)
   * Make libfcitx-qt0 provides fcitx-libs-qt to make older software
 that depend on fcitx-libs-qt happy.
   * Update d/copyright file.
   * Drop unnecessary patch 0003 in d/patches, applied upstream.
   * Add new build dependency uuid-dev.
   * Install new module fcitx-ipcportal into fcitx-modules.
   * Use secure uri in d/watch file.
   * Initiate SONAME Bump for libfcitx-gclient.
   * d/patches: Backport several upstream patches from trunk.

I'll evaluate the status of reverse dependency and request a translation slot 
/permission after
the new fcitx enters experimental.

% LANG=C apt rdepends libfcitx-gclient0
libfcitx-gclient0
Reverse Depends:
  Depends: fcitx-frontend-gtk2 (>= 4.2.9)
  Depends: libfcitx-gclient0-dbgsym (= 1:4.2.9.4-3)
  Depends: mlterm-im-fcitx (>= 4.2.7)
  Depends: fcitx-imlist (>= 4.2.7)
  Depends: fcitx-frontend-fbterm (>= 4.2.7)
  Depends: fcitx-config-gtk (>= 4.2.7)
  Depends: gir1.2-fcitx-1.0 (>= 4.2.9)
  Depends: fcitx-libs-dev (= 1:4.2.9.4-3)
  Depends: fcitx-libs (>= 

Bug#886446: closed by Sven Hoexter <s...@timegate.de> (Re: Bug#886446: RFS: btrfsmaintenance/0.3.1-17-gf7d61e3-1~exp1 [I maintain the package])

[Nicholas D Steeves]

> Date: Sun, 7 Jan 2018 14:35:50 +0100
> From: Sven Hoexter 
> To: Nicholas D Steeves , 886446-d...@bugs.debian.org
> Subject: Re: Bug#886446: RFS: btrfsmaintenance/0.3.1-17-gf7d61e3-1~exp1 [I
>  maintain the package]
> User-Agent: Mutt/1.9.2 (2017-12-15)
> 
> On Fri, Jan 05, 2018 at 08:33:30PM -0500, Nicholas D Steeves wrote:
> 
> Hi,
> 
> > btrfsmaintenance (0.3.1-17-gf7d61e3-1~exp1) experimental; urgency=medium
> > 
> >   * Add postrm script to clean up broken symlinks.
> >   * Fix Vcs-Git URL.
> >   * Install new systemd services and timers.
> >   * Uncapitalise short description.
> >   * Condense long description.
> >   * Declare Standards-Version: 4.1.3. (No additional changes needed)
> > 
> >  -- Nicholas D Steeves   Fri, 05 Jan 2018 18:55:21 -0500
> 
> 
> Uploaded, thanks.
> 
> Sven

Thank you Sven!

Sincerely,
Nicholas


signature.asc
Description: PGP signature

Bug#884740: RFS: pokemmo/1.4.2-1 [ITP] -- Multiplayer online game based on the Pokemon universe

[Carlos Donizete Froes]

Hi Chris,

> Why not simply package the game?

Yes! My intention is that in the future this package will be the game (client) 
as we release new
versions of the package.

> > (CC'ing chris so that he can share his thoughts.)
> 
> All of what you wrote sounds pretty reasonable but will hinge on the
> final result. The more verbose in debian/copyright the better, tbh :)

All the emails about the software that I'm sending to the PokeMMO developer, 
where it will improve
the software development.

Track the last email the developer talked about.

-
De: Kyu 
Para: Carlos Donizete Froes 
Assunto: Re: PokeMMO - Package Uploaded in Debian
Data: Fri, 5 Jan 2018 21:36:02 -0600

> Hi Carlos,
> 
> Once more, thank you for your time. We greatly appreciate it.
> 
> I can see there are some legality questions on the pkg-games-devel mailing 
> list due to the
> external trademark in the package description. Perhaps it is best to rewrite 
> it to something more
> generic?
> 
> If there are any other legal questions, please feel free to mail me. Thanks
-

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ - https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀   2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780

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

Bug#874305: RFS: mitlm/0.4.2-1 -- MIT Language Modeling toolkit

[Jakub Wilk]

I've retired from sponsoring. Sorry!

--
Jakub Wilk

Bug#884740: RFS: pokemmo/1.4.2-1 [ITP] -- Multiplayer online game based on the Pokemon universe

[Carlos Donizete Froes]

Hi Tobias,

> I'd substitube "launcher with installer" (as we removed the jar).
> Otherwise it is quite crisp.. I'd ammend only something like
> 
> How's about that proposal:
> 
> Description: Installer and Launcher for the PokeMMO emulator
>  PokeMMO is an emulator of several popular console
>  games with additional features and multiplayer capabilities.
>  .
>  This program downloads and installs the PokeMMO client to a user's
>  home directory and provides a launcher script for a convientient
>  starting of the emulator.
>  .
>  The permitted usage of the PokeMMO game client is defined by
>  a non-free license. The content of this license can be found
>  in the game client after an account's first login or
>  at https://pokemmo.eu/tos
> 

Great suggestion, in a few hours, will be ready.

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ - https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀   2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780

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

Bug#886583: RFS: nautilus-hide/0.2.3-2

[Carlos Maddela]

Package: sponsorship-requests
Severity: normal

Dear mentors,

  I am looking for a sponsor for my package "nautilus-hide"

 * Package name: nautilus-hide
   Version : 0.2.3-2
   Upstream Author : Bruno Nova 
 * URL : https://github.com/brunonova/nautilus-hide
 * License : GPL-3+
   Section : gnome

  It builds this binary package:

nautilus-hide - Extension for Nautilus to hide files without renaming them

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

  https://mentors.debian.net/package/nautilus-hide


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

dget -x 
https://mentors.debian.net/debian/pool/main/n/nautilus-hide/nautilus-hide_0.2.3-2.dsc

  Changes since the last upload:

  * Relocate VCS to salsa.debian.org.
  * Build with Debhelper compatibility level 11.
  * Indicate compliance with Debian Policy 4.1.3.
  * debian/gbp.conf: formatting changes.
  * Update debian/watch to allow all available versions of upstream
tarballs to be downloaded, not just the most recent ones.


  Regards,
   Carlos Maddela

Bug#886582: RFS: nautilus-admin/1.1.2-2

[Carlos Maddela]

Package: sponsorship-requests
Severity: normal

Dear mentors,

  I am looking for a sponsor for my package "nautilus-admin"

 * Package name: nautilus-admin
   Version : 1.1.2-2
   Upstream Author : Bruno Nova 
 * URL : https://github.com/brunonova/nautilus-admin
 * License : GPL-3+
   Section : gnome

  It builds this binary package:

nautilus-admin - Extension for Nautilus to do administrative operations

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

  https://mentors.debian.net/package/nautilus-admin


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

dget -x 
https://mentors.debian.net/debian/pool/main/n/nautilus-admin/nautilus-admin_1.1.2-2.dsc

  Changes since the last upload:

  * Relocate VCS to salsa.debian.org.
  * Build with Debhelper compatibility level 11.
  * Indicate compliance with Debian Policy 4.1.3.
  * debian/gbp.conf: formatting changes.
  * Update debian/watch to allow all available versions of upstream
tarballs to be downloaded, not just the most recent ones.


  Regards,
   Carlos Maddela

Bug#884740: RFS: pokemmo/1.4.2-1 [ITP] -- Multiplayer online game based on the Pokemon universe

[Chris Lamb]

Hi Tobias,

> I'm not sure if it enough to remove the term from the short description,
> but if we need to say something that the installer is a installer and
> not the game.  To make really clear that there is no connection between
> this package and PokeMMO beside that this will download the installer
> and bootstrap the game.

Why not simply package the game?

> (CC'ing chris so that he can share his thoughts.)

All of what you wrote sounds pretty reasonable but will hinge on the
final result. The more verbose in debian/copyright the better, tbh :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#884740: RFS: pokemmo/1.4.2-1 [ITP] -- Multiplayer online game based on the Pokemon universe

[Tobias Frost]

Hi Carlos

On Sat, Jan 06, 2018 at 07:54:41PM -0200, Carlos Donizete Froes wrote:
> Hi Tobias,
> 
> Sorry to bother again about my package.

no prob

> I do not know if followed the emails that 'Chris Lamb' mentioned about the 
> word "Pokemon" in my
> short description in the package.

> "pokemmo - Multiplayer online game based on the Pokemon universe"
> 
> Where he cares about the implications of the trademark for having the name in 
> this description.
> I understood the concern and I think it is totally right.
> 
> The software itself does not mention anything about "Pokemon". So I made a 
> new version of the
> software by changing this short description in the package.
> 

I just read through the thread (after being offline yesterday)

There is definitly a point from Chris, I completly missed that.
However, trademark is a tough topic (and IANAL.) Usually there is
some allowed usage of trademarks when referring to a trademarked
product... You just need to make sure that everyone understand that
the trademarked thing is something different than the package.

I'm not sure if it enough to remove the term from the short description,
but if we need to say something that the installer is a installer and
not the game.  To make really clear that there is no connection between
this package and PokeMMO beside that this will download the installer
and bootstrap the game.

So my idea would be:
- rename the source package and binary package to "pokemmo-installer"
- short title should emphasis that this is an installer / downloader.
I think it would be OK to say "installer for PokeMMO, a
multiplayer online game"

After writing that... I think I remember seeing on the forum of Pokemmo
a link to a debian package... Yeah, here it is:
https://dl.pokemmo.eu/download/pokemmo-launcher_1.3-1.deb

Looking at it, d/control has a nice description you could use as a
starting point: (It also helps to understand better what the purpose
is)

Description: Launcher for the PokeMMO emulator
 PokeMMO is an emulator of several popular console
 games with additional features and multiplayer capabilities.
 .
 This program downloads and installs the PokeMMO client to a user's
 home directory.
 .
 The permitted usage of the PokeMMO game client is defined by
 a non-free license. The content of this license can be found
 in the game client after an account's first login or
 at https://pokemmo.eu/tos


I'd substitube "launcher with installer" (as we removed the jar).
Otherwise it is quite crisp.. I'd ammend only something like

How's about that proposal:

Description: Installer and Launcher for the PokeMMO emulator
 PokeMMO is an emulator of several popular console
 games with additional features and multiplayer capabilities.
 .
 This program downloads and installs the PokeMMO client to a user's
 home directory and provides a launcher script for a convientient
 starting of the emulator.
 .
 The permitted usage of the PokeMMO game client is defined by
 a non-free license. The content of this license can be found
 in the game client after an account's first login or
 at https://pokemmo.eu/tos

Otherwise, ask them for permission and store the permission
along with the package

(CC'ing chris so that he can share his thoughts.)


> I just released the 'pokemmo/1.4.4-1' version.
> 
> https://mentors.debian.net/package/pokemmo
> 
> Changing this short description:
> 
> pokemmo - Play the new era of monster battles online
> 
> **Changelog version: 1.4.4**
>  * Changed short description in manpage
>  * Changed desktop file comment
>  * Removed single LEGAL file with license and copyright
>  * Updated GPLv3 license description with OpenSSL exception
> 
> I believe it is now all right to upload in Debian. :)
> 
> Thanks!
> 
> -- 
> ⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
> ⣾⠁⢠⠒⠀⣿⡁ - https://wiki.debian.org/coringao
> ⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
> ⠈⠳⣄⠀⠀⠀   2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780

Re: Dependencies across architectures

[Jens Reyer]

I forgot: the arch specific package needs a Depends on the arch:all
package, which has the wrappers.

Re: Dependencies across architectures

[Jens Reyer]

On 01/07/2018 05:39 PM, Wookey wrote:
> On 2018-01-07 19:23 +0800, Paul Wise wrote:
>> On Sun, Jan 7, 2018 at 5:59 PM, Ole Streicher wrote:
>>
>>> If we take Multi-Arch serious, this shouldn't be the case, right?
>>
>> I guess the release team might accept patches to britney for this but
>> I've also a vague memory that they prefer arches to be self-contained.
> 
> This issue affects so few packages that no-one has put in the effort
> to make this (automatic migration with cross-arch dependencies) work.
> I talked about it with respect to doing this for cross-compilers and
> they were OK with doing this properly this so long as there was a good
> reason (but in the end cross-compilers were done a different way so
> there was no need). In the meantime there is a rather hacky whitelist
> for the few packages that do need this (basically wine IIRC).

As *workaround* for this problem you might use some wrapper:

Indeed Wine is closely related to this issue, but we solved the problem
in another way: Wine needs some architecture specific packages which are
only available on either 32-bit or 64-bit.  So our common case on amd64
is that we need to depend on a i386 package.

However we don't use any hard cross-architecture dependencies (any
more?), only "soft" cross-architecture dependencies:  either Depends
with an alternate package from the same architecture, or Recommends.  In
our case:

 wine (arch:all)
 depends:
 wine32 (only 32-bit archs) | wine64 (only 64-bit archs)

We additionally have a wrapper script /usr/bin/wine (in wine) for the
main Wine binary (in wine32).  It gives a warning on console with
instructions how to install the foreign package wine32.  Using
wine64-only is possible, but in most cases wine32 is also wanted.  So
just warning on console, but still trying to run Wine, fits our needs
quite good.


Another affected package is playonlinux.  Its users rely on wine32 even
more then Wine users, so its maintainer would like to depend on wine32
(see: #798780).  For now he chose to just depend on wine, but afaik
plans to add some wrapper with a warning if wine32 is missing.  This
would need to be a graphical one, maybe using zenity.)


I don't know if lowering the dependency to recommends and using a
wrapper script would be a good solution for pyraf.  Assuming "iraf" is
absolutely required to make use of the application, that would mean in
the wrapper you'd need an error message which aborts (and not only warns
as in Wine's case).  Thus one could argue that python3-pyraf is buggy
because it lacks the Depends on iraf.  Counterargument would be that the
wrapper exits cleanly and at least gives _instructions_ how to add a
foreign arch and what to install then.

Greets
jre

Bug#883628: marked as done (RFS: iopport/1.2-1 [ITP] -- direct access to I/O ports from the command line)

[Debian Bug Tracking System]

Your message dated Sun, 7 Jan 2018 17:46:43 +0100
with message-id <20180107164642.ga1...@coldtobi.de>
and subject line Re: Bug#883628: ITP: ioport -- direct access to I/O ports from 
the command line
has caused the Debian Bug report #883628,
regarding RFS: iopport/1.2-1 [ITP] -- direct access to I/O ports from the 
command line
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.)


-- 
883628: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883628
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: wnpp
Severity: wishlist
Owner: Lubomir Rintel 

* Package name: ioport
  Version : 1.2
  Upstream Author : Richard Jones 
* URL : http://people.redhat.com/rjones/ioport/
* License : GPLv2+
  Programming Lang: C
  Description : direct access to I/O ports from the command line

These commands enable command line and script access directly to I/O
ports on PC hardware.

The packaging: https://people.freedesktop.org/~lkundrak/ioport/
--- End Message ---
--- Begin Message ---
Uploaded! Thanks for your contributions to Debian!

As this package has to go through the NEW queue, please manually remove
it from mentors.

Thanks!

tobi

On Sat, Jan 06, 2018 at 05:24:21PM +0100, Lubomir Rintel wrote:
> On Fri, 5 Jan 2018 16:13:19 +0100 Tobias Frost  wrote:
> > You want Debian revision -1, not -4..
> > Sorry, have ask you again for another iteration...
> 
> https://mentors.debian.net/debian/pool/main/i/ioport/ioport_1.2-1.dsc
> 
> Thanks for your patience
> Lubo
> --- End Message ---

Re: Dependencies across architectures

[Wookey]

On 2018-01-07 19:23 +0800, Paul Wise wrote:
> On Sun, Jan 7, 2018 at 5:59 PM, Ole Streicher wrote:
> 
> > If we take Multi-Arch serious, this shouldn't be the case, right?
> 
> I guess the release team might accept patches to britney for this but
> I've also a vague memory that they prefer arches to be self-contained.

This issue affects so few packages that no-one has put in the effort
to make this (automatic migration with cross-arch dependencies) work.
I talked about it with respect to doing this for cross-compilers and
they were OK with doing this properly this so long as there was a good
reason (but in the end cross-compilers were done a different way so
there was no need). In the meantime there is a rather hacky whitelist
for the few packages that do need this (basically wine IIRC).

So yes there is sort-of an assumption that architectures are
self-contained, but clearly we'd like things to work as well as
possible for the cases where they aren't/can't be.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#886446: marked as done (RFS: btrfsmaintenance/0.3.1-17-gf7d61e3-1~exp1 [I maintain the package])

[Debian Bug Tracking System]

Your message dated Sun, 7 Jan 2018 14:35:50 +0100
with message-id <20180107133550.gb31...@timegate.de>
and subject line Re: Bug#886446: RFS: btrfsmaintenance/0.3.1-17-gf7d61e3-1~exp1 
[I maintain the package]
has caused the Debian Bug report #886446,
regarding RFS: btrfsmaintenance/0.3.1-17-gf7d61e3-1~exp1 [I maintain the 
package]
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.)


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

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

Marc, I CCed you because you sponsored the last upload.  Would you
please consider sponsoring this one too?

Package name: btrfsmaintenance
Version : 0.3.1-17-gf7d61e3-1~exp1
Upstream Author : David Sterba 
URL : https://github.com/kdave/btrfsmaintenance
License : GPL-2
Section : admin

It builds this binary package:

btrfsmaintenance - automate btrfs maintenance tasks on mountpoints or 
directories

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

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/b/btrfsmaintenance/btrfsmaintenance_0.3.1-17-gf7d61e3-1~exp1.dsc

Finally, one can get checkout the git repository with these commands:

git clone ssh://git.debian.org/git/collab-maint/btrfsmaintenance.git
git checkout experimental

Changes since the last upload:

btrfsmaintenance (0.3.1-17-gf7d61e3-1~exp1) experimental; urgency=medium

  * Add postrm script to clean up broken symlinks.
  * Fix Vcs-Git URL.
  * Install new systemd services and timers.
  * Uncapitalise short description.
  * Condense long description.
  * Declare Standards-Version: 4.1.3. (No additional changes needed)

 -- Nicholas D Steeves   Fri, 05 Jan 2018 18:55:21 -0500

btrfsmaintenance (0.3.1-1~exp1) experimental; urgency=medium


Regards,
Nicholas D Steeves
--- End Message ---
--- Begin Message ---
On Fri, Jan 05, 2018 at 08:33:30PM -0500, Nicholas D Steeves wrote:

Hi,

> btrfsmaintenance (0.3.1-17-gf7d61e3-1~exp1) experimental; urgency=medium
> 
>   * Add postrm script to clean up broken symlinks.
>   * Fix Vcs-Git URL.
>   * Install new systemd services and timers.
>   * Uncapitalise short description.
>   * Condense long description.
>   * Declare Standards-Version: 4.1.3. (No additional changes needed)
> 
>  -- Nicholas D Steeves   Fri, 05 Jan 2018 18:55:21 -0500


Uploaded, thanks.

Sven--- End Message ---

Bug#884769: marked as done (RFS: freetype/2.8.1-0.2 [NMU])

[Debian Bug Tracking System]

Your message dated Sun, 7 Jan 2018 13:40:23 +0100
with message-id 

Re: Dependencies across architectures

[Paul Wise]

On Sun, Jan 7, 2018 at 5:59 PM, Ole Streicher wrote:

> Unfortunately, this is impossible: the assembler code creates a kind of
> sigsetjmp() (with its own calling interface) for Fortran 77. This cannot
> be simply remodelled in C. In principle, one could re-implement this
> with the libunwind library (see [1]), but since glibc scrambles stack
> information since some time, this does not work anymore.

Ok. I've mentioned it on #debian-ports, perhaps you'll get some help.

> Upstream is difficult for this package: the package has no new upstream
> version since five years and the communication is difficult.

Hmm, that sounds annoying.

> ... therefore I decided to create a temporary fork ...

Watch out, you could end up being the new upstream :)

> If we take Multi-Arch serious, this shouldn't be the case, right?

I guess the release team might accept patches to britney for this but
I've also a vague memory that they prefer arches to be self-contained.

> which is what I pargmatically did now (#886524). I was however not sure
> what the optimal way is, since I also don't know which architectures are
> co-runnable in practice. Theoretically, one could do anything with
> qemu-userland, however.

You can use arch-test to find out which arches a specific system can run.

I guess qemu-user can't run all arches though, like kFreeBSD.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#884769: RFS: freetype/2.8.1-0.2 [NMU]

[Hugh McMaster]

Hi Adam and Gianfranco,


Steve accepted almost all of my NMU changes last Friday, when he released a 
maintainer version of freetype.


So this RFS bug can be closed.


Thank you for your advice during the process.


Hugh


From: Hugh McMaster 
Sent: Friday, 22 December 2017 11:30:57 PM
To: Gianfranco Costamagna
Cc: Adam Borowski; 884...@bugs.debian.org
Subject: Bug#884769: RFS: freetype/2.8.1-0.2 [NMU]

Hi Gianfranco,

On Friday, 22 December 2017 3:11 AM, Gianfranco Costamagna wrote:
> ok, so fix all the reverse dependencies *before* dropping it, not after.
> We don't usually "break stuff and let maintainers fixup things", but:
> 1) open bugs (maybe with patches)

Okay, I'll start filing bugs to encourage the use of pkg-config to detect 
freetype2.
IIRC, some of the 33 already use pkg-config for other packages.

> Anyhow, we are really blocked by Steve, I pinged him on irc, maybe we can fix 
> this old bug
> now!

We should keep trying, but I don't want to pressure him to respond.

On another note, when should I prepare an NMU fixing #883698 (an RC bug)?
I'd also like to try removing the libdir code from freetype-config to make the 
package
multi-arch compatible.

Thanks,
Hugh

Bug#856792: marked as done (RFS: jpcre2/10.31.01-1 [ITP])

[Debian Bug Tracking System]

Your message dated Sun, 07 Jan 2018 10:20:18 +
with message-id 
and subject line closing RFS: jpcre2/10.31.01-1 [ITP]
has caused the Debian Bug report #856792,
regarding RFS: jpcre2/10.31.01-1 [ITP]
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.)


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

Dear mentors,

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

* Package name: jpcre2
  Version : 10.29.02-1
  Upstream Author : Md Jahidul Hamid 
* URL : https://github.com/jpcre2/jpcre2
* License : BSD
  Section : libs

  Launchpad URL   : https://launchpad.net/jpcre2 (debian source)

It builds these binary packages:

  libjpcre2-dev - C++ wrapper for PCRE2 library

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/j/jpcre2/jpcre2_10.29.02-1.dsc

More information about jpcre2 can be obtained from 
https://docs.neurobin.org/jpcre2.

Changes since the last upload:

 * Closes: #856780
 * Fix unsafe use of pcre2_substring_free

Regards,
 Md Jahidul Hamid




signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
Package jpcre2 has been removed from mentors.--- End Message ---

Re: Dependencies across architectures

[Ole Streicher]

Hi Paul,

Paul Wise  writes:
> On Sat, Jan 6, 2018 at 5:43 PM, Ole Streicher wrote:
>> "iraf" exists only on selected architectures due to some required
>> assembler code for each arch and problems with big endian.
> There could be a fallback in C for arches with no assembler yet
> and any non-baseline instructions should be detected at runtime.

Unfortunately, this is impossible: the assembler code creates a kind of
sigsetjmp() (with its own calling interface) for Fortran 77. This cannot
be simply remodelled in C. In principle, one could re-implement this
with the libunwind library (see [1]), but since glibc scrambles stack
information since some time, this does not work anymore.

If you have a portable solution, share it with me :-)

> Upstream should fix the code to deal with endianness correctly.
> Please file bugs upstream about these if you didn't already.

Upstream is difficult for this package: the package has no new upstream
version since five years and the communication is difficult. Usually,
this would count as "dead", but the package has quite some importance
for the astronomy community, and therefore I decided to create a
temporary fork, also for other downstreams (Fedora, Conda). The package
has ~750.000 LOC, so all I can do is to keep it working as it is. Big
endian was there at some point (10 years ago) on 32 bit, but they never
had a 64-big big endian release; so unless someone really puts some
efforts in, this will not happen (s390x).

>> From the description of "Multi-Arch: foreign" I would expect that this
>> allows the dependency resolved by using another architecture. However,
>> piuparts (and the migration excuses) claim a missing dependency on the
>> archs not supported by IRAF.
>
> piuparts.d.o only tests amd64 at this stage, could you quote the error
> piuparts gives for you on other arches? I'm guessing you didn't add
> the foreign architecture to the chroot that piuparts was using for
> testing.

It was (probably) my mistake, as I didn't run piuparts locally.

> I'm pretty sure the testing migration doesn't support
> cross-architecture dependencies, but the release team will hint things
> into testing where that is the only thing blocking migration.

If we take Multi-Arch serious, this shouldn't be the case, right?

>> My first thought was to limit the possible archs for python3-pyraf (by
>> explicitly setting the arch list and/or build-depending on iraf), but
>> this would not require the removal of the packages already build.
>
> Looks like you already tried this option, to get it to work you will
> have to ask the ftp-team to remove the obsolete binaries on the arches
> where pyraf no longer builds.
>
> https://qa.debian.org/excuses.php?package=pyraf

which is what I pargmatically did now (#886524). I was however not sure
what the optimal way is, since I also don't know which architectures are
co-runnable in practice. Theoretically, one could do anything with
qemu-userland, however.

Best regards

Ole

[1] https://github.com/olebole/zsvjmp/blob/master/zsvjmp-libunwind.c