Epoch version for golang-github-gomodule-redigo-dev?

[Michael Prokop]

Hi,

we have a rather unfortunate situation with the
golang-github-gomodule-redigo-dev package, see #974550 for the
details.

tl;dr: upstream released v2.0.0 on 2018-03-14, though went downwards
with version numbers afterwards and we're at v1.8.3 for the latest
upstream release now. In Debian we currently have v2.0.0 in
buster/testing/unstable.

It looks like upstream isn't willing to raise the version number
(see https://github.com/gomodule/redigo/issues/532, and a somewhat
related discussion took place also in
https://github.com/gomodule/redigo/issues/366), so if we want to fix
the situation for bullseye, we need a workaround/solution soonish.

Since the problem exists due to the way go module versioning works,
it might make sense to discuss, how to handle it a) now for
golang-github-gomodule-redigo-dev, but also b) apply the same
decision whenever the issue comes up again?

The situation is related to the fact how go module versioning works:

* `go get github.com/gomodule/redigo/redis` currently points at v1.8.3
* https://pkg.go.dev/github.com/gomodule/redigo/redis?tab=versions
  says v1, both for v1.8.3 but also v2.0.0+incompatible

AFAICS we could:

1) use 2.0.0+really1.8.3 pattern for our Debian package version
2) introduce an epoch
3) any further trick/workaround?

Thoughts?

Thanks to Clément Hermann, Tianon Gravi and Shengjing Zhu for their
feedback on #debian-golang.

regards
-mika-


signature.asc
Description: Digital signature

Re: Epoch version for golang-github-gomodule-redigo-dev?

[Paul Gevers]

Hi Michael,

On 26-11-2020 08:57, Michael Prokop wrote:
> AFAICS we could:
> 
> 1) use 2.0.0+really1.8.3 pattern for our Debian package version

As it seems not unreasonable to expect the upstream version to go past
2.0.0 in the not infinite future, this is the approach I would take.
Because you ask here, it suggests to me that doing this has some pain
for the packaging that you didn't elaborate on. Why do you even raise
the question here on debian-devel and don't just do this established way
of fixing these kind of temporarily versioning issues in Debian?

> 2) introduce an epoch

Because this you have to carry forever.

> 3) any further trick/workaround?

Paul



signature.asc
Description: OpenPGP digital signature

Re: Epoch version for golang-github-gomodule-redigo-dev?

[Holger Levsen]

On Thu, Nov 26, 2020 at 09:31:30AM +0100, Paul Gevers wrote:
> > 1) use 2.0.0+really1.8.3 pattern for our Debian package version
> As it seems not unreasonable to expect the upstream version to go past
> 2.0.0 in the not infinite future, this is the approach I would take.

well. "not unreasonable" and "not infinite future" could very likely
turn into carrying 2.0.0+really1.8.3 for the next 20 years...

> > 2) introduce an epoch
> Because this you have to carry forever.

...which more or less is the same time span as the above.

Also I find 1:1.8.3 not ugly at all, for most use cases this is 1.8.3
so I would go with that. And if someone complains about the 1: epoch
one can always point to the upstream issue explaining why this has
happened.

Oh, and I do find 2.0.0+really1.8.3 and even more 2.0.0+really1.8.4+gitXYZ
much more ugly than 1:1.8.3 or 1:1.8.3+gitXYZ


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

“If the fires of 2020 horrify you, consider that, no matter what we do, by
 2050, when the benefits of even fast climate action will only begin to arrive,
 the area burned annually in the (US) West is expected to at least double and
 perhaps quadruple.” (David Wallace-Wells)


signature.asc
Description: PGP signature

Re: Epoch version for golang-github-gomodule-redigo-dev?

[Paul Gevers]

Hi Holger,

On 26-11-2020 10:01, Holger Levsen wrote:
> Also I find 1:1.8.3 not ugly at all, for most use cases this is 1.8.3
> so I would go with that. And if someone complains about the 1: epoch
> one can always point to the upstream issue explaining why this has
> happened.

If I recall correctly, the issue with epoch's is not it's ugliness. We
had multiple threads on this list and it even ended up in policy
(5.6.12) to consult this list (bug #891216 [1]). I don't recall what the
exact problems were with epoch's (and couldn't spot it skimming that bug
report), just that there were technical issues with its use.

Paul

[1] https://bugs.debian.org/891216



signature.asc
Description: OpenPGP digital signature

Re: Epoch version for golang-github-gomodule-redigo-dev?

[Holger Levsen]

On Thu, Nov 26, 2020 at 10:32:20AM +0100, Paul Gevers wrote:
> If I recall correctly, the issue with epoch's is not it's ugliness. 

#891216 doesn't come with any justification (except that they are
often misunderstood and unneeded, which actually is a fine
justification to ask before using but which is not a good justification
against using them at all) and while both #891216 and
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_What_are_version_epochs_and_why_and_when_are_they_needed.3F
mention technical difficulties they both fail to describe them.

The FAQ comes close when stating: "An epoch is both confusing to 
users and distracting as it clutters the version string, and
technically problematic, and it's a permanent stigma denoting
that someone along the chain messed up." to which I'd reply that
1.2.3+really0.1.2+GITXYZ+DFSG-1 is equally confusing and distracting
and often also become a almost permanent stigma.

The technical problems I'm are aware of are that a.) version numbers
(with and without epoch) need to be unique, so if you had 0:2.0.0-1
you are not allowed to ever have 1:2.0.0-1 again. That's enforced
by dak however.

The other technical problem is that .deb filenames don't contain
the epoch, which is a problem the archive (and the ecosystems 
aound) has a few hundred times already so tools and people cope 
with it already, eg:

Package: bind9
Version: 1:9.11.5.P4+dfsg-5.1+deb10u2
Filename: pool/updates/main/b/bind9/bind9_9.11.5.P4+dfsg-5.1+deb10u2_amd64.deb

(which btw I consider an ugly version number but hardly due to the "1:"
but because of the rest.)

So my conclusion is: try to avoid epochs (because they are forever) but use
them if sensible. (-> if a package goes from 2.0 to 1.8.3 *maybe* an epoch
can be avoided, but if a package goes from 42 to 0.23 I'd be very inclined 
to use an epoch.) - and in any case consult -devel@ and see what this lot
has to say.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

Stop saying that we are all in the same boat.
We’re all in the same storm.
But we’re not all in the same boat.


signature.asc
Description: PGP signature

Re: Epoch version for golang-github-gomodule-redigo-dev?

[Mattia Rizzolo]

On Thu, 26 Nov 2020, 11:30 am Holger Levsen,  wrote:

>
> The technical problems I'm are aware of are that a.) version numbers
> (with and without epoch) need to be unique, so if you had 0:2.0.0-1
> you are not allowed to ever have 1:2.0.0-1 again. That's enforced
> by dak however.
>

That's not enforced by dak.  The only case it would be enforced is when
once try to upload the 1: version while the 0: is still published, which is
rare in the cases of epochs.

The other technical problem is that .deb filenames don't contain
> the epoch, which is a problem the archive


Which is the same problem as above, from my understanding.

There is that risk in having two filenames with different content across
history.


IIRC, there *used to* be an actual problem way back in some program that
couldn't handle the : in filenames, and that's why they are not present to
this day.  I argue that we could just put that : (or the %-encoded version,
to avoid accidentally ssh-ing somewhere...) and be done with whatever
problem.


The other problem, is that maintainers regularly forge to put the epoch
when writing version restrictions in d/control, but those are just bugs
that people should be aware of...



(Explicitly not drawing any conclusion here...)

Bug#975898: ITP: python-psycopg2cffi -- implementation of the psycopg2 module using cffi

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-psycopg2cffi
  Version : 2.8.1
  Upstream Author : Konstantin Lopuhin 
* URL : http://github.com/chtd/psycopg2cffi
* License : GPL-3+
  Programming Lang: Python
  Description : implementation of the psycopg2 module using cffi

 This package provides an implementation of the psycopg2 module using cffi.
 .
 Psycopg is a PostgreSQL database adapter for the Python3 programming language
 (just like pygresql and popy.) This is version 2, a complete rewrite of the
 original code to provide new-style classes for connection and cursor objects
 and other sweet candies. Like the original, psycopg 2 was written with the
 aim of being very small and fast, and stable as a rock.
 .
 psycopg is different from the other database adapter because it was designed
 for heavily multi-threaded applications that create and destroy lots of
 cursors and make a conspicuous number of concurrent INSERTs or UPDATEs.
 psycopg 2 also provides full asynchronous operations for the really brave
 programmer.

