Bug#943460: ITP: dnsenum -- tool to enumerate domain DNS information

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 

* Package name: dnsenum
  Version : 1.3.0
  Upstream Author : Network Silence 
* URL : https://github.com/SparrowOchon/dnsenum2
* License : GPL-2+
  Programming Lang: Perl
  Description : tool to enumerate domain DNS information

 Dnsenum is a multithreaded perl script to enumerate DNS information of a
 domain and to discover non-contiguous ip blocks. The main purpose of Dnsenum
 is to gather as much information as possible about a domain. The program
 currently performs the following operations:
 .
   1) Get the host's addresses (A record).
   2) Get the namservers (threaded).
   3) Get the MX record (threaded).
   4) Perform axfr queries on nameservers and get BIND versions(threaded).
   5) Get extra names and subdomains via google scraping (google query =
  "allinurl: -www site:domain").
   6) Brute force subdomains from file, can also perform recursion on subdomain
  that have NS records (all threaded).
   7) Calculate C class domain network ranges and perform whois queries on them
  (threaded).
   8) Perform reverse lookups on netranges (C class or/and whois netranges)
  (threaded).
   9) Write to domain_ips.txt file ip-blocks.
 .
 This program is useful for pentesters, ethical hackers and forensics experts.
 It also can be used for security tests.


I will maintain this package inside Debian Security Tools Packaging Team.

Bug#942808: ITP: dropbear-rescue -- A set of initramfs scripts to add and run dropbear when the system boots in rescue mode

[Guilhem Moulin]

Control: clone -1 -2
Control: reassign -2 dropbear-initramfs 2019.78-2
Control: retitle  -2 race condition: init-bottom doesn't abort/cleanup 
run_networking()
Control: severity -2 normal

On Thu, 24 Oct 2019 at 18:48:12 -0400, Anton Avramov wrote:
> However I've ran into a problem where if there is no panic and
> initramfs ipconfig command uses dhcp it would actually finish after
> the boot process is complete. And if the system itself uses static ip
> it gets overwritten by the dhcp.

Ah right, I understand the problem now.  Whether configure_networking()
is run (at premount stage) in the background or not depends on the boot
method.  On local (non-NFS) mounts it's done in the background, and
should be interrupted at bottom stage.  However if no other script is
waiting for interactive user input the bottom script might run before
dropbear had a chance to run yielding a race condition at bottom stage.
This is a bug.

> So the starting script in premount for dropbear should take care not
> to start if there is no /etc/crypttab and only start in case of panic.

dropbear-initramfs has nothing to do with /etc/crypttab, and it's not
because there are encrypted volumes to unlock that the boot process is
race-free: for instance these volumes might be unlocked in an unattended
fashion with a cheap PBKDF (or just plain dm-crypt).  Furthermore right
now the way the encrypted volumes are unlocked at initramfs stage, incl.
the location of the crypttab(5), is considered as an internal detail of
the cryptsetup-initramfs package :-P  That said I maintain that package
too, so I could help documenting the necessary interface if needs be :-D

> Considering my comment above should there be an option to activate
> dropbear in case of panic but no crypttab or there should be a config
> option to include and start dropbear in initramfs in case crypttab
> doesn't exists?

Once the race is eliminated from the init-bottom script (bug #-2),
run_dropbear() will unconditionally start, but be properly
terminated/cleaned before starting the init(1) binary.  That's your
second alternative; it's the simplest solution (either way there is a
bug that needs fixing) and it doesn't require further documentation from
initramfs-tools(7).  I also think it'd be reasonable to have an option
to run the premount script at panic stage instead.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Processed: Re: Bug#942808: ITP: dropbear-rescue -- A set of initramfs scripts to add and run dropbear when the system boots in rescue mode

[Debian Bug Tracking System]

Processing control commands:

> clone -1 -2
Bug #942808 [wnpp] ITP: dropbear-rescue -- A set of initramfs scripts to add 
and run dropbear when the system boots in rescue mode
Bug 942808 cloned as bug 943459
> reassign -2 dropbear-initramfs 2019.78-2
Bug #943459 [wnpp] ITP: dropbear-rescue -- A set of initramfs scripts to add 
and run dropbear when the system boots in rescue mode
Bug reassigned from package 'wnpp' to 'dropbear-initramfs'.
Ignoring request to alter found versions of bug #943459 to the same values 
previously set
Ignoring request to alter fixed versions of bug #943459 to the same values 
previously set
Bug #943459 [dropbear-initramfs] ITP: dropbear-rescue -- A set of initramfs 
scripts to add and run dropbear when the system boots in rescue mode
Marked as found in versions dropbear/2019.78-2.
> retitle  -2 race condition: init-bottom doesn't abort/cleanup run_networking()
Bug #943459 [dropbear-initramfs] ITP: dropbear-rescue -- A set of initramfs 
scripts to add and run dropbear when the system boots in rescue mode
Changed Bug title to 'race condition: init-bottom doesn't abort/cleanup 
run_networking()' from 'ITP: dropbear-rescue -- A set of initramfs scripts to 
add and run dropbear when the system boots in rescue mode'.
> severity -2 normal
Bug #943459 [dropbear-initramfs] race condition: init-bottom doesn't 
abort/cleanup run_networking()
Severity set to 'normal' from 'wishlist'

-- 
942808: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942808
943459: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943459
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#943456: ITP: m2r -- Markdown and reStructuredText in a single file - Python3 library

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name : python-m2r
  Version  : 0.2.1
  Upstream Author  : Hiroyuki Takagi 
* Url  : https://github.com/miyakogi/m2r
* Licenses : Expat
  Programming Lang : Python

 M2R converts a markdown file including reStructuredText (rst) markups
 to a valid rst format.
 .
 Use case is writing sphinx document in markdown,
 since it's widely used now and easy to write code blocks and lists.
 However, converters using pandoc or recommonmark
 do not support many rst markups and sphinx extensions.
 For example, rst's reference link like ``see `ref`_``
 (this is very convenient in long document
 in which same link appears multiple times)
 will be converted to a code block in HTML
 like `see ref_`,
 which is not expected.
 .
 This package provides m2r module
 for Python 3.

This package is needed by pantalaimon

I plan to maintain this package alone, keeping debianization in 
following Git repository:

 https://salsa.debian.org/debian/python-m2r.git

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#942808: ITP: dropbear-rescue -- A set of initramfs scripts to add and run dropbear when the system boots in rescue mode

[Anton Avramov]

On 2019-10-24 4:25 p.m., Guilhem Moulin wrote:

On Wed, 23 Oct 2019 at 16:04:31 -0400, Anton Avramov wrote:

On Mon., Oct. 21, 2019, 21:08 Guilhem Moulin,  wrote:

Given the scope of this package, I strongly believe it'd make more sense
to merge it with src:dropbear rather than shipping a separate source
package.

I agree. However I don't know how I can contribute to that.

It's never too late :-)  `apt showsrc dropbear-initramfs` gives a link
to the repository (hosted at salsa in the ‘Debian’ group).  Bugs,
including feature requests, are to be filed against the Debian BTS like
for any other package: https://bugs.debian.org/dropbear-initramfs .

Thank you very much! I'll do that then.



Following dropbear-initramfs package

You seem to suggest that your code takes inspiration from
dropbear-initramfs, but your copyright information doesn't reflect
that.

Sorry about that! I've tried to change that, but I'm not absolutely
certain I've done it right.

