Bug#906715: ITP: lloconv -- command line document converter using libreofficekit
Package: wnpp Severity: wishlist Owner: Olly Betts * Package name: lloconv Version : 6.1.0 Upstream Author : Olly Betts * URL : https://gitlab.com/ojwb/lloconv * License : MPL-2.0 Programming Lang: C++ Description : command line document converter using LibreOfficeKit A command line document format converter which uses LibreOffice (via its LibreOfficeKit API) to do all the hard work. It should support the same formats which LibreOffice does. LibreOfficeKit was formerly known as liblibreoffice, hence the name "lloconv".
Re: OpenStack dysfunctionality (was: salsa.debian.org maintenance...)
On 2018-08-19 09:53:36 +0200 (+0200), Bastian Blank wrote: > On Sat, Aug 18, 2018 at 11:55:19PM +0200, Thomas Goirand wrote: [...] > > First, there's dozens of OpenStack public cloud out there, so > > you're not locked-in with a single operator. > > There exists thousand variants how to setup an OpenStack instance. > Just leave out some specific service and it's not longer > compatible with your project. So you not just need to find an > OpenStack operator, you need to find an operator who provides the > correct set of services you need. Any provider brandishing the OpenStack Powered Platform trademark is required to pass a battery of tests which confirm that the minimum expected featureset is present and functions as expected: https://www.openstack.org/brand/interop/ The official SDK and unified command-line client are also intended to maintain backward compatibility with pretty much any version of official service APIs which have ever existed in the history of the project, and cope fairly well with the various deployment configurations which are found in the wild (I can confirm this, as I help maintain a distributed application which simultaneously and continuously interacts with OpenStack services operated by 10 different service providers around the World, which provides a fairly representative sample size). Believing what random people say about OpenStack is like believing what random people say about Debian. I've heard that Debian's just a bunch of pedantic wonks who care more about licensing technicalities than whether their distribution carries working software, and that they regularly introduce non-upstream security holes through naive patching of code they don't comprehend. I don't *believe* those things because I spend a lot of time in and around the Debian community and I know better, but lots of people take this as gospel. > > Then there's not a single contributor to the OpenStack source > > code, the contributors are quite diverse. > > A friend of mine called OpenStack a dysfunctional open source > project. Especially the number of different people giving the > shots and running in different directions does not help. (No > project in OpenStack looks alike. Just look at all the different > variants for how to maintain the database schema.) [...] Pot calling the kettle black? Those who live in glass houses shouldn't throw stones? As a *long time* participant in the Debian community (it's been my primary distro choice for all my personal systems since Hamm), I have a hard time believing you could seriously make such assertions. How many different package maintainers and maintainer teams does Debian have calling the shots over their individual fiefdoms? Yet this diverse community of participants collaborates effectively, often made stronger through disagreement and dissent, to produce what I believe to be the best GNU/Linux distribution ever. My attempts to help steer the OpenStack community toward healthy collaboration draw much inspiration from the sort of collaboration which I've seen go on in Debian over the years. > > Well, it's a question of view. To me, having Salsa to host some > > of its data on Google is a kind of tacit endorsement. Even > > worse, it gives the message that, from the viewpoint of the > > whole Debian community, it's ok to host there. Clearly, I'm not > > the only one bothered in this way. > > No, it's how the word is defined in the english language. Like it or not, the software and services we choose set an example for others to follow. I have the utmost respect and appreciation for all the hard work which went into replacing Alioth (and maintaining Alioth before that). As much as I'm not a fan of Gitlab's open-core development model, I recognize that the decision as to what to use was ultimately up to the people who were volunteering to do all that work. Nevertheless, to a lot of other free and open software communities who looked up to the Debian community's strong commitment to software freedom, the choice to use Gitlab instead of one of the freer alternatives out there *did* seem like a betrayal of those ideals (choosing convenience over freedom). So yes, regardless of whether you consider it to be a tacit endorsement, there are a lot of people watching and they *will* draw conclusions about Debian's stance on software freedom from the sorts of software and services it chooses to deploy for its developer community. And apologies, the OpenStack subthread here got pretty off-topic. I don't normally post about OpenStack on debian-devel (or any other non-OpenStack mailing lists for that matter), but I felt like I really did need to address a few of your points on the subject. -- Jeremy Stanley signature.asc Description: PGP signature
Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)
On 08/19/2018 09:53 AM, Bastian Blank wrote:
> On Sat, Aug 18, 2018 at 11:55:19PM +0200, Thomas Goirand wrote:
>> On 08/18/2018 01:11 PM, Bastian Blank wrote:
>> First, there's dozens of OpenStack public cloud out there, so you're not
>> locked-in with a single operator.
>
> There exists thousand variants how to setup an OpenStack instance.
Really? It's been years I'm working on OpenStack, that's not what I saw.
Could you explain a bit more?
> Just leave out some specific service and it's not longer compatible with your
> project.
What kind of specific server do you have in mind here?
> So you not just need to find an OpenStack operator, you need
> to find an operator who provides the correct set of services you need.
The bare minimum one is to expect is: keystone, nova, glance, cinder,
neutron, heat. And generally, you also find swift. I don't see how a
public cloud provider would not provide at least these. Barbican is also
slowly becoming a standard too.
Now, if your provider also has trove, designate, magnum, manilla,
murano, neutron-{fwaas,lbaas,vpnaas} and so on, that's only a bonus, but
you often can deal without them.
>> Then there's not a single contributor
>> to the OpenStack source code, the contributors are quite diverse.
>
> A friend of mine called OpenStack a dysfunctional open source project.
> Especially the number of different people giving the shots and running
> in different directions does not help. (No project in OpenStack looks
> alike. Just look at all the different variants for how to maintain the
> database schema.)
This is somewhat exaggerated. Yes, because of historical reasons,
there's both Alembic and SQLAlchemy-migrate. Though oslo.db supports
both, and in practice, it's not a problem. Though in general, I do see
that most projects are disciplined and do work on the same direction. If
you consider the amount of dependencies (539 for the last Rocky
release), it's kind of nice that they are all worked out as a whole.
Lots of things have been standardized. The technical committee is also
there to steer in a single direction.
So, if that's your feeling, I'd suggest you look a 2nd time. I really
don't think OpenStack is a dysfunctional project.
Cheers,
Thomas Goirand (zigo)
Re: Q: Packaging headers -> need for -dev package
On Aug 19, Alec Leamas wrote: > For me, it's natural to package this header in a opencpn-dev package. > However, when confronted with a "citation needed"[2] I don't find > anything written on this. I see three possibilities: I think that distributing it would be useful since it would help users to build the plugins. If this is about just one or a few header files then just ship them in the main package: there is no reason to load the archive with yet another tiny package. -- ciao, Marco signature.asc Description: PGP signature
Q: Packaging headers -> need for -dev package
Dear list, Again: Attempting to package OpenCPN [1]. In my discussions w upstream a header has been on the table. While OpenCPN certainly isn't a library, there is a lot of third-party plugin development. The interface between the plugins and the main application lives in a header called ocpn_plugin.h which thus i srequired when writing plugins. For me, it's natural to package this header in a opencpn-dev package. However, when confronted with a "citation needed"[2] I don't find anything written on this. I see three possibilities: - I'm plain wrong, there is no need to package the header - I'm right, but it's just common sense. - I'm right, and there is something written on it somewhere. Thoughts? --alec [1] http://opencpn.org/ [2] https://github.com/OpenCPN/OpenCPN/pull/1102#issuecomment-414138655
Re: Bug#906590: ITP: pass-otp -- A pass extension for managing one-time-password (OTP) tokens
Hi On Sun, Aug 19, 2018 at 06:59:06PM +0200, Philip Rinn wrote: Hi, pass-otp is already packaged: https://tracker.debian.org/pkg/pass-otp I failed to see its was already packaged cheers Best, Philip -- IRC: gfa GPG: 0X44BB1BA79F6C6333
Re: Bug#906590: ITP: pass-otp -- A pass extension for managing one-time-password (OTP) tokens
Hi, pass-otp is already packaged: https://tracker.debian.org/pkg/pass-otp Best, Philip signature.asc Description: OpenPGP digital signature
Let's start salvaging packages! -- draft text now available
Dear -devel,
as announced earlier, I have together with worked on the text for the
salvaging process. You can find the texts here: Titanpad [1] for dev-ref
and the accompanying Wikipage [2]. Credits to Pierre-Elliott Bécue, as
he wrote the first draft and thereby helped me a lot.
For the timeline, as earlier communicated I think we should discuss this
until Sepember 1st and then I will start incooporating received intput
to have a final text available soon.
[1] https://pad.riseup.net/p/debian-salvaging-packages-keep
[2] https://wiki.debian.org/PackageSalvaging
For your convenience (and for easier replies) here is the full text
for bith parts (the dev-ref part and the wiki raw text).
(The dev-ref needs modification in 5.9.5, therefore this is provided as
a patch.)
Cheers,
--
tobi
Patch for section 5.9.5: ("Adopting a package")
---
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -1471,15 +1471,20 @@ packages listed in the WNPP, please take a look at the
aforementioned page for
information and procedures.
-It is not OK to simply take over a package that you feel is neglected — that
-would be package hijacking. You can, of course, contact the current maintainer
-and ask them if you may take over the package. If you have reason to believe a
-maintainer has gone AWOL (absent without leave), see .
+It is not OK to simply take over a package without assent
+of the current maintainer — that would be package hijacking.
+You can, of course, contact the current maintainer and ask them for
+permission to you take over the package.
-Generally, you may not take over the package without the assent of the current
-maintainer. Even if they ignore you, that is still not grounds to take over a
-package. Complaints about maintainers should be brought up on the developers'
+However, when a package has been neglected by the maintainer, you might
+be able to take over package maintainership by following the package
+salvaging process as described in .
+If you have reason to believe a maintainer is no longer active at all,
+see .
+
+
+Complaints about maintainers should be brought up on the developers'
mailing list. If the discussion doesn't end with a positive conclusion, and
the issue is of a technical nature, consider bringing it to the attention of
the technical committee (see the
Package Salvaging
Package salvaging is the process by which, one attempts to save a
package that, while not officially orphaned, appear poorly maintained or
completely unmaintained. This is a weaker and faster procedure than
orphaning a package officially through powers of the MIA team.
Salvaging a package is not meant to replace MIA handling, and in
contrast to it, it does not comment about the overall activity of a
maintainer. Instead, it handles a package maintainership transition for
a single package only, leaving any other package or Debian membership or
upload rights (when applicable) untouched.
Note that the process is only intended for actively taking over
maintainership. Do not do salvaging, when you do not intend to maintain
the package for a prolonged time. If you only want to fix certain
things, but not taking over the package, you must use the NMU process,
even if the package would be eligble for salvaing. The NMU process is
explained in
Another important thing to remember: It is not acceptable to
hijack others' packages. If followed, this salvaging process will help
you to ensure that your endaveour is not a hijack, but a (legal)
salvaging procedure and you can counter any allegations of hijack with a
reference to this process. This ensurance should especially help new
maintainers to Debian to have confidence taking over packages by
salvaging.
The process is split into two phases: In the first phase you
determine whether the package in question is
eligble for the salvaging process. Only when the
eligbiliy has been determined, you can enter the second phase, the
actual package salvalging.
For an addtional informations, rationales and FAQs on package
salvaging, please visit the Salvaging Packages page on the Debian
wiki.
When a package is eligble for package salvaging
A package becomes elible for salvaging when it has been neglected by the
current maintainer. To determine that a package has really been
negelected by the maintainer, the following coarse indicators might give
an idea what to look for:
NMUs, especially if there have been more than one NMU
in a row.
Bugs filed against the package do not have answers
from the maintainer.
Upstream has released several versions, but despite
a bug entry exists asking for it, it has not been packaged
There are QA issues with the package
As said, the above list is only a very coarse. The wiki page Salvaging Packages expands on
eligbility criterias for package salvaging, you are recommended follow
them to determine eligbility. Though you are allowed to deviate from
the guidlines
Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)
Le dimanche 19 août 2018 à 09:11:23+0200, Alexander Wirt a écrit : > On Sat, 18 Aug 2018, Thomas Goirand wrote: > > > On 08/18/2018 07:42 AM, Alexander Wirt wrote: > > >> I also don't understand why we're not attempting to build a Ceph cluster > > >> at UBC. Why not? > > > go ahead. if it works well we can switch to it. > > > > > > Alex > > > > Ok, I'm getting in touch with the DSA team to see how it can be done. > > Let's see first if we have hardware, and then how I can help for the > > setup and maintenance. > Of course we also need docker. You will have to ensure that everythings work > with gitlab, that its performant enough and you will have to maintain it. > Otherwise we won't switch. Hi, I'm not sure how serious you are about adopting a home made solution. If you really consider this as preferred, I'd be happy to try helping, to the extents of my capabilities, setting such a solution up. Would you really consider such a thing seriously? Cheers. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)
On 08/19/2018 09:11 AM, Alexander Wirt wrote: > On Sat, 18 Aug 2018, Thomas Goirand wrote: > >> On 08/18/2018 07:42 AM, Alexander Wirt wrote: I also don't understand why we're not attempting to build a Ceph cluster at UBC. Why not? >>> go ahead. if it works well we can switch to it. >>> >>> Alex >> >> Ok, I'm getting in touch with the DSA team to see how it can be done. >> Let's see first if we have hardware, and then how I can help for the >> setup and maintenance. > Of course we also need docker. Hang on here. Are you saying that Salsa is using GKE? Or is it still for storage? In the later case, how is setting-up a Ceph cluster or Swift related to the storage need? Could you also describe what the need is? If I understood correctly, it would be an object store, right? Or do you also need block storage? In the former case, swift is best. In the later case, Ceph is preferred. We could even do both if we need to, and have enough hardware to play with. > You will have to ensure that everythings work > with gitlab, that its performant enough and you will have to maintain it. > Otherwise we won't switch. I get that. I suppose you remembered that I volunteered twice already for helping with Salsa. It'd be with great pleasure that I get involved. The only thing, is that I need hardware to play with, and probably will need the root to be able to do the setup. This means dealing with DSA team, and I'm not sure how they see it yet. It'd be great if we could have their view here. Cheers, Thomas Goirand (zigo)
English language & completely off-topic Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)
Hi, Bastian Blank: >> And there's what Jeremy replied to you. We shall not endorse non-free. > > No, he just said we should prefer to use free ones. > > Endorse is something different, please read yourself > https://www.merriam-webster.com/dictionary/endorse or As your link says Endorse: to approve openly, to recommend. The use of this word is entirely correct. Cheers, Ulrike
Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)
On Sat, Aug 18, 2018 at 11:55:19PM +0200, Thomas Goirand wrote: > On 08/18/2018 01:11 PM, Bastian Blank wrote: > First, there's dozens of OpenStack public cloud out there, so you're not > locked-in with a single operator. There exists thousand variants how to setup an OpenStack instance. Just leave out some specific service and it's not longer compatible with your project. So you not just need to find an OpenStack operator, you need to find an operator who provides the correct set of services you need. > Then there's not a single contributor > to the OpenStack source code, the contributors are quite diverse. A friend of mine called OpenStack a dysfunctional open source project. Especially the number of different people giving the shots and running in different directions does not help. (No project in OpenStack looks alike. Just look at all the different variants for how to maintain the database schema.) > To the contrary, if you're using a proprietary cloud like AWS, you have > no choice but to continue with them. If you depend on the _interfaces_ they provide. AWS, at least most parts of it, is easily replaceable. > > Endorse is something different, please read yourself > > https://www.merriam-webster.com/dictionary/endorse or > > http://www.learnersdictionary.com/definition/endorse > > Well, it's a question of view. To me, having Salsa to host some of its > data on Google is a kind of tacit endorsement. Even worse, it gives the > message that, from the viewpoint of the whole Debian community, it's ok > to host there. Clearly, I'm not the only one bothered in this way. No, it's how the word is defined in the english language. Bastian -- Emotions are alien to me. I'm a scientist. -- Spock, "This Side of Paradise", stardate 3417.3
Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)
Moin On Sat, Aug 18, 2018 at 11:34:53PM +0200, Thomas Goirand wrote: > Ok, I'm getting in touch with the DSA team to see how it can be done. > Let's see first if we have hardware, and then how I can help for the > setup and maintenance. If you want to do something, please show us the plan _before_ you are implementing anything. We have to vet that it is actually usable for the purpose. So just running in one direction does not help your case. Bastian -- I'm a soldier, not a diplomat. I can only tell the truth. -- Kirk, "Errand of Mercy", stardate 3198.9
Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)
On Sat, 18 Aug 2018, Thomas Goirand wrote: > On 08/18/2018 07:42 AM, Alexander Wirt wrote: > >> I also don't understand why we're not attempting to build a Ceph cluster > >> at UBC. Why not? > > go ahead. if it works well we can switch to it. > > > > Alex > > Ok, I'm getting in touch with the DSA team to see how it can be done. > Let's see first if we have hardware, and then how I can help for the > setup and maintenance. Of course we also need docker. You will have to ensure that everythings work with gitlab, that its performant enough and you will have to maintain it. Otherwise we won't switch. Alex