Note: This is a new dependency of python-sqlalchemy-utils

Re: Epoch version for golang-github-gomodule-redigo-dev?

[Holger Levsen]

On Thu, Nov 26, 2020 at 12:02:41PM +0100, Mattia Rizzolo wrote:
> That's not enforced by dak.  The only case it would be enforced is when
> once try to upload the 1: version while the 0: is still published, which is
> rare in the cases of epochs.

right, thanks for making this detail clearer.
 
> IIRC, there *used to* be an actual problem way back in some program that
> couldn't handle the : in filenames, and that's why they are not present to
> this day.  I argue that we could just put that : (or the %-encoded version,
> to avoid accidentally ssh-ing somewhere...) and be done with whatever
> problem.

I very much agree (using the %-encoded version for the sake of some
filesystems).
 

-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄


signature.asc
Description: PGP signature

Re: Epoch version for golang-github-gomodule-redigo-dev?

[Simon McVittie]

Paul Gevers wrote:
> > 1) use 2.0.0+really1.8.3 pattern for our Debian package version
> As it seems not unreasonable to expect the upstream version to go past
> 2.0.0 in the not infinite future, this is the approach I would take.

The +really pattern is normally used when the version in Debian needs
to be reverted, such as src:capstone in unstable and src:lxc in buster.
In these cases, upstream's versioning scheme didn't change: the only thing
that actually changed was Debian's idea of which upstream version was
(temporarily!) most suitable for testing/unstable, and that is something
that can eventually go away when that upstream version is superseded by
one that is "even better".

The move of src:acme-tiny from 20171115-2 to 1:4.0.4-1 [1] is a clearer
example of the upstream versioning scheme genuinely changing, which is
the situation that epochs were originally designed for.

[1] https://lists.debian.org/debian-devel/2019/04/msg00052.html

golang-github-gomodule-redigo-dev seems to be somewhere between those
situations: upstream have not changed how their versioning scheme works,
but they are no longer releasing versions 2.x and want people to use
versions 1.x instead, for reasons that I don't fully understand.

If old-1.x is incompatible with 2.x, and new-1.x is considered to be
"better than" 2.x but is incompatible with 2.x, while old-1.x is compatible
with new-1.x (in other words, there were incompatible changes in 2.x but
the upstream project now considers them to have been a mistake and has
reverted them), and the upstream project intends to be using semantic
versioning, then I think the cleanest representation would be for the
upstream project to bump the version to 3.x and move on. (Justification:
semantic versioning says you bump major version on incompatible changes,
and the releases that are considered to supersede 2.x are incompatible
with 2.x, so they should maybe be 3.x.)

However, if they won't do that, and they upstream consider 2.x to be
a dead end and have resumed releasing 1.x, then it's not necessarily
the case that there will ever be another 2.x or higher version; so the
advantage of +really (that you can eventually discard it) might never
actually materialize. So an epoch might be more appropriate here than
it would initially seem.

smcv

Re: Epoch version for golang-github-gomodule-redigo-dev?

[Clément Hermann]

(And that should have been sent from my @d.o email address, but the
setup I have in place for that is apparently broken, sorry 😉)

On 26/11/2020 14:19, Clément Hermann wrote:
> On 26/11/2020 09:31, Paul Gevers wrote:
>> Hi Michael,
>>
>> On 26-11-2020 08:57, Michael Prokop wrote:
>>> AFAICS we could:
>>>
>>> 1) use 2.0.0+really1.8.3 pattern for our Debian package version
>>
>> As it seems not unreasonable to expect the upstream version to go past
>> 2.0.0 in the not infinite future, this is the approach I would take.
>> Because you ask here, it suggests to me that doing this has some pain
>> for the packaging that you didn't elaborate on. Why do you even raise
>> the question here on debian-devel and don't just do this established way
>> of fixing these kind of temporarily versioning issues in Debian?
> 
> Well, I was the one suggesting Michael start a discussion on
> debian-devel about it, so I thought I'd chime in.
> 
> 
> My reasonning is +really seems to me to be a workaround when we
> have to change the version number for Debian only reason - with no fault
> of upstream. An example of this was the lack of transition in the last
> freeze with a bunch of Go packages that were updated in unstable when
> they shouldn't have, and had to be reverted.
> 
> Actually, I even suggested to use +upstream instead, but I
> don't know if that'd be allowed (as in understandable, clearer that
> +really and as such, useful).
> 
> Also, we don't know if it's temporary, as Holger pointed out.
> 
> An epoch might be overkill here, but also seems more appropriate to me
> since we have to work around upstream decision in this case. And since
> the Policy states it needs to be discussed first here, I suggested to do
> just that.
> 
> I do agreee that the best and most logical thing would be for upstream
> to start using 3.0, as Simon pointed out. Michael, did you bring this
> issue upstream ? Would you suggest this option to them ? If they're
> willing to do that in a reasonable timeframe, we could go the +really
> route and wait until 3.0 is available upstream. Otherwise, we can go for
> an epoch if we reach consensus here.
> 
> Thanks to everyone participating, by the way!
> 
> Cheers,
> 

Bug#975908: ITP: python-infinity -- All-in-one infinity value for Python. Can be compared to any object.

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-infinity
  Version : 1.5
  Upstream Author : Konsta Vesterinen 
* URL : https://github.com/kvesteri/infinity
* License : BSD-3-clause
  Programming Lang: Python
  Description : All-in-one infinity value for Python. Can be compared to 
any object.

 This package provides an all-in-one infinity value for Python. The infinity
 "inf" object can then be compared to any other Python object, or used in math
 expressions.

Note: This package is needed by psycopg2cffi, itself needed by the new 
python-sqlalchemy-utils.

Re: Epoch version for golang-github-gomodule-redigo-dev?

[Clément Hermann]

On 26/11/2020 09:31, Paul Gevers wrote:
> Hi Michael,
> 
> On 26-11-2020 08:57, Michael Prokop wrote:
>> AFAICS we could:
>>
>> 1) use 2.0.0+really1.8.3 pattern for our Debian package version
> 
> As it seems not unreasonable to expect the upstream version to go past
> 2.0.0 in the not infinite future, this is the approach I would take.
> Because you ask here, it suggests to me that doing this has some pain
> for the packaging that you didn't elaborate on. Why do you even raise
> the question here on debian-devel and don't just do this established way
> of fixing these kind of temporarily versioning issues in Debian?

Well, I was the one suggesting Michael start a discussion on
debian-devel about it, so I thought I'd chime in.


My reasonning is +really seems to me to be a workaround when we
have to change the version number for Debian only reason - with no fault
of upstream. An example of this was the lack of transition in the last
freeze with a bunch of Go packages that were updated in unstable when
they shouldn't have, and had to be reverted.

Actually, I even suggested to use +upstream instead, but I
don't know if that'd be allowed (as in understandable, clearer that
+really and as such, useful).

Also, we don't know if it's temporary, as Holger pointed out.

An epoch might be overkill here, but also seems more appropriate to me
since we have to work around upstream decision in this case. And since
the Policy states it needs to be discussed first here, I suggested to do
just that.

I do agreee that the best and most logical thing would be for upstream
to start using 3.0, as Simon pointed out. Michael, did you bring this
issue upstream ? Would you suggest this option to them ? If they're
willing to do that in a reasonable timeframe, we could go the +really
route and wait until 3.0 is available upstream. Otherwise, we can go for
an epoch if we reach consensus here.

Thanks to everyone participating, by the way!

Cheers,

-- 
nodens

MariaDB 10.5 has entered Debian testing (will be in Bullseye)

[Otto Kekäläinen]

Hello!

MariaDB 10.5 release 1:10.5.8-3 finally entered Debian testing
today[1]. It has been in unstable since early September, and the work
on the successor of 10.3 in Debian started already in January (with
10.4 which then turned into 10.5 as upstream released it this spring).

This also means that MariaDB 10.3 will be removed (or the remaining
traces of it to be exact) in the following weeks.

MariaDB 10.5 has a rather massive 45 step CI pipeline just for
Debian[2] and we hope the number of bugs is small, but still it is
always expected that in a major upgrade like 10.3 -> 10.5 users might
experience some issues.

If you encounter issues

1) file a high quality bug report at bugs.debian.org, and consider
filing one in parallel at upstream at jira.mariadb.org if the issue
does not seem to be packaging related

2) send a merge request on Salsa following guidelines at
https://wiki.debian.org/Teams/MySQL/patches

MariaDB in Debian is quite heavily on my shoulders right now. I would
be very glad to see more merge requests, even small ones are nice and
show that people contribute.

Some git stats for the post-10.3 cycle in Debian:

git summary 7bf99ca66..HEAD

 project  : mariadb-10.5
 commits  : 197
 authors  :
   187 Otto Kekäläinen 94.9%
 2 Christian Göttsche  1.0%
 2 Helmut Grohne   1.0%
 1 Aurelien Jarno  0.5%
 1 Bastian Germann 0.5%
 1 Christian Ehrhardt  0.5%
 1 Daniel Black0.5%
 1 Faustin Lammler 0.5%
 1 Miroslav Kure   0.5%

Thanks to all contributors! [3]
Also a big thanks those who sent patches as files and very helpful
hints, in particular jrtc27 and the porter folks!

[1] https://tracker.debian.org/pkg/mariadb-10.5
[2] https://salsa.debian.org/mariadb-team/mariadb-10.5/-/pipelines/200608
[3] https://salsa.debian.org/mariadb-team/mariadb-10.5/-/graphs/master

Re: MariaDB 10.5 has entered Debian testing (will be in Bullseye)

[Thomas Goirand]

Hi Otto,

On 11/26/20 4:44 PM, Otto Kekäläinen wrote:
> Hello!
> 
> MariaDB 10.5 release 1:10.5.8-3 finally entered Debian testing
> today[1]. It has been in unstable since early September, and the work
> on the successor of 10.3 in Debian started already in January (with
> 10.4 which then turned into 10.5 as upstream released it this spring).

Thanks for maintaining MariaDB in Debian.

Do you happen to know the procedure for upgrading a Galera cluster of 3
MariaDB nodes from 10.3 to 10.5? Is this formalized in some doc anywhere?

Cheers,

Thomas Goirand (zigo)

Re: MariaDB 10.5 has entered Debian testing (will be in Bullseye)

[Otto Kekäläinen]

to 26. marrask. 2020 klo 18.45 Thomas Goirand  kirjoitti:

> Hi Otto,
>
> On 11/26/20 4:44 PM, Otto Kekäläinen wrote:
> > Hello!
> >
> > MariaDB 10.5 release 1:10.5.8-3 finally entered Debian testing
> > today[1]. It has been in unstable since early September, and the work
> > on the successor of 10.3 in Debian started already in January (with
> > 10.4 which then turned into 10.5 as upstream released it this spring).
>
> Thanks for maintaining MariaDB in Debian.
>
> Do you happen to know the procedure for upgrading a Galera cluster of 3
> MariaDB nodes from 10.3 to 10.5? Is this formalized in some doc anywhere?
>

You can do a live rolling upgrade. New hosts with Galera 4 can join a
running Galera 3 cluster one by one, but once upgrade starts no new old
hosts can join anymore, only leave.

https://www.slideshare.net/ottokekalainen/debconf-2020-whats-new-in-mariadb-server-105-and-galera-4#34

https://galeracluster.com/library/documentation/upgrading.html