AFAICT only src/* and etc/* are taken from src:dropbear's debian/initramfs/*
(and modified by you), the rest is your own work.  Also AFAICT upstream
isn't a copyright holder for these scripts.

Regarding debian/control, your package shouldn't break or replace
dropbear <2015.68-1.  This was the case the case for drobear-initramfs
after the package split, but it doesn't apply here.  And AFAIK there is
no need to add a lower-bound on dropbear-bin's version.
  

that will install dropbear and would have the appropriate initramfs
scripts to start it in case the system enters rescue mode.

Why couldn't that be done in dropbear-initramfs instead?  Right now the
script is run at premount stage, but I guess we could have an option to
run it at another stage instead.

The only argument I can think of is to give the option to have separate
access for panic and crypt unlock.
[…]
And in principle I can give someone the right to unlock the fs, but
not login in case of panic where in that case and admin with higher
access should step in.

One can already separate access levels with a single authorized_keys(5)
file containing multiple keys and different restriction options.

dropbear-initramfs spawns the sshd at init-premount stage, ie after udev
has been started and modules loaded.  AFAIK it's unreliable to start it
earlier, because there might not be any network stack yet.  So if
initramfs-tools panics earlier you'll not be able to log in remotely
will you?

Yes, but in case it panics later it would be nice to be able to login :)

  (Anyway, again ‘panic’ is not a documented initramfs-tools(7)
subdirectory.)

I'll try to find some time and do something about that also.

  And if it panics later, for instance due to a missing
block device, then one should be able to log-in using dropbear-initramfs
alone.
Initially I've tried to just trick dropbear-initramfs by creating empty 
/etc/crypttab and then creating only a panic script to start if it 
wasn't started. However I've ran into a problem where if there is no 
panic and initramfs ipconfig command uses dhcp it would actually finish 
after the boot process is complete. And if the system itself uses static 
ip it gets overwritten by the dhcp. So the starting script in premount 
for dropbear should take care not to start if there is no /etc/crypttab 
and only start in case of panic.

By compatible I mean they can run together without interfering given they
use different port. Since there are only 2 scripts in initramfs I'm not
sure how would they suppose to share the code if we assume they are
different packages

Using Depends: plus maybe some refactoring on the drobpear-initramfs
side would be a way, but IMHO no separate binary package (let alone a
source package) is needed :-P  dropbear-initramfs's purpose is to expose
the dropbear sshd at initramfs stage, starting as early as possible and
for as long as possible.  It can be useful to unlock encrypted volumes,
but it's not its only use-case.

OK. Lets go that path. Considering my comment above should there be an 
option to activate dropbear in case of panic but no crypttab or there 
should be a config option to include and start dropbear in initramfs in 
case crypttab doesn't exists?


Best Regards

Bug#942808: ITP: dropbear-rescue -- A set of initramfs scripts to add and run dropbear when the system boots in rescue mode

[Guilhem Moulin]

On Wed, 23 Oct 2019 at 16:04:31 -0400, Anton Avramov wrote:
> On Mon., Oct. 21, 2019, 21:08 Guilhem Moulin,  wrote:
>> Given the scope of this package, I strongly believe it'd make more sense
>> to merge it with src:dropbear rather than shipping a separate source
>> package.
> 
> I agree. However I don't know how I can contribute to that.

It's never too late :-)  `apt showsrc dropbear-initramfs` gives a link
to the repository (hosted at salsa in the ‘Debian’ group).  Bugs,
including feature requests, are to be filed against the Debian BTS like
for any other package: https://bugs.debian.org/dropbear-initramfs .

>>> Following dropbear-initramfs package
>> You seem to suggest that your code takes inspiration from
>> dropbear-initramfs, but your copyright information doesn't reflect
>> that.
> 
> Sorry about that! I've tried to change that, but I'm not absolutely
> certain I've done it right.

AFAICT only src/* and etc/* are taken from src:dropbear's debian/initramfs/*
(and modified by you), the rest is your own work.  Also AFAICT upstream
isn't a copyright holder for these scripts.

Regarding debian/control, your package shouldn't break or replace
dropbear <2015.68-1.  This was the case the case for drobear-initramfs
after the package split, but it doesn't apply here.  And AFAIK there is
no need to add a lower-bound on dropbear-bin's version.
 
>>> that will install dropbear and would have the appropriate initramfs
>>> scripts to start it in case the system enters rescue mode.
>>
>> Why couldn't that be done in dropbear-initramfs instead?  Right now the
>> script is run at premount stage, but I guess we could have an option to
>> run it at another stage instead.
> 
> The only argument I can think of is to give the option to have separate
> access for panic and crypt unlock.
> […]
> And in principle I can give someone the right to unlock the fs, but
> not login in case of panic where in that case and admin with higher
> access should step in.

One can already separate access levels with a single authorized_keys(5)
file containing multiple keys and different restriction options.

dropbear-initramfs spawns the sshd at init-premount stage, ie after udev
has been started and modules loaded.  AFAIK it's unreliable to start it
earlier, because there might not be any network stack yet.  So if
initramfs-tools panics earlier you'll not be able to log in remotely
will you?  (Anyway, again ‘panic’ is not a documented initramfs-tools(7)
subdirectory.)  And if it panics later, for instance due to a missing
block device, then one should be able to log-in using dropbear-initramfs
alone.

> By compatible I mean they can run together without interfering given they
> use different port. Since there are only 2 scripts in initramfs I'm not
> sure how would they suppose to share the code if we assume they are
> different packages

Using Depends: plus maybe some refactoring on the drobpear-initramfs
side would be a way, but IMHO no separate binary package (let alone a
source package) is needed :-P  dropbear-initramfs's purpose is to expose
the dropbear sshd at initramfs stage, starting as early as possible and
for as long as possible.  It can be useful to unlock encrypted volumes,
but it's not its only use-case.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#636734: systune

[Sudip Mukherjee]

Hi All,

Is this package still being used? I downloaded it and had a look at the
source and also played with it in my laptop, its only a very simple script
which is doing 'cat' to read the values and then using 'echo' to restore
the values to /proc.


-- 
Regards
Sudip

Bug#943435: ITP: nio -- Python Matrix client library with sane I/O principles

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name : python3-matrix-nio
  Version  : 0.6
  Upstream Author  : Damir Jelić 
* Url  : https://github.com/poljar/matrix-nio
* Licenses : ISC
  Programming Lang : Python

 Nio is a multilayered matrix client library.
 The underlying base layer doesn't do any IO on its own.
 On top of the base layer,
 a no-IO HTTP client implementation exists,
 as well as a full fledged batteries included asyncio layer
 using aiohttp.

This package is needed by pantalaimon.

I plan to maintain this package in the Matrix team, keeping 
debianization in following Git repository:

 https://salsa.debian.org/debian/python-matrix-nio.git

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#866502: how does the riot.im repository then do it?

[Jonas Smedegaard]

Hi Talby,

Marco wrote:
> Hello, and sorry if out of topic, but how is it possible that the 
> upstream page riot.im can provide the riot-web deb package in their 
> provided repository?
> I don't get how in Debian it should technically not be possible to do 
> the same as upstream. And isn't it possible to simply invite them 
> /guide them / help them to become an official Debian package 
> maintainer, so that they can provide riot-web themselves in Debian?

A "Debian package" can mean either a package installable into a Debian 
system, or a package releasable with Debian itself.

Creating a .deb file installable into a Debian system requires little 
more than making a tarball or a zip file (if upstream build routines are 
sensible).

Creating a package that follows Debian Policy and is maintained as part 
of Debian requires more than that - some of it pointed out in previous 
posts to this bugreport.

I don't say this to diminish the effort done by upstream in providing a 
.deb package: That is nice, and a help for those who decide to trust 
upstream in not only creating and maintaining their own project but also 
in creating and mainting install routines executed as root on the target 
systems.

Anyone - you and upstream too - are welcome to join Debian and maintain 
packages to be integrated with Debian officially.  It does _not_ require 
you to go through any special process to become "members of Debian", you 
can simply request to join e.g. the Matrix team and start helping out.  
More information at https://wiki.debian.org/Matrix - and more generally 
at https://www.debian.org/devel/join/


Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#943419: RFA: python-requests-toolbelt -- Utility belt for advanced users of python-requests

[Ross Gammon]

Package: wnpp
Severity: normal

We request an adopter for the python-requests-toolbelt package.

The package description is:
 Collection of utilities for python-requests
 It provides transport adapters: FingerprintAdapter, SSLAdapter,
 SourceAddressAdapter, SocketOptionsAdapter, TCPKeepAliveAdapter

Petter and I both no longer have need for the package as it was package as a
dependency for creepy which is no longer in the archive.

It has picked up a few other reverse dependencies since though, so the package
is used.

The old Alioth git repository can be found archived here:
https://alioth-archive.debian.org/git/collab-maint/

It could be a good package for a new-comer to pick up. Perhaps as part of the
Debian Python Modules Team?

Regards,

Ross Gammon

Bug#943417: ITP: eslint-plugin-eslint-plugin -- ESLint plugin for linting ESLint plugins

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name : node-eslint-plugin-eslint-plugin
  Version  : 1.2.0
  Upstream Author  : Teddy Katz 
* Url  : 
https://github.com/not-an-aardvark/eslint-plugin-eslint-plugin
* Licenses : Expat
  Programming Lang : JavaScript

 This module, eslint-plugin-eslint-plugin, is an ESLint plugin
 for linting ESLint plugins.
 .
 ESLint is a tool for identifying and reporting on patterns
 found in ECMAScript/JavaScript code.

This package is needed by ESLint.

I plan to maintain this package in the JavaScript team, keeping 
debianization in following Git repository:

 https://salsa.debian.org/js-team/node-eslint-plugin-eslint-plugin.git

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#943414: ITP: eslint-visitor-keys -- Constants and utilities about visitor keys to traverse AST

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name : node-eslint-visitor-keys
  Version  : 1.1.0
  Upstream Author  : Toru Nagashima 
* Url  : https://github.com/eslint/eslint-visitor-keys
* Licenses : Apache-2.0
  Programming Lang : JavaScript

 This module, eslint-visitor-keys, provides onstants and utilities
 about visitor keys to traverse AST.
 .
 An abstract syntax tree (AST) is a tree representation
 of the abstract syntactic structure of source code
 written in a programming language.
 Each node of the tree denotes a construct
 occurring in the source code.

This package is needed by ESLint.

I plan to maintain this package in the JavaScript team, keeping 
debianization in following Git repository:

 https://salsa.debian.org/js-team/node-eslint-visitor-keys.git

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Processed: block 938718 with 943409, block 943409 with 941722

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> block 938718 with 943409
Bug #938718 [src:translate-toolkit] translate-toolkit: Python2 removal in 
sid/bullseye
938718 was blocked by: 938781
938718 was blocking: 936196 936289 936973 937410 937422 937558 937598 937695 
937700 937834 937875 937885 938022 938168 938251 938418 938484 938492 938528 
938578 938836
Added blocking bug(s) of 938718: 943409
> block 943409 with 941722
Bug #943409 [python3-cheroot] python3-cheroot: Missing dependency on 
python3-jaraco.functools
943409 was not blocked by any bugs.
943409 was blocking: 938718
Added blocking bug(s) of 943409: 941722
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
938718: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938718
943409: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943409
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#943411: ITP: cado -- Capability Ambient DO

[Mattia Biondi - mattia.bion...@studio.unibo.it]

Package: wnpp
Severity: wishlist
Owner: Mattia Biondi 

* Package name: cado
  Section : admin
  Version : 0.9.2
  Upstream Author : Davide Berardi, Renzo Davoli - VirtualSquare/University of
Bologna
* URL : http://wiki.virtualsquare.org
* License : GPL-2+
* Vcs : https://github.com/rd235/cado
  Programming Lang: C
  Description : Capability Ambient DO

Cado permits the delegation of capabilities to users. Cado is a capability
based sudo. Sudo allows authorized users to run programs as root (or as
another user), cado permits authorized users to run programs with specific
(ambient) capabilities. Cado is more selective than sudo, users can be
authorized to have only specific capabilities (and not others).

I will be the maintainer of the package.

Bug#943404: O: sopel -- simple, lightweight, open source, easy-to-use IRC utility bot

[Antoine Beaupre]

Package: wnpp
Severity: normal

I intend to orphan the sopel package.

I do not use Sopel anymore and therefore can't serve as a good
maintainer. I also couldn't find a good reason to use this instead of
more established codebase like Limnoria, which are seeing way more
development and third-party packages.

Limnoria is also well-maintained in Debian, so I am not sure sopel is
worth inclusion in Debian in the first place anymore.

The package description is:
 Sopel is a simple, lightweight, open source, easy-to-use IRC utility
 bot, written in Python. It's designed to be easy to use, easy to run,
 and easy to make new features for.
 .
 Sopel comes with a ton of ready-made features for you to use. It can
 leave notes for people, give you reminders, check RSS feeds, and much
 more.
 .
 Sopel also comes with a fully-documented and easy-to-use API, so you
 can write your own features. There's also an easy tutorial you can
 follow along with, to help you learn.
 .
 Developing for Sopel is a great way to familiarize yourself with
 Python. It's easy to start, but there's no limit to the cool things
 you can do with it.
 .
 Sopel was also known as Willie, Phenny or Jenni in previous
 incarnations.

Bug#932901: marked as done (ITP: tor-servers -- Metapackages for configuring tor relays and bridges)

[Debian Bug Tracking System]

Your message dated Thu, 24 Oct 2019 13:48:22 +0100
with message-id 
and subject line 
has caused the Debian Bug report #932901,
regarding ITP: tor-servers -- Metapackages for configuring tor relays and 
bridges
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.)


-- 
932901: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932901
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: wnpp
Severity: wishlist
Owner: "Iain R. Learmonth" 

* Package name: tor-servers
  Version : 0.0.0
  Upstream Author : Iain R. Learmonth 
* URL : None
* License : CC-0
  Programming Lang: Debian
  Description : Metapackages for configuring tor relays and bridges

This metapackage will build metapackages for configuring a tor daemon as
either a relay or a bridge in the Tor network. They will simplify the
currently complex set up process and implement best practices as
recommended by Tor Project.

This package will be maintained within the Privacy Maintainers team.
--- End Message ---
--- Begin Message ---
Admitting this is something I will be very unlikely to have time for.

The Tor bug remains open with no owner at:

https://trac.torproject.org/projects/tor/ticket/31153#comment:10



signature.asc
Description: OpenPGP digital signature
--- End Message ---

Processed: your mail

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 722578 ITP: st-console - simple mathematics statistics from the 
> command line interface
Bug #722578 [wnpp] ITP: nsum -- statistics for command-line interface (CLI)
Changed Bug title to 'ITP: st-console - simple mathematics statistics from the 
command line interface' from 'ITP: nsum -- statistics for command-line 
interface (CLI)'.
> tags 722578 pending
Bug #722578 [wnpp] ITP: st-console - simple mathematics statistics from the 
command line interface
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
722578: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722578
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: retitle 879741 to ITA: phpmyadmin -- MySQL web administration tool, owner 879741

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 879741 ITA: phpmyadmin -- MySQL web administration tool
Bug #879741 [wnpp] RFA: phpmyadmin -- MySQL web administration tool
Changed Bug title to 'ITA: phpmyadmin -- MySQL web administration tool' from 
'RFA: phpmyadmin -- MySQL web administration tool'.
> owner 879741 team+phpmyad...@tracker.debian.org
Bug #879741 [wnpp] ITA: phpmyadmin -- MySQL web administration tool
Owner recorded as team+phpmyad...@tracker.debian.org.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
879741: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879741
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems