Re: 3.2 release?

[Joan Touzet]

I just completed an open PR sweep on -docs, everything has an open PR in
need of +1s (thanks Nick, there's more waiting!) or needs some
additional help from the community.

I've also created a 3.2.0 milestone in the main repo:

  https://github.com/apache/couchdb/milestone/8

Feel free to add anything to this that you think should be in 3.2, even
if it's only aspirational. We can always pare it down if necessary.

-Joan

On 29/03/2021 07:51, Bessenyei Balázs Donát wrote:
> Following up on my open PR sweep:
> @Joan: I see that you've asked on a couple of PRs back in Oct 2020 if
> they are to be merged and some of them were left open.
> Is there any objection to closing them all? Or let's ignore them for now?
> 
> 
> Donat
> 
> On Mon, Mar 29, 2021 at 11:06 AM Bessenyei Balázs Donát
>  wrote:
>>
>> I think I have read access to the COUCHDB namespace in Confluence, but not 
>> edit.
>>
>> I'll skim through `main` to see if we need to / want to backport
>> things from there.
>> I can also bump every PR targeted for 3.x to see if people want to get
>> that content in there.
>>
>> Release notes: I'm really _not_ good with docs, so I'm happy there's
>> someone who's doing that.
>>
>>
>> Donat
>>
>> On Sun, Mar 28, 2021 at 9:20 PM Joan Touzet  wrote:
>>>
>>> Great! Excited to get help.
>>>
>>> Here's the release procedure:
>>>
>>>   https://cwiki.apache.org/confluence/display/COUCHDB/Release+Procedure
>>>
>>> Make sure you have wiki access, your Apache creds should get you in.
>>>
>>> The most valuable thing you can do is make sure all of the PRs that we
>>> want to land, have landed. Review all in-progress PRs and see if any
>>> more need to land on 3.x. Also, look for any important backports from
>>> main, though with fdb finally having landed, this will be more limited
>>> than previously. This usually takes a week or two.
>>>
>>> I get the most enjoyment out of doing the release notes, personally, but
>>> if you'd like to do it instead, go for it. Have a look at the last few
>>> releases to see the level of detail I've been including. (Plus at least
>>> one joke, which may or may not be funny.) I'll try and start on this
>>> tomorrow.
>>>
>>> -Joan
>>>
>>> On 28/03/2021 14:30, Bessenyei Balázs Donát wrote:
>>>> +1
>>>>
>>>> Let me know how I can help.
>>>>
>>>>
>>>> Donat
>>>>
>>>> On Sun, Mar 28, 2021 at 7:03 PM Joan Touzet  wrote:
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>> We have a number of high profile improvements to 3.x since 3.1.1 came
>>>>> out. I think it's about time for 3.2. Does everyone agree?
>>>>>
>>>>> If so, we should start a clock for ~2 weeks to finish closing out any
>>>>> last minute improvements, fixes, tweaks, etc. anyone wants to get in.
>>>>>
>>>>> -Joan "we did it before and we can do it again" Touzet

Re: [DISCUSS] API versioning redux

[Joan Touzet]

On 22/02/2021 20:48, Adam Kocoloski wrote:
> Hi all,
> 
> Several times in recent months we’ve had discussions on this list about 
> behavior changes in CouchDB 4.0 that boil down to tradeoffs between
> 
> a) maintaining compatibility with current CouchDB APIs, and
> b) capitalizing on the transactional semantics of FoundationDB
>   
> An example would be the support for large result sets in a view response: do 
> we stitch together multiple transactions to support very large responses, or 
> provide new pagination APIs and guarantee that each response is generated 
> from a single isolated snapshot?
> 
> I’d like to suggest that we “have our cake and eat it, too” by introducing 
> versioned APIs as previously suggested by Ilya[1]. We’d have a V3 API that 
> strives to maximize compatibility with CouchDB 3.x, and a V4 API that still 
> looks and feels like CouchDB, but introduces breaking changes where necessary 
> to provide well-defined transactional semantics. I think this explicit 
> approach to API evolution could make life easier for client library 
> maintainers, and also free us up to improve the API without needing to be 
> quite as careful about in-place backwards compatibility.
> 
> [1]: 
> https://lists.apache.org/thread.html/rcc742c0fdca0363bb338b54526045720868597ea35ee6842aef174e0%40%3Cdev.couchdb.apache.org%3E
> 
> What do you think? Cheers, Adam

In general, +1, as long as the concerns raised by Bob are addressed.
Namely: if I point a CouchDB 1.x-3.x client at a future CouchDB 4.0, I
shouldn't be *too* surprised, and as much as possible should "just work."

I've long believed that 4.0 would be a transitional version, and 5.0
would break things completely... so if 5.0 (or whatever) stops accepting
"v3" syntax, or "default" changes to "v4", fine by me.

Also it'd be great if this was advertised in the feature strings shown
in `GET /` in some intelligent way. Maybe an array of API versions
supported?

-Joan

Re: GSoC 2021 participation

[Joan Touzet]

https://community.apache.org/gsoc.html might be of help.

If you are looking to talk to other Apache projects that have done this
before, you could reach out on the dev@community.a.o list.


https://lists.apache.org/thread.html/r189a563fe003ad8f0e4c298e18fad4da8d4b2854bd2a5d741ae3ac45%40%3Cdev.community.apache.org%3E

Note the dependency on JIRA:

> All ASF projects are invited to submit their ideas to their issue tracker, 
> please be sure to add the labels “gsoc2021” and “mentor” so that we can 
> automatically include them in our list of subjects. If your project does not 
> use JIRA please contact d...@community.apache.org.

so you'll need to post at dev@community to get included in the master list.

Student applications start tomorrow for 2 weeks, so you'll need to get a
move on... If I'm around on chat I can try and help a bit.

-Joan

On 29/03/2021 01:20, Bessenyei Balázs Donát wrote:
> If there are any projects that don't exceed my CouchDB / erlang / JS
> knowledge, I'd make sure I'm available enough to support someone doing
> a GSoC with us.
> What's the workflow here? Do we have to apply as a project? Do we have
> to propose projects?
> I did look at "Prospective ASF mentors: read this" of [1], but I don't
> see what it looks like for a project. Do we need a vote here?
> 
> 
> Donat
> 
> [1]: https://community.apache.org/gsoc.html
> 
> On Sun, Mar 28, 2021 at 11:52 PM Joan Touzet  wrote:
>>
>> The ASF often ends up doing GSoC. I don't think we've ever had the
>> sponsor within the project for it (or for Outreachy, for that matter).
>>
>> The most critical part is being available on a regular basis for proper
>> mentoring. If you don't think you can get that into your schedule, don't
>> volunteer. Assume you will get zero support from any other developer
>> (not true, but best to plan for the worst case situation...)
>>
>> The second most critical part is to come up with a self-contained
>> project that makes sense for CouchDB. The most obvious thing to me would
>> be Fauxton work, esp. as it falls into the "sweet spot" of JS
>> development. I dunno how good of a target main is, given how in flux it
>> is; others might have a better take on that. There's also this PR that
>> never finished up:
>>
>>   https://github.com/apache/couchdb/issues/1254
>>
>> These topics are all probably too big, but maybe one of them could be
>> cut down to something summer-sized:
>>
>>   https://github.com/apache/couchdb/projects/1
>>
>> Thanks for taking on this initiative! I know for a fact I won't have
>> time this summer, or I'd agree to join you.
>>
>> -Joan
>>
>> On 28/03/2021 15:59, Bessenyei Balázs Donát wrote:
>>> Hi All,
>>>
>>> I've just seen that the ASF is accepted as a mentoring organisation
>>> for GSoC 2021.
>>> Is CouchDB interested in participating?
>>> I've never done a GSoC before, but I'd certainly be interested. I'd be
>>> happy to help a student contribute to CouchDB.
>>>
>>> What do you all think?
>>>
>>>
>>> Thank you,
>>> Donat
>>>

Re: Virtual folders and mailbox_list_get_root_forced

[Joan Moreau]

yes, this is getting to a mess

Details can be seen here : 
https://github.com/grosjo/fts-xapian/issues/72


It shows that sometimes mailbox_list_get_root_forced return the generic 
INDEX value, sometimes the namespace value


thank you for your help

On 2021-03-28 12:03, Aki Tuomi wrote:


Hi!

mail_location = maildir:/var/vmail/%d/%n:LAYOUT=fs:INDEX=/var/mailindex

This is going to put everyone's indexes under /var/mailindex, without 
separating them properly. Might cause fun issues.


Can you give an concrete example of what your issue is?

Aki

On 28/03/2021 13:35 Joan Moreau  wrote:

Hi
Anyone on that ?
Thank you so much

On 2021-03-22 18:16, Joan Moreau wrote: Hi
The function mailbox_list_get_root_forcedreturns sometimes the first or 
the second value of the INDEX param for the same mailbox.


How to make sure this returns only the correct one of the corresponding 
mailbox ?


mail_location = maildir:/var/vmail/%d/%n:LAYOUT=fs:INDEX=/var/mailindex
namespace {
location = 
virtual:/nix/store/toto-virtual:INDEX=/var/vmail/%d/%n/virtual

prefix = virtual/
separator = /
subscriptions = no
}

Thank you

Re: GSoC 2021 participation

[Joan Touzet]

The ASF often ends up doing GSoC. I don't think we've ever had the
sponsor within the project for it (or for Outreachy, for that matter).

The most critical part is being available on a regular basis for proper
mentoring. If you don't think you can get that into your schedule, don't
volunteer. Assume you will get zero support from any other developer
(not true, but best to plan for the worst case situation...)

The second most critical part is to come up with a self-contained
project that makes sense for CouchDB. The most obvious thing to me would
be Fauxton work, esp. as it falls into the "sweet spot" of JS
development. I dunno how good of a target main is, given how in flux it
is; others might have a better take on that. There's also this PR that
never finished up:

  https://github.com/apache/couchdb/issues/1254

These topics are all probably too big, but maybe one of them could be
cut down to something summer-sized:

  https://github.com/apache/couchdb/projects/1

Thanks for taking on this initiative! I know for a fact I won't have
time this summer, or I'd agree to join you.

-Joan

On 28/03/2021 15:59, Bessenyei Balázs Donát wrote:
> Hi All,
> 
> I've just seen that the ASF is accepted as a mentoring organisation
> for GSoC 2021.
> Is CouchDB interested in participating?
> I've never done a GSoC before, but I'd certainly be interested. I'd be
> happy to help a student contribute to CouchDB.
> 
> What do you all think?
> 
> 
> Thank you,
> Donat
> 

CouchDB download statistics for April 2020 - April 2021

[Joan Touzet]

Hey everyone, I'm overdue to post these:

  https://gist.github.com/wohali/78c14c9afa317bf665854d55ad1e70ed

In short, our Docker downloads went up by ~20 million, and everything
else held steady or decreased slightly. The biggest decline in downloads
was our source tarball, down almost 70%.

One peculiar finding: rpm downloads went up some, but 2.x rpm downloads
held steady year-over-year. This wasn't reflected in any other binary
download (Win, Mac, .deb, snap - don't know about Docker.)

-Joan ".deb is slow to change, but .rpm is...glacial?" Touzet

Re: 3.2 release?

[Joan Touzet]

Great! Excited to get help.

Here's the release procedure:

  https://cwiki.apache.org/confluence/display/COUCHDB/Release+Procedure

Make sure you have wiki access, your Apache creds should get you in.

The most valuable thing you can do is make sure all of the PRs that we
want to land, have landed. Review all in-progress PRs and see if any
more need to land on 3.x. Also, look for any important backports from
main, though with fdb finally having landed, this will be more limited
than previously. This usually takes a week or two.

I get the most enjoyment out of doing the release notes, personally, but
if you'd like to do it instead, go for it. Have a look at the last few
releases to see the level of detail I've been including. (Plus at least
one joke, which may or may not be funny.) I'll try and start on this
tomorrow.

-Joan

On 28/03/2021 14:30, Bessenyei Balázs Donát wrote:
> +1
> 
> Let me know how I can help.
> 
> 
> Donat
> 
> On Sun, Mar 28, 2021 at 7:03 PM Joan Touzet  wrote:
>>
>> Hi everyone,
>>
>> We have a number of high profile improvements to 3.x since 3.1.1 came
>> out. I think it's about time for 3.2. Does everyone agree?
>>
>> If so, we should start a clock for ~2 weeks to finish closing out any
>> last minute improvements, fixes, tweaks, etc. anyone wants to get in.
>>
>> -Joan "we did it before and we can do it again" Touzet

[Bug 1921622] Re: cannot upgrade to 20.04 LTS

[Joan van der Star]

The problem is solved.
After reading the logs on main en apt. I assumed it was link extra-codecs.
I removed this packaged and afterwards the upgrade went on.
After the upgrade I reinstalled the extra-codecs

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1921622

Title:
  cannot upgrade to 20.04 LTS

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1921622/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

3.2 release?

[Joan Touzet]

Hi everyone,

We have a number of high profile improvements to 3.x since 3.1.1 came
out. I think it's about time for 3.2. Does everyone agree?

If so, we should start a clock for ~2 weeks to finish closing out any
last minute improvements, fixes, tweaks, etc. anyone wants to get in.

-Joan "we did it before and we can do it again" Touzet

Re: Early warning: bintray is going away, deb/rpm packages will have to move

[Joan Touzet]

Hello everyone,

ASF Infra has once again come through for us. We'll be moving to the
JFrog Artifactory service. There will be a single, simple URL change to
the documentation to access the new repositories.

Once we're sure we have update access to the new repos, we'll update our
documentation tags so that docs.couchdb.org and our website list the
correct URLs to the new repositories.

Finally, we'll update our Docker containers to build from the new repos
as well.

Over on the developer side, our upload scripts for new builds will need
to be updated for the new system's API.

I'll email again when all of this is taken care of.

Cheers,
Joan

On 01/03/2021 11:09, Joan Touzet wrote:
> Hello everyone,
> 
> One month ago, we were informed that JFrog are shutting down Bintray - a
> service we currently use to host our .deb and .rpm packages for Debian
> and Ubuntu, & CentOS and RHEL respectively. (Win/Mac downloads are now
> provided by Neighbourhoodie.)
> 
> New uploads to bintray will be disabled end of March, and the service
> will be taken offline as of May 1st. This doesn't give us a lot of time
> to migrate, but the work to move the repository is not extensive.
> 
> While ASF Infra hasn't provided a replacement for us yet , as soon as
> something is identified, I'll let the community know.
> 
> Here's the INFRA ticket to follow:
> 
>https://issues.apache.org/jira/browse/INFRA-21376
> 
> -Joan "packages packages packages" Touzet
> 

Re: Bintray Deprecation

[Joan Touzet]

Thanks Gavin. I know this couldn't have been an easy task. Looking
forward to the info.

On 28/03/2021 11:00, Gavin McDonald wrote:
> Hi All,
> 
> As advertised in [1] Bintray is closing down.
> 
> We have secured a replacement for bintray, which is JFrogs more extensive
> software offering 'Artifactory'.
> 
> I have been busy these last few days and have today finally completed
> migration of all packages on Bintray over to apache.jfrog.io
> 
> There is still a bit of work to do, I  am currently working on LDAP
> integration and should be ready over the next few days.
> To prevent divergence, I will be turning off upload access to Bintray
> tomorrow. (Downloads , as per the blog post, get turned off May 1st - but
> we can start serving from the new location now.
> 
> If anyone needs access to Artifactory for some reason before I get LDAP
> enabled please let me know.
> 
> In addition, for anyone that wants to attend, I will be organising a builds@
> meeting with a guest JFrog tech Guru to go over some features of
> Artifactory - our old Bintray service is by comparison only 5% of what
> Artifactory can do (my estimate).
> 
> 
> 
> [1] -
> https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/
> 
> 

Re: Virtual folders and mailbox_list_get_root_forced

[Joan Moreau]

Hi

Anyone on that ?

Thank you so much

On 2021-03-22 18:16, Joan Moreau wrote:


Hi

The function mailbox_list_get_root_forced returns sometimes the first 
or the second value of the INDEX param for the same mailbox.


How to make sure this returns only the correct one of the corresponding 
mailbox ?


mail_location = maildir:/var/vmail/%d/%n:LAYOUT=fs:INDEX=/var/mailindex
namespace {
location = 
virtual:/nix/store/toto-virtual:INDEX=/var/vmail/%d/%n/virtual

prefix = virtual/
separator = /
subscriptions = no
}

Thank you

Virtual folders and mailbox_list_get_root_forced

[Joan Moreau]

Hi

The function mailbox_list_get_root_forced returns sometimes the first or 
the second value of the INDEX param for the same mailbox.


How to make sure this returns only the correct one of the corresponding 
mailbox ?


mail_location = maildir:/var/vmail/%d/%n:LAYOUT=fs:INDEX=/var/mailindex
namespace {
  location = 
virtual:/nix/store/toto-virtual:INDEX=/var/vmail/%d/%n/virtual

  prefix = virtual/
  separator = /
  subscriptions = no
}

Thank you

[Frameworks] Henry Hills contact

[Hawkins, Joan C.]

Does anyone have contact info for Henry Hills?
You can respond off-list

thanks so much, Joan


Joan Hawkins
Associate Professor,
Media School
Indiana University
Franklin Hall
Bloomington, IN 47405
phone 812-855-1548



-- 
Frameworks mailing list
Frameworks@film-gallery.org
https://mail.film-gallery.org/mailman/listinfo/frameworks_film-gallery.org

[SCM] GNU Mach branch, jlledom-mem-obj-proxy, updated. v1.8-219-g1cddcca

[Joan Lled�]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU Mach".

The branch, jlledom-mem-obj-proxy has been updated
   via  1cddccaacba6ad74e95cbbd180d1e911adc5c284 (commit)
  from  4191c68b2121ec78d3ed3580cc3565f638fd56c5 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 1cddccaacba6ad74e95cbbd180d1e911adc5c284
Author: Joan Lledó 
Date:   Sat Mar 20 12:11:49 2021 +0100

Memory object proxy: check the size before setting the offset

---

Summary of changes:
 vm/vm_user.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)


hooks/post-receive
-- 
GNU Mach

Re: Encriptació d'un disc secundari

[Joan]

Merci per tota la info! Sou un pou de ciència :-)

-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi


El Thu, 18 Mar 2021 11:40:58 +0100
fadelkon  va escriure:

> El 18/3/21 a les 10:45, Joan ha escrit:
> > (faig un crosspost des de la sala de Matrix)
> >
> > Bon dia,
> >
> > M'ha arribat un disc dur nou per substituir un que em donava error
> > de tant en tant.
> >
> > Llavors, estava pensant en encriptar-ne una part.-..
> >
> > Fins ara jo sempre he tingut els meus discs sense encriptar. I no
> > em cal encriptar els 4Tb del disc nou... Però he pensat, i això us
> > volia consultar, que igual podria fer una petita partició, posa de
> > 500Gb, encriptada, i la resta no...
> >
> > No sé si això és factible o el LUKS ha d'aplicar al dispositiu
> > sencer... I si trobeu que pot estar bé (per, per exemple, posar la
> > info sensible en aquesta partició, i la resta a la normal)  
> 
> Hi ha diverses configuracions, però amb LUKS, tant pots crear un
> arxiu com a volum virtual, com tota una partició.
> LUKS és només una capa per sobre (o per sota) d'una partició. En el 
> moment en que es desxifra, la clau queda a la RAM i es va desant
> llegint a l'instant xifrant i desxifrant.
> 
> Pots certament crear dues particions i que una d'elles estigui
> xifrada. També pots fer que la partició xifrada, a dins, hi tingui
> una partició de tipus LVM amb diverses particions virtuals (volums
> lvm). Aquesta última és la manera més pràctica per haver de posar
> només una contrasenya.
> 
> > Em pregunto també si te sentit crear dugues particions o ja posats,
> > encripto tot el disc. Però no sé si això implica que l'accés a la
> > info que hi hagi serà més lent, etc. És a dir, si tinc un vídeo, el
> > reproductor de vídeos o música llegirà la info, un cop arrencat el
> > sistema i subministrada la contrasenya, igual de ràpid que si no
> > estigués encriptat?  
> 
> Sense dades a la mà, costa de dir, però segur que la teva màquina
> farà més feina. Ara bé, avui dia certes operacions de criptografia es
> fan ens xips de la CPU dedicats a això. Em sembla que AES es sol fer
> per hardware, per exemple. En aquest cas, ni ho hauries de notar.
> 
> > Es conserva la mateixa funcionalitat que en els discs no
> > encriptats?  
> 
> En general, sí, perquè es munten com a loop device. Així, amb un sol 
> disc xifrat sense LVM, tindries /dev/sda i
> /dev/mapper/particio-protegida. Totes les operacions sobre la
> partició protegida són estàndards, un cop desxifrada, ni te n'adones.
> 
> La funcionalitat que perds, però, és l'arrencada automàtica. Pensa
> que per desxifrar qualsevol cosa, el que diferencia la persona que hi
> té accés legítim de la que no, és el coneixement d'un secret, en
> aquest cas, una contrasenya. També hem de tenir en compte que xifrar
> el disc et protegeix d'atacs on se t'emporten la màquina apagada.
> Quan la volen encendre, oh! està xifrat el disc i no poden llegir
> res. Per tant, en un ús legítim, cada cop que s'engegui la màquina,
> hauràs de proporcionar-li la contrasenya. Com fer-ho depèn molt de
> l'ús que li vulguis donar a la partició.
> 
> >
> > Més dubtes: si uso Syncthing per sincronitzar directoris entre
> > diferents dispositius, i vull sincronitzar un directori que només
> > està encriptat en un dispositiu, ho podria fer? Intueixo que un cop
> > jo accedeixo a la partició encriptada amb LUKS amb la contrasenya,
> > en arrencar, tota la info es accessible pel sistema, de tal manera
> > que les aplicacions, etc. no saben si està o no encriptada, oi? I
> > llavors suposo que Syncthing podrà fer la seva feina... És així?  
> 
> És així!
> 
> 
> Salut,
> fdk
> 



-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi

Encriptació d'un disc secundari

[Joan]

(faig un crosspost des de la sala de Matrix)

Bon dia,

M'ha arribat un disc dur nou per substituir un que em donava error de
tant en tant. 

Llavors, estava pensant en encriptar-ne una part.-..

Fins ara jo sempre he tingut els meus discs sense encriptar. I no em cal
encriptar els 4Tb del disc nou... Però he pensat, i això us volia 
consultar, que igual podria fer una petita partició, posa de 500Gb, 
encriptada, i la resta no... 

No sé si això és factible o el LUKS ha d'aplicar al dispositiu sencer... I si
trobeu que pot estar bé (per, per exemple, posar la info sensible en
aquesta partició, i la resta a la normal) 

Em pregunto també si te sentit crear dugues particions o ja posats, encripto 
tot el disc.
Però no sé si això implica que l'accés a la info que hi hagi serà més
lent, etc. És a dir, si tinc un vídeo, el reproductor de vídeos o
música llegirà la info, un cop arrencat el sistema i subministrada la
contrasenya, igual de ràpid que si no estigués encriptat? 

Es conserva la mateixa funcionalitat que en els discs no encriptats? 

Més dubtes: si uso Syncthing per sincronitzar directoris entre diferents
dispositius, i vull sincronitzar un directori que només està encriptat
en un dispositiu, ho podria fer? Intueixo que un cop jo accedeixo a la
partició encriptada amb LUKS amb la contrasenya, en arrencar, tota la
info es accessible pel sistema, de tal manera que les aplicacions, etc.
no saben si està o no encriptada, oi? I llavors suposo que Syncthing
podrà fer la seva feina... És així?

-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi

Re: Engegada aleatòria

[Joan Albert]

Bon dia Jordi,

>  Si amb aquesta configuració encara no ens
> ensenya res augmenta a "loglevel=7" i afegeix "debug".

He provat fins i tot aquesta opció, però el que fa és reportar molta més
informació només si passa la part crítica.
 
> Buscant per Internet he vist que hi ha força gent que ha tingut
> problemes similars al teu amb els kernels 5.10, la majoria però deien
> que se'ls hi arreglava amb la versió 5.10.0-4 però és precisament la
> que tu fas servir i ha quedat clar que no et funciona bé.

Efectivament, i de fet crec que arrossego un parell de versions que em
donaven problemes (m'hauria d'haver fixat en quina va ser la primera,
però no ho recordo).

> Si ens pots donar més informació aquestes preguntes podrien ajudar:
> - Tens el portàtil connectat a alguna dock station?? Si fos així, et
> passa el mateix quan no està endollat a ella??

No el tinc a cap dock station.

> - Utilitzes un monitor extern?? Et passa el mateix quan no està
> connectat el monitor extern? (o a la inversa)

Sí l'utilitzo normalment, però no canvia el resultat segons si està o no
connectat a ell.

> - Has provat mai d'esperar a veure si acaba arrencant? de l'ordre de
> deixar-lo 15-25 minuts (com més millor per descartar). En cas negatiu,
> normalment quan de temps has esperat abans de forçar un reinici?

Ahir mateix vaig esperar més d'una hora :)

Em pregunto si no pot ser un problema de hardware simplement...

Gràcies igualment i salut!

-- 
TS


signature.asc
Description: PGP signature

Re: Engegada aleatòria

[Joan Albert]

Hola Jordi,

De nou, moltes gràcies pel teu temps.

> Entenc que això és la sortida de dmesg d'una arrencada que ha funcionat
> correctament. 

Efectivament, és la sortida d'una arrencada que ha funcionat
correctament.

> Amb el canvi aquest del grub el proper cop que l'ordinador no s'engegui
> correctament la pantalla no amagarà cap missatge que s'hagi escrit, de manera
> que espero que surti alguna cosa interessant que ens doni una pista, més enllà
> d'aquell "Loading initial ramdisk" que ens vas posar a l'inici.
> - Per veure el llistat d'arrencades de l'ordinador: # journalctl --list-boots

El tema és que no trobo més informació d'arrencades no
satisfactòries. He revisat el llistat d'arrencades utilitzant la comanda
# journalctl --list-boots i només apareixen les arrencades que han
funcionat (només apareix una del dia d'ahir, i en total devien ser 15
intents). Tampoc apareixien més missatges a part de "Loading initial
ramdisk", tot i canviar els paràmetres del grub i fer l'actualització.

Salut,

-- 
Joan Albert

Re: Engegada aleatòria

[Joan Albert]

Hola Jordi,

> Pot ser que tinguis el GRUB configurat amb "quiet" i/o "splash" ?? Si
> és així ho podries modificar per poder veure el que s'imprimeix a la
> pantalla quan l'ordinador es congela.
> 
> Bàsicament hauries de editar el fitxer /etc/default/grub i modificar
> una línea que dirá algo similar a aixo:
> GRUB_CMDLINE_LINUX_DEFAULT="quiet"
> Pots deixar la variable buida. Guardes el fitxer i després apliques la
> configuració executant la comanda (com a root):
> update-grub2

Gràcies per la resposta. He fet el canvi que has comentat i això és el
que he pogut treure de la comanda "sudo dmesg". No sé què podria ser
rellevant i què no, per això enganxo tot fins a l'inicialització de
systemd; espero que no sigui un problema.

Gràcies amb antelació!

[0.00] microcode: microcode updated early to revision 0xe2, date
= 2020-07-14
[0.00] Linux version 5.10.0-4-amd64
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-4-amd64
root=UUID=0ddc0be7-b651-4644-8876-3871a66513bc ro
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating
point registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
[0.00] x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
[0.00] x86/fpu: Enabled xstate features 0x1f, context size is
960 bytes, using 'compacted' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x00057fff]
usable
[0.00] BIOS-e820: [mem 0x00058000-0x00058fff]
reserved
[0.00] BIOS-e820: [mem 0x00059000-0x0009dfff]
usable
[0.00] BIOS-e820: [mem 0x0009e000-0x0009efff]
reserved
[0.00] BIOS-e820: [mem 0x0009f000-0x0009]
usable
[0.00] BIOS-e820: [mem 0x000a-0x000f]
reserved
[0.00] BIOS-e820: [mem 0x0010-0xd90fafff]
usable
[0.00] BIOS-e820: [mem 0xd90fb000-0xd95fafff]
type 20
[0.00] BIOS-e820: [mem 0xd95fb000-0xd9c7efff]
reserved
[0.00] BIOS-e820: [mem 0xd9c7f000-0xd9e7efff]
ACPI NVS
[0.00] BIOS-e820: [mem 0xd9e7f000-0xd9efefff]
ACPI data
[0.00] BIOS-e820: [mem 0xd9eff000-0xd9ef]
usable
[0.00] BIOS-e820: [mem 0xd9f0-0xde7f]
reserved
[0.00] BIOS-e820: [mem 0xf80fa000-0xf80fafff]
reserved
[0.00] BIOS-e820: [mem 0xf80fd000-0xf80fdfff]
reserved
[0.00] BIOS-e820: [mem 0xfe00-0xfe010fff]
reserved
[0.00] BIOS-e820: [mem 0x0001-0x00031f7f]
usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.40 by HP
[0.00] efi: ACPI=0xd9efe000 ACPI 2.0=0xd9efe014
SMBIOS=0xd98db000 ESRT=0xd9077660
[0.00] secureboot: Secure boot could not be determined (mode 0)
[0.00] SMBIOS 2.7 present.
[0.00] DMI: HP HP ProBook 650 G2/80FD, BIOS N76 Ver. 01.02
03/01/2016
[0.00] tsc: Detected 2400.000 MHz processor
[0.000619] e820: update [mem 0x-0x0fff] usable ==>
reserved
[0.000621] e820: remove [mem 0x000a-0x000f] usable
[0.000627] last_pfn = 0x31f800 max_arch_pfn = 0x4
[0.000631] MTRR default type: write-back
[0.000632] MTRR fixed ranges enabled:
[0.000633]   0-9 write-back
[0.000634]   A-B uncachable
[0.000635]   C-F write-protect
[0.000636] MTRR variable ranges enabled:
[0.000637]   0 base 00E000 mask 7FE000 uncachable
[0.000638]   1 base 00DC00 mask 7FFC00 uncachable
[0.000638]   2 disabled
[0.000639]   3 disabled
[0.000640]   4 disabled
[0.000640]   5 disabled
[0.000641]   6 disabled
[0.000641]   7 disabled
[0.000642]   8 disabled
[0.000642]   9 disabled
[0.000981] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC-
WT
[0.001552] last_pfn = 0xd9f00 max_arch_pfn = 0x4
[0.009443] esrt: ESRT header is not in the memory map.
[0.009450] Using GB pages for direct mapping
[0.009897] RAMDISK: [mem 0x321b7000-0x350d2fff]
[0.009903] ACPI: Early table checksum verification disabled
[0.009906] ACPI: RSDP 0xD9EFE014 24 (v02 HPQOEM)
[0.009910] ACPI: XSDT 0xD9EBC188 E4 (v01 HPQOEM SLIC-BPC
  0113)
[0.009915] ACPI: FACP 0xD9EEE000 F4 (v05 HPQOEM SLIC-BPC
 HP   0001)
[0.009920] ACPI: DSDT 0xD9EC5000 0250E4 (v02 HPQOEM 80FD

Re: Engegada aleatòria

[Joan Albert]

> Potser el sistema d'arrencada estigui corrupte o mal generat:
> $ sudo update-initramfs -u -k all

He provat exactament aquesta comanda sense cap tipus d'error,
i segueixo tenint el mateix problema :)

Alguna idea més? Gràcies igualment!

-- 
TS

Re: Montar unidad de disco duro que aparece como tmpfs

[Joan Carles Albiñana Medina]

Lo consigo montar a veces y me sale esto, sdb sin particiones ni nada
Y no consigo hacer nada con el



AME FSTYPE LABEL UUID FSAVAIL FSUSE%
MOUNTPOINT
loop0
 squash  0   100%
/snap/core
loop1
 squash  0   100%
/snap/core
loop2
 squash  0   100%
/snap/core
loop3
 squash  0   100%
/snap/core
loop4
 squash  0   100%
/snap/free
loop5
 squash  0   100%
/snap/frea
loop6
 squash  0   100%
/snap/frea
loop7
 squash  0   100%
/snap/gifc
loop8
 squash  0   100%
/snap/gifc
loop9
 squash  0   100%
/snap/vlc/
loop10
 squash  0   100%
/snap/odio
loop11
 squash  0   100%
/snap/vlc/
loop12
 squash  0   100%
/snap/gnom
loop13
 squash  0   100%
/snap/gtk-
sda
├─sda1
│ntfs   Windows10
│ 000812030009D4E6   33,9G66%
/media/jua
├─sda2
│ntfs   Drives
│ 0A96B1A196B18DA7
├─sda3
│ntfs   COPIAS_W10
│ 88E42461E42453AA
├─sda4
│
├─sda5
│ext4 1ab44d0c-022f-4239-985e-d74026dab6bd  119,3G52% /
└─sda6
 swap 5a3774b0-d2ff-4740-80d0-2a43d1e7197a[SWAP]
sdb

El mar, 9 mar 2021 a las 18:19, Joan Carles Albiñana Medina (<
jcalbin...@gmail.com>) escribió:

> El disco USB WD-Elements, se me cayó de una estantería.
>
> Al principio se montaba y le pasé
>
> sudo badblocks -s -v -n -f /dev/sdb
> sudo testdisk
> etc
>
> Parecía que iba bien pero tenía muchos errores de lectura. Lo arranque en
> el maldito Windows y me dijo que tenía que reparar la unidad. Le di a
> reparar y desde entonces no consigo montarla.
>
> Abrí el disco duro para ver si el motor y el cabezal iban. No encontré
> nada raro
>
> El motor gira pero no lo detecta como disco /dev/sdx ni lee la UUID
>
> Como no lo detecta como /dev/sdx no puedo hacer nada
>
>
>
>
> El mar, 9 mar 2021 a las 17:50, Camaleón () escribió:
>
>> El 2021-03-09 a las 16:20 +, Joan Carles Albiñana Medina escribió:
>>
>> > Necesito recuperar informacion de un disco duro y no se monta como
>> /dev/sdx
>> > sino que aparece como tmpfs y punto de montaje /run/user/0
>> >
>> > ¿Alguna ayuda?
>> >
>> >
>> > [root@sysrescue ~]# df -h
>> ^
>>
>> Si estás usando alguna herramienta de rescate (livecd o entorno
>> mínimo) te lo habrá montado automáticamente. Desmonta manualmente y
>> monta donde prefieras para realizar el diagnóstico.
>>
>> > Filesystem  Size  Used Avail Use% Mounted on
>> > dev 3.9G 0  3.9G   0% /dev
>> > run 3.9G   79M  3.8G   2% /run
>> > copytoram   5.8G  647M  5.2G  11% /run/archiso/copytoram
>> > cowspace2.0G   82M  1.9G   5% /run/archiso/cowspace
>> > /dev/loop0  647M  647M 0 100% /run/archiso/sfs/airootfs
>> > airootfs2.0G   82M  1.9G   5% /
>> > tmpfs   3.9G   85M  3.8G   3% /dev/shm
>> > tmpfs   4.0M 0  4.0M   0% /sys/fs/cgroup
>> > tmpfs   3.9G   40K  3.9G   1% /tmp
>> > tmpfs   3.9G  2.1M  3.9G   1% /etc/pacman.d/gnupg
>> > tmpfs   787M   36K  787M   1% /run/user/0
>>
>> Saludos,
>>
>> --
>> Camaleón
>>
>>

Re: Montar unidad de disco duro que aparece como tmpfs

[Joan Carles Albiñana Medina]

El disco USB WD-Elements, se me cayó de una estantería.

Al principio se montaba y le pasé

sudo badblocks -s -v -n -f /dev/sdb
sudo testdisk
etc

Parecía que iba bien pero tenía muchos errores de lectura. Lo arranque en
el maldito Windows y me dijo que tenía que reparar la unidad. Le di a
reparar y desde entonces no consigo montarla.

Abrí el disco duro para ver si el motor y el cabezal iban. No encontré nada
raro

El motor gira pero no lo detecta como disco /dev/sdx ni lee la UUID

Como no lo detecta como /dev/sdx no puedo hacer nada




El mar, 9 mar 2021 a las 17:50, Camaleón () escribió:

> El 2021-03-09 a las 16:20 +0000, Joan Carles Albiñana Medina escribió:
>
> > Necesito recuperar informacion de un disco duro y no se monta como
> /dev/sdx
> > sino que aparece como tmpfs y punto de montaje /run/user/0
> >
> > ¿Alguna ayuda?
> >
> >
> > [root@sysrescue ~]# df -h
> ^
>
> Si estás usando alguna herramienta de rescate (livecd o entorno
> mínimo) te lo habrá montado automáticamente. Desmonta manualmente y
> monta donde prefieras para realizar el diagnóstico.
>
> > Filesystem  Size  Used Avail Use% Mounted on
> > dev 3.9G 0  3.9G   0% /dev
> > run 3.9G   79M  3.8G   2% /run
> > copytoram   5.8G  647M  5.2G  11% /run/archiso/copytoram
> > cowspace2.0G   82M  1.9G   5% /run/archiso/cowspace
> > /dev/loop0  647M  647M 0 100% /run/archiso/sfs/airootfs
> > airootfs2.0G   82M  1.9G   5% /
> > tmpfs   3.9G   85M  3.8G   3% /dev/shm
> > tmpfs   4.0M 0  4.0M   0% /sys/fs/cgroup
> > tmpfs   3.9G   40K  3.9G   1% /tmp
> > tmpfs   3.9G  2.1M  3.9G   1% /etc/pacman.d/gnupg
> > tmpfs   787M   36K  787M   1% /run/user/0
>
> Saludos,
>
> --
> Camaleón
>
>

Re: Engegada aleatòria

[Joan Albert]

Bona tarda,

Moltes gràcies per les respostes (Josep, Narcís i Xavier). Faig un nou
correu comentant els diversos punts:

> Jo començaria per provar a triar diferent nucli d'inici, al gestor
> d'arrencada (menú del GRUB). Si això fa variar el resultat, tindràs més
> pistes sobre l'origen del problema.

Efectivament! Provant el nucli/kernel 4.19 funciona, mentre que amb el
5.10.0-4 actual segueixo tenint aquest problema intermitent. Sent així,
quins podrien ser els següents passos?

> Un cop em va passar (bug de nucli, manca d'actualització de bios HP) que
> el nucli no progressava per culpa d'un dispositiu usb (càmera web Polycom).
> Per engegar l'havia de tenir desconnectat.
> Vaig actualitzar la bios i es va resoldre.

Perdó pel total desconeixement, però com s'actualitza la BIOS? :) He
buscat una mica d'informació, però no ho he vist massa clar, i
preferiria no provar coses sense estar-ne prou segur. Té alguna relació
amb el nucli?

> mira si tens al directori /boot/grub un fitxer amb el nom unicode.pf2, la
> corrupció d'aquest fitxer pot provocat l'aturada de l'arrencada.

He provat de fer el que comentaves, i ha estat en va. 
Probablement aquest fitxer no estigui corrupte.

Sembla que ens anem apropant poc a poc!

-- 
TS


signature.asc
Description: PGP signature

Montar unidad de disco duro que aparece como tmpfs

[Joan Carles Albiñana Medina]

Necesito recuperar informacion de un disco duro y no se monta como /dev/sdx
sino que aparece como tmpfs y punto de montaje /run/user/0

¿Alguna ayuda?


[root@sysrescue ~]# df -h
Filesystem  Size  Used Avail Use% Mounted on
dev 3.9G 0  3.9G   0% /dev
run 3.9G   79M  3.8G   2% /run
copytoram   5.8G  647M  5.2G  11% /run/archiso/copytoram
cowspace2.0G   82M  1.9G   5% /run/archiso/cowspace
/dev/loop0  647M  647M 0 100% /run/archiso/sfs/airootfs
airootfs2.0G   82M  1.9G   5% /
tmpfs   3.9G   85M  3.8G   3% /dev/shm
tmpfs   4.0M 0  4.0M   0% /sys/fs/cgroup
tmpfs   3.9G   40K  3.9G   1% /tmp
tmpfs   3.9G  2.1M  3.9G   1% /etc/pacman.d/gnupg
tmpfs   787M   36K  787M   1% /run/user/0

Engegada aleatòria

[Joan Albert]

Bon dia debianites,

Tinc un petit problema que arrossego des de fa ja unes setmanes i crec
que ha arribat el moment de demanar ajuda.

El tema és que el meu PC de la feina, el qual corre únicament Debian
testing, fa el "burru" quan s'engega. Quasi mai s'engega a la primera,
es queda aturat a la pantalla inicial, concretament a la frase "Loading
initial ramdisk". El que acaba passant és que, després d'apagar-lo
forçosament (no em mateu, si us plau) i engegar-lo de nou moltes vegades
(provant d'endollar-lo i desendollar-lo, treure-li el connector USB del
teclat extern i posar-lo de nou, etc.), màgicament s'acaba iniciant
correctament.

La solució transitòria que he decidit de moment és simplement deixar-lo
obert 24/7, però òbviament no és la solució correcta. He buscat
informació i he estat provant varies opcions (no recordo ja quines...),
tant a respostes de Debian com de Linux en general, i no me'n surto.
Algú té almenys una idea de quin pot ser el motiu? I sobretot, com pot
ser que acabi funcionant sense fer res més que reiniciar?

Moltes gràcies amb antelació,

-- 
TS


signature.asc
Description: PGP signature

Re: smartd monitoritzant els vostres discs durs...

[Joan]

El Fri, 5 Mar 2021 23:31:11 +0100
Alex Muntada  va escriure:

> Hola Joan
> 
> > Volia saber si valtros useu aquesta opció i si te alguna
> > contrapartida...  
> 
> Als servidors físics que gestionàvem a la meva antiga feina
> sempre posàvem smartmontools amb el dimoni corrent i teníem
> alertes per correu i comprovacions amb nagios.
> 
> > D'altra banda, veig quan quan es fa un anàlisi llarg, pot
> > trigar molta estona.
> > 
> > i per tant suposo que no és aquest tipus d'anàlisi els que fa
> > el dimoni smartd, oi?  
> 
> Pot fer-ne de curts i de llargs però per defecte no en fa cap.
> Tens una pila d'exemples a /etc/smartd.conf. Nosaltres no fèiem
> tests fins que no es produïa cap alerta perquè no afectés el
> rendiment durant el dia ni els backups durant la nit.


Quan dius que no fèieu tests perquè primer esperàveu a una alerta, vols
dir que smartd fa unes comprovacions DIFERENTS als testos? I son
aquestes les que posen sobre avís?


> 
> Salut,
> Alex
> 
> --
>   ⢀⣴⠾⠻⢶⣦⠀
>   ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
>   ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
>   ⠈⠳⣄
> 



-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi

Re: pci arbiter being killed

[Joan Lledó]

Hi

El 7/3/21 a les 20:33, Samuel Thibault ha escrit:

Joan Lledó, le dim. 07 mars 2021 20:08:21 +0100, a ecrit:

is not there any process that kills the arbiter after a while of not
being used?


That shouldn't be happening.


and how could I know who is sending the SIGKILL?


How do you notice that it's a SIGKILL?


I connected gdb to the arbiter and it showed a message saying the 
process has received a SIGKILL.




You could e.g. put mach_prints in glibc's sysdeps/mach/hurd/kill.c's
SIGKILL case.

Possibly better also add a mach_print in hurd/hurdsig.c SIGKILL on
_hurd_orphaned.



I'll try that, thanks.

pci arbiter being killed

[Joan Lledó]

Hi Hurd,

I've observed how my instance of the pci arbiter receives a SIGKILL 
about a minute after start, it could be my fault as I've being messing 
around with gnumach, libpciaccess and the arbiter itself, but just to 
confirm: is not there any process that kills the arbiter after a while 
of not being used? and how could I know who is sending the SIGKILL?

Removing PPC from our list of supported platforms [was: Re: Jenkins issues, looking for committer volunteer(s)]

[Joan Touzet]

Hi everyone,

In a week, six months will have passed since I wrote this email. We have
still not received replacement ppc64le CI machines.

I propose removing ppc64le from our official build matrix. This means
discontinuation of support in the Docker container and the binary
packages. This will also directly affect our downstream "top-level"
couchdb Docker container.

If anyone has objections, or has alternate proposals, please speak now.

-Joan "doing the best I can" Touzet

On 14/09/2020 22:09, Joan Touzet wrote:
> Paul informs me that IBM have discontinued all Power platform hosting at
> the level that suits us. He is following up with Adam and others to find
> a solution, but...
> 
> This directly endangers our ability to release packages and Docker
> containers on ppc64le, as this platform will not be in the regression
> suite. We've had issues on alternate platforms (such as ARM and ppc64le)
> when not performing active testing.
> 
> This is especially troubling since IBM are the primary clients for this
> platform, or rather, their customers are.
> 
> I realize this may seem harsh, but I propose to remove ppc64le from the
> packages and the couchdb top-level Docker file by end of 2020, should
> replacement machines not be made available.
> 
> Please discuss.
> 
> -Joan
> 
> On 2020-09-12 5:01 p.m., Joan Touzet wrote:
>> Hi Devs,
>>
>> FYI per Jenkins:
>>  > All nodes of label ‘ppc64le’ are offline
>>
>> This is one of the reasons causing our Jenkins failures on master.
>> (The other is our usual heisenbugs in the test suite.)
>>
>> I really would like it if someone on the PMC (other than me and Paul)
>> would agree to help keep Jenkins running. It's my weekend and I really
>> don't have time to stay on top of these things. If you're a committer
>> we can get you access to the machines fairly readily, and Paul can help
>> talk you through what's necessary to keep the workers alive.
>>
>> -Joan "more help is always welcome" Touzet

smartd monitoritzant els vostres discs durs...

[Joan]

En aquest howto:

https://www.howtoforge.com/checking-hard-disk-sanity-with-smartmontools-debian-ubuntu

he vist que e spot fer que smartd estigui funcionant sempre com a
dimoni, i a part de passar info al syslog, també envii un mail si hi ha
algun problema.

Volia saber si valtros useu aquesta opció i si te alguna
contrapartida...

D'altra banda, veig quan quan es fa un anàlisi llarg, pot trigar molta
estona. Per exemple: sudo smartctl -t long  /dev/sdb

i per tant suposo que no és aquest tipus d'anàlisi els que fa el dimoni
smartd, oi?

Fins ara,

-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi

Re: Git / Compilation error

[Joan Moreau]

I do that each time

The problem arises on recent git only

On 2021-03-04 08:16, Aki Tuomi wrote:


Try running `autoreconf -vi`

Aki

On 04/03/2021 10:13 Joan Moreau  wrote:

I already have this file (dovecot compilation was working fine until 
recent git)

[root@gjserver dovecot]# ls -al /usr/share/aclocal/gettext.m4
-rw-r--r-- 1 root root 14488 Aug 4 2020 /usr/share/aclocal/gettext.m4

On 2021-03-04 08:09, Aki Tuomi wrote: You need to find package on your 
system which contains


/usr/share/aclocal/gettext.m4

or similar. This provides AM_ICONV.

Aki

On 04/03/2021 10:07 Joan Moreau  wrote:

Hello
I already have gettext
[root@gjserver dovecot]# pacman -S gettext
warning: gettext-0.21-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...
Package (1) Old Version New Version Net Change
core/gettext 0.21-1 0.21-1 0.00 MiB

On 2021-03-04 08:03, Aki Tuomi wrote: You need to install gettext

Aki

On 04/03/2021 10:02 Joan Moreau  wrote:

Hello,
With latest git, I get the following error :
configure.ac:761: the top level
configure.ac:22: error: possibly undefined macro: AC_DEFINE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:205: error: possibly undefined macro: AC_MSG_ERROR
configure.ac:247: error: possibly undefined macro: AS_IF
configure.ac:303: error: possibly undefined macro: AM_ICONV
configure.ac:434: error: possibly undefined macro: AC_CHECK_HEADER
configure:28073: error: possibly undefined macro: AC_CHECK_FUNC

Something I am missing?
Thank you

Re: Git / Compilation error

[Joan Moreau]

I already have this file (dovecot compilation was working fine until 
recent git)


[root@gjserver dovecot]# ls -al /usr/share/aclocal/gettext.m4
-rw-r--r-- 1 root root 14488 Aug  4  2020 /usr/share/aclocal/gettext.m4

On 2021-03-04 08:09, Aki Tuomi wrote:


You need to find package on your system which contains

/usr/share/aclocal/gettext.m4

or similar. This provides AM_ICONV.

Aki

On 04/03/2021 10:07 Joan Moreau  wrote:

Hello
I already have gettext
[root@gjserver dovecot]# pacman -S gettext
warning: gettext-0.21-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...
Package (1) Old Version New Version Net Change
core/gettext 0.21-1 0.21-1 0.00 MiB

On 2021-03-04 08:03, Aki Tuomi wrote: You need to install gettext

Aki

On 04/03/2021 10:02 Joan Moreau  wrote:

Hello,
With latest git, I get the following error :
configure.ac:761: the top level
configure.ac:22: error: possibly undefined macro: AC_DEFINE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:205: error: possibly undefined macro: AC_MSG_ERROR
configure.ac:247: error: possibly undefined macro: AS_IF
configure.ac:303: error: possibly undefined macro: AM_ICONV
configure.ac:434: error: possibly undefined macro: AC_CHECK_HEADER
configure:28073: error: possibly undefined macro: AC_CHECK_FUNC

Something I am missing?
Thank you

Re: Git / Compilation error

[Joan Moreau]

Hello

I already have gettext

[root@gjserver dovecot]# pacman -S gettext
warning: gettext-0.21-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...

Package (1)   Old Version  New Version  Net Change

core/gettext  0.21-1   0.21-1 0.00 MiB

On 2021-03-04 08:03, Aki Tuomi wrote:


You need to install gettext

Aki


On 04/03/2021 10:02 Joan Moreau  wrote:

Hello,
With latest git, I get the following error :
configure.ac:761: the top level
configure.ac:22: error: possibly undefined macro: AC_DEFINE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:205: error: possibly undefined macro: AC_MSG_ERROR
configure.ac:247: error: possibly undefined macro: AS_IF
configure.ac:303: error: possibly undefined macro: AM_ICONV
configure.ac:434: error: possibly undefined macro: AC_CHECK_HEADER
configure:28073: error: possibly undefined macro: AC_CHECK_FUNC

Something I am missing?
Thank you

Git / Compilation error

[Joan Moreau]

Hello,

With latest git, I get the following error :

configure.ac:761: the top level
configure.ac:22: error: possibly undefined macro: AC_DEFINE
  If this token and others are legitimate, please use 
m4_pattern_allow.

  See the Autoconf documentation.
configure.ac:205: error: possibly undefined macro: AC_MSG_ERROR
configure.ac:247: error: possibly undefined macro: AS_IF
configure.ac:303: error: possibly undefined macro: AM_ICONV
configure.ac:434: error: possibly undefined macro: AC_CHECK_HEADER
configure:28073: error: possibly undefined macro: AC_CHECK_FUNC

Something I am missing?

Thank you

Re: [OSList] Asking for your wisdom - Leora Tushinski

[Elwin and Joan via OSList]

 Leora,
My 30 years in Open Space tells me your ONLY MANAGEMENT role is creating the 
INVITATION. Full Stop!  All else is as Harrison has stated.
eg
On Wednesday, March 3, 2021, 09:43:25 AM EST, Harrison Owen SR via OSList 
 wrote:  
 
 Leora -- My very best to Tova! Holding the tension is a loosing game.. Just 
open some space and if the people really care, they will get amazing things 
accomplished with no intervention or supervision. Ask Tova about our time 
together in Rome with 50 Palestinians and Israelis who were mostly security 
types. At the start I remember standing behind two gentlemen I didn't know. One 
said to the other, "This is really weird -- we are in business to kill each 
other." Try it. Amazing things do happen.
Harrison
On Wed, Mar 3, 2021 at 9:34 AM David Osborne via OSList 
 wrote:

Interesting question Leona.
My answer is more about the principles of self-organization underneath 
openspace (that I learned from Harrison over lunches and a cocktail or two at 
the Glenn Echo Inn) than open space methodology.  Open space requires something 
to be urgent and important.otherwise people won't care and they won't show 
up and invest in it. I think as a manager part of your role is defining what's 
important to the organization and why in a way that people care. and want to 
contribute this sets the direction for your team or group. The urgent 
important issue is like the camp fire that you can then invite people to gather 
around and discuss.it is your role as manager to make the environment 
inclusive and safe for people to gather and share their views and ideas openly 
until insight emerges about the situation itself and what to do about it.   The 
energy and motivation to act will naturally arise at this point and you can 
help the group stay connected and share information about progress and what's 
working and what's not.  It's all self-organizing or emergent change. Where 
Harrison and I differed and I'm still exploring his view is whether we need to 
do anything at all or whether it will all happen by itself.   My view has been 
that I care too, and I want to do something. I am part of the emergence. Is my 
role necessary no. But without it something different will emerge.  Systems are 
always moving toward fragmentation or cohesion and your role as manager will 
make a huge difference in which way they are headed.
Thanks for your question, and my best to all.
David
David R. Osborne
Organization and Leadership Development

6402 Arlington Blvd., Suite 1120, Falls Church, VA 22042 703-939-1777   |   
dosbo...@change-fusion.com   |   change-fusion.com

On Wed, Mar 3, 2021 at 6:13 AM leora tushinski via OSList 
 wrote:


Hello everyone,
 

This is my first time in the OSList and I am writing to ask for the wisdom I am 
sure is held in this group.

My name is Leora and I'm a student of "Dialogic interventions in Large group" , 
held by Tova Averbuch and Rotem Ofer.

As a manager I have a challenge (and maybe a fear): wondering how to "hold" the 
tension between the "freedom" in the OS method,   and “purposefulness” needed 
in most of the processes .

How can we expect to get to "bottom lines" (get the work done) when we depend 
only on the people who come, and what they decide…?

  And more, how can we avoid   the "loose" rules   lead to "anarchy", 
especially in complex environment? 

I will appreciate your time, attention and wisdom

Thank you

Leora

Israel

 
050-6207543 (972)
בברכה,ליאורה 
050-6207543
___
OSList mailing list
To post send emails to OSList@lists.openspacetech.org
To unsubscribe send an email to oslist-le...@lists.openspacetech.org
To subscribe or manage your subscription click below:
http://lists.openspacetech.org/listinfo.cgi/oslist-openspacetech.org
Past archives can be viewed here: 
http://www.mail-archive.com/oslist@lists.openspacetech.org
___
OSList mailing list
To post send emails to OSList@lists.openspacetech.org
To unsubscribe send an email to oslist-le...@lists.openspacetech.org
To subscribe or manage your subscription click below:
http://lists.openspacetech.org/listinfo.cgi/oslist-openspacetech.org
Past archives can be viewed here: 
http://www.mail-archive.com/oslist@lists.openspacetech.org
___
OSList mailing list
To post send emails to OSList@lists.openspacetech.org
To unsubscribe send an email to oslist-le...@lists.openspacetech.org
To subscribe or manage your subscription click below:
http://lists.openspacetech.org/listinfo.cgi/oslist-openspacetech.org
Past archives can be viewed here: 
http://www.mail-archive.com/oslist@lists.openspacetech.org  ___
OSList mailing list
To post send emails to OSList@lists.openspacetech.org
To unsubscribe send an email to oslist-le...@lists.openspacetech.org
To subscribe or manage your subscription click below:

Early warning: bintray is going away, deb/rpm packages will have to move

[Joan Touzet]

Hello everyone,

One month ago, we were informed that JFrog are shutting down Bintray - a
service we currently use to host our .deb and .rpm packages for Debian
and Ubuntu, & CentOS and RHEL respectively. (Win/Mac downloads are now
provided by Neighbourhoodie.)

New uploads to bintray will be disabled end of March, and the service
will be taken offline as of May 1st. This doesn't give us a lot of time
to migrate, but the work to move the repository is not extensive.

While ASF Infra hasn't provided a replacement for us yet , as soon as
something is identified, I'll let the community know.

Here's the INFRA ticket to follow:

   https://issues.apache.org/jira/browse/INFRA-21376

-Joan "packages packages packages" Touzet

Early warning: bintray is going away, deb/rpm packages will have to move

[Joan Touzet]

Hello everyone,

One month ago, we were informed that JFrog are shutting down Bintray - a
service we currently use to host our .deb and .rpm packages for Debian
and Ubuntu, & CentOS and RHEL respectively. (Win/Mac downloads are now
provided by Neighbourhoodie.)

New uploads to bintray will be disabled end of March, and the service
will be taken offline as of May 1st. This doesn't give us a lot of time
to migrate, but the work to move the repository is not extensive.

While ASF Infra hasn't provided a replacement for us yet , as soon as
something is identified, I'll let the community know.

Here's the INFRA ticket to follow:

   https://issues.apache.org/jira/browse/INFRA-21376

-Joan "packages packages packages" Touzet

[SCM] Hurd branch, jlledom-pci-mem, updated. v0.9.git20200930-10-g3280821

[Joan Lled�]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Hurd".

The branch, jlledom-pci-mem has been updated
   via  328082136dd58fd5d289193dd1a417ce3b32844c (commit)
  from  82435f89c9d089768d187349e7a1218b1c137ec4 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 328082136dd58fd5d289193dd1a417ce3b32844c
Author: Joan Lledó 
Date:   Sat Feb 27 11:30:52 2021 +0100

pci-arbiter: fix typo

---

Summary of changes:
 pci-arbiter/pci-ops.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
Hurd

Re: article: serveis cloud, programari lliure: el cas d'Elastic Search vs Amazon

[Joan]

Interessant l'article :-)

Però al final, amb tot plegat, el projecte de codi lliure nascut de
Apache Lucene continua navegant, com el kernel de linux :-)

-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi


El Thu, 25 Feb 2021 10:34:29 +0100
Àlex  va escriure:

> Bones,
> 
> volia compartir amb vosaltres aquest article, que m'ha semblat
> interessant:
> 
>   https://www.muylinux.com/2021/02/24/amazon-elasticsearch-codigo-abierto/
> 
> Salutacions
> 
> 
>    Àlex
> 
> 



-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi

[SCM] Hurd branch, jlledom-pci-mem, updated. v0.9.git20200930-9-g82435f8

[Joan Lled�]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Hurd".

The branch, jlledom-pci-mem has been updated
   via  82435f89c9d089768d187349e7a1218b1c137ec4 (commit)
   via  4ac7706550de395f5e29ddf4912d86a629d0f638 (commit)
  from  dbeb490f5c2075b9563eb2740d8886a7d5d2af37 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 82435f89c9d089768d187349e7a1218b1c137ec4
Author: Joan Lledó 
Date:   Wed Feb 24 19:52:44 2021 +0100

pci-arbiter: Stop storing the proxy for future requests

The proxy is not valid as future requests can ask for different
protection level.

commit 4ac7706550de395f5e29ddf4912d86a629d0f638
Author: Joan Lledó 
Date:   Wed Feb 24 19:49:53 2021 +0100

Revert "pci arbiter: add a memory object proxy to directory entries"

This reverts commit dc859c3d4ba4015a2dae7ce63769238dcb3e.

No need to store the proxy, as it's not valid for future requests

---

Summary of changes:
 pci-arbiter/netfs_impl.c | 8 
 pci-arbiter/pcifs.c  | 1 -
 pci-arbiter/pcifs.h  | 3 ---
 3 files changed, 12 deletions(-)


hooks/post-receive
-- 
Hurd

Re: Una de discs durs

[Joan]

El Fri, 12 Feb 2021 09:49:35 +0100
Joan  va escriure:

> El Sun, 3 Jan 2021 09:29:35 +0100
> Josep Lladonosa  va escriure:
> 
> > Hola, Joan,
> > 
> > 
> > Que no sigui cosa del cable SATA.
> > A la feina hem tingut experiències similars i canviant-lo s'ha
> > resolt.  
> 
> 
> Per cert, després de canviar el cable SATA ja no ha tornat a succeir
> la "corrupció"... O sigui, dono per bona l'explicació que era el cable
> SATA.
> 
> I t'agraeixo molt, Josep, que apuntessis en aquesta direcció...
> 
> Pd.: sembla mentida que el que pugui fallar sigui un element estàtic
> com un cbale... O que aquest comenci a fallar "un bon dia"...
> 


Doncs no era el cable. Ahir em va tornar a fallar el disc dur... 

Ara em repassaré els missatges que em vau enviar, donant-me línies
d'investigació (quin pal, perquè aquest tema de hardware no el controlo
gens!).

De moment, com que l'ordinador, un slimbox, no te dos anys, els he
enviat un missatge per veure si la garantia cobreix aquest tema (entenc
que si, però ja vorem).

Estava pensant, però, si comprar-me'n un altre, mentre resolc aquest
tema, i uso el vell com a dipòsit per clonar/sincronitzar periòdicament
el primer, en plan backup o, fins i tot, si és possible fer un RAID
(tampoc sé si és bona idea usar un disc que es va corrompent com a
segon element del raid). Ara, una cosa que veig és que l'slimbox permet
collar un disc SATA, però no dos, malgrat tenir el connector de la
placa base, el que no te és lloc per "cargolar-lo": es pot posar "sense
collar"??



> 
> > 
> > La fiabilitat dels discs durs és poca, sempre és recomanable tenir
> > còpies de seguretat i fer-los treballar per parelles, en raid 1, per
> > exemple.
> > 
> > Cada fabricant indica la seva garantia.
> > Per a mi, els pitjors, Seagate. Els millors, Hitachi (HGST que crec
> > que és de Western Digital, ara, i que també està bé).
> > 
> > Bon any,
> > Josep
> > 
> > El dg., 3 de gen. 2021, 9:01, Joan  va
> > escriure: 
> > > El problema que tinc m'ha passat dugues vegades en dugues
> > > setmanes, i tinc dubtes de si és un tema físic del disc (un disc
> > > SATA de 4Tb) no massa vell, de potser un parell d'anys, o un
> > > problema del soft que "desgabella" el disc
> > >
> > > És un disc secundari (el sistema el tinc en un SSD) a on guardo
> > > videos, fotos, etc. Un dels meus sospitosos com a causa de tot
> > > plegat podria ser l'amule.
> > >
> > > Bé, la qüestió és que quan arrenco el sistema la cosa va
> > > malament, i queda en mode d'emergència, perquè detecta un error:
> > >
> > > de gen. 02 16:21:12 pc2019 systemd-fsck[502]: magatzem: Inode
> > > 38666373 has an invalid extent node (blk 154697780, lblk 0) de
> > > gen. 02 16:21:12 pc2019 systemd-fsck[502]: magatzem: UNEXPECTED
> > > INCONSISTENCY; RUN fsck MANUALLY. de gen. 02 16:21:12 pc2019
> > > systemd-fsck[502]: (i.e., without -a or -p options) de
> > > gen. 02 16:21:12 pc2019 systemd-fsck[430]: fsck failed with exit
> > > status 4. de gen. 02 16:21:12 pc2019 systemd-fsck[430]: Running
> > > request emergency.target/start/replace de gen. 02 16:21:12 pc2019
> > > systemd[1]: systemd-fsck@dev-disk-by
> > > \x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> > > Main process exited, code=exited, status=1/FAILURE de gen. 02
> > > 16:21:12 pc2019 systemd[1]:
> > > systemd-fsck@dev-disk-by
> > > \x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> > > Failed with result 'exit-code'. de gen. 02 16:21:12 pc2019
> > > systemd[1]: Failed to start File System Check on
> > > /dev/disk/by-uuid/eabfd9a3-1b1f-4144-a9d3-d514566fa3fb. de gen. 02
> > > 16:21:12 pc2019 systemd[1]: Dependency failed for /media/magatzem.
> > > de gen. 02 16:21:12 pc2019 systemd[1]: Dependency failed for Local
> > > File Systems. de gen. 02 16:21:12 pc2019 systemd[1]:
> > > local-fs.target: Job local-fs.target/start failed with result
> > > 'dependency'. de gen. 02 16:21:12 pc2019 systemd[1]:
> > > local-fs.target: Triggering OnFailure= dependencies. de gen. 02
> > > 16:21:12 pc2019 systemd[1]: media-magatzem.mount: Job
> > > media-magatzem.mount/start failed with result 'dependency'.
> > >
> > > I a mi em mostra aquesta pantalla:
> > >
> > >
> > > https://upload.disroot.org/r/APnYtXLB#NArCJjbVYVzxd9Hui4K9xb9xhkHzk9i1vE++Qf8BQQA=
> > >
> > > Llavors jo per sol·lucionar-ho gaig un e2fsck -c /dev/sdb1
> > >
> > > Que em 

Re: Validacions de formularis PDF per internet

[Joan]

El Wed, 17 Feb 2021 10:14:31 +0100
Narcis Garcia  va escriure:

> Comento que si t'instal·les el certificat digital al M. Firefox,
> aleshores l'aplicació Autofirma l'utilitza d'allà, i ja no cal
> connectar un lector de DNI.
> 
> Ara he provat l'Okular a Debian 10 i, a diferència de l'Evince,
> informa d'allò que dóna problemes. Per exemple, aquesta versió
> informa que no admet formularis XFA.
> Funciona molt bé, tot i que la versió 17 que porta el repositori de
> Debian (buster) no inclou el tema de signatura digital.
> A veure si entra per a Debian 12 i aleshores al repositori
> bullseye-backports.
> 
> Una altra alternativa seria que el desenvolupador l'empaquetés pel seu
> compte per a Debian 11 (bullseye), ja que molts l'aprofitaríem si
> millorés la utilització dels PDFs elitistes de la GenCat.


El que no te sentit és que la Gene faci servir sistemes "elitistes"
quan podrien fer formularis web (html, amb autentificació via
certificat), o si m'apures, usar java com l'agència tributària. Tampoc
la tresoreria de la Seg. Social usa pdf. Llavors, qui collons és el
ruc que a la Gene està impulsant aquests formularis PDF? Això és el
que cal començar a denunciar públicament. 


> 
> 
> 
> Narcis Garcia
> 
> __
> I'm using this dedicated address because personal addresses aren't
> masked enough at this mail public archive. Public archive
> administrator should fix this against automated addresses collectors.
> 
> El 17/2/21 a les 8:55, Leopold Palomo-Avellaneda ha escrit:
> > Bones,
> > 
> > 
> > voldria aportar el meu granet de sorra al fil ja que a finals de
> > l'any passat em vaig barallar bastant amb el tema.
> > 
> > Jo actualment, a Debian Buster, mitjançant el meu carnet de la UPC
> > o el meu DNIe i un lector de targetes, puc:
> > 
> > * Signar un pdf amb l'Autofirma però només amb el carnet de la UPC.
> > Autofirma (1.6.5) a GNU/Linux i MacOS actualment falla amb els nous
> > DNIe per culpa de la mancança del certificat de la DGP. [1]
> > 
> > * Amb el Libreoffice puc veure (i validar) i signar un PDF. Però
> > tinc deslocalitzades les instruccions. Espero poder-les trobar
> > aviat.
> > 
> > * Amb el Firefox puc entrar "a la meva salut", als ajuntaments
> > (Terrassa i Barcelona) i fer gestions.
> > 
> > * A la aoc.cat puc validar pdfs, però tenen un problema amb la
> > plataforma GNU/Linux que no han resolt. Tiquet obert des del gener.
> > 
> > * Em sobta molt la manca d'ús del millor programa per veure pdfs que
> > tenim a GNU/Linux que és l'Okular. Des de que el principal
> > desenvolupador és local i això ja mereixeria tenir-lo en compte,
> > fins que la versió de gener de 2021 pot signar pdfs i validar-los
> > tal com far l'Acroread (versió disponible 21.04). La llàstima és
> > que no entrarà a Bullseye ja que la versió del Poppler adequada no
> > va entrar.
> > 
> > * Si algú li interessa, tinc pendent pujar-lo a les píndoles, però
> > aquí hi ha el manual que vaig fer per configurar les coses. Manca
> > la part del libreoffice.
> > 
> > https://gitioc.upc.edu/ioc/identitat_e/-/wikis/Targetes-a-GNU/Linux
> > 
> > Salutacions,
> > 
> > 
> > Leopold
> > 
> > 
> > [1] https://github.com/ctt-gob-es/clienteafirma/issues/145
> > 
> > 
> > 
> > El 16/2/21 a les 20:55, Narcis Garcia ha escrit:  
> >>>
> >>> Aquesta és una de les coses que trobo que li falta al nostre
> >>> Debian, un programa per omplir i signar els documents PDF que
> >>> integren formularis.
> >>>
> >>> Avui dia aquests documents sembla que hi siguin per tot arreu i no
> >>> veig la forma de poder-lo fer.
> >>>
> >>> El Evince (el lector que faig servir per mirar els PDF), no
> >>> permet ni tan sols la verificació de signatures, això ho he
> >>> resolt amb el autofirma, que si hi ha versió per Linux i permet
> >>> signar i verificar.
> >>>
> >>> Salut!
> >>>
> >>> Javier
> >>>  
> >>
> >> Crec que amb l'Autofirma almenys ja hi ha una via consistent per a
> >> signar i per a veure signatures. És clar que seria desitjable
> >> quelcom més ben integrat al sistema.
> >>
> >> L'Evince permet veure, emplenar i desar formularis, però la
> >> majoria dels de la Generalitat de Catalunya no.
> >> Aquest tema suposo que és tant feixuc com l'Adobe Flash ho va ser,
> >> però amb l'agravant d'una administració que se'n diu «oberta», i
> >> sovint dificultant l'exercici dels drets de les persones.
> >>
> >> Jo d'aquesta tecnologia en diria una tecnologia-barrera, que
> >> aixeca nous murs burocràtics amb els quals l'administració pública
> >> es protegeix de nosaltres, les persones.
> >>  
> > 
> >   
> 



-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi

Re: Validacions de formularis PDF per internet

[Joan]

A Caliu hi ha una comissió, acabada de crear, per recopilat tots
aquests tràmits amb les administracions públiques que no es puguin fer
amb Linux. Allà a priori també mirarem si la normativa ho ampara, o no,
i en tot cas la idea és iniciar una campanya perquè això canvii i
l'administració "oberta" sigui, realment, multiplataforma"

-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi


El Tue, 16 Feb 2021 20:55:53 +0100
Narcis Garcia  va escriure:

> __
> I'm using this dedicated address because personal addresses aren't
> masked enough at this mail public archive. Public archive
> administrator should fix this against automated addresses collectors.
> El 16/2/21 a les 19:30, Javier Silva ha escrit:
> > El mar, 16 feb 2021 a las 19:23, Josep Lladonosa
> > () escribió:  
> >>
> >> Un cop ma filla (Debianita-ubuntaire) es va trobar amb una
> >> situació tal i com la descrius aquí amb un formulari de la
> >> Generalitat. El formulari, a mida que es va emplenant, intenta fer
> >> connexions remotes i és el que li fallava. Finalment, va claudicar
> >> i amb la professora van emplenar-ho en un Windows... :-/ 
> > 
> > Aquesta és una de les coses que trobo que li falta al nostre Debian,
> > un programa per omplir i signar els documents PDF que integren
> > formularis.
> > 
> > Avui dia aquests documents sembla que hi siguin per tot arreu i no
> > veig la forma de poder-lo fer.
> > 
> > El Evince (el lector que faig servir per mirar els PDF), no permet
> > ni tan sols la verificació de signatures, això ho he resolt amb el
> > autofirma, que si hi ha versió per Linux i permet signar i
> > verificar.
> > 
> > Salut!
> > 
> > Javier
> >   
> 
> Crec que amb l'Autofirma almenys ja hi ha una via consistent per a
> signar i per a veure signatures. És clar que seria desitjable quelcom
> més ben integrat al sistema.
> 
> L'Evince permet veure, emplenar i desar formularis, però la majoria
> dels de la Generalitat de Catalunya no.
> Aquest tema suposo que és tant feixuc com l'Adobe Flash ho va ser,
> però amb l'agravant d'una administració que se'n diu «oberta», i
> sovint dificultant l'exercici dels drets de les persones.
> 
> Jo d'aquesta tecnologia en diria una tecnologia-barrera, que aixeca
> nous murs burocràtics amb els quals l'administració pública es
> protegeix de nosaltres, les persones.
> 



-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi

Re: [arch-general] Why move LTS to 5.10 when VirtualBox guests Kernel Panic with 5.10?

[Joan Figueras via arch-general]

On 17/2/21 9:48, David C. Rankin via arch-general wrote:

Archdevs,

   You move of both linux and linux-lts to the same kernel is bewildering. That
eliminates all fallback capability lts provides. Currently, virtualbox Arch
guests are broken on 5.10 (as with most other distros).

   See: https://www.virtualbox.org/ticket/20055

   With linux on 5.10 and lts on 5.4 it was workable to have lts guests. Now
you have linux and linux-lts as the same kernel. How does that make sense?


Maybe this workaround can help you to build VirtualBox module. Reference:


https://bbs.archlinux.org/viewtopic.php?pid=1956756#p1956756


Cheers

Re: Instal·lacuó IDCAT

[Joan]

Aquesta extensió, si no m'equicoco, et serveix per exemple per importar
el certificat amb el navegador. Si vas a l'apartat de seguretat del
Firefox, per exemple, voràs que hi ha un subapartat de certificats, i
allà una pestanya de certificats personals a on et permet
importar-los...

-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi


El Wed, 17 Feb 2021 13:44:57 +0100
Eduard Selma  va escriure:

> Perdoneu que us faci una pregunta que segurament té una resposta
> òbvia, però preferiria que la contestés algun usuari de Debian i no
> d'un altre S. O.
> 
> Acabo d'aconseguir un certificat IDCAT en clauer USB. Al seu interior 
> només hi ha una carpeta amb un únic fitxer (binari) que té com a nom
> el meu NIF i l'extensió ".p12" (potser de pkcs?).
> Evidentment, el meu Sistema Operatiu (Debian Buster, Stable) no té 
> aquesta extensió associada a cap aplicació. Per la xarxa he trobat 
> indicacions referides a Ubuntus (obsolets, d'altra banda) que
> recomanen instal·lar unes determinades biblioteques, que potser no
> seran les adequades per a Buster.
> 
> Les indicacions al web de IDCAT també es refereixen a Ubuntus antics,
> i no em resulten de gaire ajuda.
> 
> Segurament algú de vosaltres ja ha passat per aquest tràngol i em
> pugui aconsellar. En aquest cas, mercès per endavant.
> 
>   Salut i codi lliure,
> 
>   Eduard Selma
> 



-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi

Google Summer of Code - Política

[Joan Albert]

Bones companys i companyes,

La setmana passada vaig rebre un correu de Debian (no recordo ja quina
llista era) explicant el Google Summer of Code d'aquest any[1].

Personalment, no coneixia aquesta iniciativa, i no sé si seré l'únic a
qui li incomoda. Uns dels principals motius pels que vaig triar Debian
com a distribució és el fet de ser independent d'organitzacions i
centrat en la comunitat (en contrast amb Ubuntu, per exemple) i del seu
ús estricte de software lliure per defecte. Sent totalment parcial
respecte les empreseses GAFAM (ja no utilitzo pràcticament cap servei d'elles),
desconfio de la bona voluntat que hi pugui haver en aquest SOC.
Òbviament, Google podria organitzar-lo lliurement, però per què s'ha
d'enfatitzar oficialment des de la web de Debian i els seus canals?
Hi ha hagut mai una discussió al respecte?

Segurament ja hi ha hagut aquest debat en algun moment, simplement
m'agradaria que algú pogués donar una mica de context sobre ell.

Moltes gràcies,

[1] https://wiki.debian.org/SummerOfCode2021/ 
-- 
TS

[SCM] Hurd branch, jlledom-pci-mem, updated. v0.9.git20200930-7-gdbeb490

[Joan Lled�]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Hurd".

The branch, jlledom-pci-mem has been updated
   via  dbeb490f5c2075b9563eb2740d8886a7d5d2af37 (commit)
  from  5b2100fb28bb61b9a4585217264e36a3e151b475 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit dbeb490f5c2075b9563eb2740d8886a7d5d2af37
Author: Joan Lledó 
Date:   Sat Feb 13 13:09:52 2021 +0100

pci-arbiter: Fix bug on netfs_get_filemap()

Take the right pager to create the proxy from

---

Summary of changes:
 pci-arbiter/netfs_impl.c | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)


hooks/post-receive
-- 
Hurd

Re: [OT] Sector laboral - Ús de Debian/Software Lliure

[Joan]

Bon dia,

Arribo tard al fil, però més val tard que mai!

Jo vaig començar a usar linux a finals dels 90. Potser una KDE que
devia sortir en un CD d'alguna d'aquelles revistes tipus "sololinux" o
similars... De seguida vaig passar a Mandrake i després una Debian,
potser amb Woody (3.0) i de seguida a Sarge (3.1) (recordeu, una distro
que va durar anys com a estable). Finalment vaig provar Ubuntu fins
que vaig quedar-ne tip de que cada 6 mesos em petés una cosa diferent
en actualitzar-me. Des de llavors, amb les acaballes Debian 4
probablement, faig servir Debian, estable sempre que puc i Testing en
els equips nous que compro (que passen a estables tant bon punt com
aquella distro s'estabilitza).

A nivell laboral durant uns quants anys, a on no treballava en temes
informàtics (sóc biòleg i havia treballat temes de qualitat a
indústria, ISO 9000, i de medi ambient (ISO 14000) a les feines usava
els ordinadors que hi havia, amb Windows. Però al 2002 vaig muntar una
empresa de venda de productes ecològics a domicili, delaterra.net, i al
magatzem vaig posar un ordinador vell amb Debian, a part del de casa.
En general sempre he treballat amb Gnome, excepte si l'ordinador era
molt vellet, a on he acostumat a usar xfce o similars. En aquests temps
fins i tot vaig conèixer una empresa distribuïdora, la Finestra sul
Cielo, que tenia els seus ordinadors amb alguna distro de linux: uns
pioners en el seu ram :-)

Al 2009 vaig traspassar delaterra i vaig decidir treballar en algo que
només depengues d'un portàtil i em permetés emportar-me la feina al
damunt, en un portàtil. Vaig començar a desenvolupar webs
professionalment, amb Drupal (després també CiviCRM i Moodle). Els meus
equips personals continuen portant Debian, i quan vaig començar a
muntar-me jo mateix els servidors, doncs també, porto mitja dotzena
llarga de servidors VPS/cloud amb Debian.

Ara, congelat per la tempesta a Alemanya, tinc un pinephone amb Mobian
en trànsit a Hannover, així que xulejaré de portar una Debian també a
la butxaca :-p 

Els meus fills també tenen els equips amb linux: un amb una Manjaro,
per provar, que va substituir a la linkat d'origen, quan aquesta em va
donar el segon problema greu i em vaig afartar, i l'altre amb una doble
Debian/Suse (la segona per jugar, la primera per l'institut). Gcompris i
Wesnoth han sigut llocs comuns per a ells.

Amb els amics, parelles, etc. des del començament, ja des del principi
faig anar allò de que "jo de windows no en sé, ni en vull saber" i
m'ofereixo a posar-los linux i mantenir-lo... Sempre he tingut un
parell o tres que han picat... En general poso una Debian i jo em quedo
el root, perquè no vull que me la desmuntin :-) Això si, llavors em
toca anar a donar-los servei :-p Però en general és un sistema tant
estable que no em dona molta feina.

La meva parella ha sigut un cas notable en aquest tema de mantenir
ordinadors amb Debian per altri... Perquè treballa a Catalunya Ràdio i
allà el teletreball el fan via Citrix (ja us vaig fer alguna consulta a
la llista). Allà els Mac eren els típics que donaven problemes a
l'empresa externa que dona el suport TIC, i pel que sembla hi ha un
altre treballador, entre 400, que usava ubuntu, fins que els nostres
debians (fixe i portàtil) van trucar a la porta... I, sorprenentment,
després d'un cert esforç, ja tenim el Citrix funcionant sobre una
Debian. Una bestiesa de recursos, un exemple d'ineficència, de
llicències, etc., però bé, com a mínim no ha expulsat el linux!

I vet aquí un gat, vet aquí un gos
i aquest conte, ja s'ha fos!

-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi


El Fri, 29 Jan 2021 16:56:09 -0800
ores...@riseup.net va escriure:

> A 2021-01-27 19:54, Joan Albert escrigué:
> > Bona tarda,
> > 
> > En primer lloc, perdoneu-me si aquest fil no és adient, i espero que
> > algú pugui comentar-ho si és el cas.
> > 
> > Fa temps que tinc curiositat sobre el sector on
> > treballem/investiguem/estudiem els integrants d'aquesta llista,
> > i saber si allà utilitzem o no la nostra estimada distribució,
> > software lliure en general o no és el cas.
> >   
> 
> Som-hi doncs:
> 
> [a casa]
> 
> 5 ordinadors en actiu (3 portàtils, 2 fixes), tots exclusivament
> corrent Debian (estable o testing) amb escriptori KDE. Això inclou els
> ordinadors portàtils que usen o han usat els fills per a les tasques
> escolars. Si eren comprats via institut normalment venien amb una
> arrencada dual Linkat/Windows, però aquest darrer sistema operatiu era
> ràpidament exorcitzat així que l'ordinador es desembalava. No han
> tingut mai cap gran problema amb el professorat per aquest

Re: Una de discs durs

[Joan]

El Sun, 3 Jan 2021 09:29:35 +0100
Josep Lladonosa  va escriure:

> Hola, Joan,
> 
> 
> Que no sigui cosa del cable SATA.
> A la feina hem tingut experiències similars i canviant-lo s'ha resolt.


Per cert, després de canviar el cable SATA ja no ha tornat a succeir la
"corrupció"... O sigui, dono per bona l'explicació que era el cable
SATA.

I t'agraeixo molt, Josep, que apuntessis en aquesta direcció...

Pd.: sembla mentida que el que pugui fallar sigui un element estàtic
com un cbale... O que aquest comenci a fallar "un bon dia"...


> 
> La fiabilitat dels discs durs és poca, sempre és recomanable tenir
> còpies de seguretat i fer-los treballar per parelles, en raid 1, per
> exemple.
> 
> Cada fabricant indica la seva garantia.
> Per a mi, els pitjors, Seagate. Els millors, Hitachi (HGST que crec
> que és de Western Digital, ara, i que també està bé).
> 
> Bon any,
> Josep
> 
> El dg., 3 de gen. 2021, 9:01, Joan  va escriure:
> 
> > El problema que tinc m'ha passat dugues vegades en dugues setmanes,
> > i tinc dubtes de si és un tema físic del disc (un disc SATA de 4Tb)
> > no massa vell, de potser un parell d'anys, o un problema del soft
> > que "desgabella" el disc
> >
> > És un disc secundari (el sistema el tinc en un SSD) a on guardo
> > videos, fotos, etc. Un dels meus sospitosos com a causa de tot
> > plegat podria ser l'amule.
> >
> > Bé, la qüestió és que quan arrenco el sistema la cosa va malament, i
> > queda en mode d'emergència, perquè detecta un error:
> >
> > de gen. 02 16:21:12 pc2019 systemd-fsck[502]: magatzem: Inode
> > 38666373 has an invalid extent node (blk 154697780, lblk 0) de gen.
> > 02 16:21:12 pc2019 systemd-fsck[502]: magatzem: UNEXPECTED
> > INCONSISTENCY; RUN fsck MANUALLY. de gen. 02 16:21:12 pc2019
> > systemd-fsck[502]: (i.e., without -a or -p options) de gen.
> > 02 16:21:12 pc2019 systemd-fsck[430]: fsck failed with exit status
> > 4. de gen. 02 16:21:12 pc2019 systemd-fsck[430]: Running request
> > emergency.target/start/replace de gen. 02 16:21:12 pc2019
> > systemd[1]: systemd-fsck@dev-disk-by
> > \x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> > Main process exited, code=exited, status=1/FAILURE de gen. 02
> > 16:21:12 pc2019 systemd[1]:
> > systemd-fsck@dev-disk-by
> > \x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> > Failed with result 'exit-code'. de gen. 02 16:21:12 pc2019
> > systemd[1]: Failed to start File System Check on
> > /dev/disk/by-uuid/eabfd9a3-1b1f-4144-a9d3-d514566fa3fb. de gen. 02
> > 16:21:12 pc2019 systemd[1]: Dependency failed for /media/magatzem.
> > de gen. 02 16:21:12 pc2019 systemd[1]: Dependency failed for Local
> > File Systems. de gen. 02 16:21:12 pc2019 systemd[1]:
> > local-fs.target: Job local-fs.target/start failed with result
> > 'dependency'. de gen. 02 16:21:12 pc2019 systemd[1]:
> > local-fs.target: Triggering OnFailure= dependencies. de gen. 02
> > 16:21:12 pc2019 systemd[1]: media-magatzem.mount: Job
> > media-magatzem.mount/start failed with result 'dependency'.
> >
> > I a mi em mostra aquesta pantalla:
> >
> >
> > https://upload.disroot.org/r/APnYtXLB#NArCJjbVYVzxd9Hui4K9xb9xhkHzk9i1vE++Qf8BQQA=
> >
> > Llavors jo per sol·lucionar-ho gaig un e2fsck -c /dev/sdb1
> >
> > Que em dona aquestes pantalles (les resumeixo, perquè bàsicament
> > son 20 minuts de anar dient "yes" a tot el que em proposa, després
> > de la revisió que dura unes 8 hores o més:
> >
> >
> > https://upload.disroot.org/r/kRLsL2RX#bF9doWYguCMHAvj3APaJNb+GbUBq9zCX2mdrkLJhMAQ=
> >
> > https://upload.disroot.org/r/sYqhJfcy#Wv3pVBo0OuvfosT/i1LfCRx+6sTWwSkpWGDJIl4uTkI=
> >
> > https://upload.disroot.org/r/UTbxj19F#u5TA97h7ykB7KFj58OSPhgFLqwqFBSv00nHAQ8FoPpU=
> >
> > Llavors, les meves preguntes:
> >
> > 1) Us sembla que és un fallo de hard (el disc comença a fer el
> > tonto, amb només 15 mesos), i ja em puc espabilar a comprar-ne un
> > altra i fer-li un clonezilla?
> >
> > 2) Podria ser un problema originat pel software? (en aquest sentit
> > no sé si actualitzar la meva Debian Testing, que no actualitzo en
> > general de cop, sinó a bocinets).
> >
> > 3) No sé si al disc secundari és fa un fsck (o com es digui). Allò
> > que es fa al primari cada nosequantes arrencades. Diria que no, i
> > que és una opció configurable al fstab. El meu fstab és aquest:
> >
> > UUID=... /   ext4errors=remount-ro 0   1
> > # /home was on /dev/sdb6 during installation
> > UUID=.

Re: fts_encoder

[Joan Moreau]

Created a PR

https://github.com/dovecot/core/pull/155

On 2021-02-11 13:25, Joan Moreau wrote:


Hello

Checking further, and putting logs a bit every where in the dovecot 
code, the core is sending FIRST the initial document (not decoded) then 
SECOND the decoded version


Thisi is really weird, and the indexer then indexes a lot of binary 
crap


I am struggling to find where in the code this double call is made.

Anyone knows ?

On 2021-02-10 00:05, John Fawcett wrote:

On 09/02/2021 15:33, Joan Moreau wrote:

If I place the following code in the plugin 
fts_backend_xxx_update_build_more function (lucene, squat and xapian, 
as solr refuses to work properly on my setup)


{
char * s = i_strdup("EMPTY");
if(data != NULL) { i_free(s); s = i_strndup(data,20); }
i_info("fts_backend_update_build_more: data like '%s'",s);
i_free(s);
}

and if I send a PDF by email, the data shown in the log is "%PDF-1.7 "

so it does mean the decoder data is not properly transmitted to the 
plugin


Something is wrong in the data transmission

Joan

I too see something similar with fts_solr. I do see the raw %PDF string 
and PDF binary data being passed through to 
fts_backend_xxx_update_build_more function but I disagree with the 
conclusion you draw from it.


After the raw data I also see the decoded data, so at least in my case 
it is possible to see both the raw and decoded data in 
fts_backend_xxx_update_build_more function. In the rawlog I no longer 
see the binary data (but some blank lines), so something is filtering 
it. I do see the decoded data in the rawlog. I do get hits on the solr 
search for the decoded text.


John

Re: fts_encoder

[Joan Moreau]

Hello

Checking further, and putting logs a bit every where in the dovecot 
code, the core is sending FIRST the initial document (not decoded) then 
SECOND the decoded version


Thisi is really weird, and the indexer then indexes a lot of binary crap

I am struggling to find where in the code this double call is made.

Anyone knows ?

On 2021-02-10 00:05, John Fawcett wrote:


On 09/02/2021 15:33, Joan Moreau wrote:

If I place the following code in the plugin 
fts_backend_xxx_update_build_more function (lucene, squat and xapian, 
as solr refuses to work properly on my setup)


{
char * s = i_strdup("EMPTY");
if(data != NULL) { i_free(s); s = i_strndup(data,20); }
i_info("fts_backend_update_build_more: data like '%s'",s);
i_free(s);
}

and if I send a PDF by email, the data shown in the log is "%PDF-1.7 "

so it does mean the decoder data is not properly transmitted to the 
plugin


Something is wrong in the data transmission


Joan

I too see something similar with fts_solr. I do see the raw %PDF string 
and PDF binary data being passed through to 
fts_backend_xxx_update_build_more function but I disagree with the 
conclusion you draw from it.


After the raw data I also see the decoded data, so at least in my case 
it is possible to see both the raw and decoded data in 
fts_backend_xxx_update_build_more function. In the rawlog I no longer 
see the binary data (but some blank lines), so something is filtering 
it. I do see the decoded data in the rawlog. I do get hits on the solr 
search for the decoded text.


John

RE: trap changes made for VRF

[Joan Landry]

No – when I made those changes traps stopped working.
I have been waiting for documentation on how to use the new vrf code.
Thanks,
Joan


From: Bart Van Assche 
Sent: Wednesday, February 10, 2021 10:24 PM
To: Joan Landry ; stann...@cumulusnetworks.com
Cc: net-snmp-users@lists.sourceforge.net
Subject: Re: trap changes made for VRF

External email: [bart.vanass...@gmail.com]

Hi Joan,

Did this help?

Thanks,

Bart.

On 1/12/21 5:46 PM, Bart Van Assche wrote:
Hi Joan,

Please try the following:

git clone 
g...@github.com:net-snmp/net-snmp.git<mailto:g...@github.com:net-snmp/net-snmp.git>
 &&
cd net-snmp &&
git checkout V5-9-patches &&
for c in b3dd62016170 5d61e9367200 02de400544de dc3194eaecb4 \ 3ca90c2c1260; do 
git revert --no-edit $c || break; done

and next build, install and test Net-SNMP.

Thanks,

Bart.

On 1/12/21 11:50 AM, Joan Landry wrote:
Please tell me where to find these patches – links please.
Thanks

From: Bart Van Assche <mailto:bvanass...@acm.org>
Sent: Saturday, January 9, 2021 5:47 PM
To: Joan Landry <mailto:jolan...@adva.com>; 
stann...@cumulusnetworks.com<mailto:stann...@cumulusnetworks.com>
Cc: 
net-snmp-users@lists.sourceforge.net<mailto:net-snmp-users@lists.sourceforge.net>
Subject: Re: trap changes made for VRF



Hi Joan,

Pre-existing functionality should not have been affected by adding VRF support. 
That probably was an unintended side effect. Can you revert the following 
patches and verify whether that is sufficient to restore previous functionality?

  1.  b3dd62016170 ("libsnmp, UDP: Only display VRF debug messages if relevant")
  2.  5d61e9367200 ("snmplib, UDP transport: Do not compare array pointers 
against NULL")
  3.  02de400544de ("libsnmp: Set Linux VRF iface on Trap sink IP addresses")
  4.  3ca90c2c1260 ("libsnmp/transports/UDP: Add support for VRF")
Thanks,

Bart.

On 1/6/21 11:33 PM, Joan Landry wrote:
Can you please also explain why the pre-existing functionality of clientaddr 
x.x.x.x:port – no longer works
and what I need to do to get it to work again?
Also, where should I look for this patch – and any idea on when it might be 
available?
Thanks,
Joan



From: Bart Van Assche <mailto:bvanass...@acm.org>
Sent: Wednesday, January 6, 2021 11:28 PM
To: stann...@cumulusnetworks.com<mailto:stann...@cumulusnetworks.com>
Cc: Joan Landry <mailto:jolan...@adva.com>; 
net-snmp-users@lists.sourceforge.net<mailto:net-snmp-users@lists.sourceforge.net>
Subject: Re: trap changes made for VRF

External email:

Hi Sam,

Can you submit a patch that documents how to use the changes in the following 
two commits:
* 02de400544de ("libsnmp: Set Linux VRF iface on Trap sink IP addresses")
* 3ca90c2c1260 ("libsnmp/transports/UDP: Add support for VRF")
Thanks,

Bart.

On 1/6/21 12:39 PM, Joan Landry wrote:
Can someone please provide a link to the documentation that describes how to 
get rc = netsnmp_bindtodevice(t->sock, ep->iface);
to work – apparently the code that sends traps has been redesigned 
significantly in that NETSNMP_DS_LIB_CLIENT_ADDR no longer works as use to.

What is the change in snmpd.conf that makes this work apparently clientaddr 
x.x.x.x:port – no longer works as it used to.

I have not been able to locate any documentation on these changes or how to set 
the VRF interface or how to allow the code to set an ipaddress and port using 
NETSNMP_DS_LIB_CLIENT_ADDR

Any info on this would be greatly appreciated.


Please see our privacy statement at 
https://www.adva.com/en/about-us/legal/privacy-statement for details of how 
ADVA processes personal information.



Please see our privacy statement at 
https://www.adva.com/en/about-us/legal/privacy-statement for details of how 
ADVA processes personal information.




___
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

[cobirds] Mute Swans

[Joan Larrabee]

Today, Feb 8, I saw the Mute Swans at the lake at the Broadmoor in Colorado 
Springs, El Paso County. How do we know they are wild birds and not permanent 
birds at the Broadmoor?

[cid:9C8585CA-B978-415D-A685-967C18EC848B]

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Colorado Birds" group.
To post to this group, send email to cobirds@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/cobirds?hl=en?hl=en
* All posts should be signed with the poster's full name and city. Include bird 
species and location in the subject line when appropriate
--- 
You received this message because you are subscribed to the Google Groups 
"Colorado Birds" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cobirds+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cobirds/DF4PR8401MB046003B2E671935AE7D0D6A3CF8F9%40DF4PR8401MB0460.NAMPRD84.PROD.OUTLOOK.COM.

Re: fts_encoder

[Joan Moreau]

If I place the following code in the plugin 
fts_backend_xxx_update_build_more function (lucene, squat and xapian, as 
solr refuses to work properly on my setup)


{
char * s = i_strdup("EMPTY");
if(data != NULL) { i_free(s); s = i_strndup(data,20); }
i_info("fts_backend_update_build_more: data like 
'%s'",s);

i_free(s);
}

and if I send a PDF by email, the data shown in the log is "%PDF-1.7 "

so it does mean the decoder data is not properly transmitted to the 
plugin


Something is wrong in the data transmission

On 2021-02-09 11:58, John Fawcett wrote:

On 08/02/2021 23:05, Stuart Henderson wrote: On 2021/02/08 21:33, Joan 
Moreau wrote: Yes , once again : output of the decoder is fine, I also 
put log inide the dovecot core to
check whether data is properly transmitted, and result is that it is 
(i.e. dovecot core

receives the proper output of pdftotext via the decoder

Now, that data is the /not/ the one sent from dovecot core to the fts 
plugin (and this is the
same issue for solr and all other plugins) Seems that something is 
different with your setup than John's and mine

then, as fts_solr rawlog (which is just the http request split into
.in and .out files) has the decoded file for us.

Did you try with the actual fts_solr plugin so it's a direct comparison
with what we see? There is no need for a real solr server, just point 
it

at any http server (or I guess netcat listening on a port will also do)
with

mail_plugins = fts fts_solr

plugin {
fts_autoindex = yes
fts = solr
fts_solr = url=http://127.0.0.1:80/ rawlog_dir=/tmp/solr
}

If that is not showing decoded for you then I suppose there's some
problem on the way into/through fts. And if it does show as decoded
then perhaps fts_solr is doing something slightly different than the
places you're examining in fts and your plugin, and that might give
a point to work backwards from.
 I'd also recommend Joan to look into some of the potential 
configuration

issues I mentioned in my first reply and if the problem persists, post
some clear evidence.

John

Re: fts_encoder

[Joan Moreau]

Yes , once again : output of the decoder is fine, I also put log inide 
the dovecot core to check whether data is properly transmitted, and 
result is that it is (i.e. dovecot core receives the proper output of 
pdftotext via the decoder


Now, that data is the /not/ the one sent from dovecot core to the fts 
plugin (and this is the same issue for solr and all other plugins)


Of course, the stemming will show a good results (as PDF content will be 
stemmed) but the problem does remain.


How to make sure the data sent to the FTS plugins (xapian, solr, 
whatever...) is the the output of the decoder and /not/ the original 
data ?


On 2021-02-08 21:11, Stuart Henderson wrote:


On 2021-02-08, Joan Moreau  wrote:

Well, in the function xxx_build_more of FTS plugin, the data received 
in

the original PDF, not the output of pdftotext

Can you clarify where do you put your log in the solr plugin , so I 
can

check the situation in the xapian plugin ?


The log is particular to fts_solr, you set it with e.g.

"fts_solr = url=http://127.0.0.1:8983/solr/dovecot/ 
rawlog_dir=/tmp/solr"


Confirmed it works for me, i.e. passes text from inside the pdf, and 
not

the whole pdf itself.

Did you check that decode2text.sh works ok on your system (when running
as the relevant uid)?

cat foo.pdf | sudo -u dovecot /usr/libexec/dovecot/decode2text.sh 
application/pdf

Re: fts_encoder

[Joan Moreau]

Yes , once again : output of the decoder is fine, I also put log inide 
the dovecot core to check whereas data is properly transmitted and it is 
(i.e. dovecot core receives the proper output of pdftotext via the 
decoder


Now, that data is the /not/ the once ent from dovecot core to the fts 
plugin (and this is the same issue for solr and all other plugins)


Of course, the stemming will show a good results abut the problem does 
remain.


How to make sure the data sent to the FTS plugins (xapian, solr, 
whatever...) is the the output of the decoder and /not/ the original 
data ?


On 2021-02-08 21:11, Stuart Henderson wrote:


On 2021-02-08, Joan Moreau  wrote:

Well, in the function xxx_build_more of FTS plugin, the data received 
in

the original PDF, not the output of pdftotext

Can you clarify where do you put your log in the solr plugin , so I 
can

check the situation in the xapian plugin ?


The log is particular to fts_solr, you set it with e.g.

"fts_solr = url=http://127.0.0.1:8983/solr/dovecot/ 
rawlog_dir=/tmp/solr"


Confirmed it works for me, i.e. passes text from inside the pdf, and 
not

the whole pdf itself.

Did you check that decode2text.sh works ok on your system (when running
as the relevant uid)?

cat foo.pdf | sudo -u dovecot /usr/libexec/dovecot/decode2text.sh 
application/pdf

Re: fts_encoder

[Joan Moreau]

Well, in the function xxx_build_more of FTS plugin, the data received in 
the original PDF, not the output of pdftotext


Can you clarify where do you put your log in the solr plugin , so I can 
check the situation in the xapian plugin ?


On 2021-02-08 17:34, John Fawcett wrote:


On 08/02/2021 15:22, Joan Moreau wrote:


Well, thank you for the answer, but the actual issue is that data sent
by the decoder (stipulated in the conf file) is properly collected by
dovecot core, but /not/ sent to the plugin : the plugin receives the
original data.

This is not linked to a particular plugin (xapian, solr, squat, etc..)
but seems to be a general issue of dovecot core


Hi Joan

as far as I can see there's not a general issue in the dovecot core 
with

using the decoder. It works for me. I see the text extracted from PDF
sent to solr (I enable raw_log feature to see the actual data going 
over

) Also when I query solr I get a search hit for attachment text.

John

Re: fts_encoder

[Joan Moreau]

Well, thank you for the answer, but the actual issue is that data sent 
by the decoder (stipulated in the conf file) is properly collected by 
dovecot core, but /not/ sent to the plugin : the plugin receives the 
original data.


This is not linked to a particular plugin (xapian, solr, squat, etc..) 
but seems to be a general issue of dovecot core


On 2021-02-08 01:03, John Fawcett wrote:


On 07/02/2021 18:51, Joan Moreau wrote:

more info : the function fts_parser_script_more in 
plugins/fts/fts-parser.c properly read the output of the script


still, the data is not sent to the FTS pligins (xapian or any other)

On 2021-02-07 17:37, Joan Moreau wrote:

more info : I am running dovecot git version

On 2021-02-07 17:15, Joan Moreau wrote:

a bit more on this, adding log in the decode2text.sh, I can see that 
pdftotext output the right data, but that data is /not/ transmitted to 
the fts plugin for indexing (only the original pdf code is)


On 2021-02-07 17:00, Joan Moreau wrote:

Hello,

I am trying to deal properly with email attachements in fts-xapian 
plugins.


I tried the default script with a PDF file.

The data I receive in the fts plugin part ("xxx_build_more") is the 
original document, no the output of the pdftotext


Is there anything I am missing ?

Here my config:

plugin {
plugin = fts_xapian managesieve sieve

fts = xapian
fts_xapian = partial=2 full=20 verbose=1 attachments=1

fts_autoindex = yes
fts_enforced = yes
fts_autoindex_exclude = \Trash
fts_autoindex_exclude2 = \Drafts

fts_decoder = decode2text

sieve = /data/mail/%d/%n/local.sieve
sieve_after = /data/mail/after.sieve
sieve_before = /data/mail/before.sieve
sieve_dir = /data/mail/%d/%n/sieve
sieve_global_dir = /data/mail
sieve_global_path = /data/mail/global.sieve
}

...

service decode2text {
executable = script /usr/libexec/dovecot/decode2text.sh
user = dovecot
unix_listener decode2text {
mode = 0666
}
}

Thank you


Joan

I'm not sure I can be much use for xapian, but looking at your 
configuration I did notice some differences with the documentation. I 
don't know if they are relevant to the issue you're seeing.


First of all I don't see

mail_plugins = fts

plugin = fts

settings which are both mentioned in the xapian documentation.

Also the documentation states that attachments=1 can only index text 
attachments. Maybe you should be using attachments=0 and let fts_decode 
handle the attachments.


Failing that, I can only advise to turn on some debugging and see what 
that brings.


best regards

John

Re: fts_encoder

[Joan Moreau]

more info : the function fts_parser_script_more in 
plugins/fts/fts-parser.c properly read the output of the script


still, the data is not sent to the FTS pligins (xapian or any other)

On 2021-02-07 17:37, Joan Moreau wrote:


more info : I am running dovecot git version

On 2021-02-07 17:15, Joan Moreau wrote:

a bit more on this, adding log in the decode2text.sh, I can see that 
pdftotext output the right data, but that data is /not/ transmitted to 
the fts plugin for indexing (only the original pdf code is)


On 2021-02-07 17:00, Joan Moreau wrote:

Hello,

I am trying to deal properly with email attachements in fts-xapian 
plugins.


I tried the default script with a PDF file.

The data I receive in the fts plugin part ("xxx_build_more") is the 
original document, no the output of the pdftotext


Is there anything I am missing ?

Here my config:

plugin {
plugin = fts_xapian managesieve sieve

fts = xapian
fts_xapian = partial=2 full=20 verbose=1 attachments=1

fts_autoindex = yes
fts_enforced = yes
fts_autoindex_exclude = \Trash
fts_autoindex_exclude2 = \Drafts

fts_decoder = decode2text

sieve = /data/mail/%d/%n/local.sieve
sieve_after = /data/mail/after.sieve
sieve_before = /data/mail/before.sieve
sieve_dir = /data/mail/%d/%n/sieve
sieve_global_dir = /data/mail
sieve_global_path = /data/mail/global.sieve
}

...

service decode2text {
executable = script /usr/libexec/dovecot/decode2text.sh
user = dovecot
unix_listener decode2text {
mode = 0666
}
}

Thank you

Re: fts_encoder

[Joan Moreau]

more info : I am running dovecot git version

On 2021-02-07 17:15, Joan Moreau wrote:

a bit more on this, adding log in the decode2text.sh, I can see that 
pdftotext output the right data, but that data is /not/ transmitted to 
the fts plugin for indexing (only the original pdf code is)


On 2021-02-07 17:00, Joan Moreau wrote:


Hello,

I am trying to deal properly with email attachements in fts-xapian 
plugins.


I tried the default script with a PDF file.

The data I receive in the fts plugin part ("xxx_build_more") is the 
original document, no the output of the pdftotext


Is there anything I am missing ?

Here my config:

plugin {
plugin = fts_xapian managesieve sieve

fts = xapian
fts_xapian = partial=2 full=20 verbose=1 attachments=1

fts_autoindex = yes
fts_enforced = yes
fts_autoindex_exclude = \Trash
fts_autoindex_exclude2 = \Drafts

fts_decoder = decode2text

sieve = /data/mail/%d/%n/local.sieve
sieve_after = /data/mail/after.sieve
sieve_before = /data/mail/before.sieve
sieve_dir = /data/mail/%d/%n/sieve
sieve_global_dir = /data/mail
sieve_global_path = /data/mail/global.sieve
}

...

service decode2text {
executable = script /usr/libexec/dovecot/decode2text.sh
user = dovecot
unix_listener decode2text {
mode = 0666
}
}

Thank you

Re: fts_encoder

[Joan Moreau]

a bit more on this, adding log in the decode2text.sh, I can see that 
pdftotext output the right data, but that data is /not/ transmitted to 
the fts plugin for indexing (only the original pdf code is)


On 2021-02-07 17:00, Joan Moreau wrote:


Hello,

I am trying to deal properly with email attachements in fts-xapian 
plugins.


I tried the default script with a PDF file.

The data I receive in the fts plugin part ("xxx_build_more") is the 
original document, no the output of the pdftotext


Is there anything I am missing ?

Here my config:

plugin {
plugin = fts_xapian managesieve sieve

fts = xapian
fts_xapian = partial=2 full=20 verbose=1 attachments=1

fts_autoindex = yes
fts_enforced = yes
fts_autoindex_exclude = \Trash
fts_autoindex_exclude2 = \Drafts

fts_decoder = decode2text

sieve = /data/mail/%d/%n/local.sieve
sieve_after = /data/mail/after.sieve
sieve_before = /data/mail/before.sieve
sieve_dir = /data/mail/%d/%n/sieve
sieve_global_dir = /data/mail
sieve_global_path = /data/mail/global.sieve
}

...

service decode2text {
executable = script /usr/libexec/dovecot/decode2text.sh
user = dovecot
unix_listener decode2text {
mode = 0666
}
}

Thank you

fts_encoder

[Joan Moreau]

Hello,

I am trying to deal properly with email attachements in fts-xapian 
plugins.


I tried the default script with a PDF file.

The data I receive in the fts plugin part ("xxx_build_more") is the 
original document, no the output of the pdftotext


Is there anything I am missing ?

Here my config:

plugin {
plugin = fts_xapian managesieve sieve

fts = xapian
fts_xapian = partial=2 full=20 verbose=1 attachments=1

fts_autoindex = yes
fts_enforced = yes
fts_autoindex_exclude = \Trash
fts_autoindex_exclude2 = \Drafts

fts_decoder = decode2text

sieve = /data/mail/%d/%n/local.sieve
sieve_after = /data/mail/after.sieve
sieve_before = /data/mail/before.sieve
sieve_dir = /data/mail/%d/%n/sieve
sieve_global_dir = /data/mail
sieve_global_path = /data/mail/global.sieve
}

...

service decode2text {
   executable = script /usr/libexec/dovecot/decode2text.sh
   user = dovecot
   unix_listener decode2text {
 mode = 0666
   }
}

Thank you

Re: [VOTE] Set a finite default for max_attachment_size

[Joan Touzet]

HI Donat,

Point of order - when we do 72-hour votes, it's best to not count
weekends in that 72-hours. So, since you started on the 28th at 05:00
UTC, I would have continued the vote until Feb 2 at 05:00 UTC.

That said I am +1 on this too, long overdue.

As to Eric's point, all we need to do is document that the setting can
be lifted and that we've tested "up to XGB" attachments as working in 3.x.

4.x change notes will show that the limit is reduced, and my opinion is
that concomitant with a 4.0 release there will be a new 3.x release that
lowers the defaults to match 4.x. (This may also need the changes
mentioned in Robert's other thread that are necessary to allow 3.x <->
4.x replication, that's still unclear.) For now, we don't need to reduce
down to 10MB or 5MB or whatever it is.

-Joan

On 01/02/2021 14:06, Bessenyei Balázs Donát wrote:
> This vote is now closed as there were three +1s, one +0 and no -1s and
> the 72 hours is up. I'll merge the PR.
> 
> Thanks to all who voted!
> 
> 
> Donat
> 
> 
> On Mon, Feb 1, 2021 at 7:52 PM Eric Avdey  wrote:
>>
>> Ok, fair enough, +0 from me with a note that I'd still prefer to see this 
>> limit aligned with 4.x limits, so users wouldn't have to adjust to this 
>> change twice.
>>
>>
>> Eric
>>
>>> On Feb 1, 2021, at 14:47, Nick Vatamaniuc  wrote:
>>>
>>> I am +1 to lowering as it's better than infinity.
>>>
>>> But I also see Eric's point. I was surprised a while back just like
>>> Eric that I could successfully upload >1GB-sized files.  So why not
>>> 0.5GB or 2GB? I am thinking 2GB was (is?) a common limit on some OSes
>>> and file systems (FAT32) since they use ints for file size and
>>> offsets. Since our attachment won't be saved as is in the file systems
>>> inside a .couch file 2GB may be too high, so 1GB as a limit makes
>>> sense to me.
>>>
>>> -Nick
>>>
>>> On Mon, Feb 1, 2021 at 1:25 PM Paul Davis  
>>> wrote:
>>>>
>>>> +1
>>>>
>>>> Default unlimited seems like an oversight regardless of what we change it 
>>>> to.
>>>>
>>>> On Mon, Feb 1, 2021 at 11:59 AM Eric Avdey  wrote:
>>>>>
>>>>> Maybe I didn't express myself clear enough. Setting some finit default is 
>>>>> not a purpose, it's what you are doing and I'm asking what the reason for 
>>>>> this change. In other words I'm not asking what are you doing, I'm asking 
>>>>> why are you doing this.
>>>>>
>>>>> Introducing a new limit will be a breaking change to anoyone who uploads 
>>>>> attachments larger than that limit, obviously, so "assumed 1G is large 
>>>>> enough" sounds really arbitrary to me without any factual support for 
>>>>> that assumption.
>>>>>
>>>>>
>>>>> Eric
>>>>>
>>>>>
>>>>>> On Feb 1, 2021, at 13:15, Bessenyei Balázs Donát  
>>>>>> wrote:
>>>>>>
>>>>>> The purpose of this vote / PR is to set _some_ finite default. I went
>>>>>> with 1G as I assumed that would not break anyone's production system.
>>>>>> I'd support decreasing that limit over time.
>>>>>>
>>>>>> The vote has been open for 72 hours now, but I believe it still needs
>>>>>> two more +1s to pass.
>>>>>>
>>>>>>
>>>>>> Donat
>>>>>>
>>>>>> On Thu, Jan 28, 2021 at 10:44 PM Eric Avdey  wrote:
>>>>>>>
>>>>>>> This got me curious and I tried to upload Ubuntu image as an 
>>>>>>> attachment. Interestingly CouchDB 3.x accepted first 1.4G of 2.8G file 
>>>>>>> and then returned proper 201 response with a new doc revision, which I 
>>>>>>> certanly didn't expect. Should say, that 1.4G seems suspiciously 
>>>>>>> similar to a normal memory limit for a 32 bit process.
>>>>>>>
>>>>>>> Putting this aside, I agree that uploading large attachments is an 
>>>>>>> anti-pattern and 1G seems excessive, hence my question. I'd expect this 
>>>>>>> number to be based on something and correlating it with a  technical 
>>>>>>> limit in 4.x makes a lot of sense to me.
>>>>>>>
>>>>>>>
>>>>>>> Eric
>>>>>>>
>>>>>>&g

Re: [Evergreen-general] Latest List of Ten Signedoff Bugs

[Joan Kranich]

Thanks Michele!

Joan

On Mon, Feb 1, 2021 at 1:56 PM Morgan, Michele  wrote:

> Thanks to the efforts of the community, four bugs from the last List of
> Ten have been committed to Evergreen!
>
> I've pulled together a new list of signedoff bugs that are ready for the
> final steps of committer review and to be pushed to master for inclusion in
> the next Evergreen releases. Those marked with * are carryovers from the
> last list.
>
> *#1907866 <https://bugs.launchpad.net/evergreen/+bug/1907866> Bootstrap
> OPAC: Adding basket to Existing List has problems
> *#1908766 <https://bugs.launchpad.net/evergreen/+bug/1908766> Bootstrap
> OPAC: Lost ability to have notes in Lists
>
> Many patron and staff users make extensive use of lists and the notes
> functionality in the opac.
>
>
> *#1902265 <https://bugs.launchpad.net/evergreen/+bug/1902265> Bootstrap
> OPAC does not allow patrons to see/update per hold notification preferences
>
> This functionality came to TPAC in 3.5 and needs to be added to the
> Bootstrap OPAC.
>
>
> *#1903594 <https://bugs.launchpad.net/evergreen/+bug/1903594> Bootstrap
> opac: Suspend hold at time of placement not working
>
> Without this, patrons will think they placed a hold to be activated later,
> but find that it gets acted on immediately.
>
>
> *#1908298 <https://bugs.launchpad.net/evergreen/+bug/1908298> Bootstrap
> OPAC: Type filter missing from advanced search
>
> A format filter in the Bootstrap OPAC is sorely missed!
>
> #1895676 <https://bugs.launchpad.net/evergreen/+bug/1895676> Bootstrap
> OPAC: implement enhanced email and printing of records from OPAC
>
> Bootstrap OPAC needs the improved options for printing and email for
> patrons, released in the TPAC for 3.6
>
>
> #1840950 <https://bugs.launchpad.net/evergreen/+bug/1840950> Patron
> expiration date & iPads
>
> Allows staff to more easily create and edit patron records on iPads
>
>
> #1830089 <https://bugs.launchpad.net/evergreen/+bug/1830089> Adjust to
> Zero does not set item status to Lost and Paid
>
> This one's been signedoff for a while, leaves items stuck in Lost status
> when they should have changed to Lost and Paid
>
>
> #1907979 <https://bugs.launchpad.net/evergreen/+bug/1907979> Instructor
> search/browse option does not always display in OPAC
>
> In the Course Materials module, for libraries that choose to use the
> Instructor search, this assures the Instructor option always appears as it
> should.
>
>
> #1890629 <https://bugs.launchpad.net/evergreen/+bug/1890629> Email
> checkout receipts by default? Doesn't Always Display in Patron
> Self-Registration
>
> Libraries are doing a big business in self registration these days, it
> would be helpful to get consistency with this user preference
>
>
> Lastly, here's the list of bugs that have been committed since the last
> list.
>
> #1889128 <https://bugs.launchpad.net/evergreen/+bug/1889128> Angular
> Staff Catalog: Place Another Hold & Multi-Holds
> #1846042 <https://bugs.launchpad.net/evergreen/+bug/1846042> Angular
> admin pages need filters
> #1857351 <https://bugs.launchpad.net/evergreen/+bug/1857351> Angular Form
> Field Order
> #1894131 <https://bugs.launchpad.net/evergreen/+bug/1894131> Angular
> holdings view library setting isn't sticky
>
> Thanks Bill and Jane!
> --
> Michele M. Morgan, Technical Support Analyst
> North of Boston Library Exchange, Danvers Massachusetts
> mmor...@noblenet.org
>
> ___
> Evergreen-general mailing list
> Evergreen-general@list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
>


-- 

Joan Kranich | Library Applications Manager

CW MARS

jkran...@cwmars.org

508-755-3323 x321 or x1 <(508)%20755-3323>

http://www.cwmars.org

Pronouns <https://www.mypronouns.org/what-and-why>: she, her, hers
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

RE: Snmpv3 users details are not deleting from /var/net-snmp/snmpd.conf file

[Joan Landry]

Try to call  update_config(); instead.

From: chandrasekharreddy chinnapareddygari 
Sent: Saturday, December 12, 2020 10:54 PM
To: net-snmp-coders@lists.sourceforge.net; net-snmp-us...@lists.sourceforge.net
Subject: Snmpv3 users details are not deleting from /var/net-snmp/snmpd.conf 
file

External email: [net-snmp-users-boun...@lists.sourceforge.net]

Hi team,
I'm using net-snmp 5.8 version .My requirement is conf files should updtae 
without restarting snmpd .

I'm sending SIGHUP signal to update SNMP data with out restarting snmpd . 
snmpv3 details are not updating .
Please help me how to proceed further.


Thanks,
Chandra.



Get Outlook for 
Android

Please see our privacy statement at 
https://www.adva.com/en/about-us/legal/privacy-statement for details of how 
ADVA processes personal information.
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: [OSList] Poetry on the oslist

[Elwin and Joan via OSList]

 Brilliant Jeff, absolutely brilliant!
You get the prize.
Thank you... I needed that.
eg
On Friday, January 29, 2021, 02:52:18 PM EST, Jeff Aitken via OSList 
 wrote:  
 
 
An open space

By internet

Can serve

During

Emergencies

Fostering

Good conversations

Held in surprising

Intimacy

Just because our

Kind faces

Linger at the screen

Making that

Nearby feeling.

Optimally a

Platform like

Qiqo is a

Resource

Suited

To

Underpin a

Very

Welcoming

Xperience if

You so

deZire.




On Fri, Jan 29, 2021, 10:12 AM Jeff Aitken  wrote:


Hi folks. The warm invite to check the oslist archives led me on a good journey 
last night. Some of the jewels I found were poems, from the days of the "poetry 
celebration and contest" that lived here for a long while. 

Poems of open space! With a convenor naming a poetic "form" to follow for that 
round of celebration. 


Here is one, in the form of three stanzas of haiku.




huge pens and newsprint

like twigs and leaves on the floor:

fall forest clearing.






wall like wide canvas

bare, primed, awaiting fresh strokes

painted by our hearts.






circle of welcome,

like setting an old table

for neighbors and friends.







Here is one in a fun form using an alphabet. It's not about open space, but is 
about writing a poem, kinda. (Without launching a new Celebration formally, i 
invite you to try it...)



And I
Believe you too
Can
Do a poem, and
Even
Fairly
Gracefully – I
Have seen
Innovative
Juxtapositions
Kindly
Line up in
Many
New and
Original
Poems - it’s 
Quite
Reasonable to get
So many words
To line
Up
Very
Willingly
Xcept if you get this far it’s sometimes trouble.






___
OSList mailing list
To post send emails to OSList@lists.openspacetech.org
To unsubscribe send an email to oslist-le...@lists.openspacetech.org
To subscribe or manage your subscription click below:
http://lists.openspacetech.org/listinfo.cgi/oslist-openspacetech.org
Past archives can be viewed here: 
http://www.mail-archive.com/oslist@lists.openspacetech.org  ___
OSList mailing list
To post send emails to OSList@lists.openspacetech.org
To unsubscribe send an email to oslist-le...@lists.openspacetech.org
To subscribe or manage your subscription click below:
http://lists.openspacetech.org/listinfo.cgi/oslist-openspacetech.org
Past archives can be viewed here: 
http://www.mail-archive.com/oslist@lists.openspacetech.org

Re: [OSList] This list serve is antiquated big time

[Elwin and Joan via OSList]

Mark

If it ain't broke don't fix it!!!

eg 

On Thu Jan 28 2021 19:01:23 GMT-0500 (EST), l33t.79--- via OSList 
 wrote:  
 
 if you prefer Facebook groups, then we have one here:
https://www.facebook.com/groups/7189220743/



On Thu, 28 Jan 2021, 09:15 Mark Carmel via OSList, 
 wrote:

It is so hard to follow a thread of thought. When was this platform started? 
When the internet was first invented? Come on folks, let's catch up with a 
workable format.  This is in need of a major upgrade. Thanks for your 
consideration, Mark Carmel___
OSList mailing list
To post send emails to OSList@lists.openspacetech.org
To unsubscribe send an email to oslist-le...@lists.openspacetech.org
To subscribe or manage your subscription click below:
http://lists.openspacetech.org/listinfo.cgi/oslist-openspacetech.org
Past archives can be viewed here: 
http://www.mail-archive.com/oslist@lists.openspacetech.org
___
OSList mailing list
To post send emails to OSList@lists.openspacetech.org
To unsubscribe send an email to oslist-le...@lists.openspacetech.org
To subscribe or manage your subscription click below:
http://lists.openspacetech.org/listinfo.cgi/oslist-openspacetech.org
Past archives can be viewed here: 
http://www.mail-archive.com/oslist@lists.openspacetech.org  ___
OSList mailing list
To post send emails to OSList@lists.openspacetech.org
To unsubscribe send an email to oslist-le...@lists.openspacetech.org
To subscribe or manage your subscription click below:
http://lists.openspacetech.org/listinfo.cgi/oslist-openspacetech.org
Past archives can be viewed here: 
http://www.mail-archive.com/oslist@lists.openspacetech.org

Re: Permisos a usuari per disc dur intern que només te permisos root

[Joan]

Ja ho veig:

4 drwxr-xr-x 2 joan joan 4096 28 gen. 10:04 no_stiky
4 drwsr-sr-x 2 joan joan 4096 28 gen. 10:04 stiky

Però em pregunto si es pot un directori "stiky" (enganxòs) si no és
executable, perquè aquí la "s" la posa en lloc de la "x"... I si no és
un pre-condició, no quedaria clar si el directori és o no enganxós, no?

-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi


El Thu, 28 Jan 2021 10:03:28 +0100
Joan  va escriure:

> El Sat, 22 Jul 2017 18:54:18 +0200
> Narcis Garcia  va escriure:
> 
> > __
> > I'm using this express-made address because personal addresses
> > aren't masked enough at this mail public archive. Public archive
> > administrator should fix this against automated addresses
> > collectors. El 22/07/17 a les 11:55, Joan ha escrit:  
> > > 
> > > 
> > > El Fri, 21 Jul 2017 20:06:15 +0200
> > > Narcis Garcia  va escriure:
> > > 
> > >> Per polir-ho millor, i per si de cas la carpeta la compartiu
> > >> entre vàris usuaris autoritzats, jo faria això en un terminal
> > >> normal:
> > >>
> > >> sudo usermod --append --groups users jordi
> > >> sudo chown -R jordi:users /Dades
> > >> sudo chmod -R o= /Dades
> > > 
> > > Aquesta ordre què fa?
> > 
> > La última, deixa sense cap permís els «other» (altres) usuaris, és a
> > dir, els que no són propietaris com a usuari ni del grup de la
> > carpeta.
> >   
> > > 
> > >> sudo chmod -R ug+rwX /Dades
> > > 
> > > I en aquesta perquè la X està en majúscules?
> > 
> > La «x» en minúscula es refereix al permís d'execució, que inclou
> > tant fitxers com directoris. En majúscula especifica que només
> > afecti als directoris, per a poder-los obrir.
> >   
> > > 
> > >> sudo chmod -R g+s /Dades
> > > 
> > > I el "+s" per a què serveix?
> > 
> > L'atribut «enganxós» (s) és per a què, quan es crei un subdirectori,
> > aquest hereti el mateix grup del directori. D'aquesta manera, en
> > aquest cas, si jordi crea un subdirectori, aquest serà del grup
> > «users» i no pas del grup «jordi». Això facilita una mica la
> > compartició entre usuaris.  
> 
> 
> Osti, això de l'stiky ho trobo molt interessant... Hi quan fas un ls
> -ls queda marcat d'alguna manera, els directoris que tenen l'stiky
> activat? Ara en faré la prova, però m'ha fet gràcia trobar aquest
> missatge de fa 3 anys quan en buscava un altre :-)
> 
> 
> >   
> > > 
> > > (quines birgueries que useu!).
> > > 
> > > Joan Cervan
> > > 
> > >>
> > >> Amb tot això t'hauria d'anar finíssim, i els usuaris que vulguis
> > >> autoritzar només cal que els afegeixis al grup «users» com a la
> > >> primera instrucció.
> > >>
> > >> __
> > >> I'm using this express-made address because personal addresses
> > >> aren't masked enough at this mail public archive. Public archive
> > >> administrator should fix this against automated addresses
> > >> collectors. El 21/07/17 a les 16:29, Jordi Boixader ha escrit:
> > >>  
> > >>> Moltes gràcies als 2, així ho he fet com diu l'Ernest i ja ha
> > >>> funcionat. Espero que al reiniciar ja quedi per defecte.
> > >>>
> > >>> Salut!
> > >>>
> > >>> El dia 21 de juliol de 2017 a les 15:51, Ernest Adrogué
> > >>> mailto:nfdi...@gmail.com>> ha escrit:
> > >>>
> > >>> 2017-07-21, 15:22 (+0200); Jordi Boixader escriu:  
> > >>> > Hola,
> > >>> >
> > >>> > Al instal·lar la debian 9, vaig crear 3 particions la "/",
> > >>> > "/home" i swap. També tinc un altre HD intern al que vaig
> > >>> > anomenat "/Dades".
> > >>> >
> > >>> > El "/Dades" em surt a l'arrel, que ja m'està bé, abans el
> > >>> > tenia a "/mnt/Dades", però quan intento copiar algun arxiu
> > >>> > em diu que només hi ha permisos per a root.
> > >>> >
> > >>> > Amb el tema dels permisos no m'hi aclareixo, he estat
> > >>> > buscant per Google, però em surten moltes opcions
> > >>> > diferents i no se pas quina triar per fer-ho.
> > >>> >
> > >>> > Com ho he de fer per tenir accés total a aquesta partició
> > >>> > amb el meu usuari jordi?  
> > >>>
> > >>> Amb la partició muntada, canvies el propietari i permisos
> > >>> del punt de muntatge, per exemple:
> > >>>
> > >>> chown jordi.jordi /Dades
> > >>> chmod u=rwx,g=rx,o=rx /Dades
> > >>>
> > >>>   
> > >>
> > > 
> > > 
> > > 
> >   
> 
> 
> 



-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi

Re: Permisos a usuari per disc dur intern que només te permisos root

[Joan]

El Sat, 22 Jul 2017 18:54:18 +0200
Narcis Garcia  va escriure:

> __
> I'm using this express-made address because personal addresses aren't
> masked enough at this mail public archive. Public archive
> administrator should fix this against automated addresses collectors.
> El 22/07/17 a les 11:55, Joan ha escrit:
> > 
> > 
> > El Fri, 21 Jul 2017 20:06:15 +0200
> > Narcis Garcia  va escriure:
> >   
> >> Per polir-ho millor, i per si de cas la carpeta la compartiu entre
> >> vàris usuaris autoritzats, jo faria això en un terminal normal:
> >>
> >> sudo usermod --append --groups users jordi
> >> sudo chown -R jordi:users /Dades
> >> sudo chmod -R o= /Dades  
> > 
> > Aquesta ordre què fa?  
> 
> La última, deixa sense cap permís els «other» (altres) usuaris, és a
> dir, els que no són propietaris com a usuari ni del grup de la
> carpeta.
> 
> >   
> >> sudo chmod -R ug+rwX /Dades  
> > 
> > I en aquesta perquè la X està en majúscules?  
> 
> La «x» en minúscula es refereix al permís d'execució, que inclou tant
> fitxers com directoris. En majúscula especifica que només afecti als
> directoris, per a poder-los obrir.
> 
> >   
> >> sudo chmod -R g+s /Dades  
> > 
> > I el "+s" per a què serveix?  
> 
> L'atribut «enganxós» (s) és per a què, quan es crei un subdirectori,
> aquest hereti el mateix grup del directori. D'aquesta manera, en
> aquest cas, si jordi crea un subdirectori, aquest serà del grup
> «users» i no pas del grup «jordi». Això facilita una mica la
> compartició entre usuaris.


Osti, això de l'stiky ho trobo molt interessant... Hi quan fas un ls
-ls queda marcat d'alguna manera, els directoris que tenen l'stiky
activat? Ara en faré la prova, però m'ha fet gràcia trobar aquest
missatge de fa 3 anys quan en buscava un altre :-)


> 
> > 
> > (quines birgueries que useu!).
> > 
> > Joan Cervan
> >   
> >>
> >> Amb tot això t'hauria d'anar finíssim, i els usuaris que vulguis
> >> autoritzar només cal que els afegeixis al grup «users» com a la
> >> primera instrucció.
> >>
> >> __
> >> I'm using this express-made address because personal addresses
> >> aren't masked enough at this mail public archive. Public archive
> >> administrator should fix this against automated addresses
> >> collectors. El 21/07/17 a les 16:29, Jordi Boixader ha escrit:  
> >>> Moltes gràcies als 2, així ho he fet com diu l'Ernest i ja ha
> >>> funcionat. Espero que al reiniciar ja quedi per defecte.
> >>>
> >>> Salut!
> >>>
> >>> El dia 21 de juliol de 2017 a les 15:51, Ernest Adrogué
> >>> mailto:nfdi...@gmail.com>> ha escrit:
> >>>
> >>> 2017-07-21, 15:22 (+0200); Jordi Boixader escriu:
> >>> > Hola,
> >>> >
> >>> > Al instal·lar la debian 9, vaig crear 3 particions la "/",
> >>> > "/home" i swap. També tinc un altre HD intern al que vaig
> >>> > anomenat "/Dades".
> >>> >
> >>> > El "/Dades" em surt a l'arrel, que ja m'està bé, abans el
> >>> > tenia a "/mnt/Dades", però quan intento copiar algun arxiu
> >>> > em diu que només hi ha permisos per a root.
> >>> >
> >>> > Amb el tema dels permisos no m'hi aclareixo, he estat
> >>> > buscant per Google, però em surten moltes opcions diferents
> >>> > i no se pas quina triar per fer-ho.
> >>> >
> >>> > Com ho he de fer per tenir accés total a aquesta partició
> >>> > amb el meu usuari jordi?
> >>>
> >>> Amb la partició muntada, canvies el propietari i permisos del
> >>> punt de muntatge, per exemple:
> >>>
> >>> chown jordi.jordi /Dades
> >>> chmod u=rwx,g=rx,o=rx /Dades
> >>>
> >>> 
> >>  
> > 
> > 
> >   
> 



-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi

[OT] Sector laboral - Ús de Debian/Software Lliure

[Joan Albert]

Bona tarda,

En primer lloc, perdoneu-me si aquest fil no és adient, i espero que
algú pugui comentar-ho si és el cas.

Fa temps que tinc curiositat sobre el sector on
treballem/investiguem/estudiem els integrants d'aquesta llista,
i saber si allà utilitzem o no la nostra estimada distribució,
software lliure en general o no és el cas.

Òbviament, donaré exemple i començaré jo mateix:
Sóc un (mal anomenat) científic de dades i treballo per a una
consultoria de Barcelona. Només dues persones utilitzem sistemes
operatius GNU/Linux perquè som molt tossuts, però la resta no. Sí és
cert que disposem de màquines virtuals CentOS per a temes productius.

El meu ordinador, no cal dir-ho, utilitza Debian (testing) :D
A veure si s'anima algú més a explicar el seu cas.

Salut! 

--
Joan Albert


signature.asc
Description: PGP signature

Cadascú interpreta diferent les paraules FREE, DEBIAN, GNU i LINUX

[Joan Baptista]

escarregar el programa,
de forma FÀCIL, identificant automàticament (com ho fa sourceforge) des de
quin sistema operatiu s'està accedint a la pàgina web del projecte i
oferint-los la versió per aquest sistema operatiu, automàticament.

B) Entre 1984 i 2020 vaig intentar aprendre 9 llenguatges de programació
diferents, i això que no compto com a "llenguatges de programació
diferents" les diferents versions de bastants d'aquests cada llenguatge de
programació que vaig intentar aprendre. En mes del 75% d'aquests casos,
abans que acabés de fer un programa prou decent en algun d'aquests
llenguatges de programació (que en el moment que jo els començava a
aprendre, tenien fama de ser "el millor llenguatge de programació del
moment") ja hi havia algun "listillo" que portava 4 dies enamorat d'un
llenguatge de programació mes nou, que em deia "on vas amb aquest
llenguatge de programació prehistòric? el que jo utilitzo es el que hauries
d'aprendre, que es realment el millor !" i per tant, comentaris similars a
aquests, us podeu imaginar quina gracia em fan i com em recorden a totes
aquelles persones que després va resultar que, quan va sortir un altre
llenguatge de programació mes recent, ja no van ser capaçes ni de intentar
aprendre un 2on llenguatge de programació, fins i tot quan ja fa mooolt
temps (des de 1986 concretament) que se el que signifiquen les inicials
B.A.S.I.C. a les que fa referència el llenguatge de programació GamBAS.

C) Es molt fàcil veure i destacar els errors dels altres: veure els errors
propis i/o ajudar a corregir errors (propis i/o d'altres) no només NO es
fàcil, sinó que només en son capasses de fer-ho les persones que a mes de
tenir grans capacitats intel·lectuals, son capaces d'utilitzar-les com cal.

Hi ha milions de persones en aquest planeta que es creuen genis, però només
hi ha uns pocs milers de veritables genis en tot el planeta ... i que
parlin català, i que siguin realment genis de la informàtica i les
telecomunicacions ... possiblement ... menys de 100.

Per sort, al menys un d'aquest genis catalans (es reconeixen per la seva
humilitat, a mes de per als seus coneixements i èxits) forma part del equip
de desenvolupadors de DEBIAN GNU/LINUX.


Joan Baptista
joanbapti...@gmail.com
Tel. 665 245 561

Re: [DISCUSS] Removing erlang 19 support

[Joan Touzet]

Hey Russell, have no fear. I'm happy to say your 2014 essay is no longer 
an issue :)


We've been shipping our couchdb binaries with Erlang Solutions' 
pre-built Erlang for a very long time now, at least since 2.1.0 and 
possibly since 2.0.0 released. When they don't provide it, we build 
using kerl. Whatever version of Erlang comes with the OS doesn't matter 
at all. In fact, we ship the exact same version of Erlang across every 
OS/arch we support today.


The only limitation is whether or not the specific version of Erlang 
will *compile* on that specific OS/arch combo with the features we need 
- this usually comes down to the version of openssl shipped by the 
distro being compatible with Erlang's ssl module. There was a hiccup in 
the transition fom 0.9.8 to 1.0.x, and again from 1.0.x to 1.1.x, but 
that's all well in the past now.


Cheers,
Joan "DRY" Touzet

On 2021-01-25 3:40 p.m., Russell Branca wrote:

I'm also +1 to removing Erlang 19.

I wanted to reiterate what Newson said about Erlang Solutions providing
Erlang packaging, and I think we should more strongly lean on options like
this rather than being dependent on the OS distros Erlang versions. Many
years ago I wrote about the nuances with Erlang versions and CouchDB on the
R14/R15/R16 lines [1], and it's worth noting that multiple Debian versions
shipped versions of Erlang that were fundamentally broken for use with
CouchDB. I think we even blocked a number of those versions in the
rebar.config allowed versions.

I don't know how much of an issue that is today, but there's certainly
precedent for distro shipped Erlang versions not being an option.


-Russell



[1]
https://chewbranca.com/doc/trunk/archive/github/2014-05-07-on-the-viability-of-erlang-releases-and-couchdb.md



On Mon, Jan 25, 2021 at 5:07 AM Bessenyei Balázs Donát 
wrote:


Thank you all for the input!

I'll remove erlang 19 for `couchdb-config` and we'll be able to refer
to this thread when we have to remove it anywhere else.


Donat

On Sat, Jan 23, 2021 at 10:09 PM Adam Kocoloski 
wrote:


Ah, good research there Joan. +1 to Donat’s suggestion to drop support

for 19 from me.


Adam


On Jan 22, 2021, at 4:49 PM, Joan Touzet  wrote:

On 2021-01-22 4:37 p.m., Robert Newson wrote:

Iteresting. I’m actually surprised at the inversion here (that

CouchDB is dependent on  IBM to confirm CouchDB’s stability). I’ve always
agonised over even the perception that IBM/Cloudant is calling the shots. I
appreciate the reassurance that running at scale provides, of course, I
just don’t think it can be our official position.


It's a tough one. I was pretty aggressive on CouchDB running the very

latest until the scheduler collapse problem surfaced. After that, there was
another problem (I can't recall) that was pretty serious too. I took a
wait-and-see attitude at that point, and after I didn't see IBM move
forward to a newer release, didn't move forward ourselves. Looks like we
ended up in deadlock!


However! See your own comments on this:

https://github.com/apache/couchdb/issues/3115#issuecomment-729031967

I knew there was something at the back of my head on this. Guess we're

both getting old ;)



On the core point of the thread, it seems there’s no barrier to

dropping Erlang 19 support, so I think we can go to a VOTE thread, perhaps
best to wait till Monday for others to chime in on this discussion though.


More important is that we already committed changes on the main repo

re: Erlang 19 about 14 months ago by Paul:




https://github.com/apache/couchdb/commit/3594f2f1fc16903c1c383ebaf205d31c9c17fb3a


I think that makes Donat's request pretty straightforward.


I also think that IBM Cloudant’s chosen Erlang release is in part

influenced by CouchDB’s lack of support for later versions and requirement
of compatible with older releases, which now appears illusory.


If we're ready to move to 21 or 22 as a default, we're ready. Let's

hope the serious issues in 21/22 are at least mitigated. I'm happy to make
the 3.3 release (or whatever is next) use the very latest version of 21 or
22 from GitHub, subject to community recommendations and encouragement. 23
is still a WIP: https://github.com/apache/couchdb/issues/3115


-Jon


B.

On 22 Jan 2021, at 21:19, Joan Touzet  wrote:

On 22/01/2021 15:48, Robert Newson wrote:

I’m +1 on dropping Erlang 19 support. Erlang is now on major

release 23.


No problem here.


I’d further advocate a general policy of supporting only the most

recent 2 or 3 major releases of Erlang/OTP.


The main (I think only?) reason to keep compatibility so far back

is because of the versions supported by some OS’es. I don’t feel that is a
strong reason given the couchdb install, in common with Erlang-based
projects, is self-contained. The existence of Erlang Solutions packages for
all common platforms is also a factor.


That hasn't been the case for at least 2 years, if not longer.

As the release engineer, I've been focused on

Re: Algú vol col·laborar en aquest projecte?

[Joan]

No, perdona Leopold, em vaig descuidar un NO que hauria segut menys
ambigu:

"El contrari tampoc ho seria, però considerar que el missatge de
Leopold peca de mala educació, agressivitat, etc. és rasgar-se els
vestits i, com pots comprovar, en som uns quants que NO ho veiem
així ;-) "

-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi


El Thu, 21 Jan 2021 12:38:35 +0100
Leopold Palomo-Avellaneda  va escriure:

> Joan,
> 
> només un aclariment:
> 
> El 21/1/21 a les 12:30, Joan ha escrit:
> [...]
> 
> > El contrari tampoc ho seria, però considerar que el missatge de
> > Leopold peca de mala educació, agressivitat, etc. és rasgar-se els
> > vestits i, com pots comprovar, en som uns quants que ho veiem
> > així ;-)  
> 
> Consideres que el meu missatge peca de mala educació, agressivitat,
> etc ?
> 
> És que no em queda clar amb la segona frase.
> 
> Leopold
> 