MariaDB 10.4 intoduced Galera 4, so this applies for MariaDB 10.3 (Galera
3) -> 10.5 ((Galera 4) upgrades as well:
https://mariadb.com/kb/en/upgrading-from-mariadb-103-to-mariadb-104-with-galera-cluster/

>

Bug#975925: ITP: proxy-vole -- Java library to auto detect the platform network proxy settings

[Roger Shimizu]

Package: wnpp
Severity: wishlist
Owner: Roger Shimizu 

* Package name: proxy-vole
  Version : 1.0.3
  Upstream Author : Markus Bernhardt 
* URL : https://github.com/MarkusBernhardt/proxy-vole
* License : Apache-2.0 and BSD-3-clause
  Programming Lang: Java
  Description : Proxy Vole

 Proxy Vole is a Java library to auto detect the platform network proxy
 settings.

Bug#975930: ITP: finbin -- Hi-speed search for a byte sequence in a big byte array

[Roger Shimizu]

Package: wnpp
Severity: wishlist
Owner: Roger Shimizu 

* Package name: finbin
  Version : 0.6.2
  Upstream Author : Tom Misawa 
* URL : https://github.com/riversun/finbin
* License : Apache-2.0 or Expat
  Programming Lang: Java
  Description : Hi-speed search for a byte sequence in a big byte array

Re: MariaDB 10.5 has entered Debian testing (will be in Bullseye)

[Thomas Goirand]

On 11/26/20 7:35 PM, Otto Kekäläinen wrote:
> 
> 
> to 26. marrask. 2020 klo 18.45 Thomas Goirand  > kirjoitti:
> 
> Hi Otto,
> 
> On 11/26/20 4:44 PM, Otto Kekäläinen wrote:
> > Hello!
> >
> > MariaDB 10.5 release 1:10.5.8-3 finally entered Debian testing
> > today[1]. It has been in unstable since early September, and the work
> > on the successor of 10.3 in Debian started already in January (with
> > 10.4 which then turned into 10.5 as upstream released it this spring).
> 
> Thanks for maintaining MariaDB in Debian.
> 
> Do you happen to know the procedure for upgrading a Galera cluster of 3
> MariaDB nodes from 10.3 to 10.5? Is this formalized in some doc
> anywhere?
> 
> 
> You can do a live rolling upgrade. New hosts with Galera 4 can join a
> running Galera 3 cluster one by one, but once upgrade starts no new old
> hosts can join anymore, only leave.
> 
> https://www.slideshare.net/ottokekalainen/debconf-2020-whats-new-in-mariadb-server-105-and-galera-4#34
> 
> 
> https://galeracluster.com/library/documentation/upgrading.html
> 
> 
> MariaDB 10.4 intoduced Galera 4, so this applies for MariaDB 10.3
> (Galera 3) -> 10.5 ((Galera 4) upgrades as well:
> https://mariadb.com/kb/en/upgrading-from-mariadb-103-to-mariadb-104-with-galera-cluster/
> 

So, if I understand well, if I have 3 MariaDB Buster nodes in a cluster,
I just need to dist-upgrade them to Bullseye, and it will automagically
just work and upgrade to Galera 4? If so, that's just great, because
during our last discussion in Brazil, you told me about something a way
more risky (ie: turn off 2 nodes, upgrade the 3rd one, then upgrade node
1 and 2).

Cheers,

Thomas Goirand (zigo)

Bug#975937: ITP: puppet-module-voxpupuli-zabbix -- Puppet module for zabbix

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-voxpupuli-zabbix
  Version : 8.0.0
  Upstream Author : Vox Pupuli
* URL : https://github.com/voxpupuli/puppet-zabbix/
* License : Apache-2.0
  Programming Lang: Puppet
  Description : Puppet module for zabbix

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 puppet-zabbix installs and configure Zabbix.

Note: I'm going to use this to integrate the monitoring in OCI.

Bug#975938: ITP: jboss-vfs -- JBoss Virtual File System

[Bdale Garbee]

Package: wnpp
Severity: wishlist
Owner: Bdale Garbee 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: jboss-vfs
  Version : 3.2.15.Final
  Upstream Author : JBoss, A division of Red Hat, Inc.
* url : http://www.jboss.org
* License : Apache-2.0
  Programming Lang: Java
  Description : JBoss Virtual File System

This package delivers the JBoss VFS libraries.  A much earlier version was
once included in Debian but dropped due to lack of use.  I'm re-packaging a
modern version with help from Sudip Mukherjee because it's a dependency for
annotation-detector, which is a dependency for openrocket, which I'm trying
to get back into main instead of being a jar-installer package in contrib.

Work-needing packages report for Nov 27, 2020

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1174 (new: 3)
Total number of packages offered up for adoption: 213 (new: 3)
Total number of packages requested help for: 63 (new: 0)

Please refer to https://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   hercules (#975496), orphaned 4 days ago
 Description: System/370, ESA/390 and z/Architecture Emulator
 Reverse Depends: herculesstudio
 Installations reported by Popcon: 101
 Bug Report URL: https://bugs.debian.org/975496

   opensysusers (#975378), orphaned 5 days ago
 Installations reported by Popcon: 3
 Bug Report URL: https://bugs.debian.org/975378

   opentmpfiles (#975377), orphaned 5 days ago
 Reverse Depends: diaspora-common
 Installations reported by Popcon: 7
 Bug Report URL: https://bugs.debian.org/975377

1171 older packages have been omitted from this listing, see
https://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   archmage (#975618), offered 2 days ago
 Description: CHM (Compiled HTML) Decompressor
 Installations reported by Popcon: 146
 Bug Report URL: https://bugs.debian.org/975618

   libssh2 (#975617), offered 2 days ago
 Description: SSH2 client-side library
 Reverse Depends: cargo cargo-lichking cargo-outdated
   centreon-connector-ssh debcargo gfal2-plugin-sftp julia libaria2-0
   libcurl3-gnutls libcurl3-nss (25 more omitted)
 Installations reported by Popcon: 195135
 Bug Report URL: https://bugs.debian.org/975617

   sgmllib3k (#975620), offered 2 days ago
 Description: Python 3 port of Python 2's sgmllib
 Reverse Depends: archmage
 Installations reported by Popcon: 51
 Bug Report URL: https://bugs.debian.org/975620

210 older packages have been omitted from this listing, see
https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   album-data (#964105), requested 148 days ago (non-free)
 Description: themes, plugins and translations for album
 Installations reported by Popcon: 85
 Bug Report URL: https://bugs.debian.org/964105

   apache2 (#910917), requested 775 days ago
 Description: Apache HTTP Server
 Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom
   apache2-suexec-pristine backuppc courier-webadmin cvsweb debbugs-web
   doc-central dwww (133 more omitted)
 Installations reported by Popcon: 95321
 Bug Report URL: https://bugs.debian.org/910917

   asciio (#968843), requested 96 days ago
 Description: dynamically create ASCII charts and graphs with GTK+2
 Installations reported by Popcon: 86
 Bug Report URL: https://bugs.debian.org/968843

   aufs (#963191), requested 159 days ago
 Description: driver for a union mount for Linux filesystems
 Reverse Depends: fsprotect
 Installations reported by Popcon: 14991
 Bug Report URL: https://bugs.debian.org/963191

   autopkgtest (#846328), requested 1457 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: debci-worker qemu-sbuild-utils
 Installations reported by Popcon: 1231
 Bug Report URL: https://bugs.debian.org/846328

   balsa (#642906), requested 3350 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 688
 Bug Report URL: https://bugs.debian.org/642906

   broadcom-sta (#886599), requested 1053 days ago (non-free)
 Description: Broadcom STA Wireless driver (non-free)
 Installations reported by Popcon: 1683
 Bug Report URL: https://bugs.debian.org/886599

   cargo (#860116), requested 1325 days ago
 Description: Rust package manager
 Reverse Depends: dh-cargo
 Installations reported by Popcon: 1780
 Bug Report URL: https://bugs.debian.org/860116

   cyrus-imapd (#921717), requested 657 days ago
 Description: Cyrus mail system - IMAP support
 Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev
   cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication
 Installations reported by Popcon: 439
 Bug Report URL: https://bugs.debian.org/921717

   cyrus-sasl2 (#799864), requested 1891 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-ds-base adcli autofs-ldap cyrus-caldav
   cyrus-clients cyrus-common cyrus-dev cyrus-imapd cyrus-imspd
   cyrus-murder (77 more omitted)
 Installations reported by Popcon: 199981
 Bug Report URL: https://bugs.debian.org/799864

   db

Re: MariaDB 10.5 has entered Debian testing (will be in Bullseye)

[Otto Kekäläinen]

> So, if I understand well, if I have 3 MariaDB Buster nodes in a cluster,
> I just need to dist-upgrade them to Bullseye, and it will automagically
> just work and upgrade to Galera 4? If so, that's just great, because
> during our last discussion in Brazil, you told me about something a way
> more risky (ie: turn off 2 nodes, upgrade the 3rd one, then upgrade node
> 1 and 2).

Yes, after we spoke 1,5 years ago Galera has started to support
rolling upgrades from 3->4. I have personal experience that it works.

So keep all 3 nodes on. Upgrade fully one node, wait until it joins
and syncs and cluster is PRIMARY again, then proceed with the 2nd node
etc.