<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Hi Will,
<div class="">Yes it functions in its original manner.</div>
<div class="">I have RH rpm(s), the latest is <span style="font-family: Menlo; font-size: 11px; font-variant-ligatures: no-common-ligatures; color: rgb(180, 36, 25);" class=""><b class="">mtx</b></span><span style="font-family: Menlo; font-size: 11px; font-variant-ligatures: no-common-ligatures;" class="">-1.3.12-17fnal.el7.x86_64.
The repo url is </span><span style="font-family: Menlo; font-size: 11px;" class=""><a href="https://ssasrv1.fnal.gov/en/slf7x/x86_64" class="">https://ssasrv1.fnal.gov/en/slf7x/x86_64</a></span></div>
<div class=""><font face="Menlo" class=""><span style="font-size: 11px;" class="">Alexander</span></font></div>
<div class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Jun 9, 2021, at 12:39 PM, Will Sutton <<a href="mailto:will@sutton-family.org" class="">will@sutton-family.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class="">Alexander, <br class="">
<br class="">
Your code changes look good as a cursory glance. In the changes you made, do you think it would continue to function in its original manner as well as being callable from C and Python? If so, we could combine efforts. I have a feeling my .edu employer and .gov
sponsor would be interested in this as well. <br class="">
<br class="">
</div>
Will<br class="">
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Jun 9, 2021 at 11:43 AM Alexander Moibenko <<a href="mailto:moibenko@fnal.gov" class="">moibenko@fnal.gov</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
We, at FNAL, for instance, use TS4500 LTO8 libraries with 10000 slots and tens of tape drives. The modified mtx code allows effective use of such library.<br class="">
Alexander <br class="">
<br class="">
> On Jun 7, 2021, at 5:18 AM, James Youngman <<a href="mailto:james@youngman.org" target="_blank" class="">james@youngman.org</a>> wrote:<br class="">
> <br class="">
> I waited a while to give time for people who didn't immediately see<br class="">
> this thread to chime in. I hope everybody who wanted to has now had<br class="">
> that opportunity.<br class="">
> <br class="">
> I think we have a rough consensus on what we'll do. There are also<br class="">
> some things which seem reasonable but which we didn't discuss yet that<br class="">
> we should agree on. Here's what I think we're agreed on:<br class="">
> <br class="">
> 1. We should create or select a git repo where master corresponds to<br class="">
> the stable release, plus patches approximately representing the<br class="">
> consensus choice of a few Linux distros [see item (b) below]. That<br class="">
> is, where we can identify patches in use in (more than one of) Red Hat<br class="">
> / Centos / Debian we should adopt those into master.<br class="">
> 2. We should adopt a project structure with multiple active<br class="">
> maintainers. Will and I have, I believe, already volunteered.<br class="">
> Anybody else?<br class="">
> 3. Our initial focus should be on showing clear signs of life and<br class="">
> helping distros switch over to our now-actively-maintained upstream<br class="">
> project. This should be prioritised over feature development (we can<br class="">
> use, for example, a branch such as "next" for feature development).<br class="">
> This doesn't mean "no feature development" though, it's just not the<br class="">
> most important aspect, initially.<br class="">
> <br class="">
> If we actually don't have a consensus on 1-3 above, please voice your concern.<br class="">
> <br class="">
> Things we have not yet discussed fully, but need to agree on:<br class="">
> <br class="">
> 4. How will we structure our maintainers team? It seems reasonable<br class="">
> to use a free-tier (as in $0) Github Organization<br class="">
> (<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_organizations_plan&d=DwIFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=qUUJfY9rcpnSDJD1RsKzrrBmsb6vkJm31XurldnXpOw&m=QR4ViIlfRZs_VwnmCjqtoNClS-tGth77OWsUsQwU7f8&s=uCieIOAHwHSoalWGwfwXnb1j63Xofn_y7IK_3EmVWv4&e=" rel="noreferrer" target="_blank" class="">https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_organizations_plan&d=DwIFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=qUUJfY9rcpnSDJD1RsKzrrBmsb6vkJm31XurldnXpOw&m=QR4ViIlfRZs_VwnmCjqtoNClS-tGth77OWsUsQwU7f8&s=uCieIOAHwHSoalWGwfwXnb1j63Xofn_y7IK_3EmVWv4&e=</a>
). That allows the<br class="">
> organisation to have multiple "owners" and yet still costs nothing.<br class="">
> I'm against the idea of using an individual's repo because it would<br class="">
> mean that, once again, we'd have a single point of failure if that<br class="">
> individual becomes inactive. But I'm sure there are multiple ways to<br class="">
> solve this part of the problem. Opinions?<br class="">
> 5. Naming is something we've not discussed. If we create an<br class="">
> "organisation" per (4) above for this, that forms a useful<br class="">
> qualification to distinguish this version of mtx from the predecessor,<br class="">
> but then we will need a name for the team/organisation. Suggestions<br class="">
> anybody?<br class="">
> 6. What forum will we use for discussion? Keep the existing<br class="">
> SourceForge mtx-general list? Or something new? (my opinion on this<br class="">
> is that using mtx-general might generate uncertainty about the status<br class="">
> of what we're doing which is basically a fork)<br class="">
> <br class="">
> Some other things I think need a volunteer but aren't likely to be contentious:<br class="">
> <br class="">
> a, Do we have any contacts with teams working with much larger<br class="">
> libraries? Folks on this thread seem mostly to be using LTO<br class="">
> libraries in the 24-48 slot range. It would be good to be able to<br class="">
> get occasional testing feedback from libraries having many more slots,<br class="">
> so I think we should try to find collaborators (even if just for<br class="">
> occasional testing) who have large libraries. We could use a<br class="">
> virtualised large library with iSCSI I suppose, but even setting those<br class="">
> up is non-trivial. Testing help from someone having a linear-only<br class="">
> tape changer device would probably also be good.<br class="">
> <br class="">
> b. I think we should map out which baseline and which patches are<br class="">
> currently in use in each distribution, so that our initial "master"<br class="">
> branch doesn't include code changes likely to be perceived by dsitros<br class="">
> as "risky". I'm willing to look into this but if someone already did<br class="">
> some of this work, that would be great.<br class="">
> <br class="">
> <br class="">
> <br class="">
> On Tue, Jun 1, 2021 at 2:21 PM Will Sutton <<a href="mailto:will@sutton-family.org" target="_blank" class="">will@sutton-family.org</a>> wrote:<br class="">
>> <br class="">
>> James,<br class="">
>> <br class="">
>> I am interested in keeping this project moving forward. The code seems very stable and mature, and my day job takes me more into the C an C++ side of things, so I can be a more competent maintainer as well. I have no problem sharing ownership with the right
maintainers to keep it alive.<br class="">
>> <br class="">
>> I've been using this repo on arch for quite a while with my TL4000 and not encountered any issues.<br class="">
>> <br class="">
>> That being said, I've not heard anything from the original author since I created this repository.<br class="">
>> <br class="">
>> Carsten, I pulled your patches into their own branch. I think it should be identical to the debian branch at this point. Feel free to send me any additional patches I might be missing.<br class="">
>> <br class="">
>> I pulled my repo in from here: <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_mtx_code_HEAD_tree_branches_stable-2D1.3_&d=DwIFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=qUUJfY9rcpnSDJD1RsKzrrBmsb6vkJm31XurldnXpOw&m=QR4ViIlfRZs_VwnmCjqtoNClS-tGth77OWsUsQwU7f8&s=HkkYGzm8ObarTEbetswkNkCWneqHRfPRq4NTuekc-wU&e=" rel="noreferrer" target="_blank" class="">
https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_mtx_code_HEAD_tree_branches_stable-2D1.3_&d=DwIFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=qUUJfY9rcpnSDJD1RsKzrrBmsb6vkJm31XurldnXpOw&m=QR4ViIlfRZs_VwnmCjqtoNClS-tGth77OWsUsQwU7f8&s=HkkYGzm8ObarTEbetswkNkCWneqHRfPRq4NTuekc-wU&e=</a>
<br class="">
>> <br class="">
>> At this point, the latest code is from soruceforge is 13 years old.<br class="">
>> <br class="">
>> I'd be thrilled to open dialog with the rest of you as well.<br class="">
>> <br class="">
>> William Sutton<br class="">
>> <br class="">
>> On Tue, Jun 1, 2021 at 6:15 AM Carsten Leonhardt <<a href="mailto:leo@debian.org" target="_blank" class="">leo@debian.org</a>> wrote:<br class="">
>>> <br class="">
>>> Hello all,<br class="">
>>> <br class="">
>>> I'm the Debian mtx package Maintainer.<br class="">
>>> <br class="">
>>> James Youngman <<a href="mailto:james@youngman.org" target="_blank" class="">james@youngman.org</a>> writes:<br class="">
>>> <br class="">
>>>> I'd really like us to get to a place where there was a<br class="">
>>>> community-driven and group-managed upstream project (so that we're not<br class="">
>>>> singly-homed on one maintainer any more) where at least initial<br class="">
>>>> releases are conservative in their changes, to encourage distributions<br class="">
>>>> all to select the same upstream. Right now, I don't have opinions on<br class="">
>>>> what the basis (e.g. what repo) for that should be, and I'm aware that<br class="">
>>>> naming might need some careful consideration.<br class="">
>>> <br class="">
>>> as far as I can see, most distributions have based their mtx package on<br class="">
>>> the last stable version from Robert. I've tried to find all patches that<br class="">
>>> other distributions use and added them to the Debian package. Later I've<br class="">
>>> submitted them to Will for inclusion, but the version in Will's<br class="">
>>> repository is based on Robert's development branch.<br class="">
>>> <br class="">
>>> From my point of view I'd prefer starting from Robert's last stable<br class="">
>>> version plus the generally accepted patches.<br class="">
>>> <br class="">
>>> The patches applied for the Debian package can be found here:<br class="">
>>> <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__salsa.debian.org_bacula-2Dteam_mtx_-2D_tree_master_debian_patches&d=DwIFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=qUUJfY9rcpnSDJD1RsKzrrBmsb6vkJm31XurldnXpOw&m=QR4ViIlfRZs_VwnmCjqtoNClS-tGth77OWsUsQwU7f8&s=ke0-ii-UBkDvd0HwwF_1Ly4E6zf8xuMoGsd5CnqXzR8&e=" rel="noreferrer" target="_blank" class="">
https://urldefense.proofpoint.com/v2/url?u=https-3A__salsa.debian.org_bacula-2Dteam_mtx_-2D_tree_master_debian_patches&d=DwIFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=qUUJfY9rcpnSDJD1RsKzrrBmsb6vkJm31XurldnXpOw&m=QR4ViIlfRZs_VwnmCjqtoNClS-tGth77OWsUsQwU7f8&s=ke0-ii-UBkDvd0HwwF_1Ly4E6zf8xuMoGsd5CnqXzR8&e=</a>
<br class="">
>>> <br class="">
>>> Regards,<br class="">
>>> <br class="">
>>> Carsten<br class="">
>> <br class="">
>> <br class="">
>> <br class="">
>> --<br class="">
>> No trees were harmed in the sending of this message, but a rather large number of electrons were terribly inconvenienced.<br class="">
<br class="">
</blockquote>
</div>
<br clear="all" class="">
<br class="">
-- <br class="">
<div dir="ltr" class="gmail_signature">No trees were harmed in the sending of this message, but a rather large number of electrons were terribly inconvenienced. </div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>