-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi

Re: [DISCUSS] Removing erlang 19 support

[Joan Touzet]

On 2021-01-22 4:37 p.m., Robert Newson wrote:

Iteresting. I’m actually surprised at the inversion here (that CouchDB is 
dependent on  IBM to confirm CouchDB’s stability). I’ve always agonised over 
even the perception that IBM/Cloudant is calling the shots. I appreciate the 
reassurance that running at scale provides, of course, I just don’t think it 
can be our official position.


It's a tough one. I was pretty aggressive on CouchDB running the very 
latest until the scheduler collapse problem surfaced. After that, there 
was another problem (I can't recall) that was pretty serious too. I took 
a wait-and-see attitude at that point, and after I didn't see IBM move 
forward to a newer release, didn't move forward ourselves. Looks like we 
ended up in deadlock!


However! See your own comments on this:

https://github.com/apache/couchdb/issues/3115#issuecomment-729031967

I knew there was something at the back of my head on this. Guess we're 
both getting old ;)



On the core point of the thread, it seems there’s no barrier to dropping Erlang 
19 support, so I think we can go to a VOTE thread, perhaps best to wait till 
Monday for others to chime in on this discussion though.


More important is that we already committed changes on the main repo re: 
Erlang 19 about 14 months ago by Paul:


https://github.com/apache/couchdb/commit/3594f2f1fc16903c1c383ebaf205d31c9c17fb3a

I think that makes Donat's request pretty straightforward.


I also think that IBM Cloudant’s chosen Erlang release is in part influenced by 
CouchDB’s lack of support for later versions and requirement of compatible with 
older releases, which now appears illusory.


If we're ready to move to 21 or 22 as a default, we're ready. Let's hope 
the serious issues in 21/22 are at least mitigated. I'm happy to make 
the 3.3 release (or whatever is next) use the very latest version of 21 
or 22 from GitHub, subject to community recommendations and 
encouragement. 23 is still a WIP: 
https://github.com/apache/couchdb/issues/3115


-Jon


B.



On 22 Jan 2021, at 21:19, Joan Touzet  wrote:

On 22/01/2021 15:48, Robert Newson wrote:

I’m +1 on dropping Erlang 19 support. Erlang is now on major release 23.


No problem here.


I’d further advocate a general policy of supporting only the most recent 2 or 3 
major releases of Erlang/OTP.

The main (I think only?) reason to keep compatibility so far back is because of 
the versions supported by some OS’es. I don’t feel that is a strong reason 
given the couchdb install, in common with Erlang-based projects, is 
self-contained. The existence of Erlang Solutions packages for all common 
platforms is also a factor.


That hasn't been the case for at least 2 years, if not longer.

As the release engineer, I've been focused on stability for everyone.
This is largely driven by knowing that IBM/Cloudant largely run CouchDB
on 20.x at scale. Standing on the shoulders of giants, our releases run
the latest 20.x release at the time of binary generation.

