Bug#1071199: O: wicd -- wired and wireless network manager written in Python

[Axel Beckert]

Package: wnpp
Severity: normal
X-Debbugs-Cc: w...@packages.debian.org, txg...@gmail.com, z...@fsfe.org, 
a...@bastelmap.de, b...@debian.org
Control: affects -1 + src:wicd

Let's face it, neither me nor Giap Tran haven't done anything on wicd
since 2019 — beside moving it from unstable to experimental due to the
rather incomplete upstream state of the Python 3 port. I even forgot
to push a commit for years. (I just pushed things now and merged
Bastian's changes from Salsa. → https://salsa.debian.org/debian/wicd)

Looking at https://git.launchpad.net/wicd/log/ it seems that since
then yet another dev (Andreas Messer) tried himself on wicd upstream
and stopped again. (The last dev I had contact with was Guido Serra.)

(I've X-Debbugs-Cc'ed all mentioned persons.)

I actually haven't looked yet if the code as of October 2022 (just
documentation changes afterwards) actually works as the last device
where I used wicd on for wifi connections (an Asus EeePC 900) got very
unreliable due to fan failure. And I haven't fixed that yet.

The package is currently only available in Debian Experimental (see
https://tracker.debian.org/pkg/wicd) and its description is:

 Wicd is a general-purpose network configuration server which aims
 to provide a simple but flexible interface for connecting to networks.

 Its features include:

  * wide variety of settings;
  * ability to connect to (and maintain profiles for) both wired and
wireless networks;
  * support for many encryption schemes, including WEP, WPA, WPA2 and
custom schemes;
  * wireless-tools compatibility;
  * tray icon showing network activity and signal strength;
  * lack of GNOME dependencies (although it does require GTK+), making it
easy to use in Xfce, Fluxbox, Openbox, Enlightenment, etc.

In case there's nobody stepping up for adoption within a month or two
or so, I'll probably request removal from Debian. It's in bad shape
for long enough and I have enough other packages which need my time.

Bug#1012289: RFH: lintian -- Debian package checker

[Axel Beckert]

Hi Bill,

Bill Allombert wrote:
> By the way, what happened to lintian.debian.org ?

Seems as if someone (not me, just noticed it today when
"private/refresh-data" failed…) pulled the plug on at least the DNS
name. Probably because it hasn't been updated since Felix' try to
rewrite it, which AFAIK was never finished, but the old thing also no
more worked. (There's probably a lot of legacy code in
"lib/Lintian/Output" related to one of these two website generations,
maybe even both.)

IMHO it's generally a good thing, except that it would have been
better to redirect it to the according UDD pages instead.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1012289: RFH: lintian -- Debian package checker

[Axel Beckert]

Hi,

Bastien Roucariès wrote:
> Le dimanche 4 février 2024, 14:02:58 UTC Bill Allombert a écrit :
> > Areyou still available as lintian maintainer ? It sure would need an upload.
> I can
> 
> I am doing some pull request update

By coincidence I started to work on Lintian today (well, actually
yesterday) again, too, but saw these two mails only afterwards. Mostly
fixed the systemd/udev/usrmerge related test suite failures as well as
merged some of the open merge requests.

Let's try together to get a release done soon.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1012289: Some questions about dpatch-related checks inside lintian (was: Re: Bug#1012289: RFH: lintian -- Debian package checker)

[Axel Beckert]

Hi again,

this mail contains several points. I separated them with markdown-like
headlines.


Removing dpatch stuff from Lintian?
---

Axel Beckert wrote:
> Bastien Roucariès wrote:
> > could you please check why autotest fail
> 
> Done now:
> 
> Lintian's autopkgtest fails on Salsa for a week now because dpatch has
> been removed from unstable a week ago: https://bugs.debian.org/1010626
> (Cc'ed)
[…]
> dpatch seems to be mentioned in 269 files of the test suite. I assume
> that at least all dpatch related tags can be removed now as there's no
> point in arguing about dpatch being used (or even used wrongly) if any
> package using it will FTBFS anyway.

Then again most of these cases seem to be the same case which was
split up in dozen cases (of which most still use but actually don't
seem to require dpatch anymore) when the test suite was changed from
running all checks against all test suite packages to running just
specific checks against each test suite package.

In other words: Code duplication and cruft at its best! :-(

But this also means that

a) in many cases we can just remove all the dpatch cruft without any
   impact. It's just not yet clear to me which cases those are were we
   can't remove the dpatch cruft.

b) It's currently unclear to me which test suite packages are just
   checked for source package checks. Those likely don't need dpatch
   as it's not needed to build the .dsc source package files.

So after a first try with removing all traces of dpatch, I decided
otherwise and I tried to just remove dpatch from debian/tests/control
and see what happens. I used a feature branch called "dpatch-removal"
for that (which I likely will force-push occasionally).


New test suite failures after dropping dpatch
-

But what happened was something completely unexpected and unrelated to
dpatch:

Errors were encountered while processing:
 emacs-nox
 dh-elpa
 autopkgtest-satdep

So this time it was the still very RC-buggy emacs 28.1 upload which
broke our test suite. *sigh*

I guess in this case we just have to wait until the emacs package is
fixed again.

At least locally we can still use emacs from testing for testing, but
that also makes it a bit more annoying if I later need dpatch again
in case I need to convert some test package with quilt2dpatch which
actually uses dpatch. (Hmmm, quilt ships that script, but has no
package relation with dpatch. Isn't that an RC bug?!? SCNR ;-)


What about the tags patch-system and more-than-one-patch-system?


Another question which popped up is if we still need that
classification tag "patch-system" and the warning
"more-than-one-patch-system" since these only new about quilt and
dpatch and nothing more. So shall we remove these completely? Or keep
the dpatch detection?


More test suite failures / How to run the test suite


Additionally the test suite now fails due to
lib/Lintian/Check/Cruft.pm no more being tidy:

Failed test 'Test::Perl::Critic for "lib/Lintian/Check/Cruft.pm"'
#   at /usr/share/perl5/Test/Perl/Critic.pm line 121.
#
#   lib/Lintian/Check/Cruft.pm:82:1:Use '{' and '}' to delimit multi-line 
regexps
#   lib/Lintian/Check/Cruft.pm:107:1:Use '{' and '}' to delimit multi-line 
regexps
#   lib/Lintian/Check/Cruft.pm:232:17:Useless use of $_
#   lib/Lintian/Check/Cruft.pm:238:1:Subroutine "full_text_check" does not end 
with "return"
#   lib/Lintian/Check/Cruft.pm:249:21:Subroutine called with "&" sigil
#   lib/Lintian/Check/Cruft.pm:263:9:"%matchedkeyword" is declared but not used

(And after fixing these, some more return-related issues inside
full_text_check popped up.)

I've tried to fix these. Will push that commit later today if the test
suite run currently running here locally doesn't find anything
related. (Usually such a run takes around 40 minutes here and I really
should go to bed now.)

Hint: The test suite can be run by calling "private/runtests" nowadays.

P.S.: I'm generally open to changing what perlcritic considers bad and
what not inside lintian. For now I just haven't changed anything, but
am not 100% happy with the current settings.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: PGP signature

Bug#1012289: RFH: lintian -- Debian package checker

[Axel Beckert]

Hi Bastien,

Bastien Roucariès wrote:
> could you please check why autotest fail

Done now:

Lintian's autopkgtest fails on Salsa for a week now because dpatch has
been removed from unstable a week ago: https://bugs.debian.org/1010626
(Cc'ed)

It seems as if package removals do not take into account autopkgtest
dependencies yet. :-/

dpatch seems to be mentioned in 269 files of the test suite. I assume
that at least all dpatch related tags can be removed now as there's no
point in arguing about dpatch being used (or even used wrongly) if any
package using it will FTBFS anyway.

Thanks for notifying me of that issue!

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: PGP signature

Bug#1012289: RFH: lintian -- Debian package checker

[Axel Beckert]

Hi Bastien,

Bastien Roucariès wrote:
> I have just reinstanced the sliding windows on master.

Yay, thanks!

> could you please check why autotest fail

Will do, but probably not before the weekend.

> BTW I am really supprised that test are not run at build time

The test suite currently runs around 35-40 minutes on my 6 year old
4-core workstation and even longer on Salsa CI (1h30m to 1h45m).

(At least those were the numbers when I last measured it. There are a
few commits in there now which probably reduce that time a bit.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: PGP signature

Bug#1012289: RFH: lintian -- Debian package checker

[Axel Beckert]

Hi Bastien,

Bastien Roucariès wrote:
> I will restep to be a lintian maint.

Yay, thanks! Much appreciated.

You're still in the "lintian" group of Salsa, so you should be still
able to commit to the repo.

> Could you please prepare a list of urgent action ?

Usually, if I consider a lintian bug to be urgent-ish, I bumped its
severity to important. (And you bumped one to serious already, too.
:-) So anything RC or "important" on
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=lintian;dist=unstable
is what we should focus on first, if possible. Those marked confirmed
are those I already looked at closer:

* #993613
* #1014083
* #1014162

Then there are two other topics I have a focus on, because I think,
they're important for all of us, because they're annoying:

* False Positives:
  
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=lintian-maint%40debian.org=false-positive

* Automatically migrating non-bracketed lintian overrides to bracketed
  ones. I started here, but it's mostly lacking migration regexp
  mappings for the hundreds of tags being affected:
  
https://salsa.debian.org/lintian/lintian/-/blob/migrate-overrides/bin/lintian-migrate-overrides-to-pointed-hints

  Note that this is currently only inside a feature branch which is
  not yet merged as it is far from helpful yet.

  This is actually my fix for https://bugs.debian.org/1007002

Oh, and one more thing: I want to adhere to Semantic Versioning — the
real one (https://semver.org/), not the one which Felix called
"Semantic Versioning" despite it wasn't Semantic Versioning.

So the versioning from now on will be BREAK.FEATURE.BUGFIX:

* Changing configuration semantic or syntax or exit codes will be a BREAK. 
* Adding new tags will be a FEATURE.
* No functional changes except bug fixes will be a BUGFIX.
* Pure documentation or build-system changes will be a BUGFIX, too.

And probably also:

* Renaming tags will be a BREAK. (Feel free to discuss if you
  disagree. :-))

Not yet sure about:

* Will be removing a tag a BREAK, too?

P.S.: Yeah, there was a bit of silence (despite not complete silence)
from me on lintian, but that was mostly due to holidays (in which was
way less online that I expected), some pre-holiday and some
post-holidays stress. And also because of RC bugs in some of my other
similarily important packages. Expect some more activity on Lintian
towards to next weekend. :-)

    Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: PGP signature

Bug#826286: Bug#1008415: libnih: FTBFS: dh_auto_test: error: make -j8 check VERBOSE=1 returned exit code 2

[Axel Beckert]

Hi Marius,

Marius Gripsgard wrote:
> libnih has been removed as dependency for lomiri-donwload-manager
> for a good while upstream [0]

Ah, nice!

> but has not had a release with this in it yet. So I make a new
> released lomiri-download-manager 0.1.1 with libnih removed as dep,
> and uploaded this to unstable.

Yay! Thanks a lot.

> So nih can be removed IMO.

Done so now: https://bugs.debian.org/1013225

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: PGP signature

Bug#1012289: A better future for Lintian / Bug#1012289: O: lintian -- Debian package checker

[Axel Beckert]

Control: retitle -1 RFH: lintian -- Debian package checker (actually ITA + RFH)

Hi Felix,

I only read about the "O: lintian" bug and your mailing list posting
via this week's "Work-needing packages report".

I'm on the Lintian mailing list, but procmail filters it into a
separate incoming box as I do for many mailing lists.

Felix Lechner wrote in April:
> Given Lintian's importance to the community, I don't think I am the
> right person to take care of Lintian or its website going forward.

Oof. Why that? IMHO you did a superb job on this!

But that explains the silence with regards to lintian uploads.

> The current HEAD is in my view in reasonable shape,

Ok, will try to make an upload soonish™ to at least get the current
state into unstable plus the most pressing low hanging fruits fixed,
e.g. like the new Debian Policy version via
https://salsa.debian.org/lintian/lintian/-/merge_requests/393 as well
as some more LHF merge requests. I also skimmed through the open MRs
and marked those as "approved" which I intent to merge. Hopefully will
manage to get that done latest the upcoming weekend.

I've also removed Chris (Cc'ed) from Uploaders due to his statement in
https://lists.debian.org/debian-lint-maint/2022/04/msg00017.html

Thanks to Chris and Felix for their long-time work on Lintian!

And thanks Paul for creating this "O:" bug report and refering to
these two mails!

Chris was the last one in the Uploaders field, so I've re-added myself
to Uploaders, too. Which also means that this is kind of an ITA. (I
was already in Uploaders from 2015 to 2019.)

To get some better bus-factor, I've also granted access to those who
requested membership in the Salsa group "lintian" and who are DDs,
namely Nilesh Patra and Yadd — both Cc'ed as well.

Welcome and thanks for your offers!

There are two more membership requests pending from people who are no
DD and from whom I've never heard before. One of them might be Bo YU
from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012289#12, but
none of the user or real names in the membership requests looks
similar.

Bo YU: What's your user name on Salsa? And maybe can you try to make
some contributions to Lintian via Merge Requests first? (The latter
basically counts for all non-DD membership requests.)

> except that the MLDBM databases introduced to mitigate Bug#1003456
> (excessive memory use when confronted with enormous ELF data) do not
> seem to get deleted during global destruction. There is also an open
> Perltidy bug (#998367) that keeps the Salsa pipeline from passing.

Thanks for these hints!

In general: I will try to keep Lintian in a sane state, but I surely
will not be able to put as much effort and time into Lintian as Felix
and Chris did.

I'm fluent in Perl, but I know that I'm not the best wrt. to
performance-critical Perl code. (Niels taught me some tricks at
DebConf15, though. :-)

So I'll likely will do mostly maintainance work, bug triage and some
bug fixing, but probably won't do any invasive changes, performance
tuning nor rewrites like Felix did.

Oh, and I also have no idea of how lintian.debian.org currently
works. I suspect, I need to get added to the "lintian" LDAP group to
be able to work on that. (It seems only Felix, Russ and Colin are
current members of that LDAP group.)

And I'm probably already stuck with too many packages, so any help is
really welcome.

In other words: We definitely need more people working on Lintian
again. So instead of declaring this as ITA, I've for now declared this
to be an RFH with a taste of ITA. I hope, that's ok. :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: PGP signature

Bug#1009727: O: ruby-curses -- curses binding for Ruby

[Axel Beckert]

Hi Andrej,

Andrej Shadura wrote:
> > Shall I close this bug already again as you still seem to care about
> > ruby-curses in contrary to what you stated back in 2020?
> 
> No, I still don’t intend to continue maintaining it 

*g*

> I originally packaged it as a dependency of a Ruby implementation of
> git-crecord which I wanted to package. However, I quickly became
> unsatisfied with it and instead ported the Python code of hg-crecord
> to Git, so ruby-curses became useless to me.

I see, thanks for that background information.

> If your package uses ruby-curses, it would be great if you could
> maintain this package in the Ruby team.

I was already thinking about doing an NMU or QA upload, but I
currently don't intend to adopt ruby-curses for various reasons:

* I've nearly no experience with Ruby and no experience with ruby
  library packaging or the according workflow at all.

* I already maintain too many packages. :-/

* The package in question (irqtop) is just a bycatch of the source
  package's main package I'm interested in: iptables-netflow-dkms.

  It sidekick irqtop is mostly a performance analysis and debug tool
  for that kernel module despite it has more general use cases, too.

  And I don't want ruby dependencies in a kernel module package for
  high performance traffic statistics. :-)

* The future of the irqtop package is a bit unclear since util-linux
  upstream introduced a C written command of the same name recently,
  too. See https://bugs.debian.org/1009668 for that discussion.

Anyway, thanks to your upload the most annoying issue with irqtop (the
ruby-written one) is now gone. Thanks again! :-)

    Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1009727: O: ruby-curses -- curses binding for Ruby

[Axel Beckert]

Hi Andrej,

Andrej Shadura wrote:
> On Fri, 15 Apr 2022, at 16:23, Axel Beckert wrote:
> > Acoording to
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959115#10 (also
> > attached) the ruby-curses package in Debian is orphaned since at least
> > April 2020 (last upload April 2018) as both the team listed in the
> > Maintainer field as well as the person listed in the Uploaders field
> > (all X-Debbugs-CC'ed) stated back then, that they are not maintaining
> > this package. And there was no new upload since then either.
> 
> Thanks for filing this bug. I have uploaded a newer release, pushed
> the Git changes to Salsa and will attempt to move it to the Ruby
> team.

Thanks a lot! That's really an unexpected and positive surprise!

Shall I close this bug already again as you still seem to care about
ruby-curses in contrary to what you stated back in 2020?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1009727: O: ruby-curses -- curses binding for Ruby

[Axel Beckert]

Package: wnpp
Severity: normal

Acoording to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959115#10 (also
attached) the ruby-curses package in Debian is orphaned since at least
April 2020 (last upload April 2018) as both the team listed in the
Maintainer field as well as the person listed in the Uploaders field
(all X-Debbugs-CC'ed) stated back then, that they are not maintaining
this package. And there was no new upload since then either.

This probably also explains why the package lacks multiple generations
of new upstream releases (currently 1.2.4 vs 1.4.4 according to
https://tracker.debian.org/pkg/ruby-curses) despite there is an
related bug report from April 2020. (https://bugs.debian.org/958973,
refering already to upstream version 1.3.2.) That bug report now has
become release-critical as the outdated version 1.2.4 in Debian
Unstable is not compatible with Ruby 3.0. And Ruby 3.0 is now is in
both Debian Unstable and Testing for more than a month, making
probably all reverse dependencies unusable

(Discovering #959115 after raising the severity of #958973 to
release-critical actually triggered this package-orphaning mail.)

Some information on the package:

Package: ruby-curses
Source: ruby-curses (1.2.4-1)
Version: 1.2.4-1+b6
Installed-Size: 89
Maintainer: Debian Ruby Extras Maintainers 

Architecture: amd64
Depends: ruby (>= 1:3.0~0), libc6 (>= 2.4), libncursesw6 (>= 6), libtinfo6 (>= 
6), libruby3.0 (>= 3.0.0~preview1), ruby (<< 1:3.1~)
Description: curses binding for Ruby
 Ruby binding for curses, ncurses, and PDCurses. curses is an
 extension library for text UI applications.
 .
 This module is built with wide character support.
Homepage: http://github.com/ruby/curses
Ruby-Versions: ruby3.0
Tag: uitoolkit::ncurses
Section: ruby
Priority: optional
Filename: pool/main/r/ruby-curses/ruby-curses_1.2.4-1+b6_amd64.deb
Size: 22176

Package: ruby-curses
Binary: ruby-curses
Version: 1.2.4-1
Maintainer: Debian Ruby Extras Maintainers 

Uploaders: Andrej Shadura 
Build-Depends: debhelper (>= 9~), gem2deb, libncursesw5-dev
Architecture: any
Standards-Version: 3.9.7
Format: 3.0 (quilt)
Files:
 75861e824ca9ea030b68b70d4fcb87c9 1752 ruby-curses_1.2.4-1.dsc
 866cd65ade499eaedbbaab7e35887b22 31399 ruby-curses_1.2.4.orig.tar.gz
 e21b2f8e218d1b13966a30f9e44c073c 2908 ruby-curses_1.2.4-1.debian.tar.xz
Vcs-Browser: https://browse.dgit.debian.org/ruby-curses.git/
Vcs-Git: https://git.dgit.debian.org/ruby-curses
Homepage: http://github.com/ruby/curses
Dgit: 4eab6fe2b7f725fc089335ad43387e234bd1bb02 debian archive/debian/1.2.4-1 
https://git.dgit.debian.org/ruby-curses
Package-List:
 ruby-curses deb ruby optional arch=any
Ruby-Versions: all
Testsuite: autopkgtest-pkg-ruby
Directory: pool/main/r/ruby-curses
Priority: optional
Section: misc

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
--- Begin Message ---
On Wed, Apr 29, 2020 at 11:20:42AM -0300, Antonio Terceiro wrote:
> This package says its maintained by the Debian Ruby team, but it's not
> in the team repositories.
> 
> Maintainer: Debian Ruby Extras Maintainers 
> 
> Uploaders: Andrej Shadura 
> [...]
> Vcs-Browser: https://browse.dgit.debian.org/ruby-curses.git/
> Vcs-Git: https://git.dgit.debian.org/ruby-curses
> 
> If it's intendent to be team-maintained, it should be added to the
> ruby-team group on salsa. Otherwise, please do not list the team in the
> Maintainer: field.

Thanks for noticing. I do not intend to use or maintain this package, feel
free to properly take it over. Since it is currently in dgit only, the
repo is missing the upstream branch (since dgit doesn’t preserve it), but
I’m sure it should be fairly easy to identify the commit the branch should
be pointing at.

-- 
Cheers,
  Andrej--- End Message ---


signature.asc
Description: PGP signature

Bug#947063: ITP: pass-import -- Pass extension for importing ata from existing password managers

[Axel Beckert]

Control: retitle -1 ITP: pass-import -- Pass extension for importing ata from 
existing password managers

Dear Hans-Christoph,

Hans-Christoph Steiner wrote in December 2019:
> * Package name: pass-import
>   Version : 2.6
>   Upstream Author : Alexandre Pujol
> * URL : https://github.com/roddhjav/pass-import
> * License : GPLv3
>   Programming Lang: Python
>   Package source  :
> https://salsa.debian.org/alexander.tolios-guest/pass-import
>   Description:
>  Pass extension for importing data from existing password managers

Any news on this? The Salsa repository seems to be a bit behind
upstream with regards to upstream releases: The packaging is still at
2.6 (released June 2019) while upstream is at 3.2, released half a
year ago in May 2021.

I think seeing this tool in Debian would be a real benefit as the pass
eco-system seems to really gain in importance and popularity.

P.S.: I allowed myself to fix the ITP title as Kunal Mehta already
suggested.

    Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#994644: trickle homepage gives "403 Forbidden": Might be a web server misconfiguration

[Axel Beckert]

Hi,

after Debian's package maintainer of trickle went MIA (see
https://bugs.debian.org/994644, CC'ed) I'm trying to revamp the
package as a QA measure. First thing I noticed is that the homepage of
trickle (https://monkey.org/~marius/pages/?page=trickle) gives a "403
Forbidden".

Since anything under https://monkey.org/~marius/pages/ seems to throw
this error (and not a "404 Not Found"), I suspect that this is just a
misconfiguration and not on purpose. (Or should
https://github.com/mariusae/trickle be seen as trickle's homepage?)

Mind having a look at it? Thanks in advance!

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#905014: I'm adopting dhcpy6d

[Axel Beckert]

Control: retitle -1 RFA: dhcpy6d -- MAC address aware DHCPv6 server written in 
Python
Control: noowner -1

Hi Moritz,

Moritz Schlarb wrote in March 2019:
> Control: retitle -1 ITA: dhcpy6d -- MAC address aware DHCPv6 server written 
> in Python
> Control: owner -1 !
[…]
> I'm willing to adopt dhcpy6d.
> 
> I will create a project in the Salsa PAPT namespace for it.

despite there was quite some more discussion in this bug report, I
unfortunately haven't read or seen any further activity of you in this
matter in the past 2.5 years. (I though see other Debian activity from
you, so you don't seem MIA. :-)

To allow others to adopt this package as well, I'm herewith setting it
back to RFA. Feel free to change it back to ITA if you still intend to
adopt this package. (It though would be nice to see some activity of
you towards that direction, too.)

To any potential adopter of this package, be it Moritz or someone
else:

As of 21st of August, the package in Debian Unstable and Testing is
again up to date with upstream after the freeze for the Debian 11
Bullseye release. https://salsa.debian.org/debian/dhcpy6d is up to
date as well as and all contain the package version 1.0.5-1.

Since I have a minimal test environment at home, I can rudimentarily
test the package and will do further updates of the package. But it
still holds true that I don't use it anymore in production — which is
suboptimal for a package maintainer. Accordingly I would like to see
someone adopting it who actually uses it in production — and who
preferably knows more Python than me. ;-)

But since Henri is a very helpful and responsive upstream, the amount
Python knowledge actually isn't such a hard adoption criteria. :-)

P.S.: Please be aware that the project's homepage URL (mainly the
domain) as well as upstream's e-mail address changed. With the upload
from yesterday, the package is also up to date with regards to this.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: PGP signature

Bug#925043: O: translate -- translates words from English into German or viceversa

[Axel Beckert]

Control: retitle -1 ITA: translate -- translates words from English into German 
or viceversa
Control: owner -1

In intended to do this already quite a while ago and Jelmer's QA
upload reminded me of it.

I'm a daily and heavy user of it...

Pierre-Elliott Bécue wrote:
> The current maintainer of translate, Anibal Monsalve Salazar 
> ,
> is apparently not active anymore.  Therefore, I orphan this package
> now.

*sigh* Yeah, not the first package I took over from Anibal.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#365427: [O: apt-build] Is this package worth adopting or has it been replaced?

[Axel Beckert]

Hi,

No Body wrote:
> Is this package worth adopting or has it been replaced by something
> else?

There's nothing like it so far AFAIK. apt-src is close, but has a
different focus (modification instead of compile-time optimization).

> I read the entire bug message history and saw that in 2016 there was some
> development going on to replace the package.

I don't see which message you mean. In 2016, there were only control
messages and spam in this bug report.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#948384: abandoning elasticsearch

[Axel Beckert]

Control: retitle -1 RFP: elasticsearch -- "Open Source" (but non-free and not 
OSI-compliant), Distributed, RESTful Search Engine
Control: tag -1 + wontfix

Hi,

Kartik Kulkarni wrote:
> Due to lack of time and other constraints last year I was unable to
> look into the package at all and I think it's better for someone else
> to package it.

Nobody will gonna package this for Debian anymore since they changed
their license to the non-free SSPL. MongoDB got kicked out because of
doing that. Tagging as wontfix for now.

> I do not know if I should just put it back as RFP

Yes.

> but for now I have retitled it as O.

That's wrong as "O:" is just for packages _already_ in Debian. I'm
retitling it back to RFP with this mail accordingly.

    Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#981055: Fwd: Re: Heads up: Bug#981055: O: john -- active password cracking tool [origin: hert...@debian.org]

[Axel Beckert]

Control: retitle -1 ITA: john -- active password cracking tool
Control: owner -1 Debian Security Tools 

Hi,

with Julián (previous co-maintainer of john who wants to continue to
work on it, CC'ed) already being in pkg-security-team on Salsa and me
being invited to join (see below), we'll solve this WNPP issue by
moving john under the Debian Security Tools Packaging Team umbrella.

I think this is a good solution for all interested parties as well as
Debian's and Kali's john users. :-)

- Forwarded message from Raphael Hertzog  -
Date: Tue, 26 Jan 2021 09:34:54 +0100
From: Raphael Hertzog 
To: Axel Beckert 
Cc: Debian Security Tools 
Subject: Re: Heads up: Bug#981055: O: john -- active password cracking tool

Hello Axel,

On Tue, 26 Jan 2021, Axel Beckert wrote:
> just a heads up since I know that the Kali people maintain their own,
> much more featureful john package and I wonder if we can get that into
> Debian now:
> 
> john has been orphaned by the MIA team just today:
> https://bugs.debian.org/981055

Thanks for the notification. I believe it's a good idea, yes. We'll take
care of it.

> I'm thinking about doing a QA upload to at least fix that RC bug, but
> I do not intent to take over the package maintenance as I'm sure some
> of you can do that much better than I can do and the Kali people
> already have john 1.9.0 packaged.

I would not mind if you joined pkg-security :-)

Cheers,
>-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS
- End forwarded message -

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#981055: O: john -- active password cracking tool

[Axel Beckert]

Hi again,

Axel Beckert wrote:
> Julián Moreno Patiño wrote:
> > I will continue maintaining john the ripper package, but please go
> > ahead with the QA Upload.
[…]
> The Debian Security Tools Packaging Team (Cc'ed) also showed interest
> in the package. So I recommend to continue packaging it under their
> umbrella:

I just noticed that you already joined that team three years ago.

So I will go ahead and move the debian/john git repo on Salsa to the
pkg-security-team group and update it to their standards.

I'll also re-add you as Uploader. :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#981055: O: john -- active password cracking tool

[Axel Beckert]

Hi Julián,

cool to hear from you! (Actually didn't expect a that quick reaction. :-)

Julián Moreno Patiño wrote:
> I will continue maintaining john the ripper package, but please go
> ahead with the QA Upload.

Already did last night as I wanted to fix that RC bug as quick as
possible. But as it was a QA upload I've resetted Maintainer and Uploader
fields. :-/ But of course you are free to re-add yourself.

The Debian Security Tools Packaging Team (Cc'ed) also showed interest
in the package. So I recommend to continue packaging it under their
umbrella:

https://wiki.debian.org/Teams/pkg-security
https://tracker.debian.org/teams/pkg-security/
https://lists.debian.org/debian-security-tools

Also because that team works close with Kali Linux which already have
the most recent Jumbo version of john packaged in .deb format which is
requested in at least two bug reports against john in Debian.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#981055: O: john -- active password cracking tool

[Axel Beckert]

Hi,

Baptiste Beauplat wrote:
> The current maintainer of john, Ruben Molina ,
> is apparently not active anymore.  Therefore, I orphan this package now.

I assume that the listed Uploader (who did the last maintainer upload
in 2014) is also fine with that. Cc'ed.

> Maintaining a package requires time and skills. Please only adopt this
> package if you will have enough time and attention to work on it.

I do not intent to adopt the package, but I will do an QA upload to
fix at least the RC bug since testing autoremoval is imminent and I do
want to see john in bullseye even if its this rather old version. See
https://bugs.debian.org/979054 for details.

I've imported the whole packaging history from snapshots.debian.org
into Salsa at https://salsa.debian.org/debian/john, so anyone who
wants to take over can simply start there.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#700337: RFP: kibana --- heads up: upstream license change to the non-free SSPL

[Axel Beckert]

Hi again,

a lot of things and discussions are currently happening around the
license change of ElasticSeach and Kibana. Some of those are probably
also interesting in this context of packaging work of Kibana:

Axel Beckert wrote:
> just a heads up for everyone interested in seeing Kibana (and maybe
> ElasticSearch) in Debian:
> 
> The license for Kibana and ElasticSearch is changing:
> https://www.elastic.co/de/blog/licensing-change

For those who still would like to see Kibana being packaged for
Debian, there's a fork of the old code underway under the previous
license (Apache License 2.0) by AWS and several other companies:

https://aws.amazon.com/de/blogs/opensource/stepping-up-for-a-truly-open-source-elasticsearch/
https://logz.io/blog/truly-doubling-down-on-open-source-2/

> And this SSPL is exactly what caused MongoDB to be removed from Debian
> as it is considered non-free. See these bug reports, especially the
> first one, for details:
> 
> https://bugs.debian.org/915537 (ftp.debian.org: MongoDB SSPL v1
> license and the DFSG)

Citing from that bug report:

  MongoDB has submitted the license to OSI for review[2]; the
  discussion there is still ongoing, but the initial response seems to
  be negative.

That application process got withdrawn by the license steward from
MongoDB due to mainly negative feedback:
http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-March/003989.html

But Elastic's move to SSPL seems to have triggered an explicit
statement of the OSI on the SSPL: https://opensource.org/node/1099 —
And the headline is quite clear: "The SSPL is Not an Open Source
License"

That statement sparked quite some discussion on Twitter:
https://twitter.com/OpenSourceOrg/status/1351605387347324929

        Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#700337: RFP: kibana --- heads up: upstream license change to the non-free SSPL

[Axel Beckert]

Hi,

just a heads up for everyone interested in seeing Kibana (and maybe
ElasticSearch) in Debian:

The license for Kibana and ElasticSearch is changing:
https://www.elastic.co/de/blog/licensing-change

Citing from this page:
> Moving to the dual license strategy with SSPL or the Elastic License
> is a natural next step for us after opening our commercial code and
> creating a free tier, all under the Elastic License, nearly 3 years
> ago. It is similar to those made by many other open source companies
> over these years, including MongoDB, which developed the SSPL. The
> SSPL allows free and unrestricted use, as well as modification, with
> the simple requirement that if you provide the product as a service,
> you must also publicly release any modifications as well as the
> source code of your management layers under SSPL.

And this SSPL is exactly what caused MongoDB to be removed from Debian
as it is considered non-free. See these bug reports, especially the
first one, for details:

https://bugs.debian.org/915537 (ftp.debian.org: MongoDB SSPL v1 license and the 
DFSG)
https://bugs.debian.org/916107 (MongoDB should not be part of a stable release)
https://bugs.debian.org/947743 (RM: mongodb -- RoQA; rc-buggy; un-upgreadable 
due to license issues; …)

The same happened with MongoDB in RedHat Enterprise Linux:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/8.0_release_notes/rhel-8_0_0_release#BZ-1647908

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#978109: ITP: elpa-ligature -- display typographical ligatures in Emacs major modes

[Axel Beckert]

Hi,

Axel Beckert wrote:
> I intent to maintain this package under the umbrella of the Debian
> Emacsen Team (X-Debbugs-CC'ed). Until I get Salsa write access to their
> repos, I published my work temporarily at
> https://salsa.debian.org/abe/elpa-ligature

The repo has been moved to
https://salsa.debian.org/emacsen-team/elpa-ligature

I just uploaded the first version to Debian Experimental and it should
show up in the NEW queue within an hour or so.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#978110: ITP: libsoftware-license-orlaterpack-perl -- Use GNU licenses with "or later" clause in Software::License

[Axel Beckert]

Package: wnpp
Owner: Axel Beckert 
Severity: wishlist

* Package name: libsoftware-license-orlaterpack-perl
  Version : 0.10.2
  Upstream Author : Van de Bugger 
* URL : https://metacpan.org/release/Software-License-OrLaterPack
* License : GPL-3+
  Programming Lang: Perl
  Description : Use GNU licenses with "or later" clause in Software::License

Software::License::OrLaterPack allows one to use GNU licenses with
"or later" clause where Software::License style license names are
supported.

All "or later" are just subclasses of corresponding base license
classes. For example, Software::License::GPL_3::or_later is a
subclass of Software::License::GPL_3, so any "or later" license can
be used like any other license. For example, in your dist.ini file:

  license = GPL_3::or_later

However, licenses in the pack introduce few features not found in
base classes.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#978109: ITP: elpa-ligature -- display typographical ligatures in Emacs major modes

[Axel Beckert]

Package: wnpp
Owner: Axel Beckert 
Severity: wishlist

* Package name: elpa-ligature
  Version : 1+24+gc830b9d
  Upstream Author : Mickey Petersen 
* URL : https://github.com/mickeynp/ligature.el
* License : GPL-3+
  Programming Lang: Emacs-Lisp
  Description : display typographical ligatures in Emacs major modes

This package converts graphemes (characters) present in major modes
of your choice to the stylistic ligatures present in your frame's
font. It though only works with Debian's emacs-gtk package.

Additionally, this Debian package automatically enables system-wide
all known programming ligatures of Fira Code and Jetbrains Mono for
programming modes and the "www" ligature of Fira Code for all major
modes.



I intent to maintain this package under the umbrella of the Debian
Emacsen Team (X-Debbugs-CC'ed). Until I get Salsa write access to their
repos, I published my work temporarily at
https://salsa.debian.org/abe/elpa-ligature

Bug#977321: O: autoconf2.13 -- automatic configure script builder (obsolete version)

[Axel Beckert]

Hi Ben,

Ben Pfaff wrote:
> This package is really obsolete.  It has several bug reports but the
> right thing to do is probably to get any packages that use autoconf2.13
> updated to use something else.  (Or removed; they are antiques
> themselves.)

While I hoped that you are right, there seem at least two big blockers
on a first glance: Firefox and Thunderbird.

I tried to make a quick list of affected packages:

→ grep-dctrl -s Package -FBuild-Depends,Build-Depends-Indep,Build-Depends-Arch 
autoconf2.13 /var/lib/apt/lists/*Source* | fgrep Package | sort -u
Package: firefox
Package: firefox-esr
Package: gcc-3.3
Package: gcc-m68hc1x
Package: grass
Package: maxima
Package: mozjs52
Package: mozjs78
Package: postgis
Package: thunderbird
Package: vflib3
Package: xemacs21

And yeah, some packages in this list are really old. gcc-3.3 recently
has been orphaned for similar reasons: https://bugs.debian.org/966317

So I tried to figure out which versions of Firefox and Thunderbird
exactly are affected and it started to look less bad:

→ apt-cache showsrc firefox firefox-esr thunderbird | egrep 
'Package:|autoconf|Version:|^$' | sed -e 's/autoconf2\.13.*/autoconf2\.13, …/g'
Package: firefox
Version: 81.0-2
Build-Depends: autotools-dev, debhelper (>= 9.20160114), autoconf2.13, …
Standards-Version: 3.9.8.0

Package: firefox
Version: 82.0.3-1
Standards-Version: 3.9.8.0

Package: firefox
Version: 83.0-1
Standards-Version: 3.9.8.0

Package: firefox
Version: 84.0-1
Standards-Version: 3.9.8.0

Package: firefox-esr
Version: 78.5.0esr-1
Build-Depends: autotools-dev, debhelper (>= 9.20160114), autoconf2.13, …
Standards-Version: 3.9.8.0

Package: firefox-esr
Version: 78.6.0esr-1
Build-Depends: autotools-dev, debhelper (>= 9.20160114), autoconf2.13, …
Standards-Version: 3.9.8.0

Package: thunderbird
Version: 1:78.5.1-1
Build-Depends: autoconf2.13, …
Standards-Version: 4.5.1

Package: thunderbird
Version: 1:78.6.0-1
Build-Depends: autoconf2.13, …
Standards-Version: 4.5.1

Package: thunderbird
Version: 1:84.0~b3-1
Build-Depends: autoconf2.13, …
Standards-Version: 4.5.1

So while the current Firefox-ESR and Thunderbird are affected, the
Firefox from version 82 onwards seem to no more be affected. (The list
contains versions from Unstable, Experimental and Testing.)

But then again Thunderbird 84 still is using autoconf2.13. So
hopefully the latter can be fixed by just replacing the
build-dependency and maybe some minor other tweaks.

So in the end, removing autoconf2.13 doesn't look too hard, but still
might need some time and work.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#972607: ITP: pdns-logger -- PowerDNS protobuf logger

[Axel Beckert]

Control: retitle -1 ITP: pdns-protobuf-receiver -- PowerDNS protobuf log stream 
receiver

The upstream project has been renamed, see
https://github.com/dmachard/pdns-protobuf-receiver/issues/4#issuecomment-714571761

Some URLs have changed accordingly:

Axel Beckert wrote:
> * URL or Web page : https://github.com/dmachard/pdns_logger

It's now https://github.com/dmachard/pdns-protobuf-receiver/

> WIP packaging is available at
> https://salsa.debian.org/debian/pdns-logger

It's now https://salsa.debian.org/debian/pdns-protobuf-receiver

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#972607: ITP: pdns-logger -- PowerDNS protobuf logger

[Axel Beckert]

Package: wnpp
Owner: Axel Beckert 
Severity: wishlist

* Package name: pdns-logger
  Version : 0.0.2
  Upstream Author : Denis Machard 
* URL or Web page : https://github.com/dmachard/pdns_logger
* License : MIT (yes, "MIT" as in https://spdx.org/licenses/MIT;
there is no Expat on https://spdx.org/licenses/)
  Programming Lang: Python
  Description : PowerDNS protobuf logger

PDNS logger is a daemon or commandline tool written in Python 3 that
provides a protobuf log receiver for PowerDNS's products.

You can use it to collect DNS queries and responses and to log to
syslog or a json remote tcp collector.

WIP packaging is available at
https://salsa.debian.org/debian/pdns-logger

Bug#905014: Short status message about dhcpy6d in Debian Unstable and the Python 2 to 3 migration

[Axel Beckert]

Hi,

Axel Beckert wrote:
> just a short update on dhcpy6d in Debian Unstable (and the Python 2 to
> 3 migration):
> 
> I'm planning to do an upload of the 1.0.1 upstream version to Debian
> Unstable soon (next few days) to fix the Python 2 to 3 migration issue
> (#936391) and get the package back in shape.

Based on Henri's (binary-only) packaging changes for Python 3, I got a
version which builds as source and as binary package at
https://salsa.debian.org/debian/dhcpy6d

But it still throws a lot of lintian warnings, so there's still a lot
of work ahead before I can upload this.

You should be able to follow my packaging improvements in that git
repository.

Moritz: I've given you write access to the above mentioned git
repository. Feel free to join and maybe later take over?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#905014: Short status message about dhcpy6d in Debian Unstable and the Python 2 to 3 migration

[Axel Beckert]

Hi,

just a short update on dhcpy6d in Debian Unstable (and the Python 2 to
3 migration):

I'm planning to do an upload of the 1.0.1 upstream version to Debian
Unstable soon (next few days) to fix the Python 2 to 3 migration issue
(#936391) and get the package back in shape.

The RFA (#905014) still stands as I still don't have use for dhcpy6d
anymore (due to a job change a while ago). I can only test the package
under an artificial conditions in a temporary environment with e.g. a
handful Raspberry Pis and a desktop switch.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#873075: Package SCGI and SCGI::Request

[Axel Beckert]

Hi Richard,

Richard Hansen wrote:
> I noticed that https://github.com/raoulbhatia/backuppc copies
> https://metacpan.org/pod/SCGI and
> https://metacpan.org/pod/SCGI::Request into the backuppc source
> code.

Urgh. Yeah, such things are the reason why we don't want to take over
that packaging.

> I packaged those modules in a new libscgi-perl package so that they
> can be brought in as dependencies instead.

Thanks!

> I need a sponsor to get it submitted, however:
> https://bugs.debian.org/963105

Sorry, oversaw your first mail on that. :-/

Richard Hansen wrote:
> libscgi-perl is now in testing, so backuppc can pull it in as a dependency.

And the Debian Perl Team is a good place for it. Thanks for the
contribution!

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#905014: I'm adopting dhcpy6d

[Axel Beckert]

Hi Moritz,

I'm very sorry for the late reply, but I only discovered your mail
today when working on a python-3-supporting dhcpy6d package (c.f.
#936391). You only sent the mail to the bug report which doesn't
forward it to the bug report submitter — and I forgot to subscribe to
messages to this bug report (done now), so I never received your mail
and only downloaded it now from the bug report to be able to reply to
it.

Moritz Schlarb wrote in March 2019:
> I'm willing to adopt dhcpy6d.

Thanks, much appreciated!

> I will create a project in the Salsa PAPT namespace for it.

Ah, cool, so you're someone who has more Python knowledge than I have!

Currently despairing with good and bad python module paths, lintian
claiming that using dh_python3 would fix those paths while I already
use dh_python3 and it doesn't help... Also the test suite still fails
due to unrecognized, but generated commandline options I don't seem to
be able to influence.

See https://github.com/xtaran/dhcpy6d/tree/debian-python3 for my
effort so far.

> Someone needs to add me to the upload ACL though.

I assume you are a DM then. Is that something which someone from PAPT
will do or do you expect me to do that? In the latter case, I'd prefer
to sponsor one or two uploads first.

At least I haven't found a dhcpy6d git repo on Salsa yet, neither
under https://salsa.debian.org/python-team/applications nor with a
global search on Salsa.

Regards from the Debian Snow Camp, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: PGP signature

Bug#950796: ITP: passivedns -- network sniffer that logs all DNS server replies

[Axel Beckert]

Package: wnpp
Owner: Axel Beckert 
Severity: wishlist

* Package name: passivedns
  Version : 1.2.1
  Upstream Author : Edward Bjarte Fjellskål 
* URL : https://github.com/gamelinux/passivedns
* License : GPL-2+
  Programming Lang: C
  Description : network sniffer that logs all DNS server replies for use in 
a passive DNS setup

A tool to collect DNS records passively to aid Incident handling, Network
Security Monitoring (NSM) and general digital forensics.

PassiveDNS sniffs traffic from an interface or reads a pcap-file and outputs
the DNS-server answers to a log file. PassiveDNS can cache/aggregate duplicate
DNS answers in-memory, limiting the amount of data in the logfile without
losing the essense in the DNS answer.

PassiveDNS works on IPv4 and IPv6 traffic and parse DNS traffic over TCP and
UDP.

---

I will maintain the package together with Sascha Steinbiss
(X-Debbugs-CC'ed).

Bug#864079: Status of this bug?

[Axel Beckert]

Hi,

Axel Beckert wrote:
> Yes, Jonathan Wiltshire (Cc'ed) pushed a packaging of it to
> https://salsa.debian.org/debian/backuppc-rsync
[...]
> Will work on this later on this week. Probably won't find time for it
> today.

Just noticed that Jonathan has put himself as maintainer so far and
don't want put in the BackupPC team without asking. :-/

Will nevertheless update the package in git a bit.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#864079: Status of this bug?

[Axel Beckert]

Hi,

sixerjman wrote:
> I would like to know if anybody is working on this.

Yes, Jonathan Wiltshire (Cc'ed) pushed a packaging of it to
https://salsa.debian.org/debian/backuppc-rsync

We also had a small Debian-BackupPC-Team meeting at MiniDebConf
Vaumarcus last weekend.

Jonathan wrote, that he's also working on the BackupPC 4 packaging.
But he doesn't seem to have pushed it to Salsa yet.

I though couldn't reach him by mail or IRC recently. (Tried to reach
him twice in the past two weeks, also because of our small team
meeting.) I assume, he's currently on vacation or so.

At the small team meeting we decided to wait a little bit more for his
work on BackupPC.

But I assume that we probably won't do much double work if we check
now what's left for getting backuppc-rsync through the NEW queue.
Especially if it helps wrt. to automatic BinNMUs. Thanks for this
hint. It didn't come to me that this might be an issue.

Will work on this later on this week. Probably won't find time for it
today.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#649860: marked as done (RFP: wwwoffle -- World Wide Web OFFline Explorer)

[Axel Beckert]

Hi Helmut,

Debian Bug Tracking System wrote:
> On Sun, Jan 08, 2017 at 05:11:34AM +0100, Axel Beckert wrote:
> > Bart Martens schrieb am Fri, Jan 06, 2017 at 04:20:17PM +:
> > > RFP 649860 has no visible progress for a long time, so closing.
> > 
> > That doesn't mean that there's no more interest in getting wwwoffle
> > back into Debian. It's an RFP and not an ITP after all.
> 
> I fear that Bart is right here.

Bart hasn't thought a single second about this. It was one of his
ignorant, purely time-based closing of WNPP-bug-reports which annoy
for quite some years now. And in addition to that he was MIA for quite
a while and didn't react at all to complaints.

> We've moved to a world where http-accessible sites are rare. Most
> redirect to https.

Well, rare is a bit exaggerating. But they're getting less, yes. And
while offering HTTPS is surely a good thing, those redirects are
controversial. IMHO the decision of HTTP or HTTPS should be solely
taken by the user (unless credentials are transmitted).

> Furthermore, a lot of sites have become so interactive that they are
> useless without javascript.

JavaScript is definitely not an issue for wwwoffle. IIRC it caches any
request, be it HTML, pictures, JavaScript or JSON. I'm just not sure
about POST requests.

> The utilty of wwwoffle is fairly low these days.

Fairly low is not zero.

> The removal was warranted.

The removal of the package or the removal of the RFP bug report?

Anyway, I'll ask a friend who's AFAIK still using wwwoffle on a daily
base and ask him if its working with HTTPS. If there's any sign that
it can cope with HTTPS, I'll reopen that RFP.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#825809: unclutter: diff for NMU version 8-21.1

[Axel Beckert]

Hi Sean,

Sean Whitton wrote:
> I've prepared an NMU for unclutter (versioned as 8-21.1) and uploaded it
> to DELAYED/15. Please feel free to tell me if I should delay it longer.

Yes, please remove it completely. It is incomplete and has unsolved
issues which might be even harder to fix properly afterwards if the
upload succeeds.

I'll try to upload unclutter 8-22 (to experimental) before that NMU
passes throught, but for that, I need your feedback first:

Please check the master branch under
https://salsa.debian.org/debian/unclutter and especially the commits I
made after applying your NMU patch minus the unnecessary NMU stuff:

https://salsa.debian.org/debian/unclutter/commits/master

Main points:

* Make /etc/X11/Xsession.d/90unclutter a slave alternative, too.
* Rename /etc/default/unclutter to /etc/default/unclutter-classic.
* Make debian/unclutter.install executable. (Might have been lost when
  you generated your patch as it clearly FTBFS else.)

I'd appreciate if you could look over these changes and tell me if you
agree (as we both should agree on at least the list of slave
alternatives), have alternative suggestions or otherwise comments.

Open issues and why I haven't uploaded the current state to
experimental yet:

* In the current setup, /etc/default/unclutter might need to be a
  slave alternative, too. Not sure, though. Thoughts on this are
  welcome!

* /etc/default/unclutter and /etc/X11/Xsession.d/90unclutter could be
  implementation-independent files, but then they need to be shipped
  either by both packages (which causes a file conflict) or we create
  some unclutter-common packages with just the common files between
  both implementations.

  Looks like the least complex implementation to me, but is probably
  also the one with the most coordination effort between the
  maintainers of both packages. (I suggest to maintain such a package
  together in git so that either maintainer can easily upload fixes.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#825809: unclutter: diff for NMU version 8-21.1

[Axel Beckert]

Hi Sean,

Sean Whitton wrote:
> +
> +override_dh_auto_install:
> +

Hmmm, I think that could be avoided.

> +override_dh_installman:
> + cp unclutter.man debian/tmp/unclutter-classic.man
> + dh_installman debian/tmp/unclutter-classic.man

Hmmm, this looks rather ugly to me. If we already use dh-exec, we
should use it for that, too, IMHO.

> diff -Nru unclutter-8/debian/unclutter.install 
> unclutter-8/debian/unclutter.install
> --- unclutter-8/debian/unclutter.install  2017-12-30 11:53:06.0 
> -0700
> +++ unclutter-8/debian/unclutter.install  2019-08-31 12:32:55.0 
> -0700
> @@ -1,2 +1,4 @@
> -debian/local/90unclutter /etc/X11/Xsession.d
> -unclutter/usr/bin
> +#!/usr/bin/dh-exec
> +
> +debian/local/90unclutter => /etc/X11/Xsession.d/90unclutter
> +unclutter=> /usr/bin/unclutter-classic

I think we'll have some issues if we don't include
/etc/X11/Xsession.d/90unclutter in the alternatives, too:

* Only either unclutter or unclutter-xfixes can ship this file.

* It will operate on whatever is chosen with update-alternatives, but
  only if the package which contains it, is installed, too.

* Installing this file with different names from both packages is no
  option as it would start both programs (and I don't think that's a
  good idea) if both are installed.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#825809: unclutter: diff for NMU version 8-21.1

[Axel Beckert]

Hi Sean,

Sean Whitton wrote:
> I've prepared an NMU for unclutter (versioned as 8-21.1) and uploaded it
> to DELAYED/15. Please feel free to tell me if I should delay it longer.

Huh? I don't think an NMU is necessary nor appropriate here since I
don't think that I am MIA.

I'd rather prefer if you'd update
https://salsa.debian.org/debian/unclutter instead, either in a feature
branch or directly into the master branch (fine for me).

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#825809: ITP: unclutter-xfixes -- hide the X mouse cursor after a period of inactivity, using XFixes

[Axel Beckert]

Hi Sean,

Sean Whitton wrote:
> After thinking about this a bit and reviewing old discussions, I think
> that using the alternatives mechanism is better than doing some sort of
> transition.

Indeed.

> I have prepared a patch to src:unclutter to implement that,
> and also I've prepared packaging of unclutter-xfixes which calls
> update-alternatives(1).

Yay, thanks! Will happily include that patch in unclutter.

> Although unclutter-xfixes will work better for a lot of people,
> classic unclutter is working perfectly fine for other people, and there
> seems no need to impose a transition on the second group if it's not
> needed to benefit the first.

I fully agree. Actually being happy with the old unclutter and never
having felt the urge to change its behaviour made me hesitate to
switch to unclutter-xfixes.

    Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#902995: RFP: urh -- Universal Radio Hacker: Investigate wireless protocols like a boss

[Axel Beckert]

Hi,

JFYI: I started a prove of concept packaging at
https://salsa.debian.org/debian/urh

It's far from perfect and I'm not promising at all that I will
maintain this package in Debian (as my Python knowledge is rather
limited and I probably won't be using URH often enough to notice bugs
myself), but if anyone else wants to maintain URH as Debian package,
this is a base you can build upon.

I'm though open to team maintenance, so if anyone with a stronger
Python background than I have, wants to join, we might also maintain
this together.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#786808: RFA: adequate -- Debian package quality testing tool

[Axel Beckert]

Hi Jakub,

Jakub Wilk wrote:
> >>I request an adopter for the adequate package. (Note that RFA !=
> >>O. Talk to me before taking over this package.)
> 
> I wrote this in May 2015.
> Then, in May 2016, I orphaned the package.
[...]
> [...], so there wasn't anything for me to
> object.

Ah, sorry, missed that part when I read through the history of this
bug report. For a long time, BartM had a bug in his script retitling
WNPP bug reports from ITA to O even if they were just RFA beforehand,
so I expected this to be an victim of that bug, too,

Anyway, in that case I've likely done just the right thing. So thanks
for the clarification. :-)

I intent to take care of the package under the QA umbrella in case of
RC bugs or similar.

But if I'd ever take over the package alone respectively its
development, I likely have to rewrite tests/run-tests in another
language. Testing Perl scripts with Python scripts is definitely not
my way of doing such things, especially if TAP is not used.

So I'd really prefer if a team would take it over. And I still think
that the Lintian team would be the most appropriate team for that.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#786808: RFA: adequate -- Debian package quality testing tool

[Axel Beckert]

Dear Jakub,

Jakub Wilk wrote:
> I request an adopter for the adequate package. (Note that RFA != O.
> Talk to me before taking over this package.)

BartM's automatic WNPP mangeling has moved that bug report to an "O"
in March 2017 and you haven't objected.

There is an open RC bug (#922773) for 1.5 weeks now without response
from you.

So I assume, this package is really orphaned.

I've hence imported your Mercurial history into git and created a git
repo on Salsa at https://salsa.debian.org/debian/adequate

I intent to upload adequate as QA upload based on the above mentioned
git repo later today, to get the fix for #922773 into buster before
the hardfreeze.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#922126: RFA: xen-tools -- Tools to manage Xen virtual servers

[Axel Beckert]

Package: wnpp
Severity: normal
Forwarded: 
https://xen-tools.org/pipermail/xen-tools-discuss/2019-February/001144.html

Hi,

TL;DR: xen-tools could need a new upstream _and_ package maintainer who
is using it more often than I do nowadays.

2.5 years ago I changed to a different team at work where I no more
maintain any hosting infrastructure. So the only places where I still
need and use xen-tools are on one server at home and one for voluntary
work in an association. But in both cases new DomUs are rather seldom,
i.e. only every other year or so.

On the other hand the amount of pull requests in the past few years
clearly shows that xen-tools is used and needed, and that especially
regular updates for supporting new Ubuntu releases is wanted.

The past 2.5 years with (upstream) releases only being prompted by
Debian freezes show clearly that I can't keep up with those needs and
expectations (and have different priorities).

So I'd be happy if others would take over the lead in maintaining
xen-tools, primarily upstream, but probably best also as Debian package
maintainer. I'll continue to contribute and can also continue to host
the website at https://xen-tools.org/ and the (Mailman-based) mailing
lists.

And since I never managed to finish the rewrite of the original website
in something more maintainable than pure HTML, the new maintainer is not
only allowed but also encouraged to redo the website as he or she
prefers. Moving its hosting over to e.g. GitHub pages or similar, is
fine for me, too.

The primary upstream and package git repo is currently at
https://github.com/xen-tools/xen-tools

The website's git repo is currently at
https://github.com/xen-tools/website

The mailing lists including archives are at
https://xen-tools.org/mailman/listinfo/

For completeness, here are the current details of the binary and source
packages:

Package: xen-tools
Version: 4.8-1
Installed-Size: 704
Maintainer: Axel Beckert 
Architecture: all
Depends: debootstrap | cdebootstrap, libconfig-inifiles-perl, 
libdata-validate-domain-perl, libdata-validate-ip-perl, 
libdata-validate-uri-perl, libfile-slurp-perl, libfile-which-perl, 
libsort-versions-perl, libterm-ui-perl | perl (<< 5.17.0), 
libtext-template-perl, openssh-client, perl
Recommends: debian-archive-keyring, e2fsprogs, libexpect-perl, lvm2, rinse (>= 
1.9.1-1), ubuntu-keyring | ubuntu-archive-keyring, xen-hypervisor, xen-utils
Suggests: btrfs-progs | btrfs-tools, cfengine2, grub-xen-host, reiserfsprogs, 
xfsprogs
Description-en: Tools to manage Xen virtual servers
 This package contains tools to manage Debian based Xen virtual servers.
 .
 Using the scripts you can easily create fully configured Xen guest
 domains (DomU) which can be listed, updated, or copied easily.
 .
 xen-tools currently can install:
 .
   * Debian 3.1 Sarge (i386 only)
   * Debian 4.0 Etch
   * Debian 5.0 Lenny
   * Debian 6.0 Squeeze
   * Debian 7 Wheezy
   * Debian 8 Jessie
   * Debian 9 Stretch
   * Debian 10 Buster (under development)
   * Debian 11 Bullseye (future release name)
   * Debian 12 Bookworm (future release name)
   * Debian Sid (Unstable)
   * Ubuntu 6.06 Dapper Drake (LTS)
   * Ubuntu 6.10 Edgy Eft
   * Ubuntu 7.04 Feisty Fawn
   * Ubuntu 7.10 Gutsy Gibbon
   * Ubuntu 8.04 Hardy Heron (LTS)
   * Ubuntu 8.10 Intrepid Ibex
   * Ubuntu 9.04 Jaunty Jackaplope
   * Ubuntu 9.10 Karmic Koala
   * Ubuntu 10.04 Lucid Lynx (LTS)
   * Ubuntu 10.10 Maverick Meerkat
   * Ubuntu 11.04 Natty Narwhal
   * Ubuntu 11.10 Oneiric Ocelot
   * Ubuntu 12.04 Precise Pangolin (LTS)
   * Ubuntu 12.10 Quantal Quetzal
   * Ubuntu 13.04 Raring Ringtail
   * Ubuntu 13.10 Saucy Salamander
   * Ubuntu 14.04 Trusty Tahr (LTS)
   * Ubuntu 14.10 Utopic Unicorn
   * Ubuntu 15.04 Vivid Vervet
   * Ubuntu 15.10 Wily Werewolf
   * Ubuntu 16.04 Xenial Xerus (LTS)
   * Ubuntu 16.10 Yakkety Yak
   * Ubuntu 17.04 Zesty Zapus
   * Ubuntu 17.10 Artful Aardvark
   * Ubuntu 18.04 Bionic Beaver (LTS)
   * Ubuntu 18.10 Cosmic Cuttlefish
   * Ubuntu 19.04 Disco Dingo (preliminary support, under development)
   * CentOS 5
   * CentOS 6
Description-md5: c3da9eea0c66571fee394ecaba060312
Homepage: https://xen-tools.org/software/xen-tools
Tag: admin::virtualization, devel::debian, implemented-in::perl,
 implemented-in::python, interface::commandline, role::program,
 scope::utility, suite::openstack, system::cloud, system::virtual
Section: utils
Priority: optional
Filename: pool/main/x/xen-tools/xen-tools_4.8-1_all.deb
Size: 142208
MD5sum: 2887ad18a2b5ee9fd4680306843d368e
SHA256: da2a3d5835a409bc8abe8ac390c05d1ac8dd91035cdff0b9eedc4d1c1ca17cba

Package: xen-tools
Binary: xen-tools
Version: 4.8-1
Maintainer: Axel Beckert 
Build-Depends: debhelper (>= 10~), devscripts, git, 
libdata-validate-domain-perl, libdata-validate-ip-perl, 
libdata-validate-uri-perl, libfile-slurp-perl, libfile-which-perl, 
liblog-message-perl | perl (<< 5.17.0), libterm-ui-perl | perl (<< 5.17.0), 
libsort-versions-perl, libtest-

Bug#864079: Progress of backuppc4 packaging / support offer

[Axel Beckert]

Hi Dominik,

Dominik George wrote:
> my employer asked me about backuppc4 in Debian today. I found ITP
> bug #873075 - thus, I conclude that the plan is to keep backuppc for
> the 3.x generation and add backuppc4 as an alternative package?

That's the idea.

> As the bug is recorded as ITP by the team, I would like to know what the
> progress of the work is.

Not that far yet, I must admit.

I was glad having gotten backuppc (3.x) back in shape for buster. And
Tobi (the only other guy in the team so far), was busy with other
things the past two months IIRC.

And when it became clear that we won't manage to get 4.x into buster,
priorities shifted quickly.

My plan is to start with it (or rather #864079) once everything else
has settled down for buster, i.e. either during the hard freeze or
after the release.

(And I have upgraded my production
BackupPC server to Buster so that it can do my IPv6-only backups and I
can use my testing/secondary BackupPC for BackupPC4 testing under
production load.)

First step is though looking into packaging the rsync fork for
backuppc, see https://bugs.debian.org/864079 — where some decisions
need to made, especially the one about the final package name.
Comments on why one of the suggested packages are good or bad are
appreciated.

> I'd also like to offer support in getting teh package ready
> (probably for buster+1 and buster-backports, as it seems…).

That's the plan, yes.

Since we (clearly) didn't manage to get backuppc4 ready in time
Buster, the exact migration path is not so clear anymore.

Initially the idea was to have both in parallel for a while, maybe for
one release.

But then again, I don't think we will have backuppc 3.x in Debian 11
Bullseye anymore, so we might also just go back to just reuse the
"backuppc" package name again and run both in parallel for a while by
uploading the 4.x version to experimental first.

> My employer is giving me paid time for a backuppc4 package supported
> in Debian.

Yay! So feel free to join the team. I'd really appreciate another
couple of hands and eyes. :-)

    Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#696888: RFA: pconsole -- parallel console shell for administering clusters

[Axel Beckert]

Hi Prach,

sorry for the _very_ late reply. I seem to have forgotton to subscribe
to the RFA bug report myself and discovered your mail only today and
only more or less by accident.

Prach Pongpanich wrote in 2013:
> I interest help you on this package but I saw you updating pconsole
> in exp.

Yeah, I still feel responsible to still keep the package in an
acceptable state, hence I filed a request for an adopter and didn't
orphan the package. I just think that the package deserves a
maintainer which also uses the package.

> Are you still want a co-maintainer ?

Definitely, even after all these years. :-)

Since you're a DD now, feel free to contribute to
https://salsa.debian.org/debian/pconsole where the packaging git repo
now resides.

I just imported the 1.1 release from August last year into git. Will
probably test and upload it later today.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#727170: closed by Bart Martens (closing RFP: lua-alien -- Pure Lua extensions)

[Axel Beckert]

Control: reopen -1

Debian Bug Tracking System wrote:
> RFP 727170 has no visible progress for a long time, so closing.

Bart, when do you finally stop messing around with bug reports you
have no idea of (and probably have never read)?!?

This time Cc'ing the MIA team since you haven't reacted on _any_ of my
probably dozens of complaints in the past few years about your so
called "QA" cron jobs despite they seem to cause more harm then they
do good.

MIA team: In case Bart doesn't reply at all (what I expect given my
experience so far) and gets removed, please make sure that _all_ his
obviously unmonitored-running cron-jobs on qa.debian.org get
deactivated rather quickly. TIA!

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: Digital signature

Bug#864079: ITP: backuppc-rsync -- rsync optimised for BackupPC backup utility

[Axel Beckert]

Hi,

Tobias Frost wrote:
> Yes, we're are on it (however, I hoped to dedicate a bit more time to
> this week)

Before creating a VCS repo for it: I wonder why the package is ITP'ed
as "backuppc-rsync" despite upstream calls the software "rsync-bpc".

Shouldn't we name the package then "rsync-bpc", too?

Next question wrt. to packaging it, is: Which version to package?

The only released versions seem to be based upon rsync 3.0.9 (last
included in Debian 7 Wheezy) while rsync itself is at 3.1.2 now. In
the master branch there seems to be a version which has currently the
working title 3.1.2.beta0.

So shall we start with 3.0.9.12 or 3.1.2.beta0? (I tend to stay on the
safe side and start with 3.0.9.12, but then we at least should try to
apply all security updates against rsync 3.0.9 in Wheezy.)

    Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#811377: closed by Dmitry Bogatov (Bug#811377: fixed in sysvinit 2.88dsf-60)

[Axel Beckert]

Hi,

Dmitry Bogatov wrote:
> > Then you should probably use the common (debian group) repository...
> 
> Somewhy GitLab does not allow me to push into debian/sysvinit, so I
> pushed to my branch.

>From that and from my past contact with Dmitry (sponsoring uploads,
etc.), I assumed he's (still) a DM.

Axel Beckert wrote:
> If Ian and Benda don't oppose, I'd give Dmitry write access to
> /debian/sysvinit/.

Hence I offered to add him as additional non-DD "member" of the
sysvinit repo.

Ian Jackson wrote:
> Please do.

No more needed. Dmitry is a DD since one week ago:
https://nm.debian.org/process/448

Actually I even replied to his new @debian.org address without
noticing. :-)

Dmitry: Welcome! I'm really happy to see you on board!

Dmitry: Please try again to push to
https://salsa.debian.org/debian/sysvinit/ — your account is listed as
"Given access 2 days ago". So I assume the user database wasn't synced
as quickly as you gained traction. :-)

> I dont have time right now but can you please introduce Dmitry for me
> on debian-init-diversity ?

I'm sorry, but I'm not sure what you ask me for. I'm not subscribed to
that list, I'm just subscribed to (and mostly lurking on)
pkg-sysvinit-devel and subscribed to #811377.

> It might be worth mentioning that he did an upload to experimental
> intending to adopt the package, unaware of our efforts (in part
> because we failed to write to this RFA bug about them),

At least from lurking on pkg-sysvinit-devel I wasn't aware of any work
done on the package either with the exception of the stated ITA quite
some time (a year?) ago. The only thing I saw was the scaring amount
NMUs.

So hearing that not only Dmitry is active now but that Ian and Benda
also have something in the pipeline is great!

> but that we are welcoming him, or some such.

Great! Looking forward to the results of that grown team! And thanks
for all your efforts to keep sysvinit usable in Debian.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#811377: closed by Dmitry Bogatov (Bug#811377: fixed in sysvinit 2.88dsf-60)

[Axel Beckert]

Hi Dmitry,

Dmitry Bogatov wrote:
> Even if it just removed from Policy, not archives, it would be calamity.

*nod*

> > > I am sorry, if I stepped on someone's toes. I would greatly appericate
> > > any help in maintaining sysvinit.
> > Then you should probably use the common (debian group) repository...
> 
> Somewhy GitLab does not allow me to push into debian/sysvinit, so I
> pushed to my branch.
> 
> Every DD should be able to push in every repo under debian/ namespace,
> right?

Yes, by default all DDs, but only DDs can push to a repo under
/debian/. But in comparison to Alioth, it's easy to add write access
for single guest accounts to a single repo.

If Ian and Benda don't oppose, I'd give Dmitry write access to
/debian/sysvinit/.

> Also, maybe it worth creating separate namespace for 
> sysvinit/startpar/insserv?

Given that this is more restricting write access than a repo under
/debian/ and the past contribution history of Debian's sysvinit
package, I suggest to stay with the /debian/ namespace and add write
access for guest account to non-DD contributors.

    Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: Digital signature

Bug#811377: marked as done (RFA: sysvinit -- System-V-like init utilities - transitional package)

[Axel Beckert]

Hi Dmitry,

Debian Bug Tracking System wrote:
>* New maintainer (Closes: #811377)

Yay, thanks!

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#911682: ITP: libmojo-sqlite-perl -- tiny Mojolicious wrapper for SQLite

[Axel Beckert]

Package: wnpp
Owner: Axel Beckert 
Severity: wishlist

* Package name: libmojo-sqlite-perl
  Version : 3.001
  Upstream Author : Dan Book 
* URL : https://metacpan.org/release/Mojo-SQLite
* License : Artistic-2.0
  Programming Lang: Perl
  Description : tiny Mojolicious wrapper for SQLite

Mojo::SQLite is a tiny wrapper around DBD::SQLite that makes SQLite a
lot of fun to use with the Mojolicious real-time web framework. Use
all SQL features SQLite has to offer, generate CRUD queries from data
structures, and manage your database schema with migrations.

The package will be maintained under the umbrella of the Debian Perl
Group.

Bug#887490: BackupPC 4.x and BackupPC 3.3.2 (was: Re: Offering my help to be part of team)

[Axel Beckert]

Hi Tobias,

Tobias Frost wrote:
> Team created:
> https://tracker.debian.org/teams/pkg-backuppc/

Thanks! Joined.

BTW, the repo looks like a git-buildpackage style repo, so I assume
it's safe to use gbp for it.

> I wonder if we want to have a new (e.g backuppc4) src package to have
> the old and new one parallel for some time... What do you think?

Good question. I tent to say yes, but probably only for buster. (It
might be too short to get backuppc4 in shape for buster.)

Next question is if we want separate repositories or just separate
branches. I tend to separate repositories.

I feel well-versed enough in Perl and dynamic web pages to provided
fixes for potential security issues in BackupPC 3.x, so upstream
possibly not providing any support anymore should be ok-ish.

P.S.: There seems to be a last 3.3.2 upstream release from Jan. 2017:
https://github.com/backuppc/backuppc/releases/tag/3.3.2
https://backuppc.github.io/backuppc/BackupPC-3.3.2.html

Seems to mostly fix things we already ship as patches. IMHO we should
at least import that for the generation 3 packages. Won't be able to
do that this evening anymore, though, at least not properly with
testing, etc.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#887490: Offering my help to be part of team

[Axel Beckert]

Hi Tobias,

Tobias Frost wrote:
> > > but with the limitation that I'm no perl guy…)
> > 
> > I can help there. :-)
> 
> Sounds good ;-) So, let's do it!

Ack!

> Should we create our own BackuPPC packaging team at tracker.d.o / salsa
> ?

Team yes to have a proper team e-mail address. But I'm not sure if a
repo outside /debian/ is more helping than causing work.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#887490: Offering my help to be part of team

[Axel Beckert]

Hi Tobias,

Tobias Frost wrote:
> I've just did an QA upload of BackupPC and created a repository at
> salsa: https://salsa.debian.org/debian/backuppc

Thanks a lot, much appreciated.

> Could be a starting point for all the interested folks and non-
> developers can now also create merge-requests more easily ;-)

Will see if I can merge in the IPv6 support patches floating around.
That bothers me most.

> (I'm using BackupPPC myself, so I can volunteer helping in the
> packaging too,

Same here, but I still don't have a BackupPC running on testing, so
"testing" stuff is limited to stable.

Would you join a potential BackupPC team. I would, I just don't want
to take the lead as I have the feeling, I don't have enough time for
that.

> but with the limitation that I'm no perl guy…)

I can help there. :-)

    Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#904132: marked as done (ITP: browsh -- Fully interactive, realtime, and modern text-based browser)

[Axel Beckert]

Control: reopen -1

Dear Bart,

Debian Bug Tracking System wrote:
> From: Bart Martens 
> To: 904132-d...@bugs.debian.org
> Subject: closing ITP: browsh -- Fully interactive, realtime, and modern
>  text-based browser
> 
> Please retitle bug 903961 from RFP to ITP and set yourself as the owner.

Have you finally gone completely insane? This ITP wasn't open for more
than 1.5 months and you're now already closing it automatically after
such a very short time?

This can't be "QA" anymore, this is harassment.

Besides: This was already an ITP. Once again I have to complain that
you don't read at all the bug reports you're modifying.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#887490: O: backuppc -- high-performance, enterprise-grade system for backing up PCs

[Axel Beckert]

Hi Raoul,

Raoul Bhatia wrote:
> I've tried to keep some up2date packages in my Github repositories,
> see
> https://github.com/backuppc/backuppc/wiki/Build-Your-Own-Packages ,
> specifically
> 
> * https://github.com/raoulbhatia/rsync-bpc/tree/3.0.9.12-DEBIAN
> * https://github.com/raoulbhatia/backuppc/tree/DEBIAN
> * https://github.com/raoulbhatia/backuppc-xs/tree/DEBIAN

Thanks for these!

> Would this help to get things back in shape?

I'm sure it will. I haven't looked at them, but since the hint to your
packages in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873075#35 my plan is
to look at them and try to do a Debian QA upload based on them.

I though don't have my Debian Testing based BackupPC server in shape
yet, so I can't test it currently.

Once I managed to do this, I intent to look into making a QA upload of
BackupPC to at least get it back in shape. Or maybe first a simple 3.x
upload to unstable to get a few things fixed and then upload 4.x to
experimental first. (JFTR: This should though not keep anyone from
doing this before I get to it! I do not claim this bug.)

It's though not my top priority at the moment, so I don't want make
any promises I may not be able to keep.

> Especially, I am no Debian expert and also have basic requirements
> for BackupPC only, so I will not be able to do this properly all by
> myself.

I'd join and help if anyone wants to form a BackupPC team in Debian.
I'm though not keen on taking the lead.

    Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#905014: RFA: dhcpy6d -- MAC address aware DHCPv6 server written in Python

[Axel Beckert]

Package: wnpp
Severity: normal
Tags: ipv6

Hi,

due to a job change a while ago, I'm no more using dhcpy6d and I
currently also don't have a setup where I'm able to test it properly
before uploading.

The listed co-maintainer, Henri Wahl (X-Debbugs-Cc'ed), is actually
upstream and he has started the package initially while I revamped it to
be uptodate with Debian standards.

Upstream does publish .deb packages of dhcpy6d, but they're meant for
Debian Stable and their packaging doesn't change much unless the package
in Debian Unstable changes. Upstream says, he's not experienced enough
with Debian's standards and procedures to maintain the Debian's official
dhcpy6d package himself alone. (And he would need a sponsor anyways.)

So we're basically searching for someone who can take over the main part
of packaging work for dhcpy6d. Anything which is related to upstream
code should be already covered by Henri as the communication with him
works very good (usually GPG encrypted :-). It works so good that we
currently do the Debian packaging in upstream's git repo at
https://github.com/HenriWahl/dhcpy6d in the branch "debian".

Currently the dhcpy6d package in Debian is multiple releases behind
upstream: 0.4.3 vs 0.7.2. So getting a new upstream version into Debian
would be the first thing to do for the prospective new maintainer of
this package. It's already a "3.0 quilt" package, but still at debhelper
9 and standards version 3.9.8 (as in Stretch).

Information about the package:

Package: dhcpy6d
Version: 0.4.3-1
Installed-Size: 255
Maintainer: Axel Beckert 
Architecture: all
Depends: adduser, ucf, python:any (<< 2.8), python:any (>= 2.7.5-5~)
Pre-Depends: dpkg (>= 1.16.5)
Suggests: python-dnspython, python-mysqldb, python-psycopg2
Description-en: MAC address aware DHCPv6 server written in Python
 Dhcpy6d delivers IPv6 addresses for DHCPv6 clients, which can be
 identified by DUID, hostname or MAC address as in the good old IPv4
 days. It allows easy dualstack transition, addresses may be
 generated randomly, by range, by arbitrary ID or MAC address. Clients
 can get more than one address, leases and client configuration can be
 stored in databases and DNS can be updated dynamically.
Homepage: https://dhcpy6d.ifw-dresden.de/
Tag: implemented-in::python, interface::daemon, network::configuration,
 network::server, protocol::dhcp, protocol::ipv6, role::program,
 scope::utility, use::configuring
Section: utils
Priority: optional
Filename: pool/main/d/dhcpy6d/dhcpy6d_0.4.3-1_all.deb
Size: 58434

Package: dhcpy6d
Binary: dhcpy6d
Version: 0.4.3-1
Maintainer: Axel Beckert 
Uploaders: Henri Wahl 
Build-Depends: debhelper (>= 9~), python-all (>= 2.6.6-3~)
Build-Depends-Indep: dh-python
Architecture: all
Standards-Version: 3.9.8
Format: 3.0 (quilt)
Files:
 3c202b1824f0381022c188d79cf1c086 1886 dhcpy6d_0.4.3-1.dsc
 429c1a0f66e6dd6453bb94ace7a1f03c 70668 dhcpy6d_0.4.3.orig.tar.gz
 4e1aeafd2655bf8962ff7d9542489e16 5732 dhcpy6d_0.4.3-1.debian.tar.xz
Vcs-Browser: https://github.com/HenriWahl/dhcpy6d
Vcs-Git: https://github.com/HenriWahl/dhcpy6d.git -b debian
Homepage: https://dhcpy6d.ifw-dresden.de/
Package-List:
 dhcpy6d deb net optional arch=all
Directory: pool/main/d/dhcpy6d
Priority: extra

    Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Bug#637454: closed by Bart Martens (closing RFP: bluegriffon -- Next Generation WYSIWYG HTML editor based on Gecko)

[Axel Beckert]

Control: reopen -1

Debian Bug Tracking System wrote:
> RFP 637454 has no visible progress for a long time, so closing.

This reason is only valid, if the upstream project is dead. Which
BlueGriffon obviously isn't: The latest release is from November 2017.

Hence reopening.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#620511: ITP: ipt-netflow -- netfilter target which sends traffic statistics via NetFlow

[Axel Beckert]

Hi,

[dropping previous ITP-owners from Cc]

Axel Beckert wrote yesterday:
> Unfortunately I had no answers to these questions, so I intend to
> package ipt-netflow from scratch. Co-maintainers welcome! Details (git
> repo, actual package name, etc.) later this week.

A close-to-production, dkms-based packaging is available at
https://salsa.debian.org/debian/iptables-netflow

While the binary package name will be iptables-netflow-dkms, I'm still
unsure if I rather should go with upstream's "ipt-netflow" as the
source package name, or if I should stay with the current
"iptables-netflow" which closer to the binary package name.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#620511: ITP: ipt-netflow -- netfilter target which sends traffic statistics via NetFlow

[Axel Beckert]

Control: retitle -1 ITP: ipt-netflow -- netfilter target which sends traffic 
statistics via NetFlow
Control: owner -1

Hi,

I wrote on Wed, 7 Mar 2018:
> Alexey Osipov wrote on 02 Apr 2011:
> > Subject: ITP: ipt-netflow -- netfilter target which sends traffic
> >  statistics via NetFlow
> 
> Dmitry Yu Okunev wrote on 29 Nov 2014:
> > I've prepared the packages [1, 2] and I'm waiting for sponsor.
> > 
> >  [1] http://mentors.debian.net/package/ipt-netflow
> 
> Any of you both still interested in maintaining ipt-netflow as package
> in Debian?
> 
> If not, could you please publish your packaging work so far, so that
> others can build upon it? (Unfortunately mentors.debian.net only keeps
> packages for 3 months or so, i.e. the links above no more work.)

Unfortunately I had no answers to these questions, so I intend to
package ipt-netflow from scratch. Co-maintainers welcome! Details (git
repo, actual package name, etc.) later this week.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#620511: ITP: ipt-netflow -- netfilter target which sends traffic statistics via NetFlow

[Axel Beckert]

Hi Alexey and Dmitry,

Alexey Osipov wrote on 02 Apr 2011:
> Subject: ITP: ipt-netflow -- netfilter target which sends traffic
>  statistics via NetFlow

Dmitry Yu Okunev wrote on 29 Nov 2014:
> I've prepared the packages [1, 2] and I'm waiting for sponsor.
> 
>  [1] http://mentors.debian.net/package/ipt-netflow

Any of you both still interested in maintaining ipt-netflow as package
in Debian?

If not, could you please publish your packaging work so far, so that
others can build upon it? (Unfortunately mentors.debian.net only keeps
packages for 3 months or so, i.e. the links above no more work.)

I'd be happy to see this iptables plugin in Debian and would also
review, sponsor and/or co-maintain it, if necessary. (Not sure if I'd
maintain it alone, so not switching back to "ITP" for now.)

P.S.: I just discovered ipt-netflow upstream a few days ago. Hence the
late reply on this WNPP bug report.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#887491: Bug#887490: O: backuppc -- high-performance, enterprise-grade system for backing up PCs

[Axel Beckert]

Hi,

Ludovic Drolez wrote:
> Due to lack of time, I intend to orphan the backuppc package.


Thanks for recognizing such issues yourself and for doing the
orphaning yourself!


> Maintaining this package requires time and skills. Please only adopt this
> package if you will have enough time and attention to work on it.

I agree here and that's why I won't adopt it alone.

I'm nevertheless very interested in getting the package back in shape
and would join a team of people interested in team-maintaining
backuppc (and probably libbackuppc-xs-perl, too, see
https://bugs.debian.org/887491).

So if nobody else shows up soon-ish for joining a potential team, I
might start fixing issues doing a QA upload, getting the packaging up
to current standards, fixing long-standing trivial issues like e.g.
https://bugs.debian.org/488098 and creating a packaging git repository
under https://salsa.debian.org/debian i.e. the collab-maint successor
on Salsa. (Packaging 4.x.y versions is very likely not included in
such a first step.)

JFTR: I'm a BackupPC user and admin for more than 15 years now (in
personal as well as professional surroundings), it's in most cases my
primary backup system, and I'm even brave enough to run one soon-to-be
production instance on Debian Testing. :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#670467: Closing abandoned RFP (Bug#670467: RFP: udev-notify -- Display notifications about newly plugged hardware)

[Axel Beckert]

Control: reopen -1
Control: submitter -1 !

Hi,

On Tue, Nov 28, 2017 at 01:13:18AM +0100, nodiscc wrote:
> RFP has no visible progress for a long time, so closing.

I'm still interested in such a feature in Debian, hence reopening.

And since the bug report has been closed by the original submitter,
I'm setting myself as submitter now so the original submitter won't be
bothered anymore.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#876095: O: bash-completion -- programmable completion for the bash shell

[Axel Beckert]

Hi Gabriel,

sorry for the late reply. Replying to your original mail as I already
had written half the mail a few days ago.

Gabriel F. T. Gomes wrote:
> >> I cloned the package repository and I understood how syncing with
> >> upstream was designed (very clever, imo).  
> >
> >Nice! Didn't look that deep into the package.
> 
> At the time I sent my first email, I was unaware of the existence of
> git-buildpackage.  It turned out that bash-completion is maintained
> with it, so that's where the clever syncing with upstream comes from.

Ah, ok. :-)

> (As a side not, I'm glad I learned about it, because it helped me in
> the other packaging I am working on (pragha).  I converted it to
> git-builbpackage)

Good! :-)

> >Yes, but IMHO it's definitely a good thing to synchronise these bug
> >reports (well, those which are still valid) to Github or the Debian
> >Bug Tracking system — especially since Alioth is going away towards
> >end of this year.
> >[...]
> >Not sure if it might be a good idea to make a dump or copy of all
> >these bug reports as I don't expect them to be preserved when Alioth
> >is decommissioned.
> 
> I saved the results of your search filter as a CSV, so that I have more
> time to work on it.  Should that be enough?

I hope so. Definitely better than nothing.

> I'm keeping my work on a personal git server [1], but as I mentioned in
> the RFS for pragha [2], I don't think that's a good place to keep these
> files in the long term, because I do not fully trust myself as a
> sysadmin.

Should suffice for the moment. It's probably best to wait until
Debian's Alioth replacement is available.

> After I upgraded bash-completion to newer upstream releases, I got some
> conflicts during the installation of the package.  For instance, it
> complained about the existence of the completion file for adb:
> 
> dpkg: error processing archive 
> /home/gftg/debian/bash-completion/bash-completion_2.7-1_all.deb (--install):
>  trying to overwrite '/usr/share/bash-completion/completions/adb', which is 
> also in package adb 1:7.0.0+r33-2
> 
> I know that bts (from packages devscripts) and mount/umount (from
> package mount) have the same problem, because I locally removed them
> from bash-completion (just to test).
> 
> However, I don't know what to do about it.  There should be certainly
> more files that collide this way, but I only saw these in my computer,
> because I have few packages installed.

This is a very common issue with bash-completion and zsh-common (where
zsh's default completions live), but it's also unique to those two
packages.

Background: Some projects maintain shell completions rather well,
others don't, but the team maintaining the completions does maintain
them. If new completions are added to bash-completions, it's often a
sign that the project they're for, doesn't really maintain them.

So you should compare the conflicting files: Which are more uptodate,
which have more precise completion.

If it's the one in the project's package, just don't ship the one in
bash-completion and it's good.

If the newly appeared file in bash-completion is clearly the better,
you should maybe not ship it now, but file a bug report against the
other package to exclude it, and if that's done, add in your next
upload Breaks + Replaces headers against the last version of the
package which still contained the conflicting file.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#715470: RFP: cr3 -- Cool Reader 3, an e-book reader

[Axel Beckert]

Hi,

programmer11...@programist.ru wrote:
> URL   :   http://coolreader.org/

This website is a link spammer nowadays. Seems as if the project lost
its domain. :-/

The offical website seems to be
https://sourceforge.net/projects/crengine/ nowadays.

> Version   :3.0.59

But then again the latest download link there seems to have version
3.0.56. (It's even a .deb and upstream seems to have some some basic
debian-sih packaging at
https://sourceforge.net/p/crengine/crengine/ci/master/tree/packages/ —
last updated in 2012 though.)

https://f-droid.org/packages/org.coolreader/ lists version 3.1.2 from
2015 as the newest version.

Nevertheless the last commit in the git repository as of now is from
January 2017:
https://sourceforge.net/p/crengine/crengine/commit_browser

So there still seem to be a little bit of activity.

> License   :GPL

The F-Droid app page also states: "The default dictionary app is
non-free." — So anyone who's looking at packaging Cool Reader for
Debian proper should have a very close look at the licenses.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#876095: O: bash-completion -- programmable completion for the bash shell

[Axel Beckert]

Hi Gabriel,

Gabriel F. T. Gomes wrote:
> > Maintaining a package requires time and skills. Please only adopt this
> > package if you will have enough time and attention to work on it.  
> 
> Although I'm new to Debian maintenance (my first and only work is the
> packaging of pragha (https://mentors.debian.net/package/pragha)), I
> would like to take ownership of this package.

Everyone needs to start somewhere. Welcome on board and thanks for
joining our effort. :-)

> >Please also notice that there seems new upstream development at
> >https://github.com/scop/bash-completion/, so one of the tasks for the
> >new maintainer is to update the package to the most recent upstream
> >release.  
> 
> I cloned the package repository and I understood how syncing with
> upstream was designed (very clever, imo).

Nice! Didn't look that deep into the package.

> So, I synced it and I began working on the removal of the patches
> that are no longer required, or that do not apply cleanly.

Cool!

> Once that is solved, I'll have a package and lots of bugs on Alioth to
> mark as fixed.

Oh, the bug tracker on Alioth actually has been used for that project?

Indeed:
https://alioth.debian.org/tracker/?atid=413095_id=100114=browse

But it's only visible for logged in users. That's unexpected and a bad
thing. But nothing we will change anymore. (See below.)

> Arguably, this will be the hardest part, since there are a lot of
> open bugs and since there has been a lot of improvements upstream.

Yes, but IMHO it's definitely a good thing to synchronise these bug
reports (well, those which are still valid) to Github or the Debian
Bug Tracking system — especially since Alioth is going away towards
end of this year. See https://wiki.debian.org/Alioth and especially
these mailing list postings:

https://lists.debian.org/debian-devel-announce/2017/06/msg2.html
https://lists.debian.org/debian-devel-announce/2017/08/msg8.html
https://lists.debian.org/debian-devel-announce/2017/09/msg4.html

Not sure if it might be a good idea to make a dump or copy of all
these bug reports as I don't expect them to be preserved when Alioth
is decommissioned.

Luckily at least a few of the bug reports in there are already labeled
as being related to a bug report in the Debian Bug Tracking System.

> Is it fine if I keep doing this?

IMHO definitely.

Please tell me if not being a member of the bash-completion project on
Alioth hinders you in doing that work. (That should still be
possible.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: Digital signature

Bug#876083: ITP: zsh-theme-powerlevel9k -- theme for zsh which uses powerline fonts

[Axel Beckert]

Hi Jonathan,

Jonathan Carter wrote:
> Powerlevel9k is a theme for zsh which uses powerline fonts

Sounds interesting. Are you aware that there is a Debian Zsh Team
(Cc'ed)? See https://wiki.debian.org/Zsh

We package Zsh itself for Debian as well as some add-ons like
zsh-syntax-highlighting.

You're invited to join the team and package Zsh addons under the
umbrella of the team. And even if you don't want to join the team,
you're always welcome to join our IRC channel #pkg-zsh on
irc.freenode.net.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: Digital signature

Bug#876095: O: bash-completion -- programmable completion for the bash shell

[Axel Beckert]

Package: wnpp

The current maintainer of bash-completion, David Paleino
<da...@debian.org> (Cc'ed), currently lacks time to work on this
package and granted the MIA team to orphan his packages as necessary.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: bash-completion
Version: 1:2.1-4.3
Installed-Size: 1220
Maintainer: Bash Completion Maintainers 
<bash-completion-de...@lists.alioth.debian.org>
Architecture: all
Replaces: bash, cryptsetup (<< 2:1.1.2-2), xen-tools (<= 4.1-1)
Depends: bash (>= 3.2)
Pre-Depends: dpkg (>= 1.15.7.2~)
Breaks: xen-tools (<= 4.1-1)
Description-en: programmable completion for the bash shell
 bash completion extends bash's standard completion behavior to achieve
 complex command lines with just a few keystrokes.  This project was
 conceived to produce programmable completion routines for the most
 common Linux/UNIX commands, reducing the amount of typing sysadmins
 and programmers need to do on a daily basis.
Multi-Arch: foreign
Homepage: http://bash-completion.alioth.debian.org
Tag: implemented-in::shell, interface::shell, role::plugin
Section: shells
Priority: standard
Size: 178338

Package: bash-completion
Binary: bash-completion
Version: 1:2.1-4.3
Maintainer: Bash Completion Maintainers 
<bash-completion-de...@lists.alioth.debian.org>
Uploaders: David Paleino <da...@debian.org>
Build-Depends: debhelper (>= 9~), dh-autoreconf
Build-Depends-Indep: perl
Architecture: all
Standards-Version: 3.9.5
Format: 3.0 (quilt)
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=bash-completion/debian.git
Vcs-Git: git://anonscm.debian.org/bash-completion/debian.git
Homepage: http://bash-completion.alioth.debian.org
Package-List: 
 bash-completion deb shells standard arch=all
Directory: pool/main/b/bash-completion
Priority: source
Section: shells

Please also notice that there seems new upstream development at
https://github.com/scop/bash-completion/, so one of the tasks for the
new maintainer is to update the package to the most recent upstream
release.

    Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: Digital signature

Bug#832159: ITP: qutebrowser -- A keyboard-driven, vim-like browser based on PyQt5.

[Axel Beckert]

Hi Fritz,

Fritz Reichwald wrote:
> At the moment I'm waiting for someone to sponsor the package.

Still on my todo list, yes.

> the status of packaging can be found here:
> https://github.com/fiete201/qutebrowser-debian

Hrm, is it on purpose that this git repo only contains the debian
directory? Doing so was common back in the Subversion days, but
nowadays, I'd expect the unpacked upstream tar ball in there, too.
Anyway, that's no blocker, just unexpected.

I nevertheless just had a look at this git repo and it seems to miss
one file which were in your earlier packages (0.9.0-1 and 0.10.1-2).
Namely the debian/source/ directory with its sole file
debian/source/format is missing. Lintian also argues about it:

  I: qutebrowser source: missing-debian-source-format

Please re-add that directory.

Additionally please take a look at

  I: qutebrowser source: missing-debian-source-format

Upstream now provides GPG signatures so we should verify them.

Further, it's no more necessary to list the full text of the MPL
1.1 since Debian Policy 4.0.0 as the license text of the MPL 1.1 is
now available under /usr/share/common-licenses/MPL-1.1. Please just
refer to that file. (Yes, I know, I very likely argued about adding
MPL-1.1 to debian/copyright in an earlier review — but the inclusion
of the MPL happened only very recently. :-)

Not immediately necessary, but should happen sooner or later: Debian
Policy 4.1.0 is out. It also explicitly recommends adding support for
verifying upstream PGP signatures.

And JFTR: I just uploaded the pypeg2 package (c.f.
https://bugs.debian.org/832937) so soon all runtime dependencies of
qutebrowser should be available in Debian unstable.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: Digital signature

Bug#852224: fixed in gpm 1.20.7-1

[Axel Beckert]

Hi,

On Sun, Aug 13, 2017 at 04:34:13AM +, Axel Beckert wrote:
>* Switch to source format "3.0 (quilt)" and rewrite debian/rules as dh
>  v7 style minimal rules file with debhelper compatibility level 10.
>  + Bump versioned debhelper build-dependency accordingly.
>  + Drop build-dependencies on quilt, autoconf and autotools-dev.
>  + Refresh 021_libgpm_dev_gpmctl_debug_msg.patch to remove fuzz.
>  + Use dh-exec and executable debian/*.install files instead of
>$(INSTALL_PROGRAM) and $(INSTALL_DATA) in debian/rules.
>  + Add patch to fix FTBFS with -Wformat-security.
>* Enable all hardening build flags.
>  + Update 014_has_mouse_control.patch to properly pass compile flags.
[...]
>* Declare compliance with Debian Policy 4.0.1.
>  + Use /run/ instead of /var/run/ in init script.
>* Import stable upstream release 1.20.7.
>  + Refresh patches where necessary.
>  + Manually extend 050_dont_link_libcurses to make package compile
>again independently of libncurses5-dev being installed or not.
>  + Drop 020_daemon_quit_noverbose.patch,
>021_libgpm_dev_gpmctl_debug_msg.patch,
>022_libgpm_no_log_debug_msg.patch, 030_fd_set_negative_int.patch and
>040_no_OPEN_MAX.patch, applied upstream.
>  + Update debian/libgpm2.install wrt. to minor SONAME version.
>  + No more symlink config.{sub,guess}, call ./autogen.sh instead.
[...]
>* Add an initial symbols file.

the upload had quite some changes: complete revamp of packaging, minor
SONAME bump, hardening build flags, a lots for fiddling getting the
exclusion of the ncurses dependency right again after importing the
new (years old) upstream release, initial symbols file, etc.

I've checked the new binaries against one package linked against
libgpm2, pdmenu, and it still worked fine.

But:

Since then I seem have some kind of shadow cursor on the console and
some strange warnings in the syslog:

Aug 13 05:05:53 c-cactus2 /usr/sbin/gpm[9430]: *** warning 
[daemon/old_main.c(254)]:
Aug 13 05:05:53 c-cactus2 /usr/sbin/gpm[9430]: Data on strange file descriptor 4
Aug 13 05:06:19 c-cactus2 /usr/sbin/gpm[9430]: *** info 
[daemon/processrequest.c(42)]:
Aug 13 05:06:19 c-cactus2 /usr/sbin/gpm[9430]: Request on 6 (console 1)
Aug 13 05:07:04 c-cactus2 /usr/sbin/gpm[9430]: *** warning 
[daemon/old_main.c(254)]:
Aug 13 05:07:04 c-cactus2 /usr/sbin/gpm[9430]: Data on strange file descriptor 4

But then again, I find them also from before I started working on the package:

Aug 02 18:19:43 c-cactus2 /usr/sbin/gpm[10034]: *** warning 
[daemon/old_main.c(254)]:
Aug 02 18:19:43 c-cactus2 /usr/sbin/gpm[10034]: Data on strange file descriptor 
4

So I first uploaded it to experimental and will check it on more
devices, especially also different architectures to see if that's a
local or maybe even a non-reboot issue.

But I'd also appreciate some additional testers for that experimental
package.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#852224: Processed: retitle 852224 to ITA: gpm -- General Purpose Mouse interface

[Axel Beckert]

Hi Samuel,

Samuel Thibault wrote:
> Axel Beckert, on lun. 07 août 2017 22:43:00 +0200, wrote:
> > Debian Bug Tracking System wrote:
> > > > retitle 852224 ITA: gpm -- General Purpose Mouse interface
> > > Bug #852224 [wnpp] O: gpm -- General Purpose Mouse interface
> > > Changed Bug title to 'ITA: gpm -- General Purpose Mouse interface' from 
> > > 'O: gpm -- General Purpose Mouse interface'.
> > 
> > Do you intent to maintain the package under the Debian A11Y Team?
> 
> Not really, I just happen to use it :)

But
https://anonscm.debian.org/git/collab-maint/gpm.git/tree/debian/control
looks differently. :-)

Shall I keep the Debian A11Y team in there (I'm a member there, too,
so I wouldn't mind) or shall I change it to just you and me?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#852224: Processed: retitle 852224 to ITA: gpm -- General Purpose Mouse interface

[Axel Beckert]

Hi Samuel,

Samuel Thibault wrote:
> > Well, sounds familiar, hence I'd really prefer not to maintain
> > additional packages alone. Would it be ok to list you as
> > co-maintainer? [...]
>
> Ok for me :)

Great, will do.

> > I'd open up a gbp-compatible git repo on collab-maint.

Actually you already created a repo there about 1.5 months ago. Will
be using that. :-)

    Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#852224: Processed: retitle 852224 to ITA: gpm -- General Purpose Mouse interface

[Axel Beckert]

Hi Samuel,

Samuel Thibault wrote:
> > I'm also interested in a properly maintained gpm in Debian and would
> > join you as second co-maintainer. (And I have a good contact to
> > upstream.)
> 
> I'd say please feel free to take it, as my upload latency shows, I'm
> already too busy with packages :)

Well, sounds familiar, hence I'd really prefer not to maintain
additional packages alone. Would it be ok to list you as
co-maintainer? I'd open up a gbp-compatible git repo on collab-maint.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#852224: Processed: retitle 852224 to ITA: gpm -- General Purpose Mouse interface

[Axel Beckert]

Hi Samuel,

Debian Bug Tracking System wrote:
> > retitle 852224 ITA: gpm -- General Purpose Mouse interface
> Bug #852224 [wnpp] O: gpm -- General Purpose Mouse interface
> Changed Bug title to 'ITA: gpm -- General Purpose Mouse interface' from 'O: 
> gpm -- General Purpose Mouse interface'.

Do you intent to maintain the package under the Debian A11Y Team? I'm
also interested in a properly maintained gpm in Debian and would join
you as second co-maintainer. (And I have a good contact to upstream.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#673459: closed by Bart Martens <ba...@quantz.debian.org> (closing RFP: gofish -- Small gopher server in C)

[Axel Beckert]

*sigh*

And once again:

Bart Martens wrote:
> RFP 673459 has no visible progress for a long time, so closing.

That doesn't mean that there is still demand for that package.
Reopening.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#869389: ITP: libmpsse -- SPI/I2C control via FTDI chips

[Axel Beckert]

Package: wnpp
Owner: Axel Beckert <a...@debian.org>
Severity: wishlist

* Package name: libmpsse
  Version : 1.3+git-2-a2eafa2
  Upstream Author : Craig Heffner <heffne...@gmail.com>
* URL or Web page : https://github.com/devttys0/libmpsse
* License : BSD-2-Clause
  Description : SPI/I2C control via FTDI chips

Libmpsse is a library for interfacing with SPI/I2C devices via FTDI's
FT-2232 family of USB to serial chips. Additionally, it provides
control over the GPIO pins on the FTDI chips and supports a raw
bitbang mode as well.

This package contains the development header files.

--

This library is the first part of an effort to package all software
necessary to run a TheThingsNetwork LoRaWAN Gateway, see
https://github.com/ttn-zh/ic880a-gateway

My packaging work so far can be found at
https://github.com/xtaran/libmpsse-debian-packaging

Help welcome! If anyone wants to join this effort, I'm happy to create
and according Alioth/Pagura/whatever project.

Bug#869300: O: xfrisk -- Server and X11 client for playing risk with humans or AIs

[Axel Beckert]

Hi,

Tobias Frost wrote:
> The current maintainer of xfrisk, Joe Nahmias <je...@debian.org>,
> is apparently not active anymore.  Therefore, I orphan this package now.

I've started updating the xfrisk package for an QA upload. My work in
progress should show up soon at
https://anonscm.debian.org/cgit/collab-maint/xfrisk.git

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#852223: Anyone has objections against maintaining equivs under the Debian Perl Team hat?

[Axel Beckert]

Axel Beckert wrote:
> anyone has objections against maintaining equivs (orphaned, see
> https://bugs.debian.org/852223) under the hat of the Debian Perl Team?
> 
> (If so, I'll maintain it on my own, but I'd prefer team maintenance
> and the Perl team seems be quite fitting.)

JFTR: I've pushed my current work to
https://anonscm.debian.org/git/users/abe/proposed/equivs.git for now.

(It's currently written for a collab-maint repo and single-person
maintenance, but I'll change that to the Debian Perl Team if I don't
get any objections within the next few days.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#852223: Anyone has objections against maintaining equivs under the Debian Perl Team hat?

[Axel Beckert]

Hi,

anyone has objections against maintaining equivs (orphaned, see
https://bugs.debian.org/852223) under the hat of the Debian Perl Team?

(If so, I'll maintain it on my own, but I'd prefer team maintenance
and the Perl team seems be quite fitting.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: Digital signature

Bug#858664: RFS: dfc/3.1.0-1 [ITA]

[Axel Beckert]

Hi Sabino,

sab wrote:
>   dget -xhttps://mentors.debian.net/debian/pool/main/d/dfc/dfc_3.1.0-1.dsc

Regarding the changelog:

Please remove the following two lines from the changelog. They're no
more relevant since they're superseeded by your package adoption:

  * QA upload.
  * Set Maintainer to Debian QA Group. (See #858664.)

Additionally, it's common practice to leave one space between names
and the brackets as well as one empty line before a new contributor
section starts.

See e.g.
https://packages.qa.debian.org/w/wicd/news/20170528T210438Z.html for
an example. (Ignore the dots which indicate empty lines.)

Regarding your access to the packaging git repository: While all
Debian Developers have collab-maint write access by default, Alioth
guest users (everyone who's not a Debian Project member) don't have
write access.

It was possible to request access for non-members, but I don't know if
that's still wanted, also because Alioth (the system which hosts
Debian's git repos) is about to be replaced, see
https://lists.debian.org/debian-devel-announce/2017/06/msg2.html

So I'm not sure what's the best way to proceed with git write access
for you.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#858664: ITA: dfc -- display file system usage using graph and colors

[Axel Beckert]

Hi sab,

sab wrote:
> retitle 858664  ITA: dfc -- display file system usage using graph and colors
> owner 858664 sp...@onenetbeyond.org

Nice to see that someone is caring about dfc.

I've already prepared a new dfc upstream release (3.1.0) in the
packaging git repository
(https://anonscm.debian.org/cgit/collab-maint/dfc.git) for upload
after the stretch release.

Please build upon that state in the git repo when working on the dfc
package.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#862269: RFP: ntfs-3g-system-compression -- NTFS-3G plugin for reading "system compressed" files

[Axel Beckert]

Package: wnpp
Severity: wishlist

* Package name: ntfs-3g-system-compression
  Version : [no release yet]
  Upstream Author : Eric Biggers 
* URL or Web page : https://github.com/ebiggers/ntfs-3g-system-compression
* License : GPL-2+
  Programming lang: C
  Description : NTFS-3G plugin for reading "system compressed" files

System compression, also known as "Compact OS", is a Windows feature
that allows rarely modified files to be compressed using the XPRESS or
LZX compression formats. It is not built directly into NTFS but rather
is implemented using reparse points. This feature appeared in Windows 10
and it appears that many Windows 10 systems have been using it by
default.

This package contains a plugin which enables the NTFS-3G FUSE driver
to transparently read from system-compressed files.

Currently, only reading is supported. Compressing an existing file may
be done by using the "compact" utility on Windows, with one of the
options below ("xpress4k" is the weakest and fastest, "lzx" is the
strongest and slowest):

* /exe:xpress4k
* /exe:xpress8k
* /exe:xpress16k
* /exe:lzx

[End of potential long package description]

Some notes and thoughts:

Citing from the upstream web page:

> It must be built against NTFS-3G version 2017.3.23 or later, since
> that was the first stable version to include support for reparse point
> plugins.

Probably due to the freeze, that NTFS-3G version is not yet available in
Debian, but likely will become available after Stretch is released.

> The XPRESS and LZX compression formats used in system-compressed files
> are identical to the formats used in Windows Imaging (WIM)
> archives. Therefore, for the system compression plugin I borrowed the
> XPRESS and LZX decompressors I had already written for the wimlib
> project (https://wimlib.net/).

wimlib is already packaged for Debian by Hilko Bengen (X-Debbugs-CC'ed).

> I made some slight modifications for integration purposes.

*sigh* So there might be a chance that the library packaged by Hilko
might not be usable as (build-) dependency. Needs to be checked in
detail.

> The code in wimlib is currently licensed LGPLv3+, but I have
> relicensed the version in this plugin to GPLv2+ for consistency with
> NTFS-3G's license. (Public domain portions remain public domain.)

But at least upstream cares about license compatibility. That's good.

Regards, Axel

Bug#786808: would adequate be still in stretch or thrown out ?

[Axel Beckert]

Hi shirish,

shirish शिरीष wrote:
> couple of weeks back I saw in how-can-i-help that adequate might be
> thrown out.

Does not seem to be the case anymore. Maybe due to a dependency being
RC-buggy for more than a week which got fixed in the meanwhile?

P.S.: I'm interested in seeing adequate properly maintained, too.
Since it's written in Perl, I wonder if the Lintian Maintainers
(Cc'ed) could pick it up as it's more or less a companion to Lintian.
I would also help with that.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: Digital signature

Bug#675187: Processed: retitle to RFP: curses-apt-key -- Text-mode key manager for apt-key

[Axel Beckert]

Control: retitle -1 ITP: curses-apt-key -- Text-mode key manager for apt-key
Control: owner -1 !

*sigh*

Debian Bug Tracking System wrote:
> > retitle 675187 RFP: curses-apt-key -- Text-mode key manager for apt-key

Bart: How often do I have to tell you: You have to _read_ wnpp bugs
before retitling them from ITP to RFP.

This one is blocked by another bug and hence it's totally normal that
nothing happens until that other issue is solved.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#785658: O: xscavenger -- A lode-runner-like platform game for X

[Axel Beckert]

Hi David,

Mattia Rizzolo wrote:
> On Mon, May 18, 2015 at 08:05:46PM +, David Ashley wrote:
> > I am the original author for the game and have tried to contact the
> > maintainer (Hwei Sheng Teoh hst...@debian.org) multiple times to
> > notify him of sound related bugfixes that are available for
> > longstanding issues (on the order of 10 years old).
> 
> Right now I'm not seeing any relevant bug open against the package,

Exactly. And the maintainer is obviously active as he did an upload
last month:
https://packages.qa.debian.org/x/xscavenger/news/20170216T192022Z.html

And that's not the first one since this bug report was filed.

> which should be the main point of contact for requests about a package.
> Did you open any bug that got wrongly closed or something?

If that's not the case, please file one bug report per issue as proper
bug reports against xscavenger instead of mailing the maintainer
directly. Direct mails can get forgotten or lost. Proper bug reports
to the Bug Tracking System don't get lost. From this (IMHO
inappropriate) bug report it's totally unclear what the actual issues
are, so even reassigning it against xscavenger wouldn't really help.

Cc'ing Hwei Sheng Teoh to make him aware of this bug report.

    Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#835086: RFP: nextcloud -- self-hosted cloud services

[Axel Beckert]

Hi,

e-gleich-m-c-quad...@fantasymail.de wrote:
>Even if debian chooses to not feature the nextcloud server, (which I would
>regret) please consider the client.

At least owncloud-client is still in Debian:

https://packages.qa.debian.org/o/owncloud-client.html
https://packages.debian.org/search?keywords=owncloud-client

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#854490: RFP: xva-img -- Citrix XenServer .xva disk extraction tool

[Axel Beckert]

Hi,

Axel Beckert wrote:
> I'll probably come up with a complete packaging for this tool, but don't
> want to maintain it alone, hence RFP and not ITP.

My packaging is now at
https://anonscm.debian.org/git/collab-maint/xva-img.git

The only thing yet missing is a proper man page, hence it still
throughs these two lintian warnings:

W: xva-img source: dh-make-template-in-source debian/manpage.1.ex
W: xva-img: binary-without-manpage usr/bin/xva-img

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#854490: RFP: xva-img -- Citrix XenServer .xva disk extraction tool

[Axel Beckert]

Hi,

Axel Beckert wrote:
> * URL or Web page : https://github.com/eriklax/xva-img
> * License : GPL-2+

JFTR: I'm currently working on an initial packaging for xva-img
(should show up soon at
https://anonscm.debian.org/cgit/collab-maint/xva-img.git)
and Lintian made me aware of the following issue:

E: xva-img: possible-gpl-code-linked-with-openssl
N: 
N:This package appears to be covered by the GNU GPL but depends on the
N:OpenSSL libssl package and does not mention a license exemption or
N:exception for OpenSSL in its copyright file. The GPL (including version
N:3) is incompatible with some terms of the OpenSSL license, and therefore
N:Debian does not allow GPL-licensed code linked with OpenSSL libraries
N:unless there is a license exception explicitly permitting this.
N:
N:If only the Debian packaging, or some other part of the package not
N:linked with OpenSSL, is covered by the GNU GPL, please add a lintian
N:override for this tag. Lintian currently has no good way of
N:distinguishing between that case and problematic packages.
N:
N:Severity: serious, Certainty: wild-guess
N:
N:Check: copyright-file, Type: binary

I've filed a feature -eh- license update request upstream at
https://github.com/eriklax/xva-img/issues/5 to fix that.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#845155: Bug#851606: RFS: rmlint/2.4.6-1 [ITP]

[Axel Beckert]

Hi Carlos,

Carlos Maddela wrote:
> > Is there a reason not to use the official source tarballs from
> > https://github.com/sahib/rmlint/releases? (AFAIK and according to a
> > short check, GitHub no more produces different tarballs upon
> > subsequent downloads as it did in the past.)
[…]
> There wasn't any specific reason, except for trying to keep file sizes
> as small as possible. I have reverted to using the original tarballs now.

While trying to keep the package size small is appreciated, Debian
values original upstream tar balls more -- at least currently.

So thanks for that change.

> > In debian/rules I found this:
> >
> > # Automatically disable tests in sbuild and pbuilder.
> > ifneq (,$(filter /%nonexistent,$(HOME)))
> > export DEB_BUILD_MAINT_OPTIONS += nocheck
> > endif
[…]
> I only disabled the tests to speed up builds.

And you already found out about "nocheck". Great!

> There was initially some problems with the tests inside of sbuild,
> which prevented successful builds, but they have been resolved. The
> test suite doesn't make use of any $HOME directory. It was just my
> way of detecting if the build was being done from a chroot.

I see.
 
> Anyway, I have removed those lines completely, and the tests are
> performed now.

Thanks. The package got really nice. Seems to have been still quite
some work on top of my work

I've just uploaded your package and it should show up within the next
few hours in the so called NEW queue for review by the FTP masters,
i.e. at the end of https://ftp-master.debian.org/new.html

Nevertheless I've got two suggestions for the next upload:

* Rename debian/docs to debian/rmlint.docs for consistency with the
  other debian/rmlint.* files.

* Maybe rmlint-gui should ship a wrapper script called shredder which
  just calles 'exec rmlint --gui "$@"' -- in addition to ship the
  files necessary to make "rmlint --gui" work. But that's something
  where Christopher might want to have a word about, too. :-)

Anyway, thanks for your contribution to Debian! (And thanks to Roger
for his review, too!)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: Digital signature

Bug#854490: RFP: xva-img -- Citrix XenServer .xva disk extraction tool

[Axel Beckert]

Package: wnpp
Severity: wishlist

* Package name: xva-img
  Version : 1.4
  Upstream Author : Erik Lax 
* URL or Web page : https://github.com/eriklax/xva-img
* License : GPL-2+
  Description : Citrix XenServer .xva disk extraction tool

xva-image is a tool to generate disk images from Citrix XenServer .xva
VM images as well as to generate .xva VM images from raw disks and the
according ova.xml files.

It's for example needed if you want to forensically analyse a virtual
machine in .xva format on a non-Citrix operating system.

--

I've X-Debbugs-Cc'ed the Debian Forensics Team as well as the Kali
Developers as I assume that those are most likely interested in such a
tool.

I'll probably come up with a complete packaging for this tool, but don't
want to maintain it alone, hence RFP and not ITP.

But I might maintain the tool within a team, e.g. under the Debian
Forensics Team. I just don't have very often such files around for
testing as I don't have access to such a server. So maybe someone who
has more often contact with servers running Citrix XenServer could jump
on the bandwagon, too, to maintain the package together.

(Of course I don't mind if someone else takes over and maintains it
alone. :-)

Bug#851797: Processed: RFAs are severity normal

[Axel Beckert]

Control: severity -1 wishlist

Hi Adrian,

Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> > severity 851797 normal
> Bug #851797 [wnpp] RFA: dphys-config -- Tool to distribute config files by 
> fetching them
> Severity set to 'normal' from 'wishlist'

It might be the default severity of RFAs, but I'm not aware of any
rule saying that an RFA _must_ be of severity "normal".

This RFA was deliberately set to wishlist, so I'm setting back to
wishlist herewith.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#758238: RFP: cool-old-term -- eye-candy terminal emulator which mimics old cathode displays

[Axel Beckert]

Hi,

there's a packaging effort upstream:

https://github.com/Swordfish90/cool-retro-term/pull/331
https://github.com/Swordfish90/cool-retro-term/pull/331/commits/0423bbad4737f228ace56099332a74d05428363e

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#852948: ITP: systray-mdstat -- Notifies about Linux Software RAID changes in system tray

[Axel Beckert]

Package: wnpp
Owner: Axel Beckert <a...@debian.org>
Severity: wishlist

* Package name: systray-mdstat
  Version : (no release yet)
  Upstream Author : Axel Beckert <a...@deuxchevaux.org>
* URL : https://github.com/xtaran/systray-mdstat#readme
* License : GPL-3+
  Programming Lang: Perl
  Description : Notifies about Linux Software RAID changes in system tray

systray-mdstat is a small system tray icon indicating the state of
local Linux Software RAIDs (as set up with mdadm) by checking
/proc/mdstat for changes - especially failures - periodically.

The use case for this utility is a desktop or laptop with a software
RAID setup and no remote monitoring of the RAID (e.g. for privacy
reasons or due to lacking a permanent network connection or an
appropriate monitoring server).

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#852167: even with quirks gone, the tools are needed

[Axel Beckert]

Hi,

Adam Borowski wrote:
> > the quirks applied by pm-utils aren't really needed anymore nowadays.  I
> > suspect some of the are actually harmful these days.
> 
> But even if we get rid of the quirks, the actual tools (/usr/sbin/pm-*) are
> still needed.

Indeed, not only because of its reverse dependencies, but also because
(at least to my knowledge -- and I'd be happy to stand corrected)
they're the only (KISS/non-systemd/non-dbus-ish) commandline tools in
Debian which can suspend or hibernate a machine from the command-line.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#851797: RFA: dphys-config -- Tool to distribute config files by fetching them

[Axel Beckert]

Package: wnpp
Severity: wishlist

Hi,

neither me nor my co-maintainer (Cc'ed) use dphys-config anymore,
hence we we can't provide the proper amount of awareness about its
issues anymore.

So it would be nice if the package would be maintained by someone
who's actually using it on a daily base and keeps up the high
standards I had for the package when I was still using it.

Upstream Homepage: http://neil.franklin.ch/Projects/dphys-config/

Packaging Git Repository:
 https://anonscm.debian.org/cgit/pkg-dphys/dphys-config.git

Package Description:

  Tool to distribute config files by fetching them

  This project is aimed at automatically installing (and keeping
  update) site specific config files on many hosts, after preprocessing
  them (conditional content and include files and include sections). It
  also triggers postinstall scripts whenever their associated config
  file has been changed. It can also remove config files, including
  running an preremove script before doing so. All this is driven by an
  simple config file list.

  dphys-config is capable of reporting update failure or success to a
  Xymon (formerly Hobbit) monitoring server.

  dphys-config features an interactive mode and a non-interactive diff
  mode to check what would be updated.

We'll nevertheless continue to keep it in shape, at least with regards
to release-critical bugs.

Accordingly this RFA may only be changed to "O:" by myself, my
co-maintainer, with my or my co-maintainer's acknowledgement or if the
MIA team considers both of us being MIA.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: Digital signature

Bug#851177: RFP: cachet -- status page system

[Axel Beckert]

Package: wnpp
Severity: wishlist

* Package name: cachet
  Version : 2.3.10
  Upstream Author : Alt Three Services Ltd.
* URL or Web page : https://cachethq.io/
https://github.com/CachetHQ/Cachet
* License : BSD-3-Clause
  Description : status page system

Cachet is a PHP-written and responsive status page system which improves
downtime (support-wise and customer-wise). It is translated to over ten
languages and sports a JSON API as well as two-factor authentication
(using Google Authenticator).

A demo site is available at https://demo.cachethq.io/ and a production
site of another FLOSS project is at https://status.lineageos.org/.
(That's actually how I stumbled upon it.)

Bug#649860: closing RFP: wwwoffle -- World Wide Web OFFline Explorer

[Axel Beckert]

Control: reopen -1

Hi Bart,

Bart Martens schrieb am Fri, Jan 06, 2017 at 04:20:17PM +:
> RFP 649860 has no visible progress for a long time, so closing.

That doesn't mean that there's no more interest in getting wwwoffle
back into Debian. It's an RFP and not an ITP after all.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE