from:"Giacomo"

Il 11 Maggio 2024 19:48:58 CEST, Guido Vetere  ha 
scritto:
> e allora continuiamo la metafora
> se un anziano che non ha notato il cartello scivola e si fa male, viene
> incriminato il produttore del detersivo per pavimenti?

No, risponde dell'incidente chi ha scelto di esporre al pubblico il pavinento 
bagnato.

Tipo OpenAI per l'istanza di GPT4 aperta al pubblico.


Giacomo

Re: [nexa] Articolo sui LLMs - il punto di vista di un giurista - “eggshell” plaintiff doctrine:

Io copio... :-)

Il 11 Maggio 2024 Maria Chiara Pievatolo ha scritto:
> On 11/05/24 19:02, Guido Vetere wrote:
> > dunque non si possono lavare i pavimenti?
> 
> La risposta è lasciata come esercizio per il lettore :-)

I negozi li lavano dopo la chiusura al pubblico.

勞

Anche gli LLM possono essere usati in modo perfettamente sicuro... da chi li 
realizza.

Giacomo

[nexa] A joint statement from UniSuper CEO Peter Chun, and Google Cloud CEO, Thomas Kurian

Che succede se metti tutte le uova in un paniere (e le affidi alle volpi)?



UniSuper and Google Cloud understand the disruption to services experienced by 
members has been extremely frustrating and disappointing. We extend our sincere 
apologies to all members.

While supporting UniSuper to bring its systems back online, Google Cloud has 
been conducting a root cause analysis.

Google Cloud CEO, Thomas Kurian has confirmed that the disruption arose from an 
unprecedented sequence of events whereby an inadvertent misconfiguration during 
provisioning of UniSuper’s Private Cloud services ultimately resulted in the 
deletion of UniSuper’s Private Cloud subscription. 

This is an isolated, ‘one-of-a-kind occurrence’ that has never before occurred 
with any of Google Cloud’s clients globally. This should not have happened. 
Google Cloud has identified the events that led to this disruption and taken 
measures to ensure this does not happen again.

# Why did the outage last so long?

UniSuper had duplication in two geographies as a protection against outages and 
loss. However, when the deletion of UniSuper’s Private Cloud subscription 
occurred, it caused deletion across both of these geographies. 

Restoring UniSuper’s Private Cloud instance has called for an incredible amount 
of focus, effort, and partnership between our teams to enable an extensive 
recovery of all the core systems. The dedication and collaboration between 
UniSuper and Google Cloud has led to an extensive recovery of our Private Cloud 
which includes hundreds of virtual machines, databases and applications. 

UniSuper had backups in place with an additional service provider. These 
backups have minimised data loss, and significantly improved the ability of 
UniSuper and Google Cloud to complete the restoration.

# What’s next?

UniSuper and Google Cloud have been working around the clock on a resolution. 
The completion of the restoration swiftly, safely and securely remains Google 
Cloud and UniSuper’s top priority.

Re: [nexa] Articolo sui LLMs - il punto di vista di un giurista

Salve Guido, 

Il 11 Maggio 2024 12:02:01 CEST, Guido Vetere  ha 
scritto:
> non mi è chiaro il motivo per cui un disclaimer appropriato non offrirebbe
> garanzie sufficienti (se questo è il punto)

Se il tuo software è progettato per ingannare le menti umane, dichiararlo come 
tale
non lo rende meno ingannevole.

Le menti umane continueranno ad esserne ingannate (fintanto che non saranno
in grado di comprenderne appieno il funzionamento) e tu devi rispondere
di tale inganno, soprattutto se hai diffuso la credenza che quel software sia 
"intelligente" 
e abbia "appreso" dai testi usati per programmarlo.

Se avessero pubblicizzato GPT4 come un
"generatore automatico di stronzate plausibili"
o come una "parodia del web che non fa ridere", il tuo disclaimer offrirebbe 
garanzie sufficienti.

Ma se il tuo disclaimer viene dopo mesi di propaganda martellante a tutti i 
livelli
della società per far credere che questi software siano "intelligenze aliene", 
un disclaimer
diventa invisibile alla stragrande maggioranza della popolazione.


È un po' come andare in discoteca e confessare sottovoce ad una vittima che 
passa 
vicino alle casse che sei un maniaco assassino: al processo per omicidio, il 
tuo "disclaimer"
difficilmente sarà riconosciuto come attenuante.


> supponiamo che io metta online una tavola parolibera di marinettiana
> memoria che genera frasi a caso, eventualmente anche diffamatorie
> se dichiarassi che il sito è programmaticamente situazionista e
> non-veritativo, sarei comunque soggetto a censura?

Se nessuno ti prende sul serio, no.

Se moltissimi ritengono credibile il tuo output, è auspicabile che tu ne debba 
rispondere come
fossero parole direttamente scritte da te.

Come in fondo sono: hai solo scritto un software  che le "scrive" al tuo posto. 
È come se le avessi compresse e pubblicate "a puntate".

Disclaimer o meno.


Giacomo

Re: [nexa] Articolo sui LLMs - il punto di vista di un giurista

2024-05-10 Thread Giacomo Tesio

Il giorno Fri, 10 May 2024 380° via nexa ha scritto:

> che tipo di
> trattamento giuridico occorrerebbe riservare alle aziende che
> utilizzano il contenuto delle email, delle chat e dei post social
> _privati_ per...

Direi la reclusione da sei mesi a otto anni, o da tre a dodici se si
tratta di un minore. Come spesso accade, non servono norme
dedicate: in Italia basta l'articolo 605 del Codice Penale.

L'uso dei dati personali per qualsiasi scopo non esplicitamente
richiesto dalla persona cui quei dati fanno riferimento equivale
SEMPRE ad una privazione della libertà di quella persona. [1]


Giacomo
[1] vedi anche nota (1)
https://www.brocardi.it/codice-penale/libro-secondo/titolo-xii/capo-iii/sezione-ii/art605.html

Re: [nexa] Entrate: se la decisione è automatizzata, niente contraddittorio

2024-05-06 Thread Giacomo Tesio

Salve Enrico,

Il 2 Maggio 2024 09:49:45 CEST, Enrico Marello  ha 
scritto:
> 
> Per esempio, la maggior parte dei controlli automatizzati che terminano con
> una cartella oggi è del tipo: in dichiarazione hai indicato che hai versato
> imposte per 100, a noi ne risultano versate solo 80, paga la differenza.
> Incrocia banalmente due tabelle (dichiarato, riscosso), ben poco
> intelligente, mi pare.

Qualunque database di dimensione e complessità degne di nota e che abbia subito
evoluzioni nel tempo finisce per contenere errori 
ed inconsistenze che è necessario analizzare 
e correggere manualmente.

Sarebbe davvero ingenuo credere che basti un atto d'imperio (decreto legge, 
bolla papale..)
per correggere magicamente tali errori.

Errori che aumentano con l'aumentare delle fonti che alimentano il db stesso.


Per riprendere il tuo esempio, sarebbe più preciso dire "sul db c'è scritto che 
in
dichiarazione hai indicato che hai versato imposte per 100, sul db c'è scritto 
che ne hai
versate solo 80, paga la differenza."


Anche senza "AI", rendere più lunghe e costose le correzioni ad un db rende più 
rapida la sua
corruzione.

E mi sorprenderebbe scoprire che il tempo della Corte di Giustizia Tributaria 
costi meno 
allo stato dell'Agenzia dell'entrate.

Poi, ovviamente, se un db ricco di inconsistenze non sanate viene usato per il 
fine-tuning di
un software programmato statisticamente (impropriamente detto "AI") ci aspetta
una valanga di ricorsi vinti dai contribuenti.


Giacomo

Dtrace

2024-05-04 Thread Giacomo Vattini

Morning to all ,does someone know how to implement all the probes for dtrace as 
in FreeBSD, the oneliners toolkit are not working and everytime that i put as a 
probe TCP IP it gives me errors
Thank you for the suggestions

Re: [QGIS-it-user] QGIS Grant Proposal 2024

2024-05-03 Thread Giacomo Fontanelli via QGIS-it-user

Grazie dell'info Matteo
Giacomo

Il giorno gio 2 mag 2024 alle ore 08:42 Matteo Ghetta via QGIS-it-user <
qgis-it-user@lists.osgeo.org> ha scritto:

> Buongiorno a tutti,
>
> questi i risultati delle Grant Proposal:
>
> https://blog.qgis.org/2024/05/01/qgis-grant-programme-2024-results/
>
> Grazie a chi ha partecipato alla votazione
>
> Matteo
>
> On 4/22/24 08:50, Matteo Ghetta wrote:
> > Buongiorno a tutti,
> >
> > sono state pubblicate le Grant Proposal di quest'anno. La votazione
> > scade sabato 27 Aprile.
> >
> > Il budget totale, come gli altri anni è di 3€ e al seguente link c'è
> > la lista delle proposte definitive:
> >
> > https://github.com/qgis/PSC/issues/60#issuecomment-2041388763
> >
> > Potremmo discuterne oppure fare un sondaggio che, una volta finito, vale
> > come voto.
> >
> > Che ne pensate?
> >
> > A presto
> >
> > Matteo
> >
> >
> > Di seguito il contenuto della mail originale:
> >
> > ---
> >
> > QGIS Grant Voting - 2024
> > Please use the form below to select your preferred proposals for the
> > 2024 QGIS Grants.
> >
> > The total available grant budget is 30,000 EUR.
> >
> > All proposals that were submitted this year have been reviewed
> > concerning their fit to the grant programme requirements. To be
> > eligible, proposals have to focus on improving the QGIS project
> > infrastructure or on polishing existing features and they have to be
> > submitted by established contributors. (This means that proposal for new
> > features or by new contributors are not eligible for a grant and
> > therefore are not included in this vote.)
> >
> > The following post provides an overview of eligible proposals and links
> > to the detailed proposals:
> >
> > https://github.com/qgis/PSC/issues/60#issuecomment-2041388763
> ___
> QGIS-it-user mailing list
> QGIS-it-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-it-user
>
___
QGIS-it-user mailing list
QGIS-it-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-it-user

Bug#1066100: upstream 3.1.1 released, fixing this bug

2024-04-26 Thread Giacomo Mulas


Hi.

Just a "heads up" email to draw the attention of the maintainer(s) of the
debian freeciv packages to the release of the new 3.1.1 version of freeciv,
a bugfix release fixing, among others, the one reported here.

Any idea on if/when this new release will be packaged for debian, hence
possibly closing this bug?

Thanks, best regards
Giacomo Mulas

--
_____

Giacomo Mulas 
_

INAF - Osservatorio Astronomico di Cagliari
via della scienza 5 - 09047 Selargius (CA)

tel.   +39 070 71180255
mob. : +39 329  6603810
_

"every year keeps getting shorter, never seem to find the time
 plans that either come to naught, or half a page of scribbled lines
 the time is gone, the song is over, thought I'd something more to say"
 (Pink Floyd)
_

Re: [nexa] Gentoo Council Implements Ban on AI-Assisted Contributions

2024-04-24 Thread Giacomo Tesio

Il 24 Aprile 2024 18:50:03 CEST, "380°" ha scritto:
> 
> Poi: se il "contributor" dovesse dichiarare il falso [1] sul copyright...

Appunto: chi usa Copilot per produrre la patch e dichiara di non violare 
licenze di terze parti, 
sta dichiarando il falso.

Perché la patch è un'opera derivata da codice di terzi ma senza attribuzione.

Gentoo chiede esplicitamente a chi aderisce al progetto di evitarlo.


Mi chiedo: se senti il bisogno di usarlo e te ne sbatti delle conseguenze, 
perché contribuire
proprio a Gentoo?


Giacomo
___
nexa mailing list
nexa@server-nexa.polito.it
https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Re: [nexa] Gentoo Council Implements Ban on AI-Assisted Contributions

2024-04-24 Thread Giacomo Tesio

Ciao 380,

Il 24 Aprile 2024 17:40:49 CEST, "380°"  ha scritto:
> 
> > It is expressly forbidden to contribute to Gentoo any content that has been 
> > created 
> > with the assistance of Natural Language Processing artificial intelligence 
> > tools. 
> > This motion can be revisited, should a case been made over such a tool that 
> > does not 
> > pose copyright, ethical and quality concerns.
> 
> e questa sarebbe una policy /actionable/?!?

Lo è tanto quanto quella prevista per contribuire al kernel di Linux, cui è 
letteralmente richiesto gli sviluppatori di (auto)certificare che

```
a) The contribution was created in whole or in part by me and I have the right 
to submit it under the open source license indicated in the file; or
b) The contribution is based upon previous work that, to the best of my 
knowledge, is covered under an appropriate open source license and I have the 
right under that license to submit that work with modifications, whether 
created in whole or in part by me, under the same open source license (unless I 
am permitted to submit under a different license), as indicated in the file; or
c) The contribution was provided directly to me by some other person who 
certified (a), (b) or (c) and I have not modified it
```

https://www.kernel.org/doc/html/latest/process/submitting-patches.html#developer-s-certificate-of-origin-1-1


> non ho parole

Lo capisco: il codice prodotto da un LLM non può garantire di soddisfare 
nessuna delle 
precedenti clausole.

La policy di Gentoo rende solo esplicito ciò che il più diffuso Developer’s 
Certificate of Origin già richiede.


Come fa Linux a impedire che codice che violi quelle condizioni entri nel 
kernel?

Esattamente come farà Gentoo. ;-)


Giacomo
___
nexa mailing list
nexa@server-nexa.polito.it
https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Re: allow symlink tomcat 9

2024-04-24 Thread Giacomo Morri


Thanks. it works fine.

G



On 24/04/24 12:27, Holger Klawitter wrote:

A plain

   

should suffice.

Giacomo Morri wrote (at 2024-04-24 12:03 +0200):

Hi Holger, thanks for your reply.

consider that the symlink is /MTF/Content -> /realt/path/, how can i set the
Resource element for that path?

Regards,

Giacomo



On 24/04/24 11:55, Holger Klawitter wrote:

Hi,

allowLinking goes into a Resource Element inside Context,
not into Context itself. This changed in Tomcat 8.0 IIRC.

Giacomo Morri wrote (at 2024-04-24 11:42 +0200):

Hi, i have a servlet for uploading files inside a path that contains a
symbolic link, the upload works fine with tomcat 7 but after upgrading it to
tomcat 9 the servlet give me a java.lang.NullPointerException at
java.io.File..

I tried setting the allowLinking param to true for the context in this way:



But it doesn't work.

Can you please help me?

Regards,

Giacomo


-
To unsubscribe, e-mail:users-unsubscr...@tomcat.apache.org
For additional commands, e-mail:users-h...@tomcat.apache.org



--
Mit freundlichem Gruß / With kind regards
Holger Klawitter
--
listen  klawitter  de

-
To unsubscribe, e-mail:users-unsubscr...@tomcat.apache.org
For additional commands, e-mail:users-h...@tomcat.apache.org


--

*Cone *
*Essentially digital*
Via Sandro Totti 7A - 60131 Ancona
Tel 071 42 974
Cell 3273458156
emailgiacomo.mo...@cone.it  <mailto:giacomo.mo...@cone.it>
Webwww.cone.it  <http://www.cone.it>


-
To unsubscribe, e-mail:users-unsubscr...@tomcat.apache.org
For additional commands, e-mail:users-h...@tomcat.apache.org



--
Mit freundlichem Gruß / With kind regards
   Holger Klawitter
--
listen  klawitter  de

-
To unsubscribe, e-mail:users-unsubscr...@tomcat.apache.org
For additional commands, e-mail:users-h...@tomcat.apache.org


--

*Cone *
*Essentially digital*
Via Sandro Totti 7A - 60131 Ancona
Tel 071 42 974
Cell 3273458156
eMail giacomo.mo...@cone.it <mailto:giacomo.mo...@cone.it>
Web www.cone.it <http://www.cone.it>

Re: allow symlink tomcat 9

2024-04-24 Thread Giacomo Morri


Hi Holger, thanks for your reply.

consider that the symlink is /MTF/Content -> /realt/path/, how can i set 
the Resource element for that path?


Regards,

Giacomo



On 24/04/24 11:55, Holger Klawitter wrote:

Hi,

allowLinking goes into a Resource Element inside Context,
not into Context itself. This changed in Tomcat 8.0 IIRC.

Giacomo Morri wrote (at 2024-04-24 11:42 +0200):

Hi, i have a servlet for uploading files inside a path that contains a
symbolic link, the upload works fine with tomcat 7 but after upgrading it to
tomcat 9 the servlet give me a java.lang.NullPointerException at
java.io.File..

I tried setting the allowLinking param to true for the context in this way:



But it doesn't work.

Can you please help me?

Regards,

Giacomo


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



--
Mit freundlichem Gruß / With kind regards
   Holger Klawitter
--
listen  klawitter  de

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


--

*Cone *
*Essentially digital*
Via Sandro Totti 7A - 60131 Ancona
Tel 071 42 974
Cell 3273458156
eMail giacomo.mo...@cone.it <mailto:giacomo.mo...@cone.it>
Web www.cone.it <http://www.cone.it>


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

allow symlink tomcat 9

2024-04-24 Thread Giacomo Morri

Hi, i have a servlet for uploading files inside a path that contains a 
symbolic link, the upload works fine with tomcat 7 but after upgrading 
it to tomcat 9 the servlet give me a java.lang.NullPointerException at 
java.io.File..


I tried setting the allowLinking param to true for the context in this way:



But it doesn't work.

Can you please help me?

Regards,

Giacomo


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [nexa] Gentoo Council Implements Ban on AI-Assisted Contributions

2024-04-24 Thread Giacomo Tesio

Ciao Guido

Il giorno Wed, 24 Apr 2024 08:38:07 +0200
Guido Vetere ha scritto:

> il problema è che questi co-worker ci sono e se usati con giudizio
> aumentano di molto la produttività

SOLO se misuri la produttività dei programmatori in termini di righe di
codice committate. Che è come misurare la produttività dei filosofi in
termini di battute al minuto.

Se anche tu ci mettessi il 70% in meno a scrivere codice plausibile,
sei più produttivo se poi ci metti il 500% in più a debuggare quel
codice?

E se io, che costo all'azienda tre volte quello che costi tu, devo
spendere il triplo del tempo a rivedere le tue commit rispetto a quelle
di un altro sviluppatore (perché statisticamente ho osservato
che introduci bug più subdoli), sei più produttivo per l'azienda?

Al momento, nella mia esperienza, l'uso di LLM durante la scrittura del
codice sta aumentando i costi e riducendo la produttività complessiva
ed aumentando in modo subdolo i costi di sviluppo (al di là dei costi
vivi del SaaS).


> quindi la gente li sta usando

La gente crede di usare molte cose da cui in effetti è usata...

> pochi rinunceranno a farsi fare del boilerplate code o dei bei
> commenti perché questo non sarebbe etico, I'm afraid ...

Beh... hai scoperto l'acqua calda: più in generale, pochissimi si
pongono problemi etici. Ed una frazione di questi se li pongono nel
proprio operare cibernetico.

A guardare i numeri, potremmo tranquillamente smettere di occuparci di
etica, non credi?

> ed essendo l'etica una mediazione sociale (a meno che .. ma vabbè), il
> resto del ragionamento lo possiamo lasciare come esercizio

TINA again? :-D

Direi al contrario che l'esistenza di una minoranza consapevole delle
conseguenze che pone (e si pone) problemi etici in materia, mostra che
la mediazione sociale di cui parli è ben lontana da sintesi e persino
da compromessi universalmente accettati.

> piuttosto mi chiedo come facciano quelli di Gentoo a capire
> esattamente come è prodotto il codice che i contributori committano
> devono proprio essere grandi accher! :-))

Gli sviluppatori chiedono a chi vuole contribuire di seguire certe
policy. Perché assumi che chi non vuole seguire tali policy scelga di
contribuire a Gentoo? Perché, più in generale, assumi un comportamento
non etico da parte loro?


Giacomo
___
nexa mailing list
nexa@server-nexa.polito.it
https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Re: [nexa] Gentoo Council Implements Ban on AI-Assisted Contributions

2024-04-23 Thread Giacomo Tesio

Ciao Claudio,

Il 23 Aprile 2024 23:15:29 CEST, Claudio Agosti 
 ha scritto:
> Ciao Giacomo; capisco le ragioni che ci sono dietro, ma devo dire che ho
> provato un paio di sistemi di assistenza allo sviluppo.. ed il mio giudizio
> finale è che sono d'aiuto anche ad uno sviluppo responsabile ed informato.

Forse nel tuo caso riesci ad usarlo bene perché sei perfettamente consapevole 
che non
si tratta di codice scritto da una mente che ne comprende il significato (come 
quello scritto 
da un collega in peer programming).


Io l'ho visto usare a colleghi più giovani in peer programming, ed in più di 
un'occasione
il tempo richiesto per il refactoring/debug del output è stato maggiore del 
tempo
necessario a scrivere il codice da zero (sapendo cosa scrivere).

I colleghi in questione tendevano a fidarsi troppo dei "suggerimenti" e 
soprattutto non imparavano
dagli errori del software (forse perché non li vivevano come propri?)
Non solo: in un caso ho provato a far notare al collega i problemi che avevamo 
osservato
durante la sessione di pp, ottenendo una reazione piuttosto piccata, come se 
avessi messo
in discussione la sua competenza invece di quella di Copilot.

L'esperienza fin'ora mi ha lasciato un senso di diffidenza nei confronti del 
codice committato
da chi lo usa (cui corrispondono review più lunghe, meticolose, faticose e 
nettamente più costose
per l'azienda).

Riflettendoci, potrebbe anche aver senso tenerne conto in fase di colloquio:
a parità degli altri fattori, chi non necessita di LLM per scrivere il proprio 
codice 
ha probabilmente prospettive di crescita maggiori.


Forse può essere utile se già conosci perfettamente il dominio del problema
e il contesto di sviluppo (librerie, framework, servizi) nel cui caso riduce i 
tempi di battitura,
ma onestamente non credo che siano davvero "tempi morti": l'atto di scrivere il 
codice
"lentamente" serve a rileggerlo più volte, criticamente,  individuando in 
anticipo
potenziali problemi.

Inoltre, tale sforzo è utile a ricordarlo e dunque a debuggare mentalmente un 
problema
più rapidamente.

> sono assistito nel generare unit test più rapidamente.

Sarà sfiga, ma non gli ho visto produrre in output test utili se non in casi 
esteremamente basilari
(come funzioni pure di natura algebrica)

Nella quasi totalità dei miei casi d'uso, la quantità dei mock da configurare 
rende semplicemente
inutile quei tool.


Leggermente più utile è nella scrittura di esempi di utilizzo per la 
documentazione (ma anche
in quel caso, bisogna sempre rileggere e testare manualmente che la stronzata è 
dietro l'angolo.


> Secondo me posizioni come quella di Gentoo, sono importanti per dare un
> segnale, per fare un racconto di una comunità più attenta, ma poi sotto
> sotto, se committo del codice scritto con l'aiuto di chatgpt + co-pilot,
> costantemente rivisto da me... si può dire che il mio contributo sia stato
> AI-generato?

Sì beh... stai completamente ignorando il problema etico.

Se copi il codice che ho donato al mondo sotto un copyleft forte (supponi 
AGPLv3 o 
magari Hacking License[1]) in un progetto distribuito con una licenza 
incompatibile
(proprietaria o permissiva che sia), sei uno stronzo e lo sai.

Se lo fai perché te lo suggerisce CopyALot, sei comunque uno stronzo, ma non lo 
sai.

O meglio, scegli di non saperlo, di lavartene le mani perché... "AI".


Non saprei dire, in termini di filosofia morale, se questo ti renda doppiamente 
colpevole o meno.

Penso però si tratti di una di quelle situazioni in cui il soggetto è 
pienamente consapevole che dalle
proprie azioni deriverà un danno a terzi, ma non conoscendo personalmente i 
terzi, se ne sbatte.

Che sia usare Copilot per "risparmiare tempo", vendere criptomenate per non 
restare 
col cerino in mano o persino costruire proiettili, la questione mi sembra 
moralmente analoga.


> Non mi sono limitato a premere tab, ma ho fatto un lavoro di selezione,
> riflessione, e guida di quello che mi è stato suggerito. Mi sento comunque
> autore e responsabile dei pezzi di codice scritti, anche se c'era un
> "autocomplete" un bel po' più sofisticato del solito.

Per questo dovresti analizzare con più attenzione le implicazioni etiche.

Anche se produci sempre codice "open", quel codice deriva dal codice donato da 
altri perché 
sia sì riutilizzato, ma a certe condizioni, prima fra tutte un'attribuzione 
corretta [2]

Tu stai inevitabilmente violando quelle condizioni.


Se te ne senti davvero responsabile, come concili la consapevolezza di 
sfruttare il lavoro 
di migliaia di altri sviluppatori di software libero senza neppure citarli e la 
tua idea di te?

La scarsa probabilità di essere beccati è rilevante dal punto di vista legale, 
ma da quello morale no.


Per il software libero questi LLM costituiscono un danno secco: hai notato che 
Microsoft 
si è guardata bene dall'usare i propri sorgent

[nexa] Gentoo Council Implements Ban on AI-Assisted Contributions

2024-04-23 Thread Giacomo Tesio

Gentoo Council forbids AI-generated content from being made in contributions 
due to copyright and quality concerns.

Over the past year, artificial intelligence has become an increasingly integral 
part of the tech ecosystem. This advancement is on its way to revolutionizing 
how businesses operate, offering enhanced efficiency and automating mundane 
tasks.

At the same time, however, as AI technologies become deeply ingrained in the 
tech industry, they also usher in various concerns ranging from ethical 
dilemmas to potential quality compromises.

In light of this, the Gentoo Council, a pivotal entity in the open-source 
community, recently made headlines by setting a significant precedent 
concerning AI-generated content.

A couple of days ago, they enacted a policy explicitly prohibiting the 
contribution of any content created with the assistance of Natural Language 
Processing AI tools to Gentoo’s official projects.

The Gentoo Decision: Motivations and Implications

Several critical concerns underpin the Gentoo Council’s decision. Foremost 
among them are copyright issues. With copyright laws still catching up to the 
fast-paced evolution of AI, using AI-generated content could lead to legal 
entanglements and undermine the rigorous copyright standards that open-source 
projects like Gentoo strive to maintain.

Additionally, there are apprehensions about the quality of AI-generated 
content. While AI can produce work that appears convincingly accurate, it often 
lacks the nuanced understanding necessary for high-stakes or technically 
demanding projects.

For Gentoo, this risk is unacceptable, as it could dilute the quality of their 
projects and impose an undue burden on developers and users who would need to 
verify the accuracy of such contributions.

Ethical considerations also play a crucial role in their policy. The AI 
industry’s rapid growth has not been without controversy, including accusations 
of copyright infringement in training models and concerns over the substantial 
environmental impact due to AI data centers’ immense energy and water usage.

Moreover, the commercial deployment of AI has been linked to job disruptions, 
declining service quality, and the facilitation of scams and spam.

All of these factors led Gentoo[1] to decide to openly ban the use of AI in any 
development related to it, making it the first distribution to make such a 
decision. For more information, visit the official announcement [2]




[1] https://www.gentoo.org/

[2] https://wiki.gentoo.org/wiki/Project:Council/AI_policy

It is expressly forbidden to contribute to Gentoo any content that has been 
created 
with the assistance of Natural Language Processing artificial intelligence 
tools. 
This motion can be revisited, should a case been made over such a tool that 
does not 
pose copyright, ethical and quality concerns.
___
nexa mailing list
nexa@server-nexa.polito.it
https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

[nexa] Statement of the Global Encryption Coalition’s Steering Committee on the Belgian Presidency’s compromise proposal on EU CSAM

2024-04-20 Thread Giacomo Tesio


Statement of the Global Encryption Coalition’s Steering Committee on the 
Belgian Presidency’s compromise proposal on EU CSAM
The Global Encryption Coalition’s Steering Committee (GEC-SC)1 is alarmed by 
the latest proposal for a compromise presented by the Belgian Presidency of the 
Council of the European Union to advance the negotiations on the ‘Regulation 
laying down rules to prevent and combat child sexual abuse’ (EU CSAM). 

We are particularly concerned about:

1. The restrictive language used in the new proposal implies that service 
providers offering encrypted services could still be compelled to undermine or 
circumvent end-to-end encryption using methods like client-side scanning (CSS).

2. The new wording introduced in Recital 26 narrows the definition and 
understanding of end-to-end encryption “as data in transit protected by means 
of encryption”, which subjects stored data to little protection and subsequent 
CSS.

The GEC-SC takes note of the Presidency’s efforts to unblock the negotiations 
by introducing new provisions aimed at protecting cyber security and encrypted 
data. However, the latest text maintains end-to-end encrypted services within 
the scope of detection orders and introduces restrictive interpretations of 
general concepts that are troublesome. We also take note of news released on 16 
April indicating that under the Presidency’s new proposal, messaging services 
encrypted end-to-end would be deemed “high risk” and thus subject to detection 
orders that would require providers to scan all messages on their encrypted 
service.

The latest proposal also modifies the language previously agreed under the 
Spanish presidency2 in Article 1(5) setting out the scope of the Regulation. 
Article 1(5) now states that “This Regulation shall not create any obligation 
that would require a provider of hosting services or a provider of 
interpersonal communications services to decrypt or create access to end-to-end 
encrypted data, or that would prevent the provision of end-to-end encrypted 
services.”

The Belgian Presidency attempts to address the concerns regarding the necessity 
of protecting encryption by explicitly stating that the Regulation does not 
oblige providers to break encryption or create backdoors. However, the 
restrictive language it uses implies that providers could still be compelled by 
the regulation to undermine or circumvent end-to-end encrypted mechanisms using 
alternative methods, such as deploying client-side scanning (CSS). Client-side 
scanning is fundamentally inconsistent with the promise and purpose of 
end-to-end encryption, which is that only the user and the intended recipients 
can access the contents of a communication encrypted end-to-end.

This concern is heightened by the proposed new wording inserted in Recital 26 
that narrowly defines end-to-end encryption technology, “as data in transit 
protected by the means of encryption”. This appears to be an attempt to remove 
stored data from the scope of E2EE services to leave it unprotected from the 
prohibition against breaking encryption so it can be subjected to client-side 
scanning. However, as acknowledged by the European Data Protection Supervisor 
and the European Data Protection Board in their Joint Opinion 4/2022, CSS 
inherently undermines cybersecurity and mitigation measures for which Recital 
26 calls cannot effectively address the risk posed by access to data for 
purposes such as scanning. 

The GEC-SC reiterates its long-standing position on CSS and recalls the latest 
landmark case of the European Court of Human Rights on Podchasov vs Russia. The 
ECtHR categorically confirmed that solutions that weaken encryption or create 
backdoors to facilitate access by law enforcement authorities to encrypted 
communication data violate the right to private life under Article 8 European 
Convention on Human Rights (ECHR) of all users.

The Court took a strong stance in favour of encryption by recognizing not only 
measures that break encryption, but also any measures that weaken the 
effectiveness and intended purpose of encryption. The Court took into 
consideration a number of sources from international bodies such as the Office 
of the United Nations High Commissioner for Human Rights and the Council of 
Europe inter alia, that state that techniques that weaken or circumvent 
security measures or exploit their existing weaknesses should be strictly 
prohibited just as much as mandated encryption backdoors. 

We call on the Member States to reject the Belgian Presidency’s proposal and to 
hew to the language adopted by the European Parliament which would exclude from 
the scope of this regulation any data to which end-to-end encryption is, has 
been or will be applied.
___
nexa

Re: [9fans] VCS on Plan9

2024-04-20 Thread Giacomo Tesio

Hi 9fans

Il 18 Aprile 2024 22:41:50 CEST, Dan Cross  ha scritto:
> 
> Git and Jujitsu are, frankly, superior

out of curiosity, to your knowedge, did anyone ever tried to port fossil scm
to Plan9 or 9front (even through ape)?

<https://fossil-scm.org/home/doc/trunk/www/index.wiki>

Also (tangential) did anybody tried to port Tiny-CC?


Giacomo

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-M85b3f817edeaf49c1634b730
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[nexa] Make your own backdoor: CFLAGS code injection, Makefile injection, config(was: [CDT:L-1] (supply chain attack) Anatomia di una "backdoor injection" (parte 2))

2024-04-17 Thread Giacomo Tesio

Ciao 380,

grazie per aver speso il tempo di scrivere questa ottima disanima: sei un 
ottimo divulgatore!

Aggiungo solo qualche considerazione:




Il 13 Aprile 2024 17:45:54 CEST, "380°" ha scritto:
> Perché build-to-host.m4 è uno dei diversi file autogenerati da autotools
> e autoconf e quei file non sono umanamente leggibili, [...]
> 
> La soluzione a questo /primo/ problema è facilissima, quindi: i
> "downstream consumer" devono semplicemente smetterla di essere _pigri_

Ovvero smettere di usare la procedura
```
./configure ...
make
make install
```
Giusto per chiarire la complessità della "soluzione facilissima" a chiunque 
abbia mai scaricato
e compilato un tar.gz

Direi che questo è un caso da manuale di soluzione semplice tutt'altro che 
facile. :-)


> Usando direttamente il codice preso dal VCS upstream si azzererebbero le
> possibilità di riuscire a nascondere un trojan (tipo build-to-host.m4)
> in grado di sovvertire il processo di build e fargli installare la
> backdoor a sua volta nascosta in file binari camuffati da file necessari
> per i test.

Purtroppo non basta lontanamente.

Leggi questo bell'esperimento mentale di Vegard Nossum 
<https://www.openwall.com/lists/oss-security/2024/04/17/3>

Cito solo la conclusione a seguito di 6 possibili mitigazioni (tutt'altro che 
facili) dell'attacco 
che Nossum ha ideato:

```
Even if we did all of this, it would of course still not be enough. 

The underlying problem is having things that are unreadable or unreviewable -- 
binary files, inscrutable code (whether shell scripts, makefiles, m4 code, or, 
in some cases, Perl code). 
```

Conclusione comunque parziale: più in generale se un qualunque software 
(kernel, libreria, 
script di build...) non può essere compreso interamente (in un tempo 
ragionevole)
qualunque sistema cibernetico che ne dipenda è vulnerabile e probabilmente già 
compromesso.

Il problema è la complessità.

Aggiungere complessità non lo risolverà, potrà solo nasconderlo.


Giacomo
___
nexa mailing list
nexa@server-nexa.polito.it
https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Re: [PATCH] m25p80: Add support for the GD25WQ32E flash

2024-04-14 Thread Giacomo Parmeggiani

PING

Hi all, could you have a look at this small patch?
See also:
https://patchew.org/QEMU/20240330203520.64892-1-giacomo.parmeggi...@gmail.com/

BR,
Giacomo Parmeggiani

On Sat, Mar 30, 2024 at 9:36 PM Giacomo Parmeggiani <
giacomo.parmeggi...@gmail.com> wrote:

> This introduces the GigaDevice GD25WQ32E flash, including the SFDP table
>
> Signed-off-by: Giacomo Parmeggiani 
> ---
>  hw/block/m25p80.c  |  2 ++
>  hw/block/m25p80_sfdp.c | 40 
>  hw/block/m25p80_sfdp.h |  2 ++
>  3 files changed, 44 insertions(+)
>
> diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
> index 8dec134832..6cc05b63e5 100644
> --- a/hw/block/m25p80.c
> +++ b/hw/block/m25p80.c
> @@ -205,6 +205,8 @@ static const FlashPartInfo known_devices[] = {
>  /* GigaDevice */
>  { INFO("gd25q32", 0xc84016,  0,  64 << 10,  64, ER_4K) },
>  { INFO("gd25q64", 0xc84017,  0,  64 << 10, 128, ER_4K) },
> +{ INFO("gd25wq32e",   0xc86516,  0,  64 << 10,  64, ER_4K),
> +  .sfdp_read = m25p80_sfdp_gd25wq32e },
>
>  /* Intel/Numonyx -- xxxs33b */
>  { INFO("160s33b", 0x898911,  0,  64 << 10,  32, 0) },
> diff --git a/hw/block/m25p80_sfdp.c b/hw/block/m25p80_sfdp.c
> index 6ee2cfaf11..cb0963328d 100644
> --- a/hw/block/m25p80_sfdp.c
> +++ b/hw/block/m25p80_sfdp.c
> @@ -406,3 +406,43 @@ static const uint8_t sfdp_is25wp256[] = {
>  0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
>  };
>  define_sfdp_read(is25wp256);
> +
> +/*
> + * GigaDevice
> + */
> +
> +static const uint8_t sfdp_gd25wq32e[] = {
> +0x53, 0x46, 0x44, 0x50, 0x06, 0x01, 0x01, 0xff,
> +0x00, 0x06, 0x01, 0x10, 0x30, 0x00, 0x00, 0xff,
> +0xc8, 0x00, 0x01, 0x03, 0x90, 0x00, 0x00, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xe5, 0x20, 0xf1, 0xff, 0xff, 0xff, 0xff, 0x01,
> +0x44, 0xeb, 0x08, 0x6b, 0x08, 0x3b, 0x42, 0xbb,
> +0xee, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0xff,
> +0xff, 0xff, 0x00, 0xff, 0x0c, 0x20, 0x0f, 0x52,
> +0x10, 0xd8, 0x00, 0xff, 0x63, 0x92, 0xfd, 0xfe,
> +0x83, 0x2f, 0x26, 0x46, 0xec, 0x82, 0x18, 0x44,
> +0x7a, 0x75, 0x7a, 0x75, 0x04, 0xbd, 0xd5, 0x5c,
> +0x00, 0x06, 0x64, 0x00, 0x08, 0x10, 0x00, 0x00,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0x00, 0x36, 0x50, 0x16, 0x9e, 0xf9, 0x77, 0x64,
> +0xfc, 0xcb, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
> +};
> +define_sfdp_read(gd25wq32e);
> diff --git a/hw/block/m25p80_sfdp.h b/hw/block/m25p80_sfdp.h
> index 1733b56950..7d1f60f2ee 100644
> --- a/hw/block/m25p80_sfdp.h
> +++ b/hw/block/m25p80_sfdp.h
> @@ -29,4 +29,6 @@ uint8_t m25p80_sfdp_w25q01jvq(uint32_t addr);
>
>  uint8_t m25p80_sfdp_is25wp256(uint32_t addr);
>
> +uint8_t m25p80_sfdp_gd25wq32e(uint32_t addr);
> +
>  #endif
> --
> 2.32.1 (Apple Git-133)
>
>

-- 
*Giacomo Parmeggiani*

Re: [PATCH] m25p80: Add support for the GD25WQ32E flash

2024-04-14 Thread Giacomo Parmeggiani

PING

Hi all, could you have a look at this small patch?
See also:
https://patchew.org/QEMU/20240330203520.64892-1-giacomo.parmeggi...@gmail.com/

BR,
Giacomo Parmeggiani

On Sat, Mar 30, 2024 at 9:36 PM Giacomo Parmeggiani <
giacomo.parmeggi...@gmail.com> wrote:

> This introduces the GigaDevice GD25WQ32E flash, including the SFDP table
>
> Signed-off-by: Giacomo Parmeggiani 
> ---
>  hw/block/m25p80.c  |  2 ++
>  hw/block/m25p80_sfdp.c | 40 
>  hw/block/m25p80_sfdp.h |  2 ++
>  3 files changed, 44 insertions(+)
>
> diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
> index 8dec134832..6cc05b63e5 100644
> --- a/hw/block/m25p80.c
> +++ b/hw/block/m25p80.c
> @@ -205,6 +205,8 @@ static const FlashPartInfo known_devices[] = {
>  /* GigaDevice */
>  { INFO("gd25q32", 0xc84016,  0,  64 << 10,  64, ER_4K) },
>  { INFO("gd25q64", 0xc84017,  0,  64 << 10, 128, ER_4K) },
> +{ INFO("gd25wq32e",   0xc86516,  0,  64 << 10,  64, ER_4K),
> +  .sfdp_read = m25p80_sfdp_gd25wq32e },
>
>  /* Intel/Numonyx -- xxxs33b */
>  { INFO("160s33b", 0x898911,  0,  64 << 10,  32, 0) },
> diff --git a/hw/block/m25p80_sfdp.c b/hw/block/m25p80_sfdp.c
> index 6ee2cfaf11..cb0963328d 100644
> --- a/hw/block/m25p80_sfdp.c
> +++ b/hw/block/m25p80_sfdp.c
> @@ -406,3 +406,43 @@ static const uint8_t sfdp_is25wp256[] = {
>  0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
>  };
>  define_sfdp_read(is25wp256);
> +
> +/*
> + * GigaDevice
> + */
> +
> +static const uint8_t sfdp_gd25wq32e[] = {
> +0x53, 0x46, 0x44, 0x50, 0x06, 0x01, 0x01, 0xff,
> +0x00, 0x06, 0x01, 0x10, 0x30, 0x00, 0x00, 0xff,
> +0xc8, 0x00, 0x01, 0x03, 0x90, 0x00, 0x00, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xe5, 0x20, 0xf1, 0xff, 0xff, 0xff, 0xff, 0x01,
> +0x44, 0xeb, 0x08, 0x6b, 0x08, 0x3b, 0x42, 0xbb,
> +0xee, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0xff,
> +0xff, 0xff, 0x00, 0xff, 0x0c, 0x20, 0x0f, 0x52,
> +0x10, 0xd8, 0x00, 0xff, 0x63, 0x92, 0xfd, 0xfe,
> +0x83, 0x2f, 0x26, 0x46, 0xec, 0x82, 0x18, 0x44,
> +0x7a, 0x75, 0x7a, 0x75, 0x04, 0xbd, 0xd5, 0x5c,
> +0x00, 0x06, 0x64, 0x00, 0x08, 0x10, 0x00, 0x00,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0x00, 0x36, 0x50, 0x16, 0x9e, 0xf9, 0x77, 0x64,
> +0xfc, 0xcb, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
> +};
> +define_sfdp_read(gd25wq32e);
> diff --git a/hw/block/m25p80_sfdp.h b/hw/block/m25p80_sfdp.h
> index 1733b56950..7d1f60f2ee 100644
> --- a/hw/block/m25p80_sfdp.h
> +++ b/hw/block/m25p80_sfdp.h
> @@ -29,4 +29,6 @@ uint8_t m25p80_sfdp_w25q01jvq(uint32_t addr);
>
>  uint8_t m25p80_sfdp_is25wp256(uint32_t addr);
>
> +uint8_t m25p80_sfdp_gd25wq32e(uint32_t addr);
> +
>  #endif
> --
> 2.32.1 (Apple Git-133)
>
>

-- 
*Giacomo Parmeggiani*

Re: [nexa] [CDT:L-1] (supply chain attack) Backdoor su Xz: il problema è molto più grande... (parte 1)

2024-04-12 Thread Giacomo Tesio

Salve 380,

come Antonio, ho seguito la questione nel suo svilupparsi, con un misto di 
tristezza 
e divertimento, tanto da aver preceduto Schneier   [1].

Si tratta però di ovvietà: centinaia di simili backdoor sono correntemente in 
produzione.
Forse migliaia.

Solo i professionisti del InfoSec possono fingere di credere il contrario (da 
cui il dramma
inscenato online).


Tuttavia, tutte le analisi che ho letto sull'attacco subito da OpenSSH tramite 
SystemD 
tramite XZ sono basate sulle stesse assunzioni che hanno reso possibile 
l'attacco.

Alla base di questo castello di assunzioni c'è l'accettazione della enorme 
complessità
degli stack applicativi mainstream, in cui nascondere una backdoor è facilissimo
anche se (de)i sorgenti sono disponibili.


Le libertà promesse dal software libero (e ancor più da quello opensource) sono
sistematicamente vanificate dalla complessità che lo caratterizzano.

Se una persona adulta non può leggere e comprendere interamente un software
in (al massimo) un mese, quel software è irrimediabilmente vulnerabile e
probabilmente compromesso.


Il resto sono favolette consolatorie.


Non è un problema dell'FLOSS.
Non è un problema di autoconf.
Non è nemmeno un problema di riproducibilità delle build.

C'è un problema di sfruttamento degli sviluppatori volontari, ma risolverlo
non risolverà il problema.


Il problema è cibernetico e culturale, non tecnico o economico.

Dovremmo ristudiare Wirth: https://www.projectoberon.net/


Giacomo

[1] https://qoto.org/@Shamar/112195245691551523
___
nexa mailing list
nexa@server-nexa.polito.it
https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Bug#1068786: ITS: latencytop

2024-04-11 Thread Giacomo Catenazzi


Hello,

You, or other DD or DM can take maintainership of it. Zero objections.

ciao

    cate



On 2024-04-11 2:41, Boyuan Yang wrote:

Source: latencytop
Version: 0.5.0-0.1
Severity: important
X-Debbugs-CC: c...@debian.org

Dear package latencytop maintainer in Debian,

After looking into the package you maintain (latencytop,
https://tracker.debian.org/pkg/latencytop), I found that this package
received no maintainer updates in the past 14 years and is not in good
shape. As a result, I am filing an ITS (Intent to Salvage) request
against your package according to section 5.12 in Debian's Developers'
Reference [1].

My current plan is to refresh packaging and fix all RC bugs.

Please let me know whether you are still willing to maintain this
package. According to the criteria listed at [2], I will upload a Non-
maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days
(May 01, 2024) to continue with the package salvaging. If you find it
necessary to pause the ITS process, please let me know immediately by
replying this bug report.


[1]
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://wiki.debian.org/PackageSalvaging

Re: [nexa] "‘Lavender’: The AI machine directing Israel’s bombing spree in Gaza"

2024-04-07 Thread Giacomo Tesio

Il 6 Aprile 2024 16:10:51 CEST, Guido Vetere ha scritto:
> 
> | migliaia di palestinesi [...] sono stati spazzati via dai bombardamenti
> israeliani, [...] *a causa delle decisioni dell’intelligenza artificiale*
> 
> [...]  mi sembra che questa formulazione alimenti un
> 'fumus' molto denso nelle discussioni su etica e AI che ascoltiamo in
> questi tempi
> [...]
>
> A me sembra che in questo caso l'AI sia stata arruolata in una operazione
> di propaganda

L'idea di "intelligenza artificiale" stessa è un'operazione di propaganda e 
distrazione di massa. Da sempre.

Se parlassimo più propriamente di software programmato statisticamente, tutte
le responsabilità umane sarebbero chiaramente riconducibili:

- a chi finanzia la programmazione
- a chi la effettua
- a chi esegue il software
- a chi fornisce l'input
- a chi interpreta l'output

Questo vale per le manipolazioni cognitive subite da chi usa GMail o Instagram, 
quanto per quelle
subite da chi usa GitHub CopyALot o GPT4, fino al giornalista che si interroga 
sull'etica della 
AI invece di sottolineare il genocidio in corso ad opera di Israele.


In questo caso, tutti i responsabili andrebbero processate per crimini di 
guerra e genocidio.

Esattamente come i dirigenti e gli sviluppatori di Uber sarebbero dovuti essere 
condanati
per l'omicidio di Elaine Herzberg, quelli di Boing per le vittime del 747 Max e 
quelli di Tesla per gli incidenti causati dal autopilot.


Si tratta di software.
Niente di più e niente di meno.
E come tutto il software, esegue ciò per cui è programmato, statisticamente o 
meno.

Anche uccidere.


Parlare della "AI" serve solo a buttare fumo negli occhi per proteggere 
criminali.


Giacomo
___
nexa mailing list
nexa@server-nexa.polito.it
https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Bug#1068445: libllvm17t64: misaligned versions between amd64 and i386 make them uninstallable simultaneously

2024-04-05 Thread Giacomo Mulas

Package: libllvm17t64
Version: 1:17.0.6-9
Severity: normal

Dear Maintainer,

with the latest update, libllvm17t64 has been released in different versions 
between amd64 and i386 (1:17.0.6-9+b2 and 1:17.0.6-9+b1). This makes them 
uninstallable simultaneously, since each breaks any other lib for other archs 
unless they are exactly the same version. Please do a NMU, even without any 
changes, just making sure versions are aligned.

Thanks, best regards


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (401, 'unstable'), (10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.9-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libllvm17t64 depends on:
ii  libc6   2.37-15.1
ii  libedit23.1-20230828-1
ii  libffi8 3.4.6-1
ii  libgcc-s1   14-20240330-1
ii  libstdc++6  14-20240330-1
ii  libtinfo6   6.4+20240113-1
ii  libxml2 2.9.14+dfsg-1.3+b2
ii  libz3-4 4.8.12-3.1+b2
ii  libzstd11.5.5+dfsg2-2
ii  zlib1g  1:1.3.dfsg-3.1

libllvm17t64 recommends no packages.

libllvm17t64 suggests no packages.

-- no debconf information

[jira] [Commented] (CXF-8987) Java 21 - HttpClientHTTPConduit thread locked during shutdown

2024-04-03 Thread Giacomo Carnevale (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833499#comment-17833499
 ] 

Giacomo Carnevale commented on CXF-8987:


Hi

same problem with OpenJdk 22

openjdk version "22" 2024-03-19
OpenJDK Runtime Environment (build 22+36-2370)
OpenJDK 64-Bit Server VM (build 22+36-2370, mixed mode, sharing)

 
|*Java Stack*|at java.lang.Object.wait0(java.base@22/Native Method)
- waiting on [no object reference available]
at java.lang.Object.wait(java.base@22/Object.java:375)
at java.lang.Thread.join(java.base@22/Thread.java:2039)
- locked [0x000618372e08] (a 
jdk.internal.net.http.HttpClientImpl$SelectorManager)
at java.lang.Thread.join(java.base@22/Thread.java:2167)
at 
jdk.internal.net.http.HttpClientImpl.awaitTermination(java.net.http@22/HttpClientImpl.java:632)
at java.net.http.HttpClient.close(java.net.http@22/HttpClient.java:900)
at 
jdk.internal.net.http.HttpClientFacade.close(java.net.http@22/HttpClientFacade.java:192)
at 
org.apache.cxf.transport.http.HttpClientHTTPConduit.close(HttpClientHTTPConduit.java:125)
at 
org.apache.cxf.endpoint.AbstractConduitSelector.close(AbstractConduitSelector.java:77)
at org.apache.cxf.endpoint.ClientImpl.destroy(ClientImpl.java:177)
at org.apache.camel.component.cxf.jaxws.CxfProducer.doStop(CxfProducer.java:93)
at org.apache.camel.support.service.BaseService.stop(BaseService.java:154)|

 

My workaround is to set system property 
org.apache.cxf.transport.http.forceURLConnection=true

> Java 21 - HttpClientHTTPConduit thread locked during shutdown 
> --
>
> Key: CXF-8987
> URL: https://issues.apache.org/jira/browse/CXF-8987
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 4.0.3, 4.0.4
> Environment: [^thdump2]
> *OpenJDK 21.0.2*
> *Apache CXF 4.0.4*
> *Apache Camel 4.4.1*
>Reporter: Giacomo Carnevale
>Priority: Blocker
> Attachments: thdump2
>
>
> Hi,
> I am using Apache CXF client via the Apache Camel CXF connector.
> After I updated frm OpenJDK 17.x to OpenJDK 21.0.2, during application 
> shutdown, the following lock occurs:
> *at java.lang.Thread.join(java.base@21.0.2/Thread.java:2072)*
>     *- locked <0x00061cd2ab80> (a 
> jdk.internal.net.http.HttpClientImpl$SelectorManager)*
>     *at java.lang.Thread.join(java.base@21.0.2/Thread.java:2200)*
>     *at 
> jdk.internal.net.http.HttpClientImpl.awaitTermination(java.net.http@21.0.2/HttpClientImpl.java:628)*
>     *at 
> java.net.http.HttpClient.{color:#de350b}close{color}(java.net.http@21.0.2/HttpClient.java:900)*
>     *at 
> jdk.internal.net.http.HttpClientFacade.{color:#de350b}close{color}(java.net.http@21.0.2/HttpClientFacade.java:192)*
>     *at 
> org.apache.cxf.transport.http.HttpClientHTTPConduit.{color:#de350b}close{color}(HttpClientHTTPConduit.java:125)*
> HttpClientHTTPConduit.close
> {code:java}
> public void close() {
> if (client instanceof AutoCloseable) {
> try {
> ((AutoCloseable)client).close();
> } catch (Exception e) {
> //ignore
> }
> } else if (client != null) {
> String name = client.toString();
> client = null;
> tryToShutdownSelector(name);
> }
> defaultAddress = null;
> super.close();
> } {code}
>  
> java.net.HttpClient.close
>  
> {code:java}
> public void close() {
> boolean terminated = isTerminated();
> if (!terminated) {
> shutdown();
> boolean interrupted = false;
> while (!terminated) {
> try {
> terminated = awaitTermination(Duration.ofDays(1L));
> } catch (InterruptedException e) {
> if (!interrupted) {
> interrupted = true;
> shutdownNow();
> if (isTerminated()) break;
> }
> }
> }
> if (interrupted) {
> Thread.currentThread().interrupt();
> }
> }
> } {code}
> My workaround
> {code:java}
> public void close() {
> if (client instanceof AutoCloseable) {
> try {
> client.shutdownNow();
> //((AutoCloseable)client).close();
> } catch (Exception e) {
> //ignore
> }
> } else if (client != null) {
> String name = client.toString();
> client = null;
> tryToShutdownSelector(name);
> }
> defaultAddress = null;
> super.close();
> } {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-8931) HttpClientHTTPConduit can't disable the http chunk mode

2024-04-02 Thread Giacomo Boccardo (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833176#comment-17833176
 ] 

Giacomo Boccardo commented on CXF-8931:
---

Using 3.6.3, I'm experiencing the following absurd behavior:
* not calling setAllowChunking(): NOT chunked;
* setAllowChunking(true): NOT chunked;
* setAllowChunking(false): chunked.

I also tried setting the old default HTTP client using 
"force.urlconnection.http.conduit" set to true, but I had the same outcome.

> HttpClientHTTPConduit can't disable the http chunk mode
> ---
>
> Key: CXF-8931
> URL: https://issues.apache.org/jira/browse/CXF-8931
> Project: CXF
>  Issue Type: Bug
>Reporter: Jim Ma
>Assignee: Jim Ma
>Priority: Major
>
> This works with URLConnectionHttpConduit, but this doesn't work with the new 
> HttpClientHTTPConduit. When set the HttpClientPolicy.setAllowChunking(false)
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[PATCH] m25p80: Add support for the GD25WQ32E flash

2024-03-30 Thread Giacomo Parmeggiani

This introduces the GigaDevice GD25WQ32E flash, including the SFDP table

Signed-off-by: Giacomo Parmeggiani 
---
 hw/block/m25p80.c  |  2 ++
 hw/block/m25p80_sfdp.c | 40 
 hw/block/m25p80_sfdp.h |  2 ++
 3 files changed, 44 insertions(+)

diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
index 8dec134832..6cc05b63e5 100644
--- a/hw/block/m25p80.c
+++ b/hw/block/m25p80.c
@@ -205,6 +205,8 @@ static const FlashPartInfo known_devices[] = {
 /* GigaDevice */
 { INFO("gd25q32", 0xc84016,  0,  64 << 10,  64, ER_4K) },
 { INFO("gd25q64", 0xc84017,  0,  64 << 10, 128, ER_4K) },
+{ INFO("gd25wq32e",   0xc86516,  0,  64 << 10,  64, ER_4K),
+  .sfdp_read = m25p80_sfdp_gd25wq32e },
 
 /* Intel/Numonyx -- xxxs33b */
 { INFO("160s33b", 0x898911,  0,  64 << 10,  32, 0) },
diff --git a/hw/block/m25p80_sfdp.c b/hw/block/m25p80_sfdp.c
index 6ee2cfaf11..cb0963328d 100644
--- a/hw/block/m25p80_sfdp.c
+++ b/hw/block/m25p80_sfdp.c
@@ -406,3 +406,43 @@ static const uint8_t sfdp_is25wp256[] = {
 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
 };
 define_sfdp_read(is25wp256);
+
+/*
+ * GigaDevice
+ */
+
+static const uint8_t sfdp_gd25wq32e[] = {
+0x53, 0x46, 0x44, 0x50, 0x06, 0x01, 0x01, 0xff,
+0x00, 0x06, 0x01, 0x10, 0x30, 0x00, 0x00, 0xff,
+0xc8, 0x00, 0x01, 0x03, 0x90, 0x00, 0x00, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xe5, 0x20, 0xf1, 0xff, 0xff, 0xff, 0xff, 0x01,
+0x44, 0xeb, 0x08, 0x6b, 0x08, 0x3b, 0x42, 0xbb,
+0xee, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0xff,
+0xff, 0xff, 0x00, 0xff, 0x0c, 0x20, 0x0f, 0x52,
+0x10, 0xd8, 0x00, 0xff, 0x63, 0x92, 0xfd, 0xfe,
+0x83, 0x2f, 0x26, 0x46, 0xec, 0x82, 0x18, 0x44,
+0x7a, 0x75, 0x7a, 0x75, 0x04, 0xbd, 0xd5, 0x5c,
+0x00, 0x06, 0x64, 0x00, 0x08, 0x10, 0x00, 0x00,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0x00, 0x36, 0x50, 0x16, 0x9e, 0xf9, 0x77, 0x64,
+0xfc, 0xcb, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
+};
+define_sfdp_read(gd25wq32e);
diff --git a/hw/block/m25p80_sfdp.h b/hw/block/m25p80_sfdp.h
index 1733b56950..7d1f60f2ee 100644
--- a/hw/block/m25p80_sfdp.h
+++ b/hw/block/m25p80_sfdp.h
@@ -29,4 +29,6 @@ uint8_t m25p80_sfdp_w25q01jvq(uint32_t addr);
 
 uint8_t m25p80_sfdp_is25wp256(uint32_t addr);
 
+uint8_t m25p80_sfdp_gd25wq32e(uint32_t addr);
+
 #endif
-- 
2.32.1 (Apple Git-133)

[PATCH] m25p80: Add support for the GD25WQ32E flash

2024-03-30 Thread Giacomo Parmeggiani

This introduces the GigaDevice GD25WQ32E flash, including the SFDP table

Signed-off-by: Giacomo Parmeggiani 
---
 hw/block/m25p80.c  |  2 ++
 hw/block/m25p80_sfdp.c | 40 
 hw/block/m25p80_sfdp.h |  2 ++
 3 files changed, 44 insertions(+)

diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
index 8dec134832..6cc05b63e5 100644
--- a/hw/block/m25p80.c
+++ b/hw/block/m25p80.c
@@ -205,6 +205,8 @@ static const FlashPartInfo known_devices[] = {
 /* GigaDevice */
 { INFO("gd25q32", 0xc84016,  0,  64 << 10,  64, ER_4K) },
 { INFO("gd25q64", 0xc84017,  0,  64 << 10, 128, ER_4K) },
+{ INFO("gd25wq32e",   0xc86516,  0,  64 << 10,  64, ER_4K),
+  .sfdp_read = m25p80_sfdp_gd25wq32e },
 
 /* Intel/Numonyx -- xxxs33b */
 { INFO("160s33b", 0x898911,  0,  64 << 10,  32, 0) },
diff --git a/hw/block/m25p80_sfdp.c b/hw/block/m25p80_sfdp.c
index 6ee2cfaf11..cb0963328d 100644
--- a/hw/block/m25p80_sfdp.c
+++ b/hw/block/m25p80_sfdp.c
@@ -406,3 +406,43 @@ static const uint8_t sfdp_is25wp256[] = {
 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
 };
 define_sfdp_read(is25wp256);
+
+/*
+ * GigaDevice
+ */
+
+static const uint8_t sfdp_gd25wq32e[] = {
+0x53, 0x46, 0x44, 0x50, 0x06, 0x01, 0x01, 0xff,
+0x00, 0x06, 0x01, 0x10, 0x30, 0x00, 0x00, 0xff,
+0xc8, 0x00, 0x01, 0x03, 0x90, 0x00, 0x00, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xe5, 0x20, 0xf1, 0xff, 0xff, 0xff, 0xff, 0x01,
+0x44, 0xeb, 0x08, 0x6b, 0x08, 0x3b, 0x42, 0xbb,
+0xee, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0xff,
+0xff, 0xff, 0x00, 0xff, 0x0c, 0x20, 0x0f, 0x52,
+0x10, 0xd8, 0x00, 0xff, 0x63, 0x92, 0xfd, 0xfe,
+0x83, 0x2f, 0x26, 0x46, 0xec, 0x82, 0x18, 0x44,
+0x7a, 0x75, 0x7a, 0x75, 0x04, 0xbd, 0xd5, 0x5c,
+0x00, 0x06, 0x64, 0x00, 0x08, 0x10, 0x00, 0x00,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0x00, 0x36, 0x50, 0x16, 0x9e, 0xf9, 0x77, 0x64,
+0xfc, 0xcb, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
+};
+define_sfdp_read(gd25wq32e);
diff --git a/hw/block/m25p80_sfdp.h b/hw/block/m25p80_sfdp.h
index 1733b56950..7d1f60f2ee 100644
--- a/hw/block/m25p80_sfdp.h
+++ b/hw/block/m25p80_sfdp.h
@@ -29,4 +29,6 @@ uint8_t m25p80_sfdp_w25q01jvq(uint32_t addr);
 
 uint8_t m25p80_sfdp_is25wp256(uint32_t addr);
 
+uint8_t m25p80_sfdp_gd25wq32e(uint32_t addr);
+
 #endif
-- 
2.32.1 (Apple Git-133)

Bug#1067738: fixed with 3.7.1-1

2024-03-28 Thread Giacomo Mulas


Today, dist-upgrade brought to sid the new upstream release of tracker,
namely 3.7.1-1. With that, the problem I had reported disappeared: now
tracker-miner-fs runs for a finite time, and produces a working database.
The command tracker3 status now runs correctly, as do nautilus searches
using tracker3.

Thanks, best regards
Giacomo Mulas

--
_

Giacomo Mulas 
_

INAF - Osservatorio Astronomico di Cagliari
via della scienza 5 - 09047 Selargius (CA)

tel.   +39 070 71180255
mob. : +39 329  6603810
_

"every year keeps getting shorter, never seem to find the time
 plans that either come to naught, or half a page of scribbled lines
 the time is gone, the song is over, thought I'd something more to say"
 (Pink Floyd)
_

[Bug 2058133] Re: [SRU] update-manager crashes when ua security-status response is an error

2024-03-27 Thread Giacomo Massa

Hi Timo and everybody, just tested the proposed package for Jammy
(22.04.4), version 1:22.04.20 and it fixes the bug for me same as it did
applying the patch directly to UpdateManager.py before.

Preliminary:
- reverted UpdateManager.py to its original nonworking state
> bug is present

-updated the package to proposed version, then

Testing procedure:

mv /snap/bin/canonical-livepatch /snap/bin/canonical-livepatch.bak
>/snap/bin/canonical-livepatch printf '%s\n' '#!/bin/sh' 'exit 1'
chmod +x /snap/bin/canonical-livepatch
update-manager -c -d

Results:
software opens, runs and gives results without crashing.

** Tags removed: verification-needed-jammy
** Tags added: verification-done-jammy

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

Title:
  [SRU] update-manager crashes when ua security-status response is an
  error

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/2058133/+subscriptions


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

Bug#1067738: tracker-miner-fs: /usr/libexec/tracker-miner-fs-3 uses 100% cpu, crashes, restarts endlessly

2024-03-26 Thread Giacomo Mulas

Package: tracker-miner-fs
Version: 3.7.0-1
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation? A recent dist-upgrade on my sid laptop
   * What exactly did you do (or not do) that was effective (or
 ineffective)? tried killing the offending process, removing 
.cache/tracker3, stopping the service, none worked
   * What was the outcome of this action? regardless of what I do, tracker does 
not stop, nor does it actually work, it does not respond even to tracker3 status
   * What outcome did you expect instead? working indexing, 
/usr/libexec/tracker-miner-fs-3 running for a finite time and producing an index

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (401, 'unstable'), (10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.9-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tracker-miner-fs depends on:
ii  init-system-helpers  1.66
ii  libblkid12.39.3-10
ii  libc62.37-15.1
ii  libglib2.0-0t64  2.78.4-6
ii  libgstreamer1.0-01.24.1-1
ii  libtracker-sparql-3.0-0  3.7.0-1
ii  libupower-glib3  1.90.2-8+b1
ii  procps   2:4.0.4-4
ii  tracker  3.7.0-1
ii  tracker-extract  3.7.0-1

tracker-miner-fs recommends no packages.

tracker-miner-fs suggests no packages.

-- no debconf information

[plasmashell] [Bug 483163] blank screen on lock screen activation when using breeze plasma style

2024-03-25 Thread Giacomo Lozito

https://bugs.kde.org/show_bug.cgi?id=483163

Giacomo Lozito  changed:

   What|Removed |Added

 CC||giacomo.lozito@protonmail.c
   ||om

-- 
You are receiving this mail because:
You are watching all bug changes.

[Bug 2058133] Re: [SRU] update-manager crashes when ua security-status response is an error

2024-03-23 Thread Giacomo Massa

I don't know if this helps but I've tested the patch
https://code.launchpad.net/~nteodosio/update-manager/+git/update-
manager/+ref/jammy-json-to-api for Jammy by nteodosio and it fixes the
problem.

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

Title:
  [SRU] update-manager crashes when ua security-status response is an
  error

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/2058133/+subscriptions


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

[Bug 2058133] Re: update-manager crashes when ua security-status response is an error

2024-03-21 Thread Giacomo Massa

Hi Nathan, here is the output from the python3 command as requested:

[UpdateInfo{'download_size': 3590030, 'origin': 'it.archive.ubuntu.com',
'package': 'librados2', 'provided_by': 'standard-updates', 'status':
'upgrade_available', 'version': '17.2.7-0ubuntu0.22.04.1'},
UpdateInfo{'download_size': 3547412, 'origin': 'it.archive.ubuntu.com',
'package': 'librbd1', 'provided_by': 'standard-updates', 'status':
'upgrade_available', 'version': '17.2.7-0ubuntu0.22.04.1'},
UpdateInfo{'download_size': 115463212, 'origin': 'brave-browser-apt-
release.s3.brave.com', 'package': 'brave-browser', 'provided_by':
'standard-updates', 'status': 'upgrade_available', 'version':
'1.64.109'}, UpdateInfo{'download_size': 2412, 'origin':
'it.archive.ubuntu.com', 'package': 'linux-image-oem-22.04c',
'provided_by': 'standard-security', 'status': 'upgrade_available',
'version': '6.1.0.1036.37'}, UpdateInfo{'download_size': 1674, 'origin':
'it.archive.ubuntu.com', 'package': 'linux-modules-ipu6-oem-22.04b',
'provided_by': 'standard-security', 'status': 'upgrade_available',
'version': '6.1.0.1036.37'}, UpdateInfo{'download_size': 2370, 'origin':
'it.archive.ubuntu.com', 'package': 'linux-modules-ipu6-oem-22.04c',
'provided_by': 'standard-security', 'status': 'upgrade_available',
'version': '6.1.0.1036.37'}, UpdateInfo{'download_size': 1654, 'origin':
'it.archive.ubuntu.com', 'package': 'linux-oem-22.04b', 'provided_by':
'standard-security', 'status': 'upgrade_available', 'version':
'6.1.0.1036.37'}, UpdateInfo{'download_size': 1710, 'origin':
'it.archive.ubuntu.com', 'package': 'linux-oem-22.04c', 'provided_by':
'standard-security', 'status': 'upgrade_available', 'version':
'6.1.0.1036.37'}, UpdateInfo{'download_size': 2284, 'origin':
'it.archive.ubuntu.com', 'package': 'linux-headers-oem-22.04c',
'provided_by': 'standard-security', 'status': 'upgrade_available',
'version': '6.1.0.1036.37'}, UpdateInfo{'download_size': 1674, 'origin':
'it.archive.ubuntu.com', 'package': 'linux-modules-ivsc-oem-22.04b',
'provided_by': 'standard-security', 'status': 'upgrade_available',
'version': '6.1.0.1036.37'}, UpdateInfo{'download_size': 2378, 'origin':
'it.archive.ubuntu.com', 'package': 'linux-modules-ivsc-oem-22.04c',
'provided_by': 'standard-security', 'status': 'upgrade_available',
'version': '6.1.0.1036.37'}]

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

Title:
  update-manager crashes when ua security-status response is an error

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/2058133/+subscriptions


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

[Bug 2058133] Re: update-manager applet does exit successfully

2024-03-21 Thread Giacomo Massa

Hi, I've reported duplicate bug 2058158. I post the output of `pro
security-status --format=json` below and attach as text file my ubuntu-
avantage log.

Unexpected error(s) occurred.
For more details, see the log: /var/log/ubuntu-advantage.log
To file a bug run: ubuntu-bug ubuntu-advantage-tools


** Attachment added: "ubuntu-advantage.log"
   
https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/2058133/+attachment/5757859/+files/ubuntu-advantage.log

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

Title:
  update-manager applet does exit successfully

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/2058133/+subscriptions


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

[Bug 2058285] Re: update-manager crashes when started

2024-03-21 Thread Giacomo Massa

Hi, this is the output of `pro security-status --format=json` as
requested:

Unexpected error(s) occurred.
For more details, see the log: /var/log/ubuntu-advantage.log
To file a bug run: ubuntu-bug ubuntu-advantage-tools

I attach the log as text file.

** Attachment added: "ubuntu-advantage.log"
   
https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/2058285/+attachment/5757855/+files/ubuntu-advantage.log

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

Title:
  update-manager crashes when started

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/2058285/+subscriptions


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

[Bug 2058285] [NEW] update-manager crashes when started

2024-03-18 Thread Giacomo Massa

Public bug reported:

When started either via launcher or cli update-manager downloads
informations from sources and crashes when the operation is terminated,
just before showing the package list.

This happens since the update from update-manager version 1:22.04.18 to
1:22.04.19, done yesterday.

Updates via apt or apt-get cli commands work regularly.

Description:Ubuntu 22.04.4 LTS
Release:22.04

Package: update-manager 1:22.04.19

Expected behaviour: after sources' interrogation, the software should
either tell no updates are available or show pending updates.

Observed behaviour: the software checks for updates then crashes before
showing any results.

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: update-manager 1:22.04.19
ProcVersionSignature: Ubuntu 6.1.0-1035.35-oem 6.1.78
Uname: Linux 6.1.0-1035-oem x86_64
ApportVersion: 2.20.11-0ubuntu82.5
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Mon Mar 18 22:02:14 2024
DistributionChannelDescriptor:
 # This is the distribution channel descriptor for the OEM CDs
 # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor
 canonical-oem-somerville-jammy-amd64-20220504-33
InstallationDate: Installed on 2024-01-27 (51 days ago)
InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - 
somerville-jammy-amd64-20220504-33
PackageArchitecture: all
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=it_IT.UTF-8
 SHELL=/bin/bash
SourcePackage: update-manager
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: update-manager (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug jammy wayland-session

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

Title:
  update-manager crashes when started

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/2058285/+subscriptions


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

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

2024-03-18 Thread Giacomo Pope

To make discussion on this point easier, I have made a GitHub 
issue: https://github.com/sagemath/sage/issues/37626

For progress on this code, we have all doctests passing from the old 
implementation except:

- we cannot define toric varieties over rings, so we can't have 
hyperelliptic curves over rings
- we cannot use the current rational_points method from algebraic_schemes 
due to missing methods in the homset of toric varieties

We are also working on pairings as well as isomorphisms on top of 
supporting all older features.

On Friday, March 15, 2024 at 6:47:02 PM UTC Giacomo Pope wrote:

> Back again with more class questions and general advice help
>
> While getting all the old sage code into this new project, I realised 
> there are places where we really rely on the underlying curve classes. One 
> example is that we need
>
> ```
> def dimension():
> return 1
> ```
>
> To avoid some crashes, but more generally we also need `rational_points()` 
> which lives all the way inside `Algebraic_scheme`. There's also a whole 
> bunch of other things...
>
> I started exploring more and I found `Curve_generic` which we can create 
> with the data I already have:
>
> ```
> sage: H = HyperellipticCurveSmoothModel(x^5 + x + 1)
> sage: C = Curve_generic(H._projective_model.ambient_space(), 
> H._projective_model.defining_polynomials())
> sage: type(C)
> 
> sage: C
> Generic Curve over Rational Field defined by -X^5*Z - X*Z^5 - Z^6 + Y^2
> sage: C.ambient_space()
> 2-d toric variety covered by 3 affine patches
> ```
>
> this gets us some of the way and I think is an OK starting point, but then 
> things like asking for the curve crash for weighted projective space:
>
> ```
> sage: Curve(H)
> ---
> TypeError Traceback (most recent call last)
> .
> TypeError: ambient space neither affine nor projective
> ```
>
> and calls to things like C.rational_points() have more issues
>
> ```
> sage: C.rational_points(bounds=2)
> ---
> KeyError  Traceback (most recent call last)
> .
> AttributeError: 'SchemeHomset_points_subscheme_toric_field_with_category' 
> object has no attribute 'points'
> ```
>
> Which just goes to show that these toric varieties are a little 
> underdeveloped.
>
> Something which might be really nice would be 
>
> ```
> class WeightedProjectiveCurve(Curve_generic, 
> AlgebraicScheme_subscheme_toric):
> ```
>
> Intended to mirror the similar:
>
> ```
> class ProjectiveCurve(Curve_generic, AlgebraicScheme_subscheme_projective):
> ```
>
> This could then be the class which is inherited by the Hyperelliptic curve 
> class and we could aim for better coverage here.
>
> Any opinions on this? Any idea of people who might have thought about or 
> made progress in this area?
>
> Otherwise, the project continues. Functions for finite fields are all 
> working, generic functions mostly and the padic functions are a WIP as we 
> need to adapt to the fact we have different points at infinity (and I dont 
> know how to properly handle the case when there's two (yet)).
>
> Finally, looking at the rational_points() method itself, this is something 
> people have at least considered:
>
> ```
> .. TODO::
>
> Implement Stoll's model in weighted projective space to
> resolve singularities and find two points (1 : 1 : 0) and
> (-1 : 1 : 0) at infinity.
> ```
>
>
> On Wednesday, March 13, 2024 at 6:23:38 PM UTC Giacomo Pope wrote:
>
>> Thanks so much for the context
>>
>> Oh interesting. In this case I wonder whether we should work on and 
>> include a new class (maybe something as simple as a WeightedProjectiveSpace 
>> and a curve from this) mirroring the implementation for the plane curves. 
>> Alternatively I could go into the old plane curve code and write these 
>> useful functions specifically for the hyperelliptic curves (and here even 
>> gain that these algorithms can be optimised). For example, I already had to 
>> include a `dimension()` method on the curve to properly compute the 
>> Jacobian. Potentially AlgebraicScheme_subscheme_toric is indeed the wrong 
>> inheritance
>>
>> On Wednesday, March 13, 2024 at 6:18:12 PM UTC Nils Bruin wrote:
>>
>>> One thing that may deserve a cursory check is the overhead involved in 
>>> inheriting from AlgebraicScheme_subscheme_toric class . Some parent 
>>> structures are optimized for prolonged use *after* creation and may do a

Re: [nexa] L'AI e il cambio di paradigma

2024-03-16 Thread Giacomo Tesio

Ciao Antonio,



Il 16 Marzo 2024 12:53:15 CET, Antonio ha scritto:
> Immaginate che il prossimo primo d'aprile, le BigTech facciano al mondo un 
> bel pesce d'aprile.
> Si mettano d'accordo e spengano i loro server. Una disconnessione, non di un 
> paio d'ore come 
> è successo il 5 marzo con Facebook e consorelle [1], ma per sempre, o comunque
> per un periodo molto lungo.

Sognamo ad occhi aperti? :-D

> A parte lo shock iniziale,

In effetti... una sbornia epica... :-)

> la comunità di sviluppatori open source sarebbe in grado, nel giro di poco 
> tempo, di mettere
> su delle alternative valide

Pochi giorni, considerata l'enorme domanda non più servita da un mercato drogato
dalle sovvenzioni militari USA.

> Già, la quasi ... Ma con l'intelligenza artificiale come la mettiamo?

Perché, quella naturale è già esaurita?


Giacomo
___
nexa mailing list
nexa@server-nexa.polito.it
https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

2024-03-15 Thread Giacomo Pope

Back again with more class questions and general advice help

While getting all the old sage code into this new project, I realised there 
are places where we really rely on the underlying curve classes. One 
example is that we need

```
def dimension():
return 1
```

To avoid some crashes, but more generally we also need `rational_points()` 
which lives all the way inside `Algebraic_scheme`. There's also a whole 
bunch of other things...

I started exploring more and I found `Curve_generic` which we can create 
with the data I already have:

```
sage: H = HyperellipticCurveSmoothModel(x^5 + x + 1)
sage: C = Curve_generic(H._projective_model.ambient_space(), 
H._projective_model.defining_polynomials())
sage: type(C)

sage: C
Generic Curve over Rational Field defined by -X^5*Z - X*Z^5 - Z^6 + Y^2
sage: C.ambient_space()
2-d toric variety covered by 3 affine patches
```

this gets us some of the way and I think is an OK starting point, but then 
things like asking for the curve crash for weighted projective space:

```
sage: Curve(H)
---
TypeError Traceback (most recent call last)
.
TypeError: ambient space neither affine nor projective
```

and calls to things like C.rational_points() have more issues

```
sage: C.rational_points(bounds=2)
---
KeyError  Traceback (most recent call last)
.
AttributeError: 'SchemeHomset_points_subscheme_toric_field_with_category' 
object has no attribute 'points'
```

Which just goes to show that these toric varieties are a little 
underdeveloped.

Something which might be really nice would be 

```
class WeightedProjectiveCurve(Curve_generic, 
AlgebraicScheme_subscheme_toric):
```

Intended to mirror the similar:

```
class ProjectiveCurve(Curve_generic, AlgebraicScheme_subscheme_projective):
```

This could then be the class which is inherited by the Hyperelliptic curve 
class and we could aim for better coverage here.

Any opinions on this? Any idea of people who might have thought about or 
made progress in this area?

Otherwise, the project continues. Functions for finite fields are all 
working, generic functions mostly and the padic functions are a WIP as we 
need to adapt to the fact we have different points at infinity (and I dont 
know how to properly handle the case when there's two (yet)).

Finally, looking at the rational_points() method itself, this is something 
people have at least considered:

```
.. TODO::

Implement Stoll's model in weighted projective space to
resolve singularities and find two points (1 : 1 : 0) and
(-1 : 1 : 0) at infinity.
```


On Wednesday, March 13, 2024 at 6:23:38 PM UTC Giacomo Pope wrote:

> Thanks so much for the context
>
> Oh interesting. In this case I wonder whether we should work on and 
> include a new class (maybe something as simple as a WeightedProjectiveSpace 
> and a curve from this) mirroring the implementation for the plane curves. 
> Alternatively I could go into the old plane curve code and write these 
> useful functions specifically for the hyperelliptic curves (and here even 
> gain that these algorithms can be optimised). For example, I already had to 
> include a `dimension()` method on the curve to properly compute the 
> Jacobian. Potentially AlgebraicScheme_subscheme_toric is indeed the wrong 
> inheritance
>
> On Wednesday, March 13, 2024 at 6:18:12 PM UTC Nils Bruin wrote:
>
>> One thing that may deserve a cursory check is the overhead involved in 
>> inheriting from AlgebraicScheme_subscheme_toric class . Some parent 
>> structures are optimized for prolonged use *after* creation and may do a 
>> lot of caching/precomputation. There may be scenarios where one wants to 
>> construct *lots* of hyperelliptic curves (for instance, when computing 
>> reductions of hyperelliptic curves mod lots of primes). An expensive parent 
>> may then add undue overhead. In that case it may be better to spin off the 
>> functionality required into a "lightweight" structure that gets wrapped in 
>> the expensive, full functionality parent. After all, for core algorithms a 
>> hyperelliptic curve is just a 3*g+5 length sequence of ring/field elements: 
>> the coefficients of the defining equation.
>>
>> There are of course also odd genus hyperelliptic curves that cover a 
>> genus 0 curve that is not isomorphic to a P^1, but computing in their 
>> Jacobians has its own problems, so you should probably not try to include 
>> them in your current design.
>>
>> One thing that may be worthwhile: hyperelliptic curves do inherit some 
>> interesting functionality from plane curves (particularly via their affin

[jira] [Created] (CXF-8987) Java 21 - HttpClientHTTPConduit thread locked during shutdown

2024-03-15 Thread Giacomo Carnevale (Jira)

Giacomo Carnevale created CXF-8987:
--

 Summary: Java 21 - HttpClientHTTPConduit thread locked during 
shutdown 
 Key: CXF-8987
 URL: https://issues.apache.org/jira/browse/CXF-8987
 Project: CXF
  Issue Type: Bug
  Components: Transports
Affects Versions: 4.0.4, 4.0.3
 Environment: [^thdump2]

*OpenJDK 21.0.2*

*Apache CXF 4.0.4*

*Apache Camel 4.4.1*
Reporter: Giacomo Carnevale
 Attachments: thdump2

Hi,

I am using Apache CXF client via the Apache Camel CXF connector.

After I updated frm OpenJDK 17.x to OpenJDK 21.0.2, during application 
shutdown, the following lock occurs:

*at java.lang.Thread.join(java.base@21.0.2/Thread.java:2072)*
    *- locked <0x00061cd2ab80> (a 
jdk.internal.net.http.HttpClientImpl$SelectorManager)*
    *at java.lang.Thread.join(java.base@21.0.2/Thread.java:2200)*
    *at 
jdk.internal.net.http.HttpClientImpl.awaitTermination(java.net.http@21.0.2/HttpClientImpl.java:628)*
    *at 
java.net.http.HttpClient.{color:#de350b}close{color}(java.net.http@21.0.2/HttpClient.java:900)*
    *at 
jdk.internal.net.http.HttpClientFacade.{color:#de350b}close{color}(java.net.http@21.0.2/HttpClientFacade.java:192)*
    *at 
org.apache.cxf.transport.http.HttpClientHTTPConduit.{color:#de350b}close{color}(HttpClientHTTPConduit.java:125)*


HttpClientHTTPConduit.close
{code:java}
public void close() {
if (client instanceof AutoCloseable) {
try {
((AutoCloseable)client).close();
} catch (Exception e) {
//ignore
}
} else if (client != null) {
String name = client.toString();
client = null;
tryToShutdownSelector(name);
}
defaultAddress = null;
super.close();
} {code}
 
java.net.HttpClient.close
 
{code:java}
public void close() {
boolean terminated = isTerminated();
if (!terminated) {
shutdown();
boolean interrupted = false;
while (!terminated) {
try {
terminated = awaitTermination(Duration.ofDays(1L));
} catch (InterruptedException e) {
if (!interrupted) {
interrupted = true;
shutdownNow();
if (isTerminated()) break;
}
}
}
if (interrupted) {
Thread.currentThread().interrupt();
}
}
} {code}
My workaround
{code:java}
public void close() {
if (client instanceof AutoCloseable) {
try {
client.shutdownNow();
//((AutoCloseable)client).close();
} catch (Exception e) {
//ignore
}
} else if (client != null) {
String name = client.toString();
client = null;
tryToShutdownSelector(name);
}
defaultAddress = null;
super.close();
} {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [nexa] The Software Heritage Archive wants to deadname me forever: part 1

2024-03-15 Thread Giacomo Tesio

Caro Marco Anselmo Luca,

pur essendo felice di rassicurarti, ti suggerirei di non tediare oltre
l'intera lista con le tue (pur divertentissime :-D) esigenze personali.

On Fri, Mar 15, 2024 at 01:14:04PM +0100, Marco Anselmo Luca Calamari wrote:
> Ho invece letto il tuo utilizzo di sed per le operazioni di correzione del mio
> nome.
> 
> Ti confesso che sono un po' preoccupato, perché non mi è chiaro come tu lo 
> possa
> usare con le copie offline e di backup, tenuto conto che alcuni di questi 
> mezzi
> sono a sola scrittura.

[...]

> vorrei che tu mi confortassi che farai altrettanto su tutti i tuoi
> supporti offline o di sola lettura.
> Mi rendo conto che questo implicherà un poco ecologico consumo quotidiano di
> cdrom ma, come mi insegni, meglio sacrificare i cdrom che le persone.

Figurati, sono felicissimo di confortarti E di alleggerirti la coscienza.

Non mantengo copie di backup di mailing list che dispongono di archivi
pubblici affidabili: nessun cdrom verrà sacrificato al tuo vezzo.

sed è più che sufficiente.

> Confido che il tuo dominio dell'informatica ti consentira di automatizzare
> facilmente l'operazione.

Meglio ancora: grazie al mio dominio dell'informatica non ho alcun bisogno di 
automatizzare la modifica di backup che sarebbero superflui.

Come vedi, la tua fede è ben riposta! ;-)

> Ti devo infine rivolgere un'ultima richiesta, che mi è venuta in mente mentre
> davo ripetizioni di fisica 2 a mia nipote.
> 
> Con il tuo uso di connessioni wireless e bluetooth il mio nome errato è stato
> trasformato in onde hertziane, che come onde sferiche si stanno diffondendo
> nello spazio.
> Sono molto preoccupato che tra 4 anni gli abitanti di Proxima Centauri
> certamente in grado di craccare il WPA, vengano a conoscenza del mio nome
> errato.
> 
> Ti pregherei quindi di creare adatti campi hertziani di correzione
> superluminali, in modo che i poveri alieni ricevano onde hertziane corrette, e
> non si facciano un'opinione errata di me.

Anche su questo, posso rassicurarti: le onde elettromagnetiche che
giungeranno su alpha centauri fra 4 anni saranno indistinguibili dalla
radiazione cosmica di fondo.

Sia chiaro: non è merito mio! Fortunatamente il Signore è previdente 
e aveva già pensato alle tue esigenze ben prima che tu fossi concepito.

Chiedi pure al prossimo evangelista che ti compare in sogno: confermerà!

A presto!

Giacomo

PS: sei sicuro che tua nipote non trarrebbe giovamento da un docente di
fisica più aggiornato? la CMBR fu scoperta nel 1964... :-D

PPS: so che questa era "l'ultima richiesta" ma... se dovessi scoprire di
avere ulteriori venerabili esigenze, ti prego di scrivermele in privato.
___
nexa mailing list
nexa@server-nexa.polito.it
https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Re: [nexa] The Software Heritage Archive wants to deadname me forever: part 1

2024-03-15 Thread Giacomo Tesio

Ma certo, Marco Anselmo Luca, ma certo...

On Fri, Mar 15, 2024 at 09:13:45AM +0100, Marco Anselmo Luca Calamari wrote:
> On ven, 2024-03-15 at 00:41 +0100, Giacomo Tesio wrote:
> > Preferisco adattare gli script alle persone, che le persone agli script.
> 
> Benissimo, tu sarai i l primo a comportarti in questo modo
> [...]
> Sei quindi pregato di modificare immediatamente in questo senso tutti i miei
> messaggi che hai ricevuto od a cui hai risposto, in tutti i tuoi archivi
> permanenti, locali e/o temporanei.
> [...]
> Ovviamente senza censurarmi cancellandoli.

$ sed -e "s/Marco A. /Marco Anselmo Luca/g" -i INBOX.INBOX-Nexa.mbox

Contento? :-D

Se vuoi ti mando privatamente uno screenshot di Mutt che mostra le tue 
mail aggiornate...


> Tanto mi devi. 

Ma certo: come diceva sempre la mia mamma quando ero bambino 
"devi assecondare i capricci degli anziani..." ;-)


Giacomo

che sa quanto apprezzerai la mia notoria "politically correctness"... :-p
___
nexa mailing list
nexa@server-nexa.polito.it
https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Re: [nexa] The Software Heritage Archive wants to deadname me forever: part 1

2024-03-14 Thread Giacomo Tesio

igere che una programmatrice rinunci ad un
proprio diritto per non disturbare troppo gli script di chi ne
distrubuisce il software.

Credi davvero che il comportamento di OpenAI sia tanto diverso?


Preferisco adattare gli script alle persone, che le persone agli script.


Giacomo

[1] https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work

___
nexa mailing list
nexa@server-nexa.polito.it
https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Re: [nexa] The Software Heritage Archive wants to deadname me forever: part 1

2024-03-14 Thread Giacomo Tesio

Mi piace questo gioco! Proviamo...

Il giorno Thu, 14 Mar 2024 13:33:49 "Marco A. Calamari" ha scritto:

> Fatto: se il sistema legale ***obbliga a riscrivere la storia***, non
> solo è imperfetto il sistema legale, ma sbaglia chi lo sfrutta

Fatto: "sbaglia chi lo sfrutta" descrive un'opinione, non un fatto. ;-)

Fatto: i repository GIT non sono "la storia", ma al massimo possono
essere usati come fonte storica.

Fatto: i repository GIT in questione riportano l'attribuzione di un
opera ad un nome diverso da quello dell'autrice.

Fatto: i repository GIT corretti, qualora usati come fonte storica,
falserebbero la ricostruzione relativa ai dati di quell'opera ed
all'opera di quell'autrice.

Fatto: è sufficiente un comando per modificare tale attribuzione.

Fatto: i repository GIT corretti costituirebbero una fonte storica
migliore di quella attualmente presente negli archivi di SWH.

Opinione: la SWH dovrebbe aggiornare i repository in questione anche
solo per coerenza con la propria missione di preservare una fonte di
interesse storico.

Opinione: la SWH aggiornerà (o rimuoverà) i repository in questione
per evitare un danno di immagine che riduca il valore del servizio 
di ethic-washing per i propri sponsor.


> Opinione: la talebanaggine nella difesa dei diritti civili (pensa, lo
> dico io che sono un champion in questo campo!) non dovrebbe spingerti
> a dichiarare l'impotenza di fronte alla violazione dei diritti civili
> di un'intera umanità, anche se non è previsto, dal sistema legale, un
> garante della correttezza storica dei dati (e meno male!).

Fatto: questa frase esprime  opinioni diverse:
1. che io sia un "talebano" nella difesa dei diritti civili
   ("la talebanaggine... non dovrebbe spingerTI")
2. che tu sia un "champion" in questo campo
3. che io possa anche solo pensare di dichiararmi impotente di fronte
   alla violazione di diritti civili
4. che abbia senso parlare di diritti collettivi, ovvero non attribuiti
   a singoli individui, ma a gruppi di individui definiti. 
5. che "l'intera umanità" possa costituire un gruppo di individui
   definito
6. che a tale gruppo andrebbero riconosciuti dei diritti civili
   (che come tali, limiterebbero la libertà di azione di terzi... 
   ma terzi chi?)
7. che la correttezza storica dei dati sia catturata dai repository GIT.
8. che la richiesta dell'autrice riduca la correttezza storica dei dati
   invece di aumentarla.


Opinione: vi sono troppe opinioni da discutere in questa frase!

Fatto: mi limiterò a discutere quelle più interessanti per la lista.

Fatto: i repository GIT _non_ riproducono la correttezza storica dei
   dati: esistono comandi come `git rebase` che la alterano, puoi
   modificare la data o l'autore di una commit impostando variabili
   di ambiente etc.. etc...

Fatto: il nome presente in quei repository non corrisponde a quello
   dell'autrice, dunque correggerlo, ne incrementa la correttezza
   storica.

Fatto: nell'articolo 29 della Costituzione la "Repubblica riconosce i
   diritti della famiglia", dunque esitono precedenti illustri
   all'idea di attribuire diritti non a singoli individui ma a
   gruppi definiti di persone. Addirittura, in questo caso la
   Repubblica si limita a _riconoscere_ tali diritti, senza
   istituirli (o elencarli). 

Fatto: la dichiarazione universale dei diritti umani, purtroppo,
   elenca una serie di diritti attribuiti ai singoli membri
   dell'umanità, ma _non_ all'umanità intera.

Fatto: attribuire diritti all'umanità intera significherebbe che
   (solo) l'umanità intera potrebbe collettivamente esercitarli e
   vederli riconosciuti contro terzi.

Opinione: attribuire diritti all'umanità intera può solo servire a
  strumentalizzarla per negare diritti a uno o più membri di
  quell'umanità.


Giacomo
___
nexa mailing list
nexa@server-nexa.polito.it
https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Re: [nexa] The Software Heritage Archive wants to deadname me forever: part 1

2024-03-14 Thread Giacomo Tesio

Suvvia Marco, non facciamo confusione! ;-)

Il giorno Thu, 14 Mar 2024 01:07:15 "Marco A. Calamari" ha scritto:

> On mer, 2024-03-13 at 22:37 +0100, Giacomo Tesio wrote:
>
> > Una persona ha cambiato nome e ha legittimamente richiesto
> > l'aggiornamento dei dati
> > pubblicati da Sofware Heritage, esercitando un diritto
> > riconosciutole dal GDPR.
> > 
> > SWH non ha risposto alla sua richiesta.
>
> [...]
> IMO sarebbe più interessante riportare la trattazione di questo
> problema semplificandolo all'estremo,  e ridescrivendolo come una
> discrasia (non un conflitto) tra cancel culture, GDPR ed
> archiviazione storica .

Non è ironico che questa "semplificazione estrema" cancelli
completamente la vittima di tale discrasia? ;-)

Non è poi una semplificazione accurata, in quanto, come già detto, 
la richiesta dell'autrice non è di cancellare, ostracizzare o anche
solo boicottare la SWH o uno dei suoi membri, ma di aggiornare un dato
di natura legale che la riguarda.

I metodi della cancel culture sono molto diversi: se ricordi, ad
esempio, gli attacchi a Stallman di qualche anno fa, noterai che una
singola persona veniva attaccata da una folla inferocita e poco
interessata ai fatti, che definiva tale persona ripugnante e
pericolosa, che esigeva letteralmente la sua rimozione "from all
leadership positions" e la rimozione dell'intero Board della Free
Software Foundation colpevole di averlo rieletto.

L'autrice definisce (IMHO, erroneamente) la SWH (che non è una
singola persona, ma un'organizzazione) come "trasphobic", ma questo è
l'unica somiglianza con quanto subito da Stallman. 

Letteralmente, non chiede la cancellazione di nessuno.
(a meno che non mi sia perso qualche passaggio)

> Continua a stupirmi invece quanto non venga riconosciuta la magnifica
> distopia di Orwell, che dal voler manipolare il pensiero con la
> ridefinizione del linguaggio tenta tranquillamente anche la
> riscrittura della storia, senza che questo venga debunkato ed
> additato al pubblico ludibrio.

Sono assolutamente d'accordo che i metodi della cancel culture aprono
la strada a distopie che Orwell non avrebbe potuto immaginare.

Ma in questo caso, l'autrice non sta chiedendo una "riscrittura della
storia" ma una corretta attribuzione del proprio lavoro.

Per la legge, l'autrice ha cambiato il proprio nome.

Le sue ragioni sono irrilevanti dal punto di vista legale.

Sugli archivi della SWH, le sue opere sono erroneamente attribuite ad
una persona che (legalmente) non esiste più.

Ma l'autrice di quelle opere esiste ancora e chiede che gli archivi
vengano corretti in modo da evitare, in un futuro magari remoto, di
essere infangata dall'accusa di plagio dell'opera del proprio alter-ego
defunto.

Come richiesta appare del tutto ragionevole e perfettamente in linea
con le finalità della SWH.

> Mi chiedo quando la persona che ha scatenato questa polemica si
> accorgerà che Gihub ha mandato una copia su pellicola del suo
> repository nell'Arctic World Archive alle isole Svalbard, destinata
> alla conservazione per i prossimi 500 anni [1].
> 
> Certamente chiederà che anche i cambiamenti che ha deciso di
> apportare alla sua vita cancellino quelli "non aggiornati".

In effetti, al suo posto, io lo farei.

500 anni sono un tempo molto lungo e se tutti si dovessero dimenticare
che Giacomo2 e Giacomo1 erano la stessa persona, l'idea che gli
storici del futuro mi dipingano (io Giacomo2) come un ladro, mi darebbe
piuttosto fastidio, soprattutto per l'impossibilità di difendermi. 

> Spero che nessuno lo consideri un semplice dettaglio tecnologico, ma
> semplicemente un controesempio lampante dell'assurdità di certe
> richieste in un mondo reale.

Io non vedo alcun problema tecnologico nella sostituzione di una
pellicola. E nessuna assurdità nel richiederlo qualora violi i diritti
di una persona.

Anche appellarsi all'interesse superiore dell'umanità sarebbe
penosamente ridicolo: in questo caso, anche l'umanità ha tutto
l'interesse che i dati preservati per i prossimi 500 anni siano 
il più possibile rispondenti alla realtà che descrivono.

E archivi che attribuissero il codice preservato ad autori inesistenti
danneggerebbero la possibilità di ricostruire la nostra storia.

> Un mondo, appunto, in cui se i metodi folli del nuovo
> politically-correct dovessero diventare legge degli uomini, rimarrà
> solo la testimonianza del principio olografico a ricordare con
> esattezza quello che è stato.

Cosa c'entra il politically correct?

Se invece che aver cambiato nome legale per una scelta di genere,
l'avesse cambiato per qualche altra ragione, sarebbe cambiato qualcosa?

Se avesse scoperto di essere stata sottratta ai genitori naturali da
bambina, e riconginutasi felicemente con la famiglia originale, avesse
assunto nuovamente il nome che i suoi genitori des

[plasmashell] [Bug 483163] blank screen on lock screen activation when using breeze plasma style

2024-03-13 Thread Giacomo Lozito

https://bugs.kde.org/show_bug.cgi?id=483163

--- Comment #10 from Giacomo Lozito  ---
(In reply to Nate Graham from comment #6)
> Ah, this should have been fixed in Plasma 6.0.2, then. Can you test that and
> re-open if it's still broken?

Just tested on Arch with plasma 6.0.2 and it still occurs for me. I also
confirmed same behaviour as reported initially: only occurs with plasma style
set to Breeze and only on X11, switching to another plasma style such as Breeze
Light will prevent the issue from occurring. Does not occur with Wayland.

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: [nexa] The Software Heritage Archive wants to deadname me forever: part 1

2024-03-13 Thread Giacomo Tesio

Ciao 380,

Il 13 Marzo 2024 19:03:07 CET, "380°"  ha scritto:
>  sinceramente ho capito poco in merito alla richiesta della
> persona offesa.

Una persona ha cambiato nome e ha legittimamente richiesto l'aggiornamento dei 
dati
pubblicati da Sofware Heritage, esercitando un diritto riconosciutole dal GDPR.

SWH non ha risposto alla sua richiesta.


> la spiegazione tecnica relativa ai metadati come parte integrante della
> "chain of trust" è tecnicamente chiara, no?

SE fosse corretta (cosa di cui non sono certo), sarebbe comunque irrilevante.


> Tra l'altro, il rant è talmente sconclusionato che non ho capito bene
> qual'è la precisa richiesta della persona nei confronti del progetto
> SWH: mi spiego meglio...
> 
> La pagina di archivio del progetto è questa:
> https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://github.com/rspeer/python-ftfy

I nomi dell'autrice sono riportati in questo tweet
 <https://twitter.com/r_speer/status/1570609220197969922>

```
About my name: 

My married name is Elia Robyn Lake. People who know me call me Elia. 

My maiden name is Robyn Speer. 

My papers are, and will continue to be, under my maiden name. It's not my 
deadname. 

Call me Robyn Speer if you're citing something I wrote. 

Thanks!
```


> e attribuisce l'ultimo commit correttamente
> 
> --8<---cut here---start->8---
> 
> Tip revision: c49bb541bc2598cf7303194feeaa2cbe3a030b3e authored by Elia Robyn 
> Lake on 21 November 2023
> 
> --8<---cut here---end--->8---
> 
> Quale sarebbe il "deadname" che SWH dovrebbe modificare?

Onestamente non lo so, ma ho l'impressione che dopo la scrittura dell'articolo, 
SWH abbia trovato
il modo di modificarlo.

Che bastasse (come ipotizzavo) ri-clonare il repository?


> SWH dovrebbe riscrivere la storia di (tutti?!?) i repository che
> contengono il "deadname" di quella persona?

A quanto ho capito, lei l'ha richiesto solo per il proprio repository, non per 
i fork.


> > I pointed out that you can just change a citation if it's wrong, and
> > that I've gotten citations that deadname me changed. I pointed out
> > that people cite my code under my correct name through Zenodo,
> 
> sì certo, anche coloro che hanno effettuato una citazione 5 anni fa
> tengono aggiornate le citazioni con un "live URL" che punta al Database
> Universale Eterno delle Sacre Citazioni

Non capisco quale sia il problema: a meno che non stia mentendo (cosa che al 
momento 
non ho ragione di credere) l'autrice ha ottenuto l'aggiornamento delle 
citazioni di coloro cui ha 
richiesto di correggerle.

Ha ancora la libertà di decidere quando esercitare un proprio diritto?


> > not through whatever cryptographic bullshit SWH was dreaming up.
> 
> Oh sì certo, riscrivere la storia è un giochino da bambini dell'asilo,
> no?!?

Beh, non stiamo parlando della storia ma di uno specifico repository GIT.

Poi, secondo me serve almeno la terza media, ma il comando da usare è qui
<https://github.com/newren/git-filter-repo>


> Sono sicuro che dopo SWH la persona che si sente offesa avrà intenzione
> di aggredire con rant ancora più offensivi anche

Nella seconda parte, spiega perché considera particolarmente importante la SWH:

<https://cohost.org/arborelia/post/5052044-the-software-heritag>

In qualunque caso, sta esercitando un proprio diritto.


> Bene, attendo con trepidante ansia la causa legale presso una corte
> francese.

Non credo sarà necessario. :-)


> > Personalmente scommetto che finirà tutto a tarallucci e vino: un bel blog 
> > di scuse 
> > con tanto di ringraziamento nei confronti dell'autrice e di 
> > auto-assoluzione, 
> > la sostituzione del nome,
> 
> La sostituzione del dome DOVE?!?

Negli archivi di SWH.


> Spero che la (auto)cancel culture si esaurisca presto, perché avremmo
> cose estremamente più serie di cui occuparci.

Onestamente 380, non capisco questo commento.

Anzitutto, nessuno ti ha chiesto di occupartene sottraendo tempo a "cose 
estremamente più serie".

In secondo luogo, la cancel culture non centra molto in questo caso: l'autrice 
non vuole
né cancellare la SWH né essere cancellata dalla stessa.

Forse ti ho confuso ricordando la gogna tirata su due volte contro RMS?
In tal caso lasciami chiarire che autrice non centra nulla con quell'attacco.

Al contrario, lei chiede di vedersi attribuire correttamente le proprie opere.

A ben guardare, credo che l'autrice potrebbe anche esercitare i propri diritti 
morali d'autore:

<https://it.m.wikipedia.org/wiki/Diritto_d%27autore#Diritto_morale_d'autore>


Giacomo
___
nexa mailing list
nexa@server-nexa.polito.it
https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

2024-03-13 Thread Giacomo Pope

Thanks so much for the context

Oh interesting. In this case I wonder whether we should work on and include 
a new class (maybe something as simple as a WeightedProjectiveSpace and a 
curve from this) mirroring the implementation for the plane curves. 
Alternatively I could go into the old plane curve code and write these 
useful functions specifically for the hyperelliptic curves (and here even 
gain that these algorithms can be optimised). For example, I already had to 
include a `dimension()` method on the curve to properly compute the 
Jacobian. Potentially AlgebraicScheme_subscheme_toric is indeed the wrong 
inheritance

On Wednesday, March 13, 2024 at 6:18:12 PM UTC Nils Bruin wrote:

> One thing that may deserve a cursory check is the overhead involved in 
> inheriting from AlgebraicScheme_subscheme_toric class . Some parent 
> structures are optimized for prolonged use *after* creation and may do a 
> lot of caching/precomputation. There may be scenarios where one wants to 
> construct *lots* of hyperelliptic curves (for instance, when computing 
> reductions of hyperelliptic curves mod lots of primes). An expensive parent 
> may then add undue overhead. In that case it may be better to spin off the 
> functionality required into a "lightweight" structure that gets wrapped in 
> the expensive, full functionality parent. After all, for core algorithms a 
> hyperelliptic curve is just a 3*g+5 length sequence of ring/field elements: 
> the coefficients of the defining equation.
>
> There are of course also odd genus hyperelliptic curves that cover a genus 
> 0 curve that is not isomorphic to a P^1, but computing in their Jacobians 
> has its own problems, so you should probably not try to include them in 
> your current design.
>
> One thing that may be worthwhile: hyperelliptic curves do inherit some 
> interesting functionality from plane curves (particularly via their affine 
> patch) in the form of "riemann_surface". It may be worth keeping that, even 
> if the particular code there could be expanded to work much more 
> efficiently on hyperelliptic curves.
>
> On Wednesday 13 March 2024 at 10:32:08 UTC-7 Giacomo Pope wrote:
>
>> Thanks David, there's a bunch of nice things we could do for genus two in 
>> various cases which would be worth including. The inert case, where all 
>> degree zero divisors (except the identity element) have u with degree 2 
>> would probably allow something particularly nice. 
>>
>> As another update I have done a fairly brutish refactoring of the proof 
>> of concept code to follow the design decisions of the previous 
>> implementation. https://github.com/GiacomoPope/HyperellipticCurves
>>
>> Hyperelliptic curves are created from a dynamic class constructor on top 
>> of the AlgebraicScheme_subscheme_toric class (before this was a curve over 
>> the plane projective curves)
>> A generic class offers most features, but other classes will cover the 
>> case of finite fields, rational fields and padic fields
>> The Jacobian is a small class built on top of `jacobian_generic` which is 
>> built from the curve
>> The set of rational points of the Jacobian is built on top of 
>> SchemeHomSet and the elements (divisors) are morphisms built on top of 
>> SchemeMorphism
>>
>> I will do my best to clean up and refactor code to the standard of code 
>> which is included into Sage now, but I would love to know any feedback 
>> advice on whether this structure is still the one to use. The older version 
>> of this code dates back to the beginning of Sage so it's very possible we 
>> have new ideas of how things should be done and if we're doing the work or 
>> rewriting the whole set of classes I may as well do a good job.
>>
>> Giacomo
>>
>> On Wednesday, March 13, 2024 at 3:36:09 AM UTC David Roe wrote:
>>
>>> There is also this old trac ticket 
>>> <https://github.com/sagemath/sage/issues/23154> about implementing fast 
>>> arithmetic in genus 2 Jacobians, which never made it into Sage.  I've CCed 
>>> Mike Jabobson, who worked on it.
>>> David
>>>
>>>
>>> On Tue, Mar 12, 2024 at 12:10 PM Giacomo Pope  
>>> wrote:
>>>
>>>> Thank you for linking this and I agree this is a great way to 
>>>> cross-compare the work we have been doing. I am not an expert in this area 
>>>> so I am not sure I should do a full review but I'm happy to look over it 
>>>> if 
>>>> this helps.
>>>>
>>>> As a small update on this work, I now have 
>>>>
>>>> class HyperellipticCurveSmoothModel(AlgebraicScheme_subscheme_to

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

2024-03-13 Thread Giacomo Pope

Thanks David, there's a bunch of nice things we could do for genus two in 
various cases which would be worth including. The inert case, where all 
degree zero divisors (except the identity element) have u with degree 2 
would probably allow something particularly nice. 

As another update I have done a fairly brutish refactoring of the proof of 
concept code to follow the design decisions of the previous 
implementation. https://github.com/GiacomoPope/HyperellipticCurves

Hyperelliptic curves are created from a dynamic class constructor on top of 
the AlgebraicScheme_subscheme_toric class (before this was a curve over the 
plane projective curves)
A generic class offers most features, but other classes will cover the case 
of finite fields, rational fields and padic fields
The Jacobian is a small class built on top of `jacobian_generic` which is 
built from the curve
The set of rational points of the Jacobian is built on top of SchemeHomSet 
and the elements (divisors) are morphisms built on top of SchemeMorphism

I will do my best to clean up and refactor code to the standard of code 
which is included into Sage now, but I would love to know any feedback 
advice on whether this structure is still the one to use. The older version 
of this code dates back to the beginning of Sage so it's very possible we 
have new ideas of how things should be done and if we're doing the work or 
rewriting the whole set of classes I may as well do a good job.

Giacomo

On Wednesday, March 13, 2024 at 3:36:09 AM UTC David Roe wrote:

> There is also this old trac ticket 
> <https://github.com/sagemath/sage/issues/23154> about implementing fast 
> arithmetic in genus 2 Jacobians, which never made it into Sage.  I've CCed 
> Mike Jabobson, who worked on it.
> David
>
>
> On Tue, Mar 12, 2024 at 12:10 PM Giacomo Pope  wrote:
>
>> Thank you for linking this and I agree this is a great way to 
>> cross-compare the work we have been doing. I am not an expert in this area 
>> so I am not sure I should do a full review but I'm happy to look over it if 
>> this helps.
>>
>> As a small update on this work, I now have 
>>
>> class HyperellipticCurveSmoothModel(AlgebraicScheme_subscheme_toric)
>>
>> So this new class builds on top of AlgebraicScheme_subscheme_toric and 
>> the smooth projective model is built using a toric variety. The points on 
>> the curve are currently SchemeMorphism_point_toric_field, potentially I 
>> will need to make a child class of these if methods on the points 
>> themselves are required.
>>
>> With the working arithmetic and this new inheritance my work is now going 
>> to be the rather slow and painful rewrite of all hyperelliptic methods from 
>> the current implementation to ensure everything works on the smooth degree 
>> model.
>>
>> On Monday, March 11, 2024 at 6:23:38 AM UTC Kwankyu Lee wrote:
>>
>>> On Friday, March 8, 2024 at 7:37:04 PM UTC+9 Giacomo Pope wrote:
>>>
>>> As a small update, the repository now contains code to
>>>
>>> - perform arithmetic for
>>>   - the imaginary model (ramified, one point at infinity) for all cases
>>>   - the real model (split, two points at infinity) for all cases
>>>   - the real model (inert, zero points at infinity) for even genus
>>>   Which allows us to do "as much" as Magma does for Jacobians of 
>>> hyperellipticc curves from the perspective of arithmetic. 
>>>
>>> My current "test" for the arithmetic is that D - D = 0 for all cases, 
>>> that jacobian_order * D = zero and that order_from_multiple(D) works. If 
>>> people have other ideas for tests, please let me know. Of course at the 
>>> moment these tests are over finite fields but you can reasonable use other 
>>> fields (as Sabrina's message shows) but I am less sure about how to do 
>>> randomised testing here.
>>>
>>>
>>> I just set https://github.com/sagemath/sage/pull/35467 to "needs 
>>> review" status. The PR implements Jacobian arithmetic for general 
>>> projective curves.
>>>
>>> It is slow compared with Jacobian arithmetic using Mumford 
>>> representation, but could be used to crosscheck the computations.
>>>
>> -- 
>>
> You received this message because you are subscribed to the Google Groups 
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to sage-devel+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/7f646c6d-bd0b-452d-a730-30144415f590n%40googlegroups.com
>>  
>

[nexa] The Software Heritage Archive wants to deadname me forever: part 1

2024-03-13 Thread Giacomo Tesio

When I first contacted them, politely, they didn't even respond to me. What 
happened instead was that their content policy changed from a standard EU 
content policy to one that is very defensive about their ability to archive 
personal data forever with no exceptions.

[...]

The reason they can't just change references to your deadname, like any decent 
person would, is vaguely because of "integrity" (the common refrain of 
transphobic cowards), but more specifically because they made a fucking 
immutable blockchain out of it.

[...]

You can guess what happened next: I fucking exploded at them on Twitter.

This got a faster reaction than anything else I'd seen in the process. The rant 
against changing names in the content policy disappeared again. One of the 
developers went to my DMs to tell me condescendingly that I'd understood it 
wrong. It wasn't a blockchain, he explained, it's just a Merkle tree, like Git, 
because we copied your Git repository.

I screenshotted their documentation that said "blockchain".  [...]

He said, but we have to do that, what if someone wanted to cite your code in a 
paper? You can't just change a citation.

I pointed out that you can just change a citation if it's wrong, and that I've 
gotten citations that deadname me changed. I pointed out that people cite my 
code under my correct name through Zenodo, not through whatever cryptographic 
bullshit SWH was dreaming up.

He said, well anyway, I don't see why this is our problem. You can't even 
change your name in your own repository! Imagine if people could just change 
history ha ha

I pointed him at my Git repository that I had already mutated using 
git-filter-repo.

He stopped replying.

Continua su https://cohost.org/arborelia/post/4968198-the-software-heritag


Questa storia presenta molti aspetti politicamente interessanti.

Anzitutto evidenzia come l'ignoranza tecnica causi alienazione cibernetica dove 
meno
ce la si aspetta: modificare un repository git è facilissimo, SH avrebbe potuto 
riclonarlo 
in pochi minuti da github già aggiornato e con qualche giorno di lavoro avrebbe 
anche 
potuto introdurre dei redirect dalle url con i vecchi hash a quelle con i nuovi.

MA, non sapendolo, hanno tirato su questo ridicolo muro di gomma, trattando una 
persona che esercita i propri diritti come un problema di conformità alla 
macchina: in sintesi
credendo che la macchina non si possa adattare ai diritti di una persona, si 
chiede a quella persona di rinunciare ai propri diritti.

Non è la prima e non sarà l'ultima volta, ma questa volta al posto della 
mistica "AI"
troviamo semplici repository GIT.


E poi interessantissimo come tale ignoranza/alienazione venga scambiata per 
transfobia
dall'autrice che definisce "transphobic" "white cis" i dirigenti della Software 
Heritage.
Un'accusa ovviamente infondata, ma che non può non richiamare alla memoria 
un'accusa
altrettanto strumentale sottoscritta da alcuni di quei dirigenti contro 
un'altra vittima [1].
In quell'occasione però, misogynist, ableist e transphobic era una singola 
persona,
definita come "forza pericolosa" e indicata con nome e cognome.


In secondo luogo porta alla luce come, anche nella civilissima Francia, i DPO 
dimentichino
spesso lo scopo del proprio ruolo: garantire la protezione dei dati personali, 
non degli
interessi dei propri clienti.

Fortunatamente in questo caso, la caparbietà del richiedente potrebbe far 
coincidere
la negligenza del DPO (che avrebbe dovuto dar seguito alla richiesta di 
esercizio dei diritti,
non riscrivere la privacy policy sperando di esentare la Software Heritage) con 
un
meritatissimo danno di immagine al proprio cliente.


In terzo luogo, è interessantissimo come l'esercizio dei diritti sia dovuto 
passare da
Twitter.

È interessante non solo perché rende evidente come chi ha partecipato o 
scatenato 
gogne come quella subita anni fa da Stallman, le teme molto di più di quanto 
non tema un
Garante serio come quello francese.

E d'altro canto, si tratta di un timore infondato: Twitter non ha alcuna 
ragione di catalizzare
uno shitstorm contro una organizzazione finanziata, fra gli altri da Google, 
Microsoft, Intel
e molti altre aziende con interessi strategici affini [2].

Stallman invece può davvero sembrare "una forza pericolosa nel software libero" 
per quegli interessi. [3]


Infine sarà interessante vedere come andrà a finire (sembra che l'autrice si 
stia preparando
a dare battaglia sul piano legale).


Personalmente scommetto che finirà tutto a tarallucci e vino: un bel blog di 
scuse 
con tanto di ringraziamento nei confronti dell'autrice e di auto-assoluzione, 
la sostituzione del nome, una vittoria giustamente sbandierata dalla stessa
autrice (e probabilmente strumentalizzata da qualche movimento).

Alla fine, questa volta, il diritto verrà esercitato con successo.

Speriamo ne nasca un precedente utile per tutti!


Giacomo


[1] htt

[plasmashell] [Bug 483163] blank screen on lock screen activation when using breeze plasma style

2024-03-12 Thread Giacomo Lozito

https://bugs.kde.org/show_bug.cgi?id=483163

--- Comment #5 from Giacomo Lozito  ---
(In reply to Nate Graham from comment #1)
> Does it happen on Wayland too, or only X11?

It only occurs with X11 for me. Tested this evening with Wayland and Breeze
plasma style, did not manage to reproduce; when activating the screen locker in
wayland, the screen consistently behaves by going blank for a half second
first, and then displaying the lock screen correctly.

-- 
You are receiving this mail because:
You are watching all bug changes.

Bug#1066100: freeciv: new cities unmanageable in a long game

2024-03-12 Thread Giacomo Mulas

Package: freeciv
Version: 3.1.0+ds-1
Severity: normal

Dear Maintainer,

in a long game with a huge map, I hit a weird bug. 
New cities are unmanageable, i.e. I cannot:
- change their production
- set them as "home" for any unit
- add settlers to them
etc.

I will send a saved game that shows this in an additional subsequent message to 
this bug report.

Bye, thanks in advance
Giacomo

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (401, 'unstable'), (10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages freeciv depends on:
ii  freeciv-client-gtk3  3.1.0+ds-1
ii  freeciv-data 3.1.0+ds-1

freeciv recommends no packages.

freeciv suggests no packages.

-- no debconf information

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

2024-03-12 Thread Giacomo Pope

Thank you for linking this and I agree this is a great way to cross-compare 
the work we have been doing. I am not an expert in this area so I am not 
sure I should do a full review but I'm happy to look over it if this helps.

As a small update on this work, I now have 

class HyperellipticCurveSmoothModel(AlgebraicScheme_subscheme_toric)

So this new class builds on top of AlgebraicScheme_subscheme_toric and the 
smooth projective model is built using a toric variety. The points on the 
curve are currently SchemeMorphism_point_toric_field, potentially I will 
need to make a child class of these if methods on the points themselves are 
required.

With the working arithmetic and this new inheritance my work is now going 
to be the rather slow and painful rewrite of all hyperelliptic methods from 
the current implementation to ensure everything works on the smooth degree 
model.

On Monday, March 11, 2024 at 6:23:38 AM UTC Kwankyu Lee wrote:

> On Friday, March 8, 2024 at 7:37:04 PM UTC+9 Giacomo Pope wrote:
>
> As a small update, the repository now contains code to
>
> - perform arithmetic for
>   - the imaginary model (ramified, one point at infinity) for all cases
>   - the real model (split, two points at infinity) for all cases
>   - the real model (inert, zero points at infinity) for even genus
>   Which allows us to do "as much" as Magma does for Jacobians of 
> hyperellipticc curves from the perspective of arithmetic. 
>
> My current "test" for the arithmetic is that D - D = 0 for all cases, that 
> jacobian_order * D = zero and that order_from_multiple(D) works. If people 
> have other ideas for tests, please let me know. Of course at the moment 
> these tests are over finite fields but you can reasonable use other fields 
> (as Sabrina's message shows) but I am less sure about how to do randomised 
> testing here.
>
>
> I just set https://github.com/sagemath/sage/pull/35467 to "needs review" 
> status. The PR implements Jacobian arithmetic for general projective curves.
>
> It is slow compared with Jacobian arithmetic using Mumford representation, 
> but could be used to crosscheck the computations.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/7f646c6d-bd0b-452d-a730-30144415f590n%40googlegroups.com.

Re: [sage-devel] VOTE: use the smooth model instead of the plane projective model for hyperelliptic curves

2024-03-12 Thread Giacomo Pope

I'm (somewhat) aware of bugs which come from poor treatment of weighted 
polynomial rings. In my mind this has two solutions.

1) Someone who is an expert in toric varieties has another look through the 
current code, adds more extensive testing and methods for computations in 
the area
2) We work with what we currently have for the hyperelliptic curve case and 
when something appears to be broken we attempt to fix it.

I am in no position to do 1) as I do not know enough. As a result I will 
start one 2) but I am happy for more work to be done in parallel?

My current experimentation I believe we want to define the curve in the 
following way

```
sage: def projective_model(f, h, g):
: """
: Compute the weighted projective model (1 : g + 1 : 1)
: """
: k = f.base_ring()
: T = toric_varieties.WP([1, g + 1, 1], base_ring=k, names="X, Y, 
Z")
: (X, Y, Z) = T.gens()
:
: if h.is_zero():
: d = f.degree()
: F = sum(f[i] * X**i * Z**(d - i) for i in range(d + 1))
: G = Y**2 - F
: else:
: d = max(h.degree(), (f.degree() / 2).ceil())
: H = sum(h[i] * X**i * Z**(d - i) for i in range(d + 1))
: F = sum(f[i] * X**i * Z**(2*d - i) for i in range(2*d + 1))
: G = Y**2 + H*Y - F
:
: return T.subscheme([G])
:
sage: f = x^7 + 1
sage: h = x
sage: g = HyperellipticCurve(f, h).genus() # simply make sure this is a 
"good" choice of f, h for this field
sage: g
3
sage: projective_model(f, h, g)
Closed subscheme of 2-d toric variety covered by 3 affine patches defined 
by:
  -X^7*Z - Z^8 + X*Y*Z^3 + Y^2
```

Which suggests to me that the generic class for hyperelliptic curves is a 
child class HyperellipticCurve_generic(AlgebraicScheme_subscheme_toric) and 
we start building this from here.
On Monday, March 11, 2024 at 11:17:02 PM UTC Dima Pasechnik wrote:

> Sage's treatment of weighted polynomial rings is  buggy, cf. e.g.
> https://github.com/sagemath/sage/issues/37167
>
> this is something that should be addressed, one way or another
>
>
>
> On Mon, Mar 11, 2024 at 9:31 PM Giacomo Pope  wrote:
>
>> Dear all,
>>
>> *Summary*
>>
>> To better support arithmetic on Jacobians and have a more natural 
>> implementation of hyperelliptic curves, we should implement them as toric 
>> varieties with a weighted polynomial ring (1 : 3 : 1) instead of plane 
>> projective curves.
>>
>> *Yes / No*
>>
>> *Discussion*
>>
>> I am currently hoping to improve hyperelliptic curves and Jacobians of 
>> hyperelliptic curve in Sage. One big motivation for me is to try and get 
>> our computations with similar coverage to what exists in Magma to allow 
>> more academics in the field to benefit from the open-source community of 
>> Sage. The first main goal of this is for full featured arithmetic on the 
>> Jacobians of hyperelliptic curves.
>>
>> The big blocker for me currently is that currently Sage implements 
>> hyperelliptic curves in the plane projective model. This is not an issue 
>> for the current methods, and it also allows for sensible arithmetic on 
>> Jacobians when there is one point at infinity. However, the more natural 
>> model I believe is the smooth model which uses a weighted polynomial 
>> (weights of (1 : 3 : 1)). For example, this would allow us to have a 
>> natural way of performing arithmetic on the real model of hyperelliptic 
>> curves. Something important for my own research. 
>>
>> I believe in terms of Sage code this means changing the hyperelliptic 
>> curves to be toric varieties rather than projective varieties and will 
>> ultimately lead to a lot of work in rewriting the classes. 
>>
>> This is not unexpected though. For example the docstring of the 
>> `points()` method discusses the possibility of this change in the future: 
>> https://github.com/sagemath/sage/blob/e417e2205be84d6d567b8897527fa6945ad09bdb/src/sage/schemes/hyperelliptic_curves/hyperelliptic_finite_field.py#L805-L858
>>
>> This is associated with the sage-devel thread: 
>> https://groups.google.com/g/sage-devel/c/eKY85KwFldE which discusses 
>> progress on implementing arithmetic for Jacobians of hyperelliptic curves 
>> where there are 2, 1 (all cases) or 0 (only even genus) points at infinity. 
>> The work being done there uses a weighted polynomial ring to compute on the 
>> smooth model of hyperelliptic curves. 
>>
>> *A note on inheritance*
>>
>> There is currently another hiccup in this transition. The class 
>> EllipticCurve_finite_field is a child of HyperellipticCurve_finite_field 
>> which 
>> se

[sage-devel] Re: VOTE: use the smooth model instead of the plane projective model for hyperelliptic curves

2024-03-11 Thread Giacomo Pope

Yes, I didn't properly think about breaking changes so if I simply add a 
new implementation into sage then maybe this thread can switch from a VOTE 
to simply people giving advice / feedback if they so wish.

On Monday, March 11, 2024 at 10:24:46 PM UTC Nils Bruin wrote:

> On Monday 11 March 2024 at 15:04:50 UTC-7 Giacomo Pope wrote:
>
> I chose the weighting (1 : g + 1 : 1) following Galbraith's textbook 
> https://www.math.auckland.ac.nz/~sgal018/crypto-book/ch10.pdf when 
> implementing the arithmetic on the Jacobian. This is not a "good" answer 
> though.
>
> I would love to hear from more people about what they use / would want to 
> use. 
>
>
> I think it makes sense because at least it means the representation of 
> most points is still compatible.
>  
>
> As for deprecations, I won't know exactly how much will change before I 
> start working on this but if anyone's code fundamentally uses the fact it's 
> a projective variety and the functions coming from this then I suppose 
> everything will simply have to exist as a second class with deprecation 
> warnings. I don't know what's best here.
>
>
> Yes, with a change as fundamental as this, I think you may be best of just 
> copying over the class and make your adjustments there. We'll have two 
> underlying "implementations" of hyperelliptic curves, with different 
> projective closures. We'll start out with the bad backward compatible one 
> as default. At some point, we deprecate that. Then you can change the 
> default. Then we can delete the old implementation. And then you can 
> reintroduce the old naming as an alias/default.
>
> I suspect most code that relies on non-weighted projective closures is 
> broken anyway, but you'd need pretty strong arguments to deviate from 
> normal deprecation.
>  
>
> Ultimately (even if I wait 2 years) I think it would be good for sage to 
> have more functioning arithmetic on Jacobians but this is obviously a very 
> small slice of pie in the whole meal of hyperellptic curves.
>
>
> We can have the functionality without delay. It might just not be 
> available on "default" objects until 2 years down the road. That's a little 
> unfortunate and makes it less discoverable, but I think we do need to take 
> backward compatibility seriously. 
>
> Also note that with this course of action, there is hardly anything 
> controversial to the first steps: you're just adding functionality. So a 
> sagedevel vote might not even be necessary.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/39d3d787-ab42-4417-bec4-bc00ce345bb1n%40googlegroups.com.

[sage-devel] Re: VOTE: use the smooth model instead of the plane projective model for hyperelliptic curves

2024-03-11 Thread Giacomo Pope

I chose the weighting (1 : g + 1 : 1) following Galbraith's 
textbook https://www.math.auckland.ac.nz/~sgal018/crypto-book/ch10.pdf when 
implementing the arithmetic on the Jacobian. This is not a "good" answer 
though.

I would love to hear from more people about what they use / would want to 
use. 

As for deprecations, I won't know exactly how much will change before I 
start working on this but if anyone's code fundamentally uses the fact it's 
a projective variety and the functions coming from this then I suppose 
everything will simply have to exist as a second class with deprecation 
warnings. I don't know what's best here.

Ultimately (even if I wait 2 years) I think it would be good for sage to 
have more functioning arithmetic on Jacobians but this is obviously a very 
small slice of pie in the whole meal of hyperellptic curves.

As one data point, the following magma code

```
R := PolynomialRing(Rationals());
f := x^6 + x + 1;
H := HyperellipticCurve(f);
Ambient(H)
```

Outputs

Projective Space of dimension 2 over Rational Field
Variables: $.1, $.2, $.3
The grading is:
1, 3, 1

Matching my proposed grading.

On Monday, March 11, 2024 at 9:52:09 PM UTC Nils Bruin wrote:

> The change makes sense, but you should investigate if it is at all 
> possible to do this going through normal deprecation procedures, which 
> would probably involve having both functionalities for some time (likely 
> via differently named methods or via a flag implemented in a 
> backward-compatime way), then having a deprecation period on the "old" 
> functionality. After that the deprecated functionality can be removed. 
> After a suitable wait period, the vacated space in the namespace can now be 
> used for the new method. You'll be taking a couple of years before you're 
> there.
>
> If it's not possible, you'd better have very good reasons to probably 
> break people's code out there with very little warning.
>
> Once you find a way to do this, there's another choice in convention to 
> consider: do you go with (1:1:g+1) weights or with (1:g+1:1) ? I.e., with 
> [X:Z:Y] or [X:Y:Z]. Both have precedent and people who are used to the 
> other convention will find it really annoying to adjust.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/608132ed-19f5-4502-9506-ddd892ff3d85n%40googlegroups.com.

[sage-devel] VOTE: use the smooth model instead of the plane projective model for hyperelliptic curves

2024-03-11 Thread Giacomo Pope

Dear all,

*Summary*

To better support arithmetic on Jacobians and have a more natural
implementation of hyperelliptic curves, we should implement them as toric
varieties with a weighted polynomial ring (1 : 3 : 1) instead of plane
projective curves.

*Yes / No*

*Discussion*

I am currently hoping to improve hyperelliptic curves and Jacobians of
hyperelliptic curve in Sage. One big motivation for me is to try and get
our computations with similar coverage to what exists in Magma to allow
more academics in the field to benefit from the open-source community of
Sage. The first main goal of this is for full featured arithmetic on the
Jacobians of hyperelliptic curves.

The big blocker for me currently is that currently Sage implements
hyperelliptic curves in the plane projective model. This is not an issue
for the current methods, and it also allows for sensible arithmetic on
Jacobians when there is one point at infinity. However, the more natural
model I believe is the smooth model which uses a weighted polynomial
(weights of (1 : 3 : 1)). For example, this would allow us to have a
natural way of performing arithmetic on the real model of hyperelliptic
curves. Something important for my own research.

I believe in terms of Sage code this means changing the hyperelliptic
curves to be toric varieties rather than projective varieties and will
ultimately lead to a lot of work in rewriting the classes.

This is not unexpected though. For example the docstring of the `points()`
method discusses the possibility of this change in the
future:
https://github.com/sagemath/sage/blob/e417e2205be84d6d567b8897527fa6945ad09bdb/src/sage/schemes/hyperelliptic_curves/hyperelliptic_finite_field.py#L805-L858

This is associated with the sage-devel
thread: https://groups.google.com/g/sage-devel/c/eKY85KwFldE which
discusses progress on implementing arithmetic for Jacobians of
hyperelliptic curves where there are 2, 1 (all cases) or 0 (only even
genus) points at infinity. The work being done there uses a weighted
polynomial ring to compute on the smooth model of hyperelliptic curves.

*A note on inheritance*

There is currently another hiccup in this transition. The class
EllipticCurve_finite_field is a child of HyperellipticCurve_finite_field which
seems to have happened at some point in the past when computing lists of
points on the curve. As far as I can tell, this inheritance has no other
used functionality. (Please correct me if I am missing something). I have
shown in https://github.com/sagemath/sage/pull/37595 that this inherited
method is always slower than using the group structure on the elliptic
curve, so this inheritance can be removed once PR 37595 has been merged.

--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/dc78d787-5e82-4fdb-92cd-f299b71972c5n%40googlegroups.com.

[Powerdevil] [Bug 481308] screen locker black with cursor on X11

2024-03-10 Thread Giacomo Lozito

https://bugs.kde.org/show_bug.cgi?id=481308

--- Comment #49 from Giacomo Lozito  ---
(In reply to Jakob Petsovits from comment #44)
> Not sure how best to deal with bug reports because ideally we'd have two
> separate ones, but if the symptoms are indeed very similar then it'll be
> difficult to tell them apart. Hopefully a large number of users will see
> their setup fixed and the remaining ones can target the screen locker /
> Plasma theme issue in a targeted way.

I have created a separate bug report
(https://bugs.kde.org/show_bug.cgi?id=483163) for the breeze style +
kscreenlocker issue. Not an urgent one to fix imho as I can simply switch to
Breeze Light for now to mitigate issue.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kscreenlocker] [Bug 483163] New: blank screen on lock screen activation when using breeze plasma style

2024-03-10 Thread Giacomo Lozito

https://bugs.kde.org/show_bug.cgi?id=483163

Bug ID: 483163
   Summary: blank screen on lock screen activation when using
breeze plasma style
Classification: Plasma
   Product: kscreenlocker
   Version: 6.0.1
  Platform: Arch Linux
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: plasma-b...@kde.org
  Reporter: giacomo.loz...@protonmail.com
  Target Milestone: ---

SUMMARY
When activating lock screen (via shortcut, menu option or timer), the screen
becomes blank. The screen is not turned off and maintains the backlight on, but
nothing is drawn on screen. Cursor can be seen when moved, and password can be
blindly typed to return into desktop, which becomes immediately visible again.
Also, when the lock screen is blank like this, switching to another virtual
terminal and returning to the lock screen vt will cause it to be displayed
correctly.

This behavior only occurs when Breeze is selected as plasma style, and it
happens most of the time. Switching to Breeze Light, Breeze Dark or Oxygen will
result in the lock screen being displayed correctly 100% of the time. Switching
back to Breeze will cause the wrong behavior again. 

Please note that this bug is separate from
https://bugs.kde.org/show_bug.cgi?id=481308 which is powerdevil-related and
causes the screen to turn off. Energy settings make no difference for this
issue, the screen is still on but blank. The difference to behaviour seems to
be made by changing the plasma style.

STEPS TO REPRODUCE
1. Use Breeze as plasma style
2.  Activate lock screen using keyboard shortcut, launcher option or wait for
it to be activated by inactivity
3. 19 times out of 20, the lock screen will be blank, even if the screen is
turned on

OBSERVED RESULT
Blank screen, with the screen turned on. Moving cursor around makes it visible.

EXPECTED RESULT
Lock screen window correctly drawn.

SOFTWARE/OS VERSIONS
Operating System: Arch Linux 
KDE Plasma Version: 6.0.1
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.7.9-arch1-1 (64-bit)
Graphics Platform: X11
Processors: 8 × AMD Ryzen 7 3700U with Radeon Vega Mobile Gfx
Memory: 13.6 GiB of RAM
Graphics Processor: AMD Radeon Vega 10 Graphics

ADDITIONAL INFORMATION
Speculation: one notable difference between Breeze and the other plasma styles
(Breeze Light, Dark, etc.) is that Breeze is the only style that is designed to
follow the user-chosen color scheme. So it is possible that color scheme
implementation in plasma is playing a role into the issue. I have tried
changing the color scheme (i.e., using the one from wallpaper or the default
one) but changing the scheme itself makes no difference. The issue only seems
to occur with the screen locker and I have not seen it anywhere else in plasma.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Powerdevil] [Bug 481308] screen locker black with cursor on X11

https://bugs.kde.org/show_bug.cgi?id=481308

--- Comment #43 from Giacomo Lozito  ---
(In reply to Jakob Petsovits from comment #42)
> (In reply to Giacomo Lozito from comment #41)
> > Based on logs, I think you are right on Powerdevil is not turning the screen
> > off. But something is causing the screen lock not to be displayed (as if its
> > window wasn't drawn?)
> 
> Okay, so then we've got two different bugs on our hands. My patch from
> https://invent.kde.org/plasma/powerdevil/-/merge_requests/332 should solve
> one. We'll still have to figure out where the other one comes from.

For my specific issue, I just made some progress. I tried changing the plasma
style away from breeze to breeze light and now the screen lock consistently
shows up when I lock screen. Once I switch plasma style back to breeze, I can
reproduce the issue again. Switching away from breeze to breeze dark or oxygen
also fixes it. I have tried deleting ~/.cache on the off chance this is caused
by a cached copy of breeze, but does not seem to help.

Anyway, even though this issue only manifests with the screen lock (and the
symptoms are deceptively similar to what reported by others for powerdevil) my
issue is unrelated with powerdevil.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Powerdevil] [Bug 481308] screen locker black with cursor on X11

https://bugs.kde.org/show_bug.cgi?id=481308

--- Comment #41 from Giacomo Lozito  ---
> On that note, perhaps run a quick test with powerdevil stopped (i.e.
> `systemctl stop --user plasma-powerdevil.service`) to confirm that the DPMS
> action is actually responsible for this? Screen stays on with powerdevil
> stopped and turns blank with powerdevil running, yes?

Just done this test. The screen still goes blank as soon as I activate screen
lock, even with powerdevil off, and obviously no powerdevil-related log lines
appearing in journalctl.

> If you're not seeing those, I have to wonder if perhaps some other component
> is independently turning off the screen that's unrelated to PowerDevil.

There is an important detail here, which I reported incorrectly in my previous
message, sorry. When I activate the screen lock, the screen goes blank, but not
off (meaning that I can still see the screen backlight on, and the mouse cursor
is visible if I move it). If I then press Esc, it goes off. If I press it
again, the screen turns on (with nothing displayed, but the backlight is on)
for a moment, then back off.

Based on logs, I think you are right on Powerdevil is not turning the screen
off. But something is causing the screen lock not to be displayed (as if its
window wasn't drawn?)

-- 
You are receiving this mail because:
You are watching all bug changes.

[Powerdevil] [Bug 481308] screen locker black with cursor on X11

https://bugs.kde.org/show_bug.cgi?id=481308

--- Comment #39 from Giacomo Lozito  ---
Note: reading those log lines and looking at where those are located in the
patch, the impression I get is that my timeout for turning off the screen (60
seconds) is not being honored. Instead, it immediately proceeds to turn off the
screen. This would also explain why I pressing esc turns on the screen for a
moment for me, and then turns it off again (because instead of waiting 60
seconds, it's doing the fast display turn off without waiting for timeout).

-- 
You are receiving this mail because:
You are watching all bug changes.

[Powerdevil] [Bug 481308] screen locker black with cursor on X11

https://bugs.kde.org/show_bug.cgi?id=481308

--- Comment #38 from Giacomo Lozito  ---
(In reply to Jakob Petsovits from comment #37)
> (In reply to Steven Noonan from comment #32)
> > Tried applying the patch in the powerdevil merge request and
> > rebuilt/installed poweredevil. From what I can tell it had no impact on
> > either the escape key behavior or the blank lock screen render.
> 
> (In reply to Giacomo Lozito from comment #35)
> > Same, patch does not seem to change behaviour. Also FWIW, I have turn off
> > screen automatically after 5 mins in Energy Saving config, and allow
> > unlocking without password for 15 seconds in Screen Locking config.
> 
> Thanks for testing, much appreciated. I'm unclear as to why the fix wouldn't
> be working. Given that you have a built-from-souce setup, could you do two
> more things to help out?
> 
> 1. Please make sure that
> $PREFIX/lib/plugins/powerdevil/action/powerdevil_dpmsaction.so was installed
> in addition to the powerdevil binary itself. That's where the power
> management service's screen turn-off logic (and the proposed fix) is located
> in practice.
> 
> 2. Please provide some of that new debug output that I added in the same
> commit, to get a rough understanding of how your screen turns blank. On a
> system with systemd, the easiest way to make the extra logs show up in
> journalctl is:
> 
> systemctl edit --user plasma-powerdevil.service
> 
> and in the free space between the top two comment paragraphs, add this line:
> 
> [Service]
> Environment="QT_LOGGING_RULES=org.kde.powerdevil=true"
> 
> The new logging entries all start with "org.kde.powerdevil: DPMS:", they
> describe what idle timeouts are set for the action to trigger and when the
> screen actually gets turned off. Please paste some of those logs here. If
> that's an issue because the screen is blank, I've found that switching
> between virtual terminals (e.g. Ctrl+Alt+F7 and back to the original one,
> wherever it's located as per `loginctl list-sessions`) will restore the
> screen to non-black.
> 
> Thanks!

Happy to test.
For 1. I confirmed that
/usr/lib/qt6/plugins/powerdevil/action/powerdevil_dpmsaction.so is included in
the arch powerdevil package I patched and rebuilt. I also confirmed its md5sum
being different before/after rebuild/reinstall to make sure it's been modified.

For 2. I have enabled logging and I can see some of the logging lines in
question, more precisely (filtering only the powerdevil: DPMS lines):

Mar 09 17:00:20 arcadia org_kde_powerdevil[1211]: org.kde.powerdevil: DPMS:
registering idle timeout (screen lock activating) after 6ms
Mar 09 17:00:22 arcadia org_kde_powerdevil[1211]: org.kde.powerdevil: DPMS:
registering idle timeout (screen unlocked) after 30ms

Mar 09 17:00:39 arcadia org_kde_powerdevil[1211]: org.kde.powerdevil: DPMS:
registering idle timeout (screen lock activating) after 6ms
Mar 09 17:00:43 arcadia org_kde_powerdevil[1211]: org.kde.powerdevil: DPMS:
registering idle timeout (screen unlocked) after 30ms

Mar 09 17:01:23 arcadia org_kde_powerdevil[1211]: org.kde.powerdevil: DPMS:
registering idle timeout (screen unlocked) after 30ms
Mar 09 17:01:20 arcadia org_kde_powerdevil[1211]: org.kde.powerdevil: DPMS:
registering idle timeout (screen lock activating) after 6ms

Mar 09 17:02:13 arcadia org_kde_powerdevil[1211]: org.kde.powerdevil: DPMS:
registering idle timeout (screen lock activating) after 6ms
Mar 09 17:02:25 arcadia org_kde_powerdevil[1211]: org.kde.powerdevil: DPMS:
registering idle timeout (screen unlocked) after 30ms

for each of the 4 attempts, the first line (screen lock activating) pops up as
soon as I activate screen lock using Meta+L. The screen unlocked one comes up
as I blindly type my password to unlock screen. Worth mentioning that one of
these 4 attempts was "successful" (like I mentioned before, rarely the
screenlock screen will show as expected). I also tried to switch virtual
terminal in the fourth attempt, which  causes the screenlock screen to show
correctly once switched back to, but does not seem to produce any additional
log line of interest.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Powerdevil] [Bug 481308] screen locker black with cursor on X11

https://bugs.kde.org/show_bug.cgi?id=481308

--- Comment #35 from Giacomo Lozito  ---
(In reply to Steven Noonan from comment #32)
> Tried applying the patch in the powerdevil merge request and
> rebuilt/installed poweredevil. From what I can tell it had no impact on
> either the escape key behavior or the blank lock screen render.

Same, patch does not seem to change behaviour. Also FWIW, I have turn off
screen automatically after 5 mins in Energy Saving config, and allow unlocking
without password for 15 seconds in Screen Locking config.

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

2024-03-08 Thread Giacomo Pope

As a small update, the repository now contains code to

- perform arithmetic for
  - the imaginary model (ramified, one point at infinity) for all cases
  - the real model (split, two points at infinity) for all cases
  - the real model (inert, zero points at infinity) for even genus
  Which allows us to do "as much" as Magma does for Jacobians of 
hyperellipticc curves from the perspective of arithmetic. 

My current "test" for the arithmetic is that D - D = 0 for all cases, that 
jacobian_order * D = zero and that order_from_multiple(D) works. If people 
have other ideas for tests, please let me know. Of course at the moment 
these tests are over finite fields but you can reasonable use other fields 
(as Sabrina's message shows) but I am less sure about how to do randomised 
testing here.

- We also have a function which can randomly (but not uniformly) sample 
elements of the Jacobian for all the cases.
- We can compute the order of the Jacobian from the frob. polynomial and 
using the arithmetic and in-build `order_from_multiple` then find the order 
of divisors

I think the next thing to do is to look at isomorphisms and maybe even 
isogenies (Richelot only for genus two perhaps?)

If you are interested in this area and want to contribute, then I think 
fleshing out the code in this repo will be easier during these early stages 
and once it feels complete we can look at replacing the current code in 
sagemath with this newer version.

On Thursday, March 7, 2024 at 9:40:58 PM UTC Sabrina Kunzweiler wrote:

> Thanks for mentioning the related discussion. We checked that in the new 
> implementation in Giacomo's repository, this issue is solved. 
>
> In the example that was given in the chat, we obtain the following output:
> ```
> sage: R. = QQ[]
> sage: f = 144*x^6 - 240*x^5 + 148*x^4 + 16*x^3 - 16*x^2 - 4*x + 1
> sage: H = HyperellipticCurveNew(f)
> sage: J = Jacobian(H)
> sage: P = J(H([0,1]))-J(H([0,-1]))
> sage: (5*P).is_zero()
> False
> sage: 5*P
> (1, 0 : 2)
> ```
> Here, this means $$ 5 P = (1:12:0) - (1:-12:0) $$ which coincides with the 
> result from magma. 
>
>
> Kwankyu Lee schrieb am Donnerstag, 7. März 2024 um 05:44:33 UTC+1:
>
>> It's still here: https://github.com/sagemath/sage/issues/32024
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/16695996-c9bc-4a08-a1a4-37179e7a8956n%40googlegroups.com.

[kscreenlocker] [Bug 481308] screen locker blank-with-cursor [xorg]

2024-03-07 Thread Giacomo Lozito

https://bugs.kde.org/show_bug.cgi?id=481308

--- Comment #25 from Giacomo Lozito  ---
> Thanks everyone for chiming in with system configurations. Just to make
> sure, the trick from the corresponding (now fixed) Wayland bug doesn't help
> here, where you press Esc twice to make the display come back? (once to hide
> the screen locker and properly turn off the screen, the second time to bring
> it back)

Not for me. If anything, it shows very odd behaviour.
When I lock screen:
- screen will be blank
- first Esc keypress will cause screen to turn off
- second Esc keypress will cause it to turn on again for a moment (but blank),
and then the screen will turn off after a second
- subsequente Esc keypresses will do the same (screen on for a second but
blank, then turning off)
- moving the mouse, unlike the Esc keypress, causes the screen to stay on
(although still blank)

In case it helps, this behaviour is somewhat reproducible with"
kscreenlocker_greet --testing" too:
- launching the testing screen will work fine (lock screen content is visible
within a decorated window)
- pressing Esc will cause the screen to turn off
- a second Esc keypress will cause the screen to turn on again, but it will
turn off on its own after a second
-  moving the mouse, unlike the Esc keypress, causes the he testing screen to
stay on (with content visible)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kscreenlocker] [Bug 481308] screen locker blank-with-cursor [xorg]

2024-03-07 Thread Giacomo Lozito

https://bugs.kde.org/show_bug.cgi?id=481308

--- Comment #19 from Giacomo Lozito  ---
Can confirm on Arch Linux current on my laptop, upgraded this morning to plasma
6. No monitor attached, issue occurs on the laptop screen directly. As soon as
I lock screen, either via application launcher or via keyboard shortcut, screen
goes blank but I can see cursor if I move it, as per previous comments. I can
type my password blindly and it unlocks screen and screen is visible again.
Perhaps worth mentioning that I get the issue 19 times out of 20. Very rarely,
the lock screen works as expected.

Also
/usr/lib/kscreenlocker_greet --testing
always works fine.

SOFTWARE/OS VERSIONS
Linux: linux 6.7.8-arch1-1
KDE Plasma Version: 6.0.1
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Graphics Platform: X11
Processors: 8 × AMD Ryzen 7 3700U with Radeon Vega Mobile Gfx
Memory: 13.6 GiB of RAM
Graphics Processor: AMD Radeon Vega 10 Graphics
Manufacturer: ASUSTeK COMPUTER INC.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kscreenlocker] [Bug 481308] screen locker blank-with-cursor [xorg]

2024-03-07 Thread Giacomo Lozito

https://bugs.kde.org/show_bug.cgi?id=481308

Giacomo Lozito  changed:

   What|Removed |Added

 CC||giacomo.loz...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

Bug#1065599: gcc-14-offload-nvptx: openmp offload compile fails due to missing libgomp.spec

Package: gcc-14-offload-nvptx
Version: 14-20240303-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

due to a different organisation in file installation with respect to 
gcc-12-offload-nvptx, compiling code to offload openmp to nvptx fails with the 
following:
x86_64-linux-gnu-accel-nvptx-none-gcc-14: fatal error: cannot read spec file 
'libgomp.spec': No such file or directory
compilation terminated.
nvptx mkoffload: fatal error: x86_64-linux-gnu-accel-nvptx-none-gcc-14 returned 
1 exit status
compilation terminated.
lto-wrapper: fatal error: 
/usr/libexec/gcc/x86_64-linux-gnu/14//accel/nvptx-none/mkoffload returned 1 
exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed

While gcc-12-offload-nvptx installed executables, includes, and libs under 
/usr/lib/gcc/x86_64-linux-gnu/12/accel/nvptx-none, and found them, 
gcc-14-offload-nvptx does not appear to install them anywhere, nor
to depend on any other separate package that does. This effectively renders the 
package unusable. 

Thanks in advance, best regards
Giacomo Mulas


*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (401, 'unstable'), (10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-14-offload-nvptx depends on:
ii  gcc-14 14-20240303-1
ii  gcc-14-base14-20240303-1
ii  libc6  2.37-15.1
ii  libc6-dev  2.37-15.1
ii  libgmp10   2:6.3.0+dfsg-2+b1
ii  libgomp-plugin-nvptx1  14-20240303-1
ii  libmpc31.3.1-1+b2
ii  libmpfr6   4.2.1-1+b1
ii  libzstd1   1.5.5+dfsg2-2
ii  nvptx-tools0.20230904-1
ii  zlib1g 1:1.3.dfsg-3.1

gcc-14-offload-nvptx recommends no packages.

gcc-14-offload-nvptx suggests no packages.

-- no debconf information

Bug#1065599: gcc-14-offload-nvptx: openmp offload compile fails due to missing libgomp.spec

Package: gcc-14-offload-nvptx
Version: 14-20240303-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

due to a different organisation in file installation with respect to 
gcc-12-offload-nvptx, compiling code to offload openmp to nvptx fails with the 
following:
x86_64-linux-gnu-accel-nvptx-none-gcc-14: fatal error: cannot read spec file 
'libgomp.spec': No such file or directory
compilation terminated.
nvptx mkoffload: fatal error: x86_64-linux-gnu-accel-nvptx-none-gcc-14 returned 
1 exit status
compilation terminated.
lto-wrapper: fatal error: 
/usr/libexec/gcc/x86_64-linux-gnu/14//accel/nvptx-none/mkoffload returned 1 
exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed

While gcc-12-offload-nvptx installed executables, includes, and libs under 
/usr/lib/gcc/x86_64-linux-gnu/12/accel/nvptx-none, and found them, 
gcc-14-offload-nvptx does not appear to install them anywhere, nor
to depend on any other separate package that does. This effectively renders the 
package unusable. 

Thanks in advance, best regards
Giacomo Mulas


*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (401, 'unstable'), (10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-14-offload-nvptx depends on:
ii  gcc-14 14-20240303-1
ii  gcc-14-base14-20240303-1
ii  libc6  2.37-15.1
ii  libc6-dev  2.37-15.1
ii  libgmp10   2:6.3.0+dfsg-2+b1
ii  libgomp-plugin-nvptx1  14-20240303-1
ii  libmpc31.3.1-1+b2
ii  libmpfr6   4.2.1-1+b1
ii  libzstd1   1.5.5+dfsg2-2
ii  nvptx-tools0.20230904-1
ii  zlib1g 1:1.3.dfsg-3.1

gcc-14-offload-nvptx recommends no packages.

gcc-14-offload-nvptx suggests no packages.

-- no debconf information

Bug#1065599: gcc-14-offload-nvptx: openmp offload compile fails due to missing libgomp.spec

Package: gcc-14-offload-nvptx
Version: 14-20240303-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

due to a different organisation in file installation with respect to 
gcc-12-offload-nvptx, compiling code to offload openmp to nvptx fails with the 
following:
x86_64-linux-gnu-accel-nvptx-none-gcc-14: fatal error: cannot read spec file 
'libgomp.spec': No such file or directory
compilation terminated.
nvptx mkoffload: fatal error: x86_64-linux-gnu-accel-nvptx-none-gcc-14 returned 
1 exit status
compilation terminated.
lto-wrapper: fatal error: 
/usr/libexec/gcc/x86_64-linux-gnu/14//accel/nvptx-none/mkoffload returned 1 
exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed

While gcc-12-offload-nvptx installed executables, includes, and libs under 
/usr/lib/gcc/x86_64-linux-gnu/12/accel/nvptx-none, and found them, 
gcc-14-offload-nvptx does not appear to install them anywhere, nor
to depend on any other separate package that does. This effectively renders the 
package unusable. 

Thanks in advance, best regards
Giacomo Mulas


*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (401, 'unstable'), (10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-14-offload-nvptx depends on:
ii  gcc-14 14-20240303-1
ii  gcc-14-base14-20240303-1
ii  libc6  2.37-15.1
ii  libc6-dev  2.37-15.1
ii  libgmp10   2:6.3.0+dfsg-2+b1
ii  libgomp-plugin-nvptx1  14-20240303-1
ii  libmpc31.3.1-1+b2
ii  libmpfr6   4.2.1-1+b1
ii  libzstd1   1.5.5+dfsg2-2
ii  nvptx-tools0.20230904-1
ii  zlib1g 1:1.3.dfsg-3.1

gcc-14-offload-nvptx recommends no packages.

gcc-14-offload-nvptx suggests no packages.

-- no debconf information

Bug#1065598: gcc-13-offload-nvptx: openmp offload compile fails due to missing libgomp.spec

Package: gcc-13-offload-nvptx
Version: 13.2.0-18
Severity: grave
Justification: renders package unusable

Dear Maintainer,

due to a different organisation in file installation with respect to 
gcc-12-offload-nvptx, compiling code to offload openmp to nvptx fails with the 
following:
x86_64-linux-gnu-accel-nvptx-none-gcc-13: fatal error: cannot read spec file 
'libgomp.spec': No such file or directory
compilation terminated.
nvptx mkoffload: fatal error: x86_64-linux-gnu-accel-nvptx-none-gcc-13 returned 
1 exit status
compilation terminated.
lto-wrapper: fatal error: 
/usr/libexec/gcc/x86_64-linux-gnu/13//accel/nvptx-none/mkoffload returned 1 
exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed

While gcc-12-offload-nvptx installed executables, includes, and libs under 
/usr/lib/gcc/x86_64-linux-gnu/12/accel/nvptx-none, and found them, 
gcc-13-offload-nvptx does not appear to install them anywhere, nor to depend on 
any other separate package that does. This effectively renders the package 
unusable. While the gcc-12 offload still works, gcc-13 is now the default 
compiler on sid, meaning that trying to compile openmp to offload to nvptx with 
the default compiler fails.

Thanks in advance, best regards
Giacomo Mulas


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (401, 'unstable'), (10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-13-offload-nvptx depends on:
ii  gcc-13 13.2.0-18
ii  gcc-13-base13.2.0-18
ii  libc6  2.37-15.1
ii  libc6-dev  2.37-15.1
ii  libgmp10   2:6.3.0+dfsg-2+b1
ii  libgomp-plugin-nvptx1  14-20240303-1
ii  libmpc31.3.1-1+b2
ii  libmpfr6   4.2.1-1+b1
ii  libzstd1   1.5.5+dfsg2-2
ii  nvptx-tools0.20230904-1
ii  zlib1g 1:1.3.dfsg-3.1

gcc-13-offload-nvptx recommends no packages.

gcc-13-offload-nvptx suggests no packages.

-- no debconf information

Bug#1065598: gcc-13-offload-nvptx: openmp offload compile fails due to missing libgomp.spec

Package: gcc-13-offload-nvptx
Version: 13.2.0-18
Severity: grave
Justification: renders package unusable

Dear Maintainer,

due to a different organisation in file installation with respect to 
gcc-12-offload-nvptx, compiling code to offload openmp to nvptx fails with the 
following:
x86_64-linux-gnu-accel-nvptx-none-gcc-13: fatal error: cannot read spec file 
'libgomp.spec': No such file or directory
compilation terminated.
nvptx mkoffload: fatal error: x86_64-linux-gnu-accel-nvptx-none-gcc-13 returned 
1 exit status
compilation terminated.
lto-wrapper: fatal error: 
/usr/libexec/gcc/x86_64-linux-gnu/13//accel/nvptx-none/mkoffload returned 1 
exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed

While gcc-12-offload-nvptx installed executables, includes, and libs under 
/usr/lib/gcc/x86_64-linux-gnu/12/accel/nvptx-none, and found them, 
gcc-13-offload-nvptx does not appear to install them anywhere, nor to depend on 
any other separate package that does. This effectively renders the package 
unusable. While the gcc-12 offload still works, gcc-13 is now the default 
compiler on sid, meaning that trying to compile openmp to offload to nvptx with 
the default compiler fails.

Thanks in advance, best regards
Giacomo Mulas


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (401, 'unstable'), (10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-13-offload-nvptx depends on:
ii  gcc-13 13.2.0-18
ii  gcc-13-base13.2.0-18
ii  libc6  2.37-15.1
ii  libc6-dev  2.37-15.1
ii  libgmp10   2:6.3.0+dfsg-2+b1
ii  libgomp-plugin-nvptx1  14-20240303-1
ii  libmpc31.3.1-1+b2
ii  libmpfr6   4.2.1-1+b1
ii  libzstd1   1.5.5+dfsg2-2
ii  nvptx-tools0.20230904-1
ii  zlib1g 1:1.3.dfsg-3.1

gcc-13-offload-nvptx recommends no packages.

gcc-13-offload-nvptx suggests no packages.

-- no debconf information

Bug#1065598: gcc-13-offload-nvptx: openmp offload compile fails due to missing libgomp.spec

Package: gcc-13-offload-nvptx
Version: 13.2.0-18
Severity: grave
Justification: renders package unusable

Dear Maintainer,

due to a different organisation in file installation with respect to 
gcc-12-offload-nvptx, compiling code to offload openmp to nvptx fails with the 
following:
x86_64-linux-gnu-accel-nvptx-none-gcc-13: fatal error: cannot read spec file 
'libgomp.spec': No such file or directory
compilation terminated.
nvptx mkoffload: fatal error: x86_64-linux-gnu-accel-nvptx-none-gcc-13 returned 
1 exit status
compilation terminated.
lto-wrapper: fatal error: 
/usr/libexec/gcc/x86_64-linux-gnu/13//accel/nvptx-none/mkoffload returned 1 
exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed

While gcc-12-offload-nvptx installed executables, includes, and libs under 
/usr/lib/gcc/x86_64-linux-gnu/12/accel/nvptx-none, and found them, 
gcc-13-offload-nvptx does not appear to install them anywhere, nor to depend on 
any other separate package that does. This effectively renders the package 
unusable. While the gcc-12 offload still works, gcc-13 is now the default 
compiler on sid, meaning that trying to compile openmp to offload to nvptx with 
the default compiler fails.

Thanks in advance, best regards
Giacomo Mulas


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (401, 'unstable'), (10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-13-offload-nvptx depends on:
ii  gcc-13 13.2.0-18
ii  gcc-13-base13.2.0-18
ii  libc6  2.37-15.1
ii  libc6-dev  2.37-15.1
ii  libgmp10   2:6.3.0+dfsg-2+b1
ii  libgomp-plugin-nvptx1  14-20240303-1
ii  libmpc31.3.1-1+b2
ii  libmpfr6   4.2.1-1+b1
ii  libzstd1   1.5.5+dfsg2-2
ii  nvptx-tools0.20230904-1
ii  zlib1g 1:1.3.dfsg-3.1

gcc-13-offload-nvptx recommends no packages.

gcc-13-offload-nvptx suggests no packages.

-- no debconf information

Bug#1065596: gcc-12-offload-nvptx: offloading fails due to unsupported sm_35 default arch

Package: gcc-12-offload-nvptx
Version: 12.3.0-15
Severity: normal

Dear Maintainer,

current versions of ptxas dropped support for sm_35, yet gcc-12-offload-nvptx 
uses that as the default, if unspecified. I can still compile openmp code 
offloaded to nvptx, but I have to explicitly add something like 
-foffload-options=nvptx-none="-march=sm_53" to override the default target 
arch. Please fix this, or make the default configurable so that one does not 
have to always specify it on the command line.
I am not sure this should be fixed in gcc-12-offload-nvptx or in nvptx-tools, 
feel free to reassign the bug, if appropriate.

Thanks in advance, best regards
Giacomo Mulas

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (401, 'unstable'), (10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-12-offload-nvptx depends on:
ii  gcc-12 12.3.0-15
ii  gcc-12-base12.3.0-15
ii  libc6  2.37-15.1
ii  libc6-dev  2.37-15.1
ii  libgmp10   2:6.3.0+dfsg-2+b1
ii  libgomp-plugin-nvptx1  14-20240303-1
ii  libmpc31.3.1-1+b2
ii  libmpfr6   4.2.1-1+b1
ii  libzstd1   1.5.5+dfsg2-2
ii  nvptx-tools0.20230904-1
ii  zlib1g 1:1.3.dfsg-3.1

gcc-12-offload-nvptx recommends no packages.

gcc-12-offload-nvptx suggests no packages.

-- no debconf information

Bug#1065596: gcc-12-offload-nvptx: offloading fails due to unsupported sm_35 default arch

Package: gcc-12-offload-nvptx
Version: 12.3.0-15
Severity: normal

Dear Maintainer,

current versions of ptxas dropped support for sm_35, yet gcc-12-offload-nvptx 
uses that as the default, if unspecified. I can still compile openmp code 
offloaded to nvptx, but I have to explicitly add something like 
-foffload-options=nvptx-none="-march=sm_53" to override the default target 
arch. Please fix this, or make the default configurable so that one does not 
have to always specify it on the command line.
I am not sure this should be fixed in gcc-12-offload-nvptx or in nvptx-tools, 
feel free to reassign the bug, if appropriate.

Thanks in advance, best regards
Giacomo Mulas

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (401, 'unstable'), (10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-12-offload-nvptx depends on:
ii  gcc-12 12.3.0-15
ii  gcc-12-base12.3.0-15
ii  libc6  2.37-15.1
ii  libc6-dev  2.37-15.1
ii  libgmp10   2:6.3.0+dfsg-2+b1
ii  libgomp-plugin-nvptx1  14-20240303-1
ii  libmpc31.3.1-1+b2
ii  libmpfr6   4.2.1-1+b1
ii  libzstd1   1.5.5+dfsg2-2
ii  nvptx-tools0.20230904-1
ii  zlib1g 1:1.3.dfsg-3.1

gcc-12-offload-nvptx recommends no packages.

gcc-12-offload-nvptx suggests no packages.

-- no debconf information

[gem5-users] Re: Transfer cache information to misc register in arm

2024-03-06 Thread Giacomo Travaglini via gem5-users

Hi,

You should establish a link between your cache and the ISA. It shouldn't be 
hard to hack things around.
A cleaner solution would involve using probe points. You could use a probe 
listener per ISA object. For every alocation update on the l2 cache, the 
listeners will be awakened and the sysreg value updated accordingly.

Hope this helps

Giacomo

From: tyhtyh--- via gem5-users 
Sent: 06 March 2024 12:57
To: gem5-users@gem5.org 
Cc: tyh...@mail.ustc.edu.cn 
Subject: [gem5-users] Transfer cache information to misc register in arm

I am a beginner who has just started to learn Gem5. Recently, I attempted to 
use the msr instruction to read out the currently allocated entries in L2cache 
(variable "int allocated" in gem5 stable \ src \ mem \ cache \ queue.hh). I 
have added a new system register for this purpose (by modifying gem5 stable \ 
src \ arch \ arm \ regs \ misc.hh and misc.cc), and the mrs instruction can 
correctly read the value of this register. But what confuses me is how to pass 
this variable to the MiscRegLUTEntry, or in other words, there is an array 
called RegVal miscRegs [NUM-MISCREGS] in "gem 5 stable \ src \ arch \ arm \ 
isa. hh" (which I think is used to store different misc register values). What 
should I do to pass the allocated variable in src \ mem \ cache \ queue.hh to 
miscRegs [NUM-MISCREGS] in src \ arch \ arm \ isa. hh?Thank you very much for 
your help！
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org

Re: [sage-devel] Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

2024-03-06 Thread Giacomo Pope

Thanks John.

>From my minimal local testing I have at least that

- random sampling on the jacobian can find every point on the jacobian 
(there is a fast method using sums of J(P) for P on the curve, but this 
doesnt guarantee all elements of the jacobian are found)
- that multiplication by any random point by the order of the jacobian 
gives the zero element
- that every element has an order dividing the order of the jacobian 
computed using `order_from_multiple`
- that this seems to work for char 2 and odd char providing there are two 
points at infinity (base assumption).
- that the implementation of negation works as expected and for random 
points D - D is always zero

Now that these basic features are in place and we have addition, 
subtraction and multiplication by scalars, I want to make sure the 
functions are as simple as possible to aid with the integration into sage.

On Wednesday, March 6, 2024 at 1:52:26 PM UTC John Cremona wrote:

> I'm going to forward this to sage-nt as there may be people who read that 
> but not this.
>
> Meanwhile I would recommend getting something to work correctly before 
> worrying too much about what is most efficient.
>
>
> John
>
> On Wed, 6 Mar 2024, 12:52 Giacomo Pope,  wrote:
>
>> *=== Summary*
>>
>> Arithmetic of divisors for Jacobians of hyperelliptic curves with two 
>> points at infinity is not currently properly supported for SageMath. Worse, 
>> there are no checks or error handling and the output of the arithmetic is 
>> simply wrong.
>>
>> Minimal example:
>>
>> sage: R. = PolynomialRing(GF(11))
>> sage: f = x^6 + x + 1
>> sage: H = HyperellipticCurve(f)
>> sage: J = H.jacobian()
>> sage: D = J(H.lift_x(1))
>> sage: jacobian_order = sum(H.frobenius_polynomial())
>> sage: jacobian_order * D
>> (x + 10, y + 5) # this should be (1)
>>
>> I wrote about this as a GitHub issue as well: 
>> https://github.com/sagemath/sage/issues/37109 but I am now coming to 
>> sage-devel as I have *some* progress and want to try and have advice / 
>> conversation about how we can improve this.
>>
>> *=== Suggestion*
>>
>> I have been working on a small proof of concept for arithmetic with 
>> Sabrina Kunzweiler using sage (
>> https://github.com/GiacomoPope/HyperellipticCurves) which has been 
>> implemented following the balanced strategy of the following paper:
>>
>> Efficient Hyperelliptic Arithmetic using Balanced Representation for 
>> Divisors
>> Steven D. Galbraith, Michael Harrison, and David J. Mireles Morales
>> https://www.math.auckland.ac.nz/~sgal018/ANTS08.pdf
>>
>> This is similar but distinct to what Magma uses for arithmetic. 
>> Essentially the arithmetic is the same as Cantor, but to ensure a unique 
>> representation of the zero degree divisors there is an integer weight n 
>> together with Mumford polynomials (u, v). By keeping track of this weight 
>> during composition and reduction arithmetic is complete. We can ensure 
>> deg(u) <= g by using composition and reduction at infinity. 
>>
>> This implementation works as I expect and I am happy with it. But getting 
>> it into Sage will be a bigger job. I will try and outline some of the 
>> issues I see but as with everything the unknown unknowns will be the 
>> biggest issue.
>>
>> Minimal working implementation: 
>> https://github.com/GiacomoPope/HyperellipticCurves
>>
>> *=== Potential Issues*
>>
>> *Weighted projective models*
>>
>> The balanced representation is naturally tied to a weighted projective 
>> model for the hyperelliptic curve (with weights (1 : 3 : 1)) which is much 
>> less built out than unweighted polynomial rings in sagemath. 
>>
>> Two recent issues with the weighted polynomial ring:
>>
>> https://github.com/sagemath/sage/issues/37155
>> https://github.com/sagemath/sage/issues/37167
>>
>> In our implementation I simply build the weighted projective model in a 
>> normal polynomial ring by computing the correct weights but there could be 
>> further complications if we really try and implement this "properly" from 
>> the construction class in sage. This feels like the first big blocker.
>>
>> A "concrete" example of why we need this is when writing down the two 
>> points at infinity for the real model. These are not "points" on the 
>> current curve because the projective model is different and causes a range 
>> of issues.
>>
>> *Constructing the right classes*
>>
>> I think aside from maybe needing additional methods on the hyperelliptic 
>> curve

Re: [sage-devel] sensational bug!

2024-03-06 Thread Giacomo Pope

This was also something I saw 
in: https://github.com/sagemath/sage/issues/37455 and I haven't been able 
to locally reproduce it either.

On Wednesday, March 6, 2024 at 12:18:51 PM UTC dmo...@deductivepress.ca 
wrote:

> I think this is issue 
> #35715  on the sagemath 
> github. So I think the discussion should go there.
>
> On Wednesday, March 6, 2024 at 6:53:04 AM UTC-5 Martin R wrote:
>
>> It is not my machine, just the bot, see the link above.
>>
>> On Wednesday 6 March 2024 at 12:42:19 UTC+1 Dima Pasechnik wrote:
>>
>>> Not confirmed here, either. We need more details about the machine, the 
>>> OS, the setup, etc.
>>>
>>> Is it reproducible, i.e. if you repeat this command, does it fail again?
>>>
>>> Dima
>>>
>>> On Wed, Mar 6, 2024 at 9:47 AM 'Martin R' via sage-devel <
>>> sage-...@googlegroups.com> wrote:
>>>
 On 
 https://github.com/sagemath/sage/actions/runs/8168335359/job/22330264302?pr=37545

 I see

 sage -t --long --random-seed=286735480429121101562228604801325644303 
 src/sage/rings/tests.py 
 ** 
 Error: Failed example:: Got: Random testing has revealed a problem in 
 test_karatsuba_multiplication 
 Please report this bug! You may be the first 
 person in the world to have seen this problem. 
 Please include this random seed in your bug report: 
 Random seed: 305806809989734915896642073966608392384 
 ValueError('Multiplication failed') 
 test_karatsuba_multiplication(QQbar, 3, 3, numtests=2) # long time, 
 needs sage.rings.number_field 
 Expected nothing 
 Got: 
 Random testing has revealed a problem in test_karatsuba_multiplication 
 Please report this bug! You may be the first 
 person in the world to have seen this problem. 
 Please include this random seed in your bug report: 
 Random seed: 305806809989734915896642073966608392384 
 ValueError('Multiplication failed') 

 -- 
 You received this message because you are subscribed to the Google 
 Groups "sage-devel" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to sage-devel+...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/sage-devel/522bab60-a7e7-47f4-8d17-2c8ce329b85dn%40googlegroups.com

 .

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/be384c9a-c5b4-40e7-97d2-a518a60ef756n%40googlegroups.com.

[sage-devel] Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

2024-03-06 Thread Giacomo Pope

*=== Summary*

Arithmetic of divisors for Jacobians of hyperelliptic curves with two 
points at infinity is not currently properly supported for SageMath. Worse, 
there are no checks or error handling and the output of the arithmetic is 
simply wrong.

Minimal example:

sage: R. = PolynomialRing(GF(11))
sage: f = x^6 + x + 1
sage: H = HyperellipticCurve(f)
sage: J = H.jacobian()
sage: D = J(H.lift_x(1))
sage: jacobian_order = sum(H.frobenius_polynomial())
sage: jacobian_order * D
(x + 10, y + 5) # this should be (1)

I wrote about this as a GitHub issue as 
well: https://github.com/sagemath/sage/issues/37109 but I am now coming to 
sage-devel as I have *some* progress and want to try and have advice / 
conversation about how we can improve this.

*=== Suggestion*

I have been working on a small proof of concept for arithmetic with Sabrina 
Kunzweiler using sage (https://github.com/GiacomoPope/HyperellipticCurves) 
which has been implemented following the balanced strategy of the following 
paper:

Efficient Hyperelliptic Arithmetic using Balanced Representation for 
Divisors
Steven D. Galbraith, Michael Harrison, and David J. Mireles Morales
https://www.math.auckland.ac.nz/~sgal018/ANTS08.pdf

This is similar but distinct to what Magma uses for arithmetic. Essentially 
the arithmetic is the same as Cantor, but to ensure a unique representation 
of the zero degree divisors there is an integer weight n together with 
Mumford polynomials (u, v). By keeping track of this weight during 
composition and reduction arithmetic is complete. We can ensure deg(u) <= g 
by using composition and reduction at infinity. 

This implementation works as I expect and I am happy with it. But getting 
it into Sage will be a bigger job. I will try and outline some of the 
issues I see but as with everything the unknown unknowns will be the 
biggest issue.

Minimal working implementation: 
https://github.com/GiacomoPope/HyperellipticCurves

*=== Potential Issues*

*Weighted projective models*

The balanced representation is naturally tied to a weighted projective 
model for the hyperelliptic curve (with weights (1 : 3 : 1)) which is much 
less built out than unweighted polynomial rings in sagemath. 

Two recent issues with the weighted polynomial ring:

https://github.com/sagemath/sage/issues/37155
https://github.com/sagemath/sage/issues/37167

In our implementation I simply build the weighted projective model in a 
normal polynomial ring by computing the correct weights but there could be 
further complications if we really try and implement this "properly" from 
the construction class in sage. This feels like the first big blocker.

A "concrete" example of why we need this is when writing down the two 
points at infinity for the real model. These are not "points" on the 
current curve because the projective model is different and causes a range 
of issues.

*Constructing the right classes*

I think aside from maybe needing additional methods on the hyperelliptic 
curve, once the projective model is right and points on the curve are well 
defined for all cases. I do not have any intuition on whether the balanced 
model will for example have issues with the p-Adic implementation as I have 
no experience in this area.

Using the language 
of https://www.math.auckland.ac.nz/~sgal018/crypto-book/ch10.pdf, the 
"imaginary" or ramified model is what is currently well supported in sage. 
Here we have only one point at infinity. For the split or "real" model, 
this is what is sketched out in my own repo and what I want to address, 
there are two distinct points at infinity. Proper representation of the 
degree zero divisors needs more than (u, v) for unique representation. For 
the inert model, where there are no points at infinity over the base ring, 
I think we should simply reject all arithmetic and force the user to change 
the curve model or work over a field extension. This is what Magma does.

This leads me to the Jacobian. I believe we should have a 
`Jacobian_ramified` and `Jacobian_split` class and `Jacobian_inert`, each 
with their own efficient (or missing) arithmetic and representation (the 
inert case simply has NotImplemented for arithmetic. The hyperelliptic 
curve class should know the number of points at infinity and then select 
this class without user input (so H.jacobian() does whatever the use 
expects).

This will end up being a fairly large refactoring of the current code and I 
believe this will be hazardous work! 

*=== Backwards compatibility *

This is where I am most worried. I am familiar with and probably capable of 
working with the curves over finite fields and building sensible classes 
which allow for efficient arithmetic for odd and even genus for the 
ramified and split models, but I know there's a lot more maths than the 
arithmetic of these divisors and I need to ensure everything which everyone 
needs works in the same way while making all these changes.

*=== Next steps*

This feels like a

[ClusterLabs] Migrating GFS2 clustered storage from RH7 to RH9

2024-03-05 Thread Giacomo Rinaldi

Hello,

I have a simple setup with 2 hosts and one SAN storage (RH7 + HA + CLVM + GFS2).
I am migrating to RH9, one server at the time, but I cannot add the RH9 to the 
original cluster
because I think of corosync incompatibility between the 2 so different versions 
(something to do with kronosnet).
Furthermore, I want to move from clvm to lvmlock.
My plan is to change the lock type of the clustered VG to Shared VG in the 
original server RH7, upgrade the 2 servers to RH9
and setup a new cluster adding the shared VGs. I couldn't find any howto with 
this scenario, but I bet it is going to be pretty common after june 
Any recommendation or suggestions?
I have made a backup of all the data from the storage, but it would be faster 
to re-use the data ... ~12TB.

Thanks for your help,

Giacomo





___
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users

ClusterLabs home: https://www.clusterlabs.org/

Re: [sage-devel] VOTE: Use "CI Fix" label for merging into continuous integration runs

2024-03-04 Thread Giacomo Pope

+1

On Monday, March 4, 2024 at 1:57:48 PM UTC Dima Pasechnik wrote:

> +1
>
> On Mon, Mar 4, 2024 at 8:43 AM David Roe  wrote:
>
>> The following proposal has been made several times the last few weeks: in 
>> PR #37428 , in this thread 
>>  and then in this 
>> thread .  It is 
>> orthogonal to the ongoing vote in this thread 
>> .  With no further 
>> discussion, I'm calling a vote.
>>
>> *Background*
>>
>> Starting in Sage 10.2, PRs with the Blocker label have been merged into 
>> all other PRs before running CI; see the changelog 
>> 
>>  
>> and this post 
>>  
>> for more details.  This has led to disagreements about whether this label 
>> should be applied.
>>
>> *Proposal*
>> We use "CI Fix" rather than Blocker to determine whether an open PR 
>> should be merged before running CI.  Blocker will retain its previous 
>> meaning of a PR that should be merged before the next release is finished.  
>> The process below describes how to resolve disagreements about whether the 
>> "CI Fix" label should be applied.
>> a. Only PRs with positive review should be marked with the "CI Fix" 
>> label.  This should be done if both author and reviewer agree that it is 
>> appropriate, and a rationale should be given in a comment on the ticket.
>> b. If a PR becomes disputed (as described in this proposal 
>> ), the "CI Fix" 
>> status can be voted on separately upon request; otherwise it should be 
>> applied if and only if positive review is applied.
>>
>> Voting will be open until Wednesday, March 13.
>> David
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to sage-devel+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/CAChs6_mYLUWXMU6AZKJGPKd2oz0AC_qAUjnGoD9Q9yixzNBC2w%40mail.gmail.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/77cc05b2-1c52-4aae-80ca-4d0ec0830e2dn%40googlegroups.com.

Re: [sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`

2024-03-01 Thread Giacomo Pope

As an aside, the univariate LaurentPolynomialRing had a notion of 
`valuation` but the multivariate one didn't...

In the PR: https://github.com/sagemath/sage/pull/37490 I added random 
elements but also a notion of valuation() for the multivariate case and 
just made it act similarly to the univariate one.

On Friday, March 1, 2024 at 6:18:01 PM UTC Nils Bruin wrote:

> On Friday 1 March 2024 at 09:49:15 UTC-8 Giacomo Pope wrote:
>
> Following this discussion, I have made a draft PR to change the degree for 
> *only* the LaurentPolynomialRing and I will see if the CI detects anything.
>
> https://github.com/sagemath/sage/pull/37513
>
> I agree that if we change the LaurentPolynomialRing we should also change 
> the `LaurentSeriesRing`, at the moment `LazyLaurentSeriesRing` has no 
> method `degree()` but *does* have a `valuation()` method... so this is odd.
>
>
> OK, let's keep it that way then! I don't think there is a notion on 
> LaurentSeriesRing that deserves the name "degree". Sorry about mixing that 
> one in. I thought it existed. And I think it does:
>
>  sage: R.=LaurentSeriesRing(QQ)
> sage: z=R(0)
> sage: z.valuation()
> +Infinity
> sage: z.degree()
> -1
>
> but if it's not documented, perhaps we can just ignore it.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a1a59d64-4f6a-46da-9ee4-5a414d612918n%40googlegroups.com.

Re: [sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`

2024-03-01 Thread Giacomo Pope

Following this discussion, I have made a draft PR to change the degree for 
*only* the LaurentPolynomialRing and I will see if the CI detects anything.

https://github.com/sagemath/sage/pull/37513

I agree that if we change the LaurentPolynomialRing we should also change 
the `LaurentSeriesRing`, at the moment `LazyLaurentSeriesRing` has no 
method `degree()` but *does* have a `valuation()` method... so this is odd.

On Friday, March 1, 2024 at 5:29:53 PM UTC Martin R wrote:

> Could you expand on 'the whole valuation interpretation of "degree" goes 
> out of the window'?  What do you mean with "valuation interpretation"?
>
> Is raising an exception out of the question?
>
> On Friday 1 March 2024 at 18:11:40 UTC+1 Nils Bruin wrote:
>
>> On Friday 1 March 2024 at 04:26:43 UTC-8 Dima Pasechnik wrote:
>>  
>>
>> It seems that exactly the same algorithm will work (I didn't check this!) 
>> for Laurent polynomials (they still form a Euclidean domain), and there you 
>> better set degree(0)=-oo, otherwise it's going to be a problem.
>>
>> I think it's been established 
>> that LaurentPolynomialRing(QQ,'x').zero().degree() == -1 is problematic. 
>> With the definition that (1/x).degree() == -1 it clearly is.
>>
>> I think the question is more: do we have enough evidence that setting 
>> degree(0) == -oo for *all* polynomial rings is significantly better (if 
>> better at all) that it's worth the pain and incompatibilities that would 
>> ensue from changing the rest of sage as well? That's not so clear to me. 
>> From the perspective of multivariate polynomials, the whole valuation 
>> interpretation of "degree" goes out of the window, so there "-1" is largely 
>> available and quite possibly used extensively by the underlying libraries.
>>
>> I guess one could see what happens if the change is made to Laurent 
>> polynomials (and Laurent series as well, perhaps?). Based on how that goes 
>> one could re-evaluate degrees of 0 polynomials in other polynomial rings.
>>
>> Alternatively, we could deprecate degree on them in favour of using 
>> valuation-inspired terms instead, where the extension val(0)=oo is more 
>> universal. As Oscar's example in Matlab shows, the concept of degree gets 
>> (mis)used for other, more implementation-oriented definitions as well, so 
>> perhaps the term should just be avoided for Laurent polynomials.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/6a79e795-60d5-4385-b2fb-79e53be18bc1n%40googlegroups.com.

Re: [nexa] Microsoft, Mistral AI e l'AI Act

2024-02-29 Thread Giacomo Tesio

Salve 380,

credo di aver abbastanza chiara la differenza fra
- creazione di opere derivate (come sono i "modelli AI" di cui parliamo)
- distribuzione di opere derivate (come sono, transitivamente, gli output di 
tali software)
- ridistribuzione di opere originali o loro parti

Creative Commons in effetti confonde i due temi, confrontando Google Books
(che distribuisce verbatim, parti di testi coperti da copyright) con i "modelli 
AI" 
che "imparano" dalle opere protette (ROTFL!!!).

Non mi sembra di aver fatto lo stesso errore, ma se qualcosa che ho scritto ti 
sembra 
evidenziare ignoranza giuridica in merito, ti sarei grato se volessi chiarire 
quale passaggio
esattamente ti ha dato questa impressione e possibilmente qualche riferimento 
per colmare la lacuna in questione.


A presto!


Giacomo

Il 29 Febbraio 2024 12:09:10 CET, "380°"  ha scritto:
> Giacomo Tesio  writes:
> 
> [...]
> 
> >> https://creativecommons.org/2023/02/17/fair-use-training-generative-ai/
> >
> > Sono avvocati, mica informatici. :-)
> 
> [...]
> 
> > L'ignoranza informatica diffusa è talmente profonda che nemmeno rischiano
> > di perdere la faccia!
> 
> Anche l'ignoranza del diritto, in questo caso d'autore, è così diffusa e
> profonda, anche tra gli informatici, che c'è estrema confusione tra
> distribuzione di opere dell'ingengo ottenute tramite (ri)elaborazione
> (ovviamente locale) di testi, sui quali negli USA esiste la disciplina
> del "fair use" (in EU siamo più arzigogolati), e _redistribuzione_ dei
> testi orignali (che sai benissimo sono tutelati _esattamente_ NELLA loro
> forma originale).
> 
> Se vuoi contestare agli avvocati di Creative Commons ignoranza
> informatica fai pure, ma non mi pare sia la strata migliore per
> contestare i loro giudizi; lasciatelo dire da un informatico che ha
> dovuto molto precocemente fare i conti con la propria ingnoranza nel
> diritto d'autore.
> 
> [...]
> 
> Saluti, 380°
> 
___
nexa mailing list
nexa@server-nexa.polito.it
https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Re: [sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`

2024-02-29 Thread Giacomo Pope

There seem to be two things we could do here:

1. Have some form of vote / discussion on whether the degree of the zero 
polynomial should *ever* be -1
2. Modify the degree calls for the LaurentSeries and LaurentPolynomialRing 
(maybe other Laurent* which I am unfamiliar with) to have the zero 
polynomial have degree -Infinity.

Option 1 may be cleaner in the long run, but I assume will cause issues for 
more people in the short term. Option 2 seems fairly harmless and there's 
no good argument for degree -1 in this case.

If anyone is interested in option 2, I will find time to make a PR to do 
this, but I will not start this work without other people's input as this 
is not code I am familiar with using and so I don't know what people could 
be relying on.
On Wednesday, February 28, 2024 at 6:41:48 PM UTC Dima Pasechnik wrote:

> On Wed, Feb 28, 2024 at 5:00 PM Nils Bruin  wrote:
>
>> On Wednesday 28 February 2024 at 08:03:45 UTC-8 Giacomo Pope wrote:
>>
>>
>> I don't know the history of this choice or what we should be doing 
>> generally. -1 for polynomials with only positive degree seems like a 
>> computer science workaround, but for the LaurentPolynomialRing it just 
>> seems wrong?
>>
>>
>> I think it's more than just a CS workaround. It has its roots in 
>> dimension considerations: the space of polynomials of degree at most d is 
>> (d+1)-dimensional. WIth that convention, 0 having degree -1 makes perfect 
>> sense.
>>
>
> well, it's the convention used in Singular.
> But GAP and Macaulay2 use -infinity.
>
> The arguments for -infinity:
>
> 1) degree of the product should be the sum of degrees; so it's got to be 
> infinite.
> 2) it should be -infinity, to make sense of the rule that if you do 
> division f/g with remainder r,
> the degree of the remainder should be less than the deg(r)<=deg(f), but if 
> r=0 then the only way
> to get this is to use -infinity.
>
> Dima
>  
>
>>
>> For deg = - ord_infty it should definitely be -oo, though, and for 
>> Laurent polynomials the dimension argument doesn't work.
>>
>> -- 
>>
> You received this message because you are subscribed to the Google Groups 
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to sage-devel+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/ac40d2e7-5e71-43e1-8914-869081f9bdd9n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/sage-devel/ac40d2e7-5e71-43e1-8914-869081f9bdd9n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/6d95b253-fb17-4e2f-a61c-c723737774e8n%40googlegroups.com.

Re: [nexa] Microsoft, Mistral AI e l'AI Act

2024-02-29 Thread Giacomo Tesio

3)
La loro commercializzazione come SaaS riduce il mercato degli autori
(punto 4)


Guarda caso, gli avvocati di Creative Commons non hanno nemmeno provato
ad analizzare i casi in questione alla luce del testo della norma (di
cui pure citano i fattori da includere nella valutazione).

Invece si arrampicano ardite interpretazione di precedenti
cherry-picked per sostenere la tesi dei propri supporters,
la cui applicazione avrebbe conseguenze surreali.


Ad esempio, se scrivo un compilatore C per una mia VM e compilo il
decompilato di Microsoft Office, l'output è altamente trasformativo!

Il binario ottenuto in output sarà irriconoscibile.

Sarà pure meno efficente di quello di Microsoft, ma sarò felice di
rivendere la "suite di Giacomo" per un decimo del prezzo di Microsoft.

Se la trasformativeness è rilevante nel "fair use", allora è la fine
del copyright software. Il che va benissimo, purché valga per tutti.



Giacomo
___
nexa mailing list
nexa@server-nexa.polito.it
https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Re: [nexa] Microsoft, Mistral AI e l'AI Act

2024-02-28 Thread Giacomo Tesio

Certo Giuseppe,

Il 28 Febbraio 2024 15:29:49 CET, Giuseppe Attardi  ha 
scritto:
> Secondo Creative Commons, l’utilizzo di pagine web per l’addestramento di 
> modelli, costituisce “fair use”:
> 
> https://creativecommons.org/2023/02/17/fair-use-training-generative-ai/

Sono avvocati, mica informatici. :-)

D'altro canto, pagando bene non è difficile trovare persino "informatici" 
disposti a sostenere
che un LLM non è un'opera derivata dai testi da cui matematicamente deriva.

L'ignoranza informatica diffusa è talmente profonda che nemmeno rischiano
di perdere la faccia!

Altro che moratorie o obiezione di coscienza!

E se questo vale per gli informatici, figurati gli altri, che parlano di 
informatica senza conoscerla.


E poi, perché inimicarsi i supporters più danarosi?

https://creativecommons.org/support-cc/supporters/


Giacomo
___
nexa mailing list
nexa@server-nexa.polito.it
https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Re: [sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`

Not a "maths" why, but I know anything which uses singular currently 
returns -1 because of the following snippet

cdef long singular_polynomial_deg(poly *p, poly *x, ring *r) noexcept:
cdef long _deg, deg
cdef int dummy

deg = -1
_deg = -1
if p == NULL:
return -1
...

I don't know the history of this choice or what we should be doing 
generally. -1 for polynomials with only positive degree seems like a 
computer science workaround, but for the LaurentPolynomialRing it just 
seems wrong?
On Wednesday, February 28, 2024 at 3:29:25 PM UTC Dima Pasechnik wrote:

> in the polynomial case, the usual convention is deg(0)=-infinity
> I don't know why Sage uses -1 instead:
> R.=QQ[]
> f=0*x*y
> f.degree()
>
> gives -1.
>
> On Wed, Feb 28, 2024 at 1:50 PM 'Martin R' via sage-devel <
> sage-...@googlegroups.com> wrote:
>
>> Sorry, I confused it with valuation, but I guess it is still a related 
>> question.
>> On Wednesday 28 February 2024 at 14:36:35 UTC+1 Giacomo Pope wrote:
>>
>>> This is not what I see on the current beta:
>>>
>>> sage: R. = LaurentSeriesRing(QQ)
>>> sage: R.zero().degree()
>>> -1
>>> sage: R. = LazyLaurentSeriesRing(QQ)
>>> sage: R.zero().degree()
>>>
>>> ---
>>> AttributeErrorTraceback (most recent call 
>>> last)
>>> Cell In[4], line 1
>>> > 1 R.zero().degree()
>>>
>>> File ~/sage/sage/src/sage/structure/element.pyx:489, in 
>>> sage.structure.element.Element.__getattr__()
>>> 487 AttributeError: 
>>> 'LeftZeroSemigroup_with_category.element_class' object has no attribute 
>>> 'blah_blah'...
>>> 488 """
>>> --> 489 return self.getattr_from_category(name)
>>> 490 
>>> 491 cdef getattr_from_category(self, name) noexcept:
>>>
>>> File ~/sage/sage/src/sage/structure/element.pyx:502, in 
>>> sage.structure.element.Element.getattr_from_category()
>>> 500 else:
>>> 501 cls = P._abstract_element_class
>>> --> 502 return getattr_from_other_class(self, cls, name)
>>> 503 
>>> 504 def __dir__(self):
>>>
>>> File ~/sage/sage/src/sage/cpython/getattr.pyx:357, in 
>>> sage.cpython.getattr.getattr_from_other_class()
>>> 355 dummy_error_message.cls = type(self)
>>> 356 dummy_error_message.name = name
>>> --> 357 raise AttributeError(dummy_error_message)
>>> 358 cdef PyObject* attr = instance_getattr(cls, name)
>>> 359 if attr is NULL:
>>>
>>> AttributeError: 'LazyLaurentSeriesRing_with_category.element_class' 
>>> object has no attribute 'degree'
>>>
>>> On Wednesday, February 28, 2024 at 12:05:32 PM UTC Martin R wrote:
>>>
>>>> LazyLaurentSeriesRing(QQ) currently gives +Infinity.
>>>>
>>>> On Wednesday 28 February 2024 at 12:50:45 UTC+1 Giacomo Pope wrote:
>>>>
>>>>> While chasing various bugs which appeared in the CI, I ended up adding 
>>>>> a small method for computing random elements for the 
>>>>> LaurentPolynomialRing 
>>>>> class.
>>>>>
>>>>> When writing randomised testing I got myself confused about the degree 
>>>>> of the zero polynomial. For the univariate and multivariate polynomial 
>>>>> rings, we currently use that the degree for 0 (both R(0).degree() as well 
>>>>> as R(0).degree(x)) is -1. This is unambiguous for the case of these types.
>>>>>
>>>>> However for the LaurentPolynomialRings, a polynomial with negative 
>>>>> valuation is very natural. For example the following code snippet shows 
>>>>> the 
>>>>> ambiguity.
>>>>>
>>>>> sage: L. = LaurentPolynomialRing(QQ)
>>>>> sage: f = (1/x); f
>>>>> x^-1
>>>>> sage: f.degree()
>>>>> -1
>>>>> sage: L.zero().degree()
>>>>> -1
>>>>>
>>>>> I don't feel familiar enough with the mathematics here and the usual 
>>>>> use cases in sage to offer a PR "fixing" this, or whether it even needs 
>>>>> fixing. However, I got confused so I thought maybe others might get 
>>>>> confused and someone on this list might have a suggestion.
>>>>>
>>>>>

[sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`

Ahh ok, thank you. Considering the following output I think a PR to make 
the degree of zero for these Laurent classes -Infinity is reasonable?

```
sage: R. = LaurentSeriesRing(QQ)
sage: R.zero().valuation()
+Infinity
sage: R.zero().degree()
-1
sage: 
sage: R. = LaurentPolynomialRing(QQ)
sage: R.zero().valuation()
+Infinity
sage: R.zero().degree()
-1
sage: 
sage: R. = LazyLaurentSeriesRing(QQ)
sage: R.zero().valuation()
+Infinity
sage: R.zero().degree()
# Errors



On Wednesday, February 28, 2024 at 1:50:23 PM UTC Martin R wrote:

> Sorry, I confused it with valuation, but I guess it is still a related 
> question.
> On Wednesday 28 February 2024 at 14:36:35 UTC+1 Giacomo Pope wrote:
>
>> This is not what I see on the current beta:
>>
>> sage: R. = LaurentSeriesRing(QQ)
>> sage: R.zero().degree()
>> -1
>> sage: R. = LazyLaurentSeriesRing(QQ)
>> sage: R.zero().degree()
>>
>> ---
>> AttributeErrorTraceback (most recent call 
>> last)
>> Cell In[4], line 1
>> > 1 R.zero().degree()
>>
>> File ~/sage/sage/src/sage/structure/element.pyx:489, in 
>> sage.structure.element.Element.__getattr__()
>> 487 AttributeError: 
>> 'LeftZeroSemigroup_with_category.element_class' object has no attribute 
>> 'blah_blah'...
>> 488 """
>> --> 489 return self.getattr_from_category(name)
>> 490 
>> 491 cdef getattr_from_category(self, name) noexcept:
>>
>> File ~/sage/sage/src/sage/structure/element.pyx:502, in 
>> sage.structure.element.Element.getattr_from_category()
>> 500 else:
>> 501 cls = P._abstract_element_class
>> --> 502 return getattr_from_other_class(self, cls, name)
>> 503 
>> 504 def __dir__(self):
>>
>> File ~/sage/sage/src/sage/cpython/getattr.pyx:357, in 
>> sage.cpython.getattr.getattr_from_other_class()
>> 355 dummy_error_message.cls = type(self)
>> 356 dummy_error_message.name = name
>> --> 357 raise AttributeError(dummy_error_message)
>> 358 cdef PyObject* attr = instance_getattr(cls, name)
>> 359 if attr is NULL:
>>
>> AttributeError: 'LazyLaurentSeriesRing_with_category.element_class' 
>> object has no attribute 'degree'
>>
>> On Wednesday, February 28, 2024 at 12:05:32 PM UTC Martin R wrote:
>>
>>> LazyLaurentSeriesRing(QQ) currently gives +Infinity.
>>>
>>> On Wednesday 28 February 2024 at 12:50:45 UTC+1 Giacomo Pope wrote:
>>>
>>>> While chasing various bugs which appeared in the CI, I ended up adding 
>>>> a small method for computing random elements for the LaurentPolynomialRing 
>>>> class.
>>>>
>>>> When writing randomised testing I got myself confused about the degree 
>>>> of the zero polynomial. For the univariate and multivariate polynomial 
>>>> rings, we currently use that the degree for 0 (both R(0).degree() as well 
>>>> as R(0).degree(x)) is -1. This is unambiguous for the case of these types.
>>>>
>>>> However for the LaurentPolynomialRings, a polynomial with negative 
>>>> valuation is very natural. For example the following code snippet shows 
>>>> the 
>>>> ambiguity.
>>>>
>>>> sage: L. = LaurentPolynomialRing(QQ)
>>>> sage: f = (1/x); f
>>>> x^-1
>>>> sage: f.degree()
>>>> -1
>>>> sage: L.zero().degree()
>>>> -1
>>>>
>>>> I don't feel familiar enough with the mathematics here and the usual 
>>>> use cases in sage to offer a PR "fixing" this, or whether it even needs 
>>>> fixing. However, I got confused so I thought maybe others might get 
>>>> confused and someone on this list might have a suggestion.
>>>>
>>>> I think the "usual" suggestion would be to have the degree as -infty, 
>>>> but then there's a question about whether this should be done for other 
>>>> polynomial rings...
>>>>
>>>> I made an issue for this on GitHub too:
>>>>
>>>> https://github.com/sagemath/sage/issues/37491
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/1d06c246-f250-4c37-997e-066ddaefbaean%40googlegroups.com.

[sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`

This is not what I see on the current beta:

sage: R. = LaurentSeriesRing(QQ)
sage: R.zero().degree()
-1
sage: R. = LazyLaurentSeriesRing(QQ)
sage: R.zero().degree()
---
AttributeErrorTraceback (most recent call last)
Cell In[4], line 1
> 1 R.zero().degree()

File ~/sage/sage/src/sage/structure/element.pyx:489, in 
sage.structure.element.Element.__getattr__()
487 AttributeError: 
'LeftZeroSemigroup_with_category.element_class' object has no attribute 
'blah_blah'...
488 """
--> 489 return self.getattr_from_category(name)
490 
491 cdef getattr_from_category(self, name) noexcept:

File ~/sage/sage/src/sage/structure/element.pyx:502, in 
sage.structure.element.Element.getattr_from_category()
500 else:
501 cls = P._abstract_element_class
--> 502 return getattr_from_other_class(self, cls, name)
503 
504 def __dir__(self):

File ~/sage/sage/src/sage/cpython/getattr.pyx:357, in 
sage.cpython.getattr.getattr_from_other_class()
355 dummy_error_message.cls = type(self)
356 dummy_error_message.name = name
--> 357 raise AttributeError(dummy_error_message)
358 cdef PyObject* attr = instance_getattr(cls, name)
359 if attr is NULL:

AttributeError: 'LazyLaurentSeriesRing_with_category.element_class' object 
has no attribute 'degree'

On Wednesday, February 28, 2024 at 12:05:32 PM UTC Martin R wrote:

> LazyLaurentSeriesRing(QQ) currently gives +Infinity.
>
> On Wednesday 28 February 2024 at 12:50:45 UTC+1 Giacomo Pope wrote:
>
>> While chasing various bugs which appeared in the CI, I ended up adding a 
>> small method for computing random elements for the LaurentPolynomialRing 
>> class.
>>
>> When writing randomised testing I got myself confused about the degree of 
>> the zero polynomial. For the univariate and multivariate polynomial rings, 
>> we currently use that the degree for 0 (both R(0).degree() as well as 
>> R(0).degree(x)) is -1. This is unambiguous for the case of these types.
>>
>> However for the LaurentPolynomialRings, a polynomial with negative 
>> valuation is very natural. For example the following code snippet shows the 
>> ambiguity.
>>
>> sage: L. = LaurentPolynomialRing(QQ)
>> sage: f = (1/x); f
>> x^-1
>> sage: f.degree()
>> -1
>> sage: L.zero().degree()
>> -1
>>
>> I don't feel familiar enough with the mathematics here and the usual use 
>> cases in sage to offer a PR "fixing" this, or whether it even needs fixing. 
>> However, I got confused so I thought maybe others might get confused and 
>> someone on this list might have a suggestion.
>>
>> I think the "usual" suggestion would be to have the degree as -infty, but 
>> then there's a question about whether this should be done for other 
>> polynomial rings...
>>
>> I made an issue for this on GitHub too:
>>
>> https://github.com/sagemath/sage/issues/37491
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e245cd6a-a18b-4d72-bf55-d55d8d699d5dn%40googlegroups.com.

[Nut-upsuser] NUT help request

2024-02-28 Thread Giacomo Tognetti via Nut-upsuser

Hi guys
I just struggling to configure my EPYC Neon UPS (it appears like Cyber Power 
System, Inc. PR1500LCDRT2U UPS) using NUT on my Home Assistant server.
I installed official NUT from HACS add-ons and I placed a very easy config:
users:
  - username: nutty
password: 
instcmds:
  - all
actions: []
devices:
  - name: neon
driver: usbhid-ups
port: auto
config: []
mode: netserver
shutdown_host: false
list_usb_devices: true
But it doesn’t work, even if UPS is actually listed, as you can see from the 
complete log.

s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service base-addon-banner: starting

---
 Add-on: Network UPS Tools
 Manage battery backup (UPS) devices
---
 Add-on version: 0.13.0
 You are running the latest version of this add-on.
 System: Home Assistant OS 11.5  (amd64 / qemux86-64)
 Home Assistant Core: 2024.2.3
 Home Assistant Supervisor: 2024.02.0
---
 Please, share the above information when looking for help
 or support in, e.g., GitHub, forums or the Discord chat.
---
s6-rc: info: service base-addon-banner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service base-addon-timezone: starting
s6-rc: info: service base-addon-log-level: starting
s6-rc: info: service fix-attrs successfully started
[15:30:13] INFO: Configuring timezone (Europe/Rome)...
s6-rc: info: service base-addon-log-level successfully started
s6-rc: info: service base-addon-timezone successfully started
s6-rc: info: service legacy-cont-init: starting
cont-init: info: running /etc/cont-init.d/nut.sh
[15:30:16] INFO: Setting mode to netserver...
[15:30:16] INFO: Connected USB devices:
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 003: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Bus 002 Device 002: ID 0764:0601 Cyber Power System, Inc. PR1500LCDRT2U UPS
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU Tablet
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
[15:30:17] INFO: Generating /etc/nut/upsd.users...
[15:30:17] INFO: Configuring user: nutty
[15:30:17] INFO: Password is NOT in the Have I Been Pwned database! Nice!
[15:30:18] INFO: Configuring Device named neon...
[15:30:18] INFO: Starting the UPS drivers...
Network UPS Tools - Generic HID driver 0.47 (2.8.0)
USB communication driver (libusb 1.0) 0.43
libusb1: Could not open any HID devices: insufficient permissions on everything
No matching HID UPS found
Driver failed to start (exit status=1)
Network UPS Tools - UPS driver controller 2.8.0
cont-init: info: /etc/cont-init.d/nut.sh exited 1
cont-init: info: running /etc/cont-init.d/nutclient.sh
cont-init: info: /etc/cont-init.d/nutclient.sh exited 0
cont-init: warning: some scripts exited nonzero
s6-rc: warning: unable to start service legacy-cont-init: command exited 1
/run/s6/basedir/scripts/rc.init: warning: s6-rc failed to properly bring all 
the services up! Check your logs (in /run/uncaught-logs/current if you have 
in-container logging) for more information.
/run/s6/basedir/scripts/rc.init: fatal: stopping the container.
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service base-addon-timezone: stopping
s6-rc: info: service base-addon-log-level: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service base-addon-timezone successfully stopped
s6-rc: info: service base-addon-log-level successfully stopped
s6-rc: info: service base-addon-banner: stopping
s6-rc: info: service base-addon-banner successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped


I tried to add vendorid (764) and producid (601, in my case) but results are 
the same.

I really need your help, also because I’ve struggling around forums and GitHub 
and I see many people in my situation with no answers at all.

Please let me know.

Giacomo







___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

[sage-devel] Degree of the zero polynomial ring for `LaurentPolynomialRing`

While chasing various bugs which appeared in the CI, I ended up adding a
small method for computing random elements for the LaurentPolynomialRing
class.

When writing randomised testing I got myself confused about the degree of
the zero polynomial. For the univariate and multivariate polynomial rings,
we currently use that the degree for 0 (both R(0).degree() as well as
R(0).degree(x)) is -1. This is unambiguous for the case of these types.

However for the LaurentPolynomialRings, a polynomial with negative
valuation is very natural. For example the following code snippet shows the
ambiguity.

sage: L. = LaurentPolynomialRing(QQ)
sage: f = (1/x); f
x^-1
sage: f.degree()
-1
sage: L.zero().degree()
-1

I don't feel familiar enough with the mathematics here and the usual use
cases in sage to offer a PR "fixing" this, or whether it even needs fixing.
However, I got confused so I thought maybe others might get confused and
someone on this list might have a suggestion.

I think the "usual" suggestion would be to have the degree as -infty, but
then there's a question about whether this should be done for other
polynomial rings...

I made an issue for this on GitHub too:

https://github.com/sagemath/sage/issues/37491

--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/0efa0dd8-b322-4896-b9af-a88effeaa195n%40googlegroups.com.

Re: [sage-devel] Re: Labels and Reviewing