A few times recently issues cropped up in 21 and 22 that we didn't
encounter in our user base because, at scale, we are deployed on
20.3.8.something. Some of these issues were non-trivial. (I'm off today,
so I don't have the time to dig into the specifics until Monday.)

So my $0.02 is that: if IBM/Cloudant is ready to move to something newer
at scale, I'm ready to release binaries on a newer Erlang by default.

The alternative (running newer Erlangs in the binary distributions than
IBM/Cloudant run in production) could possibly be perceived as treating
our open source customers as guinea pigs. I'd rather not risk that
perception, but am willing to be convinced otherwise.

-Joan



B.


On 22 Jan 2021, at 19:54, Bessenyei Balázs Donát  wrote:

Hi All,

CI for https://github.com/apache/couchdb-config appears to be broken.
I wanted to fix it in
https://github.com/apache/couchdb-config/pull/34/files , but I'm
getting issues with erlang 19. Are we okay with dropping 19 support
there?

On a different note: are we okay with dropping erlang 19 support
overall in couch project(s)?


Thank you,
Donat

Re: [DISCUSS] Removing erlang 19 support

[Joan Touzet]

On 22/01/2021 15:48, Robert Newson wrote:
> I’m +1 on dropping Erlang 19 support. Erlang is now on major release 23.

No problem here.

> I’d further advocate a general policy of supporting only the most recent 2 or 
> 3 major releases of Erlang/OTP.
>
> The main (I think only?) reason to keep compatibility so far back is because 
> of the versions supported by some OS’es. I don’t feel that is a strong reason 
> given the couchdb install, in common with Erlang-based projects, is 
> self-contained. The existence of Erlang Solutions packages for all common 
> platforms is also a factor.

That hasn't been the case for at least 2 years, if not longer.

As the release engineer, I've been focused on stability for everyone.
This is largely driven by knowing that IBM/Cloudant largely run CouchDB
on 20.x at scale. Standing on the shoulders of giants, our releases run
the latest 20.x release at the time of binary generation.

A few times recently issues cropped up in 21 and 22 that we didn't
encounter in our user base because, at scale, we are deployed on
20.3.8.something. Some of these issues were non-trivial. (I'm off today,
so I don't have the time to dig into the specifics until Monday.)

So my $0.02 is that: if IBM/Cloudant is ready to move to something newer
at scale, I'm ready to release binaries on a newer Erlang by default.

The alternative (running newer Erlangs in the binary distributions than
IBM/Cloudant run in production) could possibly be perceived as treating
our open source customers as guinea pigs. I'd rather not risk that
perception, but am willing to be convinced otherwise.

-Joan

> 
> B.
> 
>> On 22 Jan 2021, at 19:54, Bessenyei Balázs Donát  wrote:
>>
>> Hi All,
>>
>> CI for https://github.com/apache/couchdb-config appears to be broken.
>> I wanted to fix it in
>> https://github.com/apache/couchdb-config/pull/34/files , but I'm
>> getting issues with erlang 19. Are we okay with dropping 19 support
>> there?
>>
>> On a different note: are we okay with dropping erlang 19 support
>> overall in couch project(s)?
>>
>>
>> Thank you,
>> Donat
> 

Re: Algú vol col·laborar en aquest projecte?

[Joan]

Jo entenc el que vols dir, Àlex. I entenc el positiu que hi ha en
l'esforç de no vigilar en absolut les formes o el no tenir en compte
que una valoració descarnada, que per alguns no ens suposa un problema,
per altres els pot suposar un trauma...

Però com tot en aquesta vida, no hi ha blanc i negres, i cal trobar un
punt d'equilibri (mòbil/revisable/evolucionable). 

El teu punt de vista, Àlex, ens porta a una comunitat puritana, poruga,
d'autocensura i, a la pràctica, menys operativa i útil.

Aquest missatge és un exemple: en Joan B. demana ajuda/col·laboració i
l'aportació més útil, per no dir la única, que a sobre és realment un
luxe (en Leopold demostra molt criteri i encert en els seus
comentaris, per molt que en plan purità podríem dir que tot és
opinable, que igual en Joan B. no demanava que se li destaquessin els
defectes que, sense hipocresia, TOTHOM en aquesta llista veu en el seu
sot. / plantejament).

Llavors, en Joan B., QUE HA DEMANAT AJUT, te una sèrie de suggeriments
que li seran útils, però que en un món poruc d'autocensura i
puritanisme no li haguessin arribat. I pot fer el que més
l'interessaria objectivament, continuar la conversa, demanar
aclariments, donant arguments contraris en els punts en què ho
consideri, etc. i, a la fi, millorar el seu projecte (o descartar-lo si
pensa que no va per bon camí).

L'altra opció que te és ofendre's molt del to i continuar rossegant ell
sol el seu projecte, sense millores i, per tant, en la mateixa via
morta en la que està.

De vegades la música que sona bé (el que vens a dir, Àlex) no és
saludable, ni convenient, ni útil.

El contrari tampoc ho seria, però considerar que el missatge de Leopold
peca de mala educació, agressivitat, etc. és rasgar-se els vestits i,
com pots comprovar, en som uns quants que ho veiem així ;-)

De totes formes, he trobat aquest debat, i tota la info i reflexions
que has fet i propiciat, Àlex, molt interessants... I, de fet, penso
que ja va bé que hi hagi gent que tibi en la direcció a on tu tibes...
Però no vull caure en un silenci per correcció política que seria
hipòcrita per part meva.

Salutacions,

-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi


El Thu, 21 Jan 2021 10:07:04 +0100
Alex Muntada  va escriure:

> Hola Ernest
> 
> > Potser ho he interpretat malament, però jo diria que ha demanat
> > ajuda perquè veu que el programa no té gaires usuaris ni troba
> > gent que es vulgui involucrar en el projecte. Quin altre
> > plantejament hi pot haver, per tal d'ajudar a resoldre aquesta
> > situació, que no sigui analitzar precisament els motius que
> > provoquen aquesta falta d'interès?  
> 
> Entenc el que vols dir però tinc la sensació que abans de fer una
> valoració pública del seu projecte jo li hauria preguntat si hi
> estava interessat o li hauria enviat en privat directament. Potser
> només volia que li passéssim contactes de gent que treballa amb
> Gambas, o senzillament que provéssim el programa per veure si
> funciona bé en el nostre entorn.
> 
> > O sigui, entenc que tu t'abstindries de comentar cap defecte o
> > mancança del programa que pugui ser atribuïble al seu autor,
> > per por que aquest se senti ofès.  
> 
> Jo no he dit això. El que dic és que no el faria responsable del
> defecte. No serveix de res assenyalar amb el dit.
> 
> > Per exemple, no qüestionaries l'elecció del llenguatge de
> > programació, o el fet de no seguir les pràctiques habituals
> > en l'àmbit dels projectes de programari lliure, tot i ser saber
> > que això redueix enormement les probabilitats que altres
> > persones vulguin participar en el projecte.  
> 
> No d'entrada sense tenir més context i conèixer millor la persona
> amb qui estic parlant. Primer intentaria entendre per què ha pres
> les decisions que ha pres i quina ha estat la seva experiència.
> D'aquesta manera podria valorar millor en quin moment introduir
> les bones pràctiques.
> 
> > No trobo cap regla que parli de diversitat. L'únic que he trobat
> > és una declaració de diversitat [1] que diu que el projecte està
> > obert a les contribucions de gent de qualsevol àmbit. Pel que fa
> > al codi de conducta aplicable a les llistes [2], diu que no
> > utilitzem llenguatge malsonant i que intentem no fer "flames".  
> 
> El codi de conducta de les llistes[2] enllaça al codi de conducta
> general[3], que enllaça a la declaració de diversitat[1] a Debian.
> La declaració es va aprovar mitjançant una resolució general[4]
> l'any 2012.
> 
>  [1] https://www.debian.org/intro/diversity
>  [2] ht

Re: Algú vol col·laborar en aquest projecte?

[Joan]

Jo estava a punt de dir que estava d'acord amb l'opinió d el'Ernest
sobre el missatge del Leopold, però llegint el teu missatge, Àlex,
entenc que la direcció correcta és la de no pressuposar la pell dura
sinó forçar-nos a ser amables...

També vull posar en valor, però, malgrat la millora que comenteu sobre
la positivitat, la feina del Leopold, que de fet és qui ha fet uns
suggeriments més útils per en Baptista, si no te en compte les
asprors del missatge. Jo, que no he fet l'esforç de mirar ni el codi
d'en Baptista (no sóc programador) entenc que el que diu en Leopold va
en la bona direcció... Però és només un suggeriment, es clar...

-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi


El Tue, 19 Jan 2021 09:14:51 +0100
Alex Muntada  va escriure:

> Hola Ernest
> 
> > Doncs a mi m'ha semblat una resposta molt adequada i
> > respectuosa.  
> 
> Evidentment ets ben lliure de pensar-ho i de dir-ho, però això
> no farà que ho sigui. Cadascú de nosaltres té un context concret
> que ens fa interpretar els missatges de forma diferent.
> 
> > Concretament, què és el que trobes inadequat de la seva
> > resposta? Sembla que dius que li falta "empatia" i
> > "comprensió", però jo no veig ni una cosa ni l'altra.  
> 
> Per exemple, dir que són errors greus haver triat sourceforge
> i visual basic com a llenguatge de programació; dir que el codi
> està mal cuidat i que el formulari principal és infumable.
> 
> L'empatia es basa en posar-se en el lloc i el context de la
> persona a qui va dirigit el missatge. En valorar quin pot ser
> el seu estat d'ànim (el missatge d'en Joan donava algunes pistes
> en aquest sentit) i ajustar el to per fer-lo més adient. També
> es basa en no jutjar la feina (tenint en compte que tothom fa el
> que pot amb els coneixements i els recursos que té) i ajustar-se
> al que s'està demanant.
> 
> En Joan no ha demanat que es critiqui la seva feina ni que es
> qüestionin les seves decisions. Demana ajuda per millorar-la,
> que no és ben bé el mateix.
> 
> Per exemple, quan he provat el programa, al formulari principal
> se solapen alguns dels camps i el text blanc en fons gris amb
> l'enllaç de la imatge ISO té poc contrast. Dient-ho així, a banda
> de ser més concret i donar pistes de com resoldre-ho, no estic
> jutjant la feina d'en Joan.
> 
> > I si algú deixa de demanar l'opinió sobre els seus projectes
> > per por de rebre una opinió negativa, personalment veig molt
> > més preocupant el fet que no sàpiguen afrontar les crítiques
> > i les opinions negatives, que el fet que deixin de preguntar.  
> 
> Això d'haver de tenir la pell dura era un fet acceptat fa temps
> en moltes comunitats i justificava moltes faltes de respecte que
> allunyava força persones d'aquestes comunitats, fent-les menys
> diverses i més endogàmiques.
> 
> Avui en dia ja no és així. La majoria de comunitats no defensen
> que calgui tenir la pell dura, ben al contrari, demanen tenir
> sensibilitat i comprensió per a la gran diversitat que persones
> que hi ha, fins i tot a costa de l'excel·lència tècnica que
> tinguin les persones que defensen tenir la pell dura.
> 
> També passa a la feina: hi ha companys que són més receptius a
> rebre feedback de tot tipus i ho diuen explícitament. Aleshores
> jo els dono *els dos tipus* de feedback, positiu i negatiu,
> provant de no jutjar i aportant contraexemples o propostes de
> millora concretes. Altres companys són menys receptius i m'estic
> de fer-los alguns comentaris, procuro centrar-me en les parts
> positives i celebrar-les per generar la confiança suficient
> perquè més endavant també puguem comentar les negatives.
> 
> Us asseguro que donar feedback en positiu és més gratificant per
> a tothom, tant per qui el dóna com per qui el rep.
> 
> Salut,
> Alex
> 
> --
>   ⢀⣴⠾⠻⢶⣦⠀
>   ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
>   ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
>   ⠈⠳⣄
> 



-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi

Re: [OT] Feedback (era Re: Algú vol col·laborar en aquest projecte?)

[Joan]

Retroalimentació?

> >
> > Per cert, com es tradueix feedbck al català?
> >
> >  

Pd.: respecte al teu comentari, Adrià, de ma esquerra, motivació
d'equips, etc.: molt d'acord. És un àmbit en el que jo mateix he de
millorar molt, però trobo que paga la pena anar en aquesta línia i no la
contrària, per començar, fent-ne proselitisme, etc.


-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi

Re: [OT] Feedback (era Re: Algú vol col·laborar en aquest projecte?)

[Joan Baptista]

Com deia Jack el destripador : "Anem per parts" ;-)

1- Gràcies a totes les persones que heu llegit el meu "correu-rotllo" sobre
el primer "pogramita" que faig per Linux, amb Gambas 3.x

2- No era la meva intenció crear tanta controversia, i tampoc es el
objectiu de Tria Sistema Operatiu <https://tria-s-o-1-2.sourceforge.io>

3- Per si la meva opinió (basada en la meva experiència en aquests temes)
li pot servir a algú en totes les empreses que he treballat (mes de 20,
tant en tasques relacionades amb informàtica i telecomunicacions com en
altres tasques) a l'hora de fer-li una crítica negativa a algú (quan és
necessari perquè es pugui arribar al objectiu desitjat i no per aparentar
saber mes o aconseguir reconeixement a l'empresa) sempre és millor fer-ho
en privat que en public, ja que d'aquesta manera s'humilia menys a la
persona que ha de rebre la crítica, a mes de que aquesta persona té mes
possibilitats d'explicar BE perquè ho ha fet d'una manera i no d'una altra
i fins i tot existeix la possibilitat remota que descobrim que el problema
no era aquella persona, sinó que el que ha passat es que altres persones
del mateix departament o altres de la mateixa empresa han deixat de fer el
que havien de fer i/o fan malament la seva feina i resulta que el teòric
"infractor" porta temps saturat intentant fer la seva feina a la vegada que
fent/corregint la dels altres. Per tant, segons quins missatges, serien
molt mes útils a l'adreça e-mail privada enlloc de a la llista de correu.

4- Sóc conscient (com ja vaig dir) que a dia d'avui encara sóc un
programador mediocre de Visual Basic i bastant dolent (tirant a terrible i
penós) de Gambas 3.12.x i Gambas 3.14.x però en els 32 anys que vaig viure
a un "poblet" anomenat Barcelona (1982-2014) vaig tenir la gran sort de
treballar amb un munt de programadors MOLT BONS en diferents llenguatges de
programació (però no amb Gambas ... que jo sapigués) i van ser molt pocs
els genis que van tenir la bondat de compartir el seu coneixement amb mi i
la major part d'ells es limitaven a utilitzar la seva inteligencia (poca o
molta) per escalar dins l'empresa, encara que fos a costa d'amagar el que
feien malament i destacar el que feien bé, atribuint-se mèrits que no els
hi corresponen, per tant, agraeixo especialment al Sr. Alex Muntada (espero
que no li molesti el tracte de vostè) la seva crìtica constructiva, ja que
es la que mes m'està ajudant (tècnica i emocionalment) últimament, doncs
des del setembre de 2014 que visc a Salou, i fins i tot havent fet MOLTS
esforços en aquests últims 5 anys per contactar al Camp de Tarragona amb
gent que estimi *compartir *coneixement en informàtica i telecomunicacions,
en aquest sentit, sento que visc en una illa deserta i si no fos per
correus com els que escriu el GRAN Alex Muntada, ara mateix ja estaria un
altre cop dedicant mes temps a buscar cracks de M$ Win, VB.net, Office 365
... i merdes per l'estil, enlloc de tornar a esforçar-me en:

A) buscar ajuda / suport ... *de qui sigui*: encara que visqui al Japó,
només parla un dialecte del japonès que només coneixen 4 persones al mon i
no sàpiga ni la diferència entre apagar i reiniciar.

B) seguir aprenent Linux (preferentment Debian GNU/Linux o distribucions
que jo anomeno ".deb") i programació en Gambas

C) seguir esforçant-me per compartir coneixement


Per últim ... intentant posar una mica d'humor i per treure-li ferro a
tanta controversia (sense ànim d'ofendre ningú) per a mi ... en català ...
feedbck ... jo ho escric "feedback" com ho has posat tu en el "subject"
(assumpte). Però si resulta que li has d'escriure a algú que té odi i / o
pànic al idioma anglès ... doncs jo posaria "comentari(s) de seguiment" o
"opinió personal sobre la tasca/feina realitzada" ... i és per això que a
xerrameques com jo, que ens enrollem mes que les persianes, paraules com
"feedback" o "free" o "feelings" ens ajuden i agraden, ja que en anglès,
escrivint molt poc, es pot dir MOLT.


(bu)fff :-)

Joan Baptista
joanbapti...@gmail.com
Tel. 665 245 561


Missatge de Adrià  del dia dt., 19 de gen. 2021 a les 23:41:

> Hola a tothom,
>
> no volia escriure perquè ja ho he fet massa últimament, però aquí hi
> sóc de nou; ja em fareu callar si de cas.
>
> No pretenc erigir-me com a moderador ni donar lliçons de res, perquè
> ni em correspon, ni sóc la persona adient ni tinc coneixements per
> fer-ho. Però voldria compartir quatre coses que he anat aprenent i
> posant en pràctica (o intentant-ho) en els últims temps.
>
> A l'empresa on treballo, pel fet de tenir persones provinents de
> diverses cultures, es dediquen hores a donar, rebre i fomentar el
> feedbck i donar-lo d'una forma responsable i efectiva.
> I dic jo que, si una empresa dedica recursos a aquesta qüestió, vull
> pensar que és perquè no és tr

RE: snmpd.conf security

[Joan Landry]

I switched over to use /var/net-snmp/snmpd.conf and I call update_config but 
the passwords do not get changed to localized keys in the file - the v3 
credentials do work correctly.

Can you please tell me what triggers the agent to change the createUser line in 
the snmpd.conf file to remove the passwords - when a new v3 user is added - 
that is not occurring when I call update_config();

Thanks,
Joan





-Original Message-
From: Wes Hardaker 
Sent: Tuesday, January 5, 2021 3:40 PM
To: Joan Landry 
Cc: net-snmp-users@lists.sourceforge.net
Subject: Re: snmpd.conf security

External email: [harda...@users.sourceforge.net]

..
Joan Landry  writes:

> Would like to know if there is a way to make snmpd.conf file more
> secure - as currently it shows the password for a usm user.
> createUser v3user MD5 abcdefghij DES abcdefghij trapsess -r 10 -t 3 -l
> authPriv -u v3user -a MD5 -A abcdefghij -x DES -X abcdefghij
> 10.11.12.98

Per the documentation, a createUser line should *only* go into the persistent 
file (/var/net-snmp/snmpd.conf) and is replaced by the agent with a usmUser 
line after startup.  The usmUser line is also sensitive, however, as it 
contains a private key that is at least localized to just that agent 
fortunately.  That file is written by the process owner and should only be read 
by the process owner (typically root), and is the best that can be achieved 
given the need by the protocol to store localized keys.
--
Wes Hardaker
USC/ISI
Please see our privacy statement at 
https://www.adva.com/en/about-us/legal/privacy-statement for details of how 
ADVA processes personal information.


___
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

Re: Algú vol col·laborar en aquest projecte?

[Joan Lledó]

El 18 de gener de 2021 16:36:35 CET, "Ernest Adrogué"  ha 
escrit:
>Doncs a mi m'ha semblat una resposta molt adequada i respectuosa. 

A mi sí que m'ha semblat agressiva, si jo haguera rebut una resposta així quan 
vaig començar a programar potser ho hauria deixat.

-- 
Enviat des d'/e/ Mail.

Re: [rsyslog] errors from omprog script

[Joan Sala via rsyslog]

Normally you should test your script independently before integrating it
with rsyslog, it's far easier. Anyway, the output setting will also capture
these kind of errors.

On Sat, Jan 16, 2021, 04:18 Fourhundred Thecat via rsyslog <
rsyslog@lists.adiscon.com> wrote:

>  > On 2021-01-15 19:57, John Chivian wrote:
> > The python script should trap its own stderr (and/or stdout) and write
> it to a separate file.
>
> but what if there is syntax error in my script?
> Where can I see this error?
>
> thanks,
> ___
> rsyslog mailing list
> https://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
> What's up with rsyslog? Follow https://twitter.com/rgerhards
> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad
> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you
> DON'T LIKE THAT.
>
___
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of 
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE 
THAT.

Re: [DISCUSS] Replicator scheduler improvement

[Joan Touzet]

but could also starve lower priority jobs. I
> was thinking when we have a high/_replicator:99 db which is fed newer
> jobs continuously, and the low/_replicator:1 which never gets a chance
> to run if its share gets rounded down to 0. I think one way to avoid
> that would be to ensure we pick at least one job from each db, and
> then apply the proportional shares, or just make it round down 1 as a
> minimum...

I would consider that user error in configuration, which I guess is
similar to the corner case in your proposal of having >max_jobs
replicator DBs.

But yeah, min(1, ) solves that problem
nicely too.

> The paper and your proposal presents an interesting way of
> "materializing" the proportional shares as explicit quantity, and the
> current and my scheme don't have that part (there is no
> "scheduler_share" variable and we just pick the jobs in the order of
> start time).  But I like the idea and it's worth giving it a try. It
> might have to be one of those things, that once we start playing with
> the code, some things might become more obvious and easy to do and
> some too complicated.

Sure, let's try it!

> Thank you, Joan, for the great suggestions and for taking a look!

My pleasure!

If you need a use case that is hard to reason about, consider a
resource-constrained cluster (where # of replications vastly outstrips
resources avialable) and you need to ensure fairness across a very large
number of continuous and one-shot replications. Within these the
one-shot are considered higher priority, but they should not completely
drown out the continuous ones.

I can give more detail on the example if it sounds interesting to you -
this was a client system I worked on for a while (after it was too late
to improve the design) and we never were able to get CouchDB's
replication scheduler to do the right thing. Everything got replaced by
an external scheduler that knew what max_jobs was, and did everything as
one-shot replications.

-Joan

Re: [rsyslog] errors from omprog script

[Joan Sala via rsyslog]

You can use the 'output' setting of the omprog action (see details in the
reference doc). Or, you can make your program write its own log files.


On Fri, Jan 15, 2021, 19:04 Fourhundred Thecat via rsyslog <
rsyslog@lists.adiscon.com> wrote:

> Hello
>
> I am using omprog, to send logs to my script:
>
>   mail.*   action(type="omprog" binary="/usr/bin/blacklist.py ... )
>
> If my script generates errors, where can I see these errors? I looked in
> my main syslog log file, but there is nothing.
>
> I can run my script from commandline, and see the error, but not when it
> is run by syslog.
>
> thanks,
>
>
> ___
> rsyslog mailing list
> https://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
> What's up with rsyslog? Follow https://twitter.com/rgerhards
> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad
> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you
> DON'T LIKE THAT.
>
___
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of 
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE 
THAT.

Re: [ANNOUNCE] Bessenyei Balázs Donát elected as CouchDB committer

[Joan Touzet]

Cheers Donat - thanks for the info! And welcome again.

-Joan

On 2021-01-14 4:26 p.m., Bessenyei Balázs Donát wrote:

Dear All,

Thank you for the invitation and the welcome! It's a great honour.

@Joan: my username is bessbd where I can pick and it isn't already in
use. People usually call me Donat.


Donat


On Thu, Jan 14, 2021 at 10:09 PM Nick Vatamaniuc  wrote:


Congrats Donat and welcome!

-Nick


On Thu, Jan 14, 2021 at 3:55 PM Joan Touzet  wrote:


Congratulations Bessenyei! Do you have a nickname (other than bessbd)?

-Joan

On 2021-01-14 3:48 p.m., Robert Newson wrote:

Dear community,

I am pleased to announce that the CouchDB Project Management Committee has 
elected Bessenyei Balázs Donát as a CouchDB committer.

Apache ID: bessbd

Committers are given a binding vote in certain project decisions, as well as 
write access to public project infrastructure.

This election was made in recognition of Donát's commitment to the project. We 
mean this in the sense of being loyal to the project and its interests.

Please join me in extending a warm welcome to Donát!

On behalf of the CouchDB PMC,

Robert Newson

Re: [DISCUSS] Replicator scheduler improvement

[Joan Touzet]

On 2021-01-12 12:55 p.m., Nick Vatamaniuc wrote:

Hello everyone


Hi (Dr.) Nick! ;)


I wanted to see what we thought about adding a scheduling improvement
to the replicator. Specifically adding round-robin fairness amongst
different _replicator dbs


We've needed some sort of priority system for a while -- critically, in
some cases, our failure to offer something has forced my hand into
recommending use of external replication scheduling techniques. I'd
never thought of using multiple databases as a way of handling this
problem, though.

Currently, the scheduler runs all the jobs in the system fairly. It 
does it by using the jobs' "last started" timestamp to select which 
jobs to stop and start next. So each scheduling cycle, the jobs which

ran the longest (have the lowest start time) get stopped, then, from
the list of pending jobs we also pick those with the lowest start
times (since they waited the longest) to run next.


There is also some difference between continuous and one-shot
replication jobs, isn't there? I seem to recall one-shot jobs get
priority over continuous ones.

However, this algorithm can be unfair among replication jobs from 
different _replicator dbs. For example, if max_jobs=10 and one 
_replicator db has a 1000 jobs and another has only one doc then, 
that one job might have to wait for quite a while to get its turn to

 run. If we picked fairly amongst _replicator dbs, then for example,
 the one job would get at least one of the 10 max_jobs run "slots", 
and the rest of the 9 slots would go to the replicator db with 1000 
docs. If there would be 11 _replicator dbs, then a docs from the ones

with the lowest start times amongst them would be picked first.


That does sound unfair. I wasn't aware of this "gotcha" with multiple
replicator DBs (in the field I rarely see >1 replicator DB) but it
intuitively makes sense - all replicator DBs are unioned in the
scheduler's queue and treated like a single, big DB. (There is basically
no advantage to multiple _replicator DBs today then, other than perhaps
security / obscurity reasons, is there?)

This feature would also allow running some quick replication jobs, 
when there is already a full queue main _replicator db jobs by 
creating a "quickjobs/_replicator" db, and insert these new jobs 
there. With this new scheme they would start running right away even 
if the queue is full with jobs from the main _replicator db. Another,

related idea I had, was to add per job user-configurable priorities:
high/default/low or numeric. However, that scheme is not as good as
it could lead to permanent starvation of jobs while the round-robin
db scheduling scheme still guarantees all jobs will eventually run.


I think this proposal can be improved. I like the idea of leveraging
multiple replicator DBs to provide some sort of priority tweak, but I am
not sure I can predict what will happen in the case of e.g. 10 different
replicator DBs fighting with each other in the scheduler as you've laid
it out.

Would a fair-share scheduler [1] make sense here? We can't borrow many
of the OS-level scheduling ideas because we don't have the same insight
into the runtime characteristics of our jobs, but fair share might be a
good match.

Here's one way it could be implemented:

* Each replicator DB could represent a logical grouping of jobs, e.g.
  background continuous backup jobs, one-shot migration jobs,
  high-priority user requests, etc.

* An INI-level config could determine how these groups are handled:

  * 100% fair (default) -- total available job slots are divided by
the number of replicator DBs, then allocated round-robin within
that DB. The difference from today's setup is that each DB gets
its own round-robin scheduler. I *think* this might be what Nick
was suggesting, but I can't be 100% sure.

  * Specific priority -- A list of DBs and their fixed percentages.
Example: _replicator:30,high/_replicator:50,low/_replicator:20

If a configured database is not present, or has no active jobs in
it, its fixed proportion of cycles are "given up" to the other
replicator DBs.

* Jobs are then allocated based on these breakdowns, and we continue
  to use round-robin within each database to maintain the current
  approach. This means no visible change for upgrading users with a
  single _replicator DB.


Example, with the numbers picked to make the math turn out nice:

```
[replicator]
db_priorities = _replicator:30,high/_replicator:50,low/_replicator:20
max_jobs = 100
```

The % allocation of jobs across DBs is, by default:

  _replicator:  30 / (30+20+50) = 30%
  high/_replicator: 20 / (30+20+50) = 20%
  low/_replicator:  50 / (30+20+50) = 50%

First, put 100 jobs into _replicator. Because the other two DBs have no
jobs, all 100 free jobs are allocated to those jobs:

  _replicator:  30 / (30) = 100% * 100 jobs = 100

Now, we add another 100 jobs into the high DB. Since low is empty, we
recalculate calculate the 

Re: [ANNOUNCE] Bessenyei Balázs Donát elected as CouchDB committer

[Joan Touzet]

Congratulations Bessenyei! Do you have a nickname (other than bessbd)?

-Joan

On 2021-01-14 3:48 p.m., Robert Newson wrote:

Dear community,

I am pleased to announce that the CouchDB Project Management Committee has 
elected Bessenyei Balázs Donát as a CouchDB committer.

Apache ID: bessbd

Committers are given a binding vote in certain project decisions, as well as 
write access to public project infrastructure.

This election was made in recognition of Donát's commitment to the project. We 
mean this in the sense of being loyal to the project and its interests.

Please join me in extending a warm welcome to Donát!

On behalf of the CouchDB PMC,

Robert Newson

Algú vol col·laborar en aquest projecte?

[Joan Baptista]

 Benvolguts i benvolgudes usuaris i usuàries del nostre estimat Debian
GNU/Linux:


Llegeixo i gaudeixo aquesta llista de fa bastants anys i tinc clar que ni
soc dels que mes ni dels que menys sap d’informàtica i telecomunicacions,
ni de Linux, ni de Debian dintre d’aquesta llista.


Aquesta es la primera vegada que escric demanant ajuda, ja que em dol molt
portar mesos sense trobar gent que ni provi, ni utilitzi ni millori el
millor programa que mai he fet i faré a la meva vida, que tot i tenir clar
que no es cap gran meravella, si considero que el objectiu d’aquest
programa es digne d’una mica mes d’atenció i feina (promoció, fer un
manual, actualitzar versions de sistemes operatius, traduir a mes idiomes
i/o qualsevol altra cosa) i per això avui he decidit que potser algú
d’aquesta llista em pot ajudar, encara que només fos posant-me en contacte
amb algú a qui li podria interessar.


El objectiu de Tria S.O. 1.2.12 (tant la versió per Windows, com per
GNU/Linux) es ajudar al màxim de gent possible de tot el mon a descobrir i
utilitzar GNU/Linux (preferentment Debian o derivats, però he volgut donar
el màxim de llibertat possible a qui utilitzi el programa) recomanant els
sistemes operatius d’escriptori (privatiu, lliure i fins i tot un de cada)
que poden provocar el millor rendiment a qualsevol pc que tingui menys de
25 anys d’antiguitat, tant si es tracta d’ordinador(s) molt potent(s) com
si no.


A https://tria-s-o-1-2.sourceforge.io no només hi trobareu els 2 programes
i el codi font (unes 1.000 línies aproximadament, tant codi Visual Basic
com codi Gambas) sinó també els documents que vaig crear prèviament per
poder començar a programar.


Gràcies per el vostre temps i disculpeu per no saber explicar-ho mes
breument.

Joan Baptista
joanbapti...@gmail.com
Tel. 665 245 561

Re: Traducció de la web de debian

[Joan]

A mi m'interessaria més col·laborar en la traducció de la web... Algú
sap com està muntat?

-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi


El Wed, 13 Jan 2021 19:21:32 +0100
Adrià  va escriure:

> On Wed, Jan 13, 2021 at 05:14:37PM +0100, a...@probeta.net wrote:
> > Benvolguts/des
> > 
> > Com que no en sé prou de l'univers Debian penso que les píndoles em
> > seran molt útils però al mateix temps no sabia ben bé com
> > contribuir.
> > 
> > Crec que m'animo a traduir al català una cosa que estic llegint
> > sobre Debian:
> > 
> >   https://debian-handbook.info/browse/stable/sect.release-lifecycle.html
> > 
> > De fet, crec que podria traduir també aquest altre capítol:
> > 
> >   https://debian-handbook.info/browse/stable/sect.debian-internals.html
> > 
> > Com treballarem? Escric les píndoles/traduccions en markdown i les
> > envío a algú amb accés a aquest Gitlab? I després gent que en sap
> > del tema afegeix coses o les corregeix?
> > 
> > Gràcies
> > 
> > 
> >  Àlex
> >   
> 
> Hola Àlex,
> 
> el Debian Handbook també està a Salsa, però a un repositori diferent.
> Si hi vols col·laborar, hi ha una llista de correu pròpia i si no vols
> usar Git pots usar Weblate.
> 
> Pots trobar tota la informació a [0] o [1], o em pots preguntar
> directament, doncs vaig ser un dels traductors de fa una o dues
> edicions.
> 
> Espero que et serveixi!
> 
> 0: https://debian-handbook.info/contribute/
> 1:
> https://salsa.debian.org/hertzog/debian-handbook/-/blob/HEAD/README.translators
> 



-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi

RE: trap changes made for VRF

[Joan Landry]

Please tell me where to find these patches – links please.
Thanks

From: Bart Van Assche 
Sent: Saturday, January 9, 2021 5:47 PM
To: Joan Landry ; stann...@cumulusnetworks.com
Cc: net-snmp-users@lists.sourceforge.net
Subject: Re: trap changes made for VRF

External email: [bart.vanass...@gmail.com]

Hi Joan,

Pre-existing functionality should not have been affected by adding VRF support. 
That probably was an unintended side effect. Can you revert the following 
patches and verify whether that is sufficient to restore previous functionality?

  *   b3dd62016170 ("libsnmp, UDP: Only display VRF debug messages if relevant")
  *   5d61e9367200 ("snmplib, UDP transport: Do not compare array pointers 
against NULL")
  *   02de400544de ("libsnmp: Set Linux VRF iface on Trap sink IP addresses")
  *   3ca90c2c1260 ("libsnmp/transports/UDP: Add support for VRF")
Thanks,

Bart.

On 1/6/21 11:33 PM, Joan Landry wrote:
Can you please also explain why the pre-existing functionality of clientaddr 
x.x.x.x:port – no longer works
and what I need to do to get it to work again?
Also, where should I look for this patch – and any idea on when it might be 
available?
Thanks,
Joan



From: Bart Van Assche <mailto:bvanass...@acm.org>
Sent: Wednesday, January 6, 2021 11:28 PM
To: stann...@cumulusnetworks.com<mailto:stann...@cumulusnetworks.com>
Cc: Joan Landry <mailto:jolan...@adva.com>; 
net-snmp-users@lists.sourceforge.net<mailto:net-snmp-users@lists.sourceforge.net>
Subject: Re: trap changes made for VRF

External email: [bart.vanass...@gmail.com<mailto:bart.vanass...@gmail.com>]

Hi Sam,

Can you submit a patch that documents how to use the changes in the following 
two commits:
* 02de400544de ("libsnmp: Set Linux VRF iface on Trap sink IP addresses")
* 3ca90c2c1260 ("libsnmp/transports/UDP: Add support for VRF")
Thanks,

Bart.

On 1/6/21 12:39 PM, Joan Landry wrote:
Can someone please provide a link to the documentation that describes how to 
get rc = netsnmp_bindtodevice(t->sock, ep->iface);
to work – apparently the code that sends traps has been redesigned 
significantly in that NETSNMP_DS_LIB_CLIENT_ADDR no longer works as use to.

What is the change in snmpd.conf that makes this work apparently clientaddr 
x.x.x.x:port – no longer works as it used to.

I have not been able to locate any documentation on these changes or how to set 
the VRF interface or how to allow the code to set an ipaddress and port using 
NETSNMP_DS_LIB_CLIENT_ADDR

Any info on this would be greatly appreciated.


Please see our privacy statement at 
https://www.adva.com/en/about-us/legal/privacy-statement for details of how 
ADVA processes personal information.



Please see our privacy statement at 
https://www.adva.com/en/about-us/legal/privacy-statement for details of how 
ADVA processes personal information.
___
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

Re: Píndoles de DebianCat

[Joan]

Doncs, si pot servir la meva engruna per pujar-te un dècima de grau
l'ànim, t'envio una afectuosa abraçada telemàtica... Te les mereixes
totes :-)

Debian és un projecte molt xulo, que funciona en el dia a dia... I
potser també en cal, a la comunitat, una mica de pedagogia en la línia
del que comentes... De o bé fer crítica constructiva (aportant, si és
possible, treball) o bé muntar o engrescar a muntar alternatives
millors!

Ara el que estic és expectant per quan comparteixis això que estàs
barrinant!

Salut a tots i gràcies per les contribucions!

-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi


El Tue, 12 Jan 2021 15:55:06 +0100
Alex Muntada  va escriure:

> Hola Alba
> 
> > Trobo que les píndoles que ja estan disponibles ja poden ajudar
> > a molta gent (jo ja he après coses, gràcies!) i m'han fet venir
> > idees per a altres píndoles (ara només falta que tregui el temps
> > per fer-les :-P).  
> 
> T'agraeixo molt els teus comentaris positius per la feina que ha
> fet l'Adrià. T'agraeixo també que hagis llegit les píndoles abans
> d'enviar els teus comentaris.
> 
> Us he de confessar que porto uns dies força trist i decebut pels
> comentaris negatius que s'han fet. Tothom pot tenir una opinió
> sobre la feina que fan els altres però de vegades és preferible
> guardar-se-la si no aporta cap valor positiu, sobretot per a les
> persones que han dedicat el temps i l'esforç a fer la feina.
> 
> De wiki ja fa dècades que n'hi ha a Debian (wiki.debian.org) i
> també un espai per al nostre grup. No sembla pas que hi hagi
> gaire gent escrivint-hi, així que quin mal fa que algú provi
> alguna cosa diferent si le ve de gust? No us agrada, doncs cal
> pas que hi col·laboreu ni cal que ens ho feu saber a la resta.
> Voleu dedicar temps a fer una alternativa que us agradi més?
> Aleshores endavant, la diversitat és benvinguda a Debian.
> 
> Per altra banda, ara resulta que de cop i volta volem escriure
> píndoles i la temàtica de Debian és massa limitada perquè les
> volem escriure justament en aquest nou espai de col·laboració
> de Debian pensat per a la comunitat catalana de Debian. Doncs
> tampoc cal que ens ho feu saber, busqueu un altre espai que us
> encaixi millor i escriviu-les allà. Després, si voleu, podeu
> compartir-les també a la llista, és clar.
> 
> Jo tenia ganes de compartir amb vosaltres un projecte en què
> m'he engrescat fa poc i que crec que podria agradar-vos, però
> ara mateix estic molt desanimat.
> 
> --
>   ⢀⣴⠾⠻⢶⣦⠀
>   ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
>   ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
>   ⠈⠳⣄
> 



-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi

Re: Dovecot FTS not using plugins

[Joan Moreau]

Soirry, I always forget that dovecot does not do multi-threading (why ?)

The process was waiting for another process.

On 2021-01-11 14:57, Aki Tuomi wrote:


On 11/01/2021 16:51 Joan Moreau  wrote:

Hello,
With recent git version of dovecot, I can see that the FTS does not 
use the configured plugin anymore, but tries to sort the mailbox 
directly on the spot (which is of course very painful).
Is there a change in the configuration file in order to recover the 
old behavior ? or something else has changed ?

Thank you
Joan


Can you share `doveconf -n` and output of `doveadm -Dv search -u victim 
text foobar`?


Aki

Dovecot FST not using plugins

[Joan Moreau]

Hello,

With recent git version of dovecot, I can see that the FTS does not use 
the configured plugin anymore, but tries to sort the mailbox directly on 
the spot (which is of course very painful).


Is there a change in the configuration file in order to recover the old 
behavior ? or something else has changed ?


Thank you

Joan

Re: [VOTE] couchdb 4.0 transaction semantics

[Joan Touzet]

If this proposal means v3.x replicators can't replicate one-shot / 
normal / non-continuous changes from 4.x+ endpoints, that sounds like a 
big break in compatibility.


I'm -0.5, tending towards -1, but mostly because I'm having trouble 
understanding if it's even possible - unless a proposal is being made to 
release a 3.2 that introduces replication compatibility with 4.x in tandem.


-Joan

On 2021-01-09 6:45 p.m., Nick Vatamaniuc wrote:

I withdraw my vote until I can get a clearer view. Nick would you mind

re-stating?

Not at all! The longer version and other considerations was stated in
my last reply to the discussion thread so I assumed that was accepted
as a consensus since nobody replied arguing otherwise.

https://lists.apache.org/thread.html/r45bff6ca4339f775df631f47e77657afbca83ee0ef03c6aa1a1d45cb%40%3Cdev.couchdb.apache.org%3E

But the gist of it is that existing (< 3.x) replicators won't be able
to replicate non-continuous (normal) changes from >= 4.x endpoints.

Regards,
-Nick

On Sat, Jan 9, 2021 at 1:26 AM Joan Touzet  wrote:


Wait, what? I thought you agreed with this approach in that thread.

I withdraw my vote until I can get a clearer view. Nick would you mind
re-stating?

-Joan

On 2021-01-08 11:37 p.m., Nick V wrote:

+1 for 1 through 3

-1 for 4  as I think the exception should apply to normal change feeds as well, 
as described in the thread

Cheers,
-Nick


On Jan 8, 2021, at 17:12, Joan Touzet  wrote:

Thanks, then it's a solid +1 from me.

-Joan


On 2021-01-08 4:13 p.m., Robert Newson wrote:
You are probably thinking of a possible “group commit”. That is anticipated and 
not contradicted by this proposal. This proposal is explicitly about not using 
multiple states of the database for a single doc lookup, view query, etc.

On 8 Jan 2021, at 19:53, Joan Touzet  wrote:


+1.

This is for now I presume, as I thought that there was feeling about
relaxing this restriction somewhat for the 5.0 timeframe? Memory's dim.

-Joan

On 07/01/2021 06:00, Robert Newson wrote:

Hi,

Following on from the discussion at 
https://lists.apache.org/thread.html/rac6c90c4ae03dc055c7e8be6eca1c1e173cf2f98d2afe6d018e62d29%40%3Cdev.couchdb.apache.org%3E
 
<https://lists.apache.org/thread.html/rac6c90c4ae03dc055c7e8be6eca1c1e173cf2f98d2afe6d018e62d29@%3Cdev.couchdb.apache.org%3E>

The proposal is;

"With the exception of the changes endpoint when in feed=continuous mode, that 
all data-bearing responses from CouchDB are constructed from a single, immutable 
snapshot of the database at the time of the request.”

Paul Davis summarised the discussion in four bullet points, reiterated here for 
context;

1. A single CouchDB API call should map to a single FDB transaction
2. We absolutely do not want to return a valid JSON response to any
streaming API that hit a transaction boundary (because data
loss/corruption)
3. We're willing to change the API requirements so that 2 is not an issue.
4. None of this applies to continuous changes since that API call was
never a single snapshot.


Please vote accordingly, we’ll run this as lazy consensus per the bylaws 
(https://couchdb.apache.org/bylaws.html#lazy 
<https://couchdb.apache.org/bylaws.html#lazy>)

B.

Re: [VOTE] couchdb 4.0 transaction semantics

[Joan Touzet]

Wait, what? I thought you agreed with this approach in that thread.

I withdraw my vote until I can get a clearer view. Nick would you mind 
re-stating?


-Joan

On 2021-01-08 11:37 p.m., Nick V wrote:

+1 for 1 through 3

-1 for 4  as I think the exception should apply to normal change feeds as well, 
as described in the thread

Cheers,
-Nick


On Jan 8, 2021, at 17:12, Joan Touzet  wrote:

Thanks, then it's a solid +1 from me.

-Joan


On 2021-01-08 4:13 p.m., Robert Newson wrote:
You are probably thinking of a possible “group commit”. That is anticipated and 
not contradicted by this proposal. This proposal is explicitly about not using 
multiple states of the database for a single doc lookup, view query, etc.

On 8 Jan 2021, at 19:53, Joan Touzet  wrote:


+1.

This is for now I presume, as I thought that there was feeling about
relaxing this restriction somewhat for the 5.0 timeframe? Memory's dim.

-Joan

On 07/01/2021 06:00, Robert Newson wrote:

Hi,

Following on from the discussion at 
https://lists.apache.org/thread.html/rac6c90c4ae03dc055c7e8be6eca1c1e173cf2f98d2afe6d018e62d29%40%3Cdev.couchdb.apache.org%3E
 
<https://lists.apache.org/thread.html/rac6c90c4ae03dc055c7e8be6eca1c1e173cf2f98d2afe6d018e62d29@%3Cdev.couchdb.apache.org%3E>

The proposal is;

"With the exception of the changes endpoint when in feed=continuous mode, that 
all data-bearing responses from CouchDB are constructed from a single, immutable 
snapshot of the database at the time of the request.”

Paul Davis summarised the discussion in four bullet points, reiterated here for 
context;

1. A single CouchDB API call should map to a single FDB transaction
2. We absolutely do not want to return a valid JSON response to any
streaming API that hit a transaction boundary (because data
loss/corruption)
3. We're willing to change the API requirements so that 2 is not an issue.
4. None of this applies to continuous changes since that API call was
never a single snapshot.


Please vote accordingly, we’ll run this as lazy consensus per the bylaws 
(https://couchdb.apache.org/bylaws.html#lazy 
<https://couchdb.apache.org/bylaws.html#lazy>)

B.

Re: [VOTE] couchdb 4.0 transaction semantics

[Joan Touzet]

Thanks, then it's a solid +1 from me.

-Joan

On 2021-01-08 4:13 p.m., Robert Newson wrote:

You are probably thinking of a possible “group commit”. That is anticipated and 
not contradicted by this proposal. This proposal is explicitly about not using 
multiple states of the database for a single doc lookup, view query, etc.


On 8 Jan 2021, at 19:53, Joan Touzet  wrote:

+1.

This is for now I presume, as I thought that there was feeling about
relaxing this restriction somewhat for the 5.0 timeframe? Memory's dim.

-Joan

On 07/01/2021 06:00, Robert Newson wrote:

Hi,

Following on from the discussion at 
https://lists.apache.org/thread.html/rac6c90c4ae03dc055c7e8be6eca1c1e173cf2f98d2afe6d018e62d29%40%3Cdev.couchdb.apache.org%3E
 
<https://lists.apache.org/thread.html/rac6c90c4ae03dc055c7e8be6eca1c1e173cf2f98d2afe6d018e62d29@%3Cdev.couchdb.apache.org%3E>

The proposal is;

"With the exception of the changes endpoint when in feed=continuous mode, that 
all data-bearing responses from CouchDB are constructed from a single, immutable 
snapshot of the database at the time of the request.”

Paul Davis summarised the discussion in four bullet points, reiterated here for 
context;

1. A single CouchDB API call should map to a single FDB transaction
2. We absolutely do not want to return a valid JSON response to any
streaming API that hit a transaction boundary (because data
loss/corruption)
3. We're willing to change the API requirements so that 2 is not an issue.
4. None of this applies to continuous changes since that API call was
never a single snapshot.


Please vote accordingly, we’ll run this as lazy consensus per the bylaws 
(https://couchdb.apache.org/bylaws.html#lazy 
<https://couchdb.apache.org/bylaws.html#lazy>)

B.

Re: [VOTE] couchdb 4.0 transaction semantics

[Joan Touzet]

+1.

This is for now I presume, as I thought that there was feeling about
relaxing this restriction somewhat for the 5.0 timeframe? Memory's dim.

-Joan

On 07/01/2021 06:00, Robert Newson wrote:
> Hi,
> 
> Following on from the discussion at 
> https://lists.apache.org/thread.html/rac6c90c4ae03dc055c7e8be6eca1c1e173cf2f98d2afe6d018e62d29%40%3Cdev.couchdb.apache.org%3E
>  
> <https://lists.apache.org/thread.html/rac6c90c4ae03dc055c7e8be6eca1c1e173cf2f98d2afe6d018e62d29@%3Cdev.couchdb.apache.org%3E>
> 
> The proposal is;
> 
> "With the exception of the changes endpoint when in feed=continuous mode, 
> that all data-bearing responses from CouchDB are constructed from a single, 
> immutable snapshot of the database at the time of the request.”
> 
> Paul Davis summarised the discussion in four bullet points, reiterated here 
> for context;
> 
> 1. A single CouchDB API call should map to a single FDB transaction
> 2. We absolutely do not want to return a valid JSON response to any
> streaming API that hit a transaction boundary (because data
> loss/corruption)
> 3. We're willing to change the API requirements so that 2 is not an issue.
> 4. None of this applies to continuous changes since that API call was
> never a single snapshot.
> 
> 
> Please vote accordingly, we’ll run this as lazy consensus per the bylaws 
> (https://couchdb.apache.org/bylaws.html#lazy 
> <https://couchdb.apache.org/bylaws.html#lazy>)
> 
> B.
> 
> 

RE: Response buffer size

[Joan ventusproxy]

Hi,

Sorry, I’m using http async client 4.1.4.

Thanks,
Joan.


From: Joan grupoventus  
Sent: Friday, January 8, 2021 4:57 PM
To: 'Joan ventusproxy' 
Subject: Response buffer size

Hello,

I’m using HttpClient 4.5.7. reading responses from a backend through a 
‘HttpAsyncResponseConsumer’ on the ‘consumeContent’ method  in this way:

while ( (numBytesRead = decoder.read(this.bbuf)) > 0 ) {
( . . . )
}

where  this.bbuf = ByteBuffer.allocate(32768);


The buffer size in the async http instance is configured in this way (‘phccm’ 
is  a ‘PoolingNHttpClientConnectionManager’):
this.phccm.setDefaultConnectionConfig(ConnectionConfig.custom().setBufferSize(32768).setFragmentSizeHint(32768).build()

And on the IOReactor:
IOReactorConfig ioReactorConfig = IOReactorConfig.custom().setRcvBufSize(32768) 
...


But when we start reading the response on the consume content method, the byte 
buffer is filled out just with 16K of data:
Cycle 0 :: bytes read = 15812, total size (K) = 15
Cycle 1 :: bytes read = 16368, total size (K) = 31
Cycle 2 :: bytes read = 16376, total size (K) = 47
Cycle 3 :: bytes read = 16384, total size (K) = 63
Cycle 4 :: bytes read = 16376, total size (K) = 79
Cycle 5 :: bytes read = 16384, total size (K) = 95
Cycle 6 :: bytes read = 16376, total size (K) = 111
Cycle 7 :: bytes read = 16384, total size (K) = 127

What am I missing?

Thanks,

Joan.




-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org

Response buffer size

[Joan grupoventus]

Hello,

 �

I’m using HttpClient 4.5.7. reading responses from a backend through a 
‘HttpAsyncResponseConsumer’ on the ‘consumeContent’ method  in this way:

 �

while ( (numBytesRead = decoder.read(this.bbuf)) > 0 ) {

( . . . )

}

  

where  this.bbuf = ByteBuffer.allocate(32768);

  

  

The buffer size in the async http instance is configured in this way (‘phccm’ 
is  a ‘PoolingNHttpClientConnectionManager’):

this.phccm.setDefaultConnectionConfig(ConnectionConfig.custom().setBufferSize(32768).setFragmentSizeHint(32768).build()

  

And on the IOReactor:

IOReactorConfig ioReactorConfig = IOReactorConfig.custom().setRcvBufSize(32768) 
...

  

  

But when we start reading the response on the consume content method, the byte 
buffer is filled out just with 16K of data:

Cycle 0 :: bytes read = 15812, total size (K) = 15

Cycle 1 :: bytes read = 16368, total size (K) = 31

Cycle 2 :: bytes read = 16376, total size (K) = 47

Cycle 3 :: bytes read = 16384, total size (K) = 63

Cycle 4 :: bytes read = 16376, total size (K) = 79

Cycle 5 :: bytes read = 16384, total size (K) = 95

Cycle 6 :: bytes read = 16376, total size (K) = 111

Cycle 7 :: bytes read = 16384, total size (K) = 127

 �

What am I missing?

 �

Thanks,

 �

Joan.

 