Neppomuk's questions

Ontem meu Fritzing 0.9.3b no Linux (x86_64; OpenSuSE Leap 15.5) parou de funcionar sem aviso prévio. Após o lançamento, recebi esta mensagem de erro:

Can't find Git repository.

Depois disso, recebo a reclamação sobre 181 (!) peças faltando (não posso copiá-la para este post porque é muito longo) e, no console, recebo um monte de mensagens de erro como esta:

QSqlQuery::prepare: database not open
QGraphicsLinearLayout::itemAt: invalid index -1

…e depois de tentar abrir um esboço (que sempre funcionou sem problemas), Fritzing trava:

[1]    24550 segmentation fault (core dumped)  Fritzing

Fim da jornada. :-(

Estas são coisas que já experimentei, mas não adianta:

1. Excluindo e reinstalando o Fritzing
2. Atualizando para a versão 0.9.9b do repositório de um contribuidor no OpenSuSE
3. Baixar as partes via Git, copiá-las para /usr/share/fritzing-parts, excluir o diretório de peças corrompido (?) em usr/share/fritzing/parts, e tornar o novo diretório /usr/share/fritzing-partsgravável mundialmente, conforme estipulado em alguma entrada no fórum OpenSuSE .

Há outra entrada no fórum Fritzing que descreve meu problema, mas é antigo e não foi resolvido.

O que está acontecendo de errado aqui o tempo todo?

Recentemente projetei uma placa frontal com grampos no FreeCAD 0.20.2. Possui placas laterais em dois lados, que foram projetadas como um corpo separado preso à placa frontal, que é ela própria um objeto de extrusão. Além disso, existem dois grampos (cada um com seu próprio corpo) fixados na parte traseira da extrusão. Você pode ver os grampos logo acima do meio desta captura de tela:

A geração de desenhos técnicos 2D para a placa frontal e as placas laterais funcionou bem, mas o que ainda preciso é de um desenho 2D mostrando a borda superior da extrusão, bem como os dois grampos, para que eu possa adicionar dimensionamento mostrando onde os grampos estão situados exatamente.

Como não encontrei um modo multicorpo no recurso TechDraw (posso arrastar vários corpos para um desenho, mas eles são colocados na tela separadamente), preciso saber como adicionar a vista superior de toda a construção a um desenho, para que eu possa representar a distância exata dos grampos da borda da placa frontal.

Arquivo STL de toda a parte

Acabei de atualizar minha máquina para o OpenSuSE Leap 15.5. Para instalar um aplicativo baseado em Python chamado DisplayCAL, preciso configurar a versão recente do Python, wxWidgets e as ligações wxPython. O Python 3.11 já está integrado:

╭─jacek@epica ~  
╰─➤  rpm -q python311-base
python311-base-3.11.2-150400.9.5.6.x86_64

…e wxWidgets também:

╭─jacek@epica ~  
╰─➤  rpm -qa | grep wxWidgets
wxWidgets-3_2-devel-3.1.5-150400.1.7.x86_64

Mas, infelizmente, pipse recusa a instalar wxPython…

╭─jacek@epica ~  
╰─➤  pip install wxPython --verbose 

…devido a um wx/setup.harquivo ausente:

  In file included from ../../../../ext/wxWidgets/include/wx/defs.h:45:0,
                   from ../../../../ext/wxWidgets/include/wx/wx.h:14,
                   from ../../../../wx/include/wxPython/wxpy_api.h:41,
                   from ../../../../sip/cpp/sipAPI_core.h:22068,
                   from ../../../../sip/cpp/sip_corewxZoomGestureEvent.cpp:10:
  ../../../../ext/wxWidgets/include/wx/platform.h:159:10: fatal error: wx/setup.h: No such file or directory.
   #include "wx/setup.h"
            ^~~~~~~~~~~~
  compilation terminated.

Bem, sim, eu encontrei platform.hem /usr/include/wx-3.1/wx(e contém uma diretiva de inclusão na linha 159, então deve ser o arquivo que eu estava procurando), mas não consigo encontrar nenhum setup.hnesta pasta. Aparentemente não faz parte do wxWidgets-3_2-develpacote.

Onde posso conseguir o que falta setup.h?

ATUALIZAÇÃO: A página correspondente na referência pkgs.org me disse que existe um arquivo chamado /usr/lib64/wx/include/gtk2-unicode-3.1/wx/setup.h, que faz parte do wxWidgets-3_2-develpacote. Mas: Vincular este arquivo a /usr/include/wx-3.1/wxNÃO ajuda. Aparentemente, o platform.h(que gera o erro) não é aquele situado em /usr/include/wx-3.1/wx, mas não consigo encontrar esse arquivo de cabeçalho em nenhum lugar da minha máquina! O processo de compilação do pip está usando alguns arquivos shadow invisíveis para o usuário normal?

Para testar uma nova versão de um aplicativo Python, preciso instalar a última versão estável do Python em minha máquina OpenSuSE 15.4 /* que, por padrão, vem com o Python 3.6 */. Então, baixei o Python 3.10.11 e o construí. make installfuncionou, mas o próximo comando não por causa de um msvcrtmódulo ausente:

╭─jacek@epica ~/bin/tmp/Python-3.10.11/dist/bin  
╰─➤  ./python3 -m pip install --upgrade pip 
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Traceback (most recent call last):
  File "/home/jacek/bin/tmp/Python-3.10.11/dist/lib/python3.10/subprocess.py", line 69, in <module>
    import msvcrt
ModuleNotFoundError: No module named 'msvcrt'

O módulo ausente é realmente a interface para o tempo de execução do Microsoft Visual C++? Se sim, por que é necessário ao instalar o Python em uma máquina Linux? Aparentemente, existe apenas um tipo de tarball de origem (embora em 2 formatos de arquivo diferentes) no site do Python. As variáveis ​​home / dir do python não estão definidas, BTW:

╭─jacek@epica ~/bin/tmp/Python-3.10.11/dist/bin  
╰─➤  echo $PYTHONHOME                                                       1 ↵

╭─jacek@epica ~/bin/tmp/Python-3.10.11/dist/bin  
╰─➤  echo $PYTHONPATH

╭─jacek@epica ~/bin/tmp/Python-3.10.11/dist/bin  
╰─➤  

Definir o diretório inicial do python manualmente (no meu caso: /home/jacek/bin/tmp/Python-3.10.11/dist) não ajuda, no entanto.

Estou planejando construir um cluster de computadores de placa única que eu poderia usar como servidor de arquivos (usando Ceph) e banco de dados (Postgres XL). Como o desempenho do Mixtile Blade 3 me impressiona bastante, acho que vou juntar alguns deles em um cluster.

Porém, estou com o seguinte problema:

Alguns desses nós (4 deles no início) serão equipados com um SSD cada, enquanto o restante será usado como nós de computação. O Mixtile Blade possui uma porta PCIe 3 de 4 vias, que pode ser usada para conectar um SSD ou para nós em cadeia em uma rede de alta velocidade. Quando a porta PCIe tiver um SSD, ela não estará mais disponível para encadeamento.

Devo então conectar as duas portas ethernet de 2,5 GBit dos nós de armazenamento (com os SSDs PCIe) a um switch, vinculá-los ( eth0+ eth1→ bond0) para obter 5 GBit / seg e também conectar os nós restantes da mesma maneira? Isso permitirá acessar os SSDs de todos os nós do cluster sem comprometer a velocidade, a latência ou a segurança?

No momento, estou procurando um gabinete de torre de servidor "old-school" com várias baias externas de 5¼", que geralmente são preenchidas com gaiolas de HDD hot-swap com backplanes, então recentemente me deparei com o chassi Core W200 da Thermaltake . no entanto, é que o datasheet informa que são 3 baias externas de 5¼", mas de acordo com as fotos do produto, deve haver mais de três delas (ou pelo menos duas delas são de altura dupla):

Até onde minha visão é boa o suficiente, existem duas baias de altura simples + uma de altura dupla + uma de altura tripla, o que totaliza o equivalente a sete baias de 5 ¼" de altura única. Então, quem está agora?

Eu tenho um teclado modelo M de edição de 2015 (por Unicomp, 122 teclas, layout alemão, USB), que ignora certos pressionamentos de tecla resp. combinações de teclas:

• Página para baixo
• Caps Lock
• Ctrl direito + X (funciona com Ctrl esquerdo)
• Alt Direita (+ Shift) + S (Alt Direita é usado como deslocamento ISO Nível 3)

Estou usando a placa em um sistema OpenSuSE Leap 15.2.

Uma pequena pesquisa usando xevme mostrou que nesses casos, a chave afetada não emite um scancode. Nas combinações, o Ctrl resp. O pressionamento de tecla Alt é registrado, enquanto a tecla de letra em si é ignorada. Eu removi e recoloquei a placa controladora nas lâminas condutoras, mas não adiantou.

Alguém sabe o que está errado aqui?

ATUALIZAÇÃO: Acabei de testar em um Raspi, também com xev. Exatamente o mesmo comportamento. E: Como a placa tem 6 anos, já está fora da garantia.

Desde ontem à noite, tive o seguinte problema com meu servidor doméstico Linux (OpenSuSE Leap 15.0) (fabricado em casa): Um de seus dois links ethernet integrados continua caindo, depois subindo, depois caindo novamente, … com bastante frequência.

Normalmente, essas interrupções duram alguns segundos e passam despercebidas, mas também tive paradas de vários minutos. Um deles até faz com que o RAID do meu servidor perca a consistência.

Aqui está a saída de dmesg(mensagens da outra interface de rede, que não é afetada, foram excluídas):

[  815.518384] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[  835.069925] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Down
[  838.322327] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[  897.277739] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Down
[  900.218140] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[  974.621515] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Down
[  977.501918] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[ 1069.501256] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Down
[ 1073.073644] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[ 1126.653085] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Down
[ 1129.465504] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[ 1440.928076] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Down
[ 1444.176477] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[ 1447.680055] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Down
[ 1450.888453] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[ 1532.575777] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Down
[ 1535.812158] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[ 1554.875708] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Down
[ 1557.728109] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[ 1688.103281] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Down
[ 1691.411675] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[ 1753.243072] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Down
[ 1756.119469] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[ 1781.274983] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Down
[ 1814.927299] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[ 1839.818791] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Down
[ 2108.682340] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[ 2119.769891] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Down
[ 2128.118276] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[ 2172.877720] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Down
[ 2203.106035] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[ 2207.337608] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Down
[ 2465.245184] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[ 4206.183121] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Down
[ 4209.203544] igb 0000:01:00.0 eth2: igb: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX

A interface de rede é uma conexão de rede I210 Gigabit (eth2) em uma placa Asus. E aqui está a versão do SO:

╭─root@valen ~  
╰─➤  uname -a
Linux valen 4.12.14-lp150.12.64-default #1 SMP Mon Jun 17 16:53:50 UTC 2019 (3edfd41) x86_64 x86_64 x86_64 GNU/Linux

A última atualização do sistema foi na última terça-feira, mas os problemas começaram na sexta-feira à noite, então não acho que seja um problema de driver.

O que pode ser a causa? Obrigada.

ATUALIZAÇÃO: A pedido, aqui está a ethtoolsaída:

╭─root@valen ~  
╰─➤  ethtool -S eth2
NIC statistics:
     rx_packets: 257315
     tx_packets: 603706
     rx_bytes: 85237411
     tx_bytes: 775258267
     rx_broadcast: 1023
     tx_broadcast: 419
     rx_multicast: 75
     tx_multicast: 104
     multicast: 75
     collisions: 0
     rx_crc_errors: 0
     rx_no_buffer_count: 0
     rx_missed_errors: 0
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_window_errors: 0
     tx_abort_late_coll: 0
     tx_deferred_ok: 0
     tx_single_coll_ok: 0
     tx_multi_coll_ok: 0
     tx_timeout_count: 0
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_align_errors: 0
     tx_tcp_seg_good: 82646
     tx_tcp_seg_failed: 0
     rx_flow_control_xon: 21
     rx_flow_control_xoff: 21
     tx_flow_control_xon: 0
     tx_flow_control_xoff: 0
     rx_long_byte_count: 85237411
     tx_dma_out_of_sync: 0
     tx_smbus: 0
     rx_smbus: 0
     dropped_smbus: 0
     os2bmc_rx_by_bmc: 0
     os2bmc_tx_by_bmc: 0
     os2bmc_tx_by_host: 0
     os2bmc_rx_by_host: 0
     tx_hwtstamp_timeouts: 0
     tx_hwtstamp_skipped: 0
     rx_hwtstamp_cleared: 0
     rx_errors: 0
     tx_errors: 0
     tx_dropped: 0
     rx_length_errors: 0
     rx_over_errors: 0
     rx_frame_errors: 0
     rx_fifo_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_queue_0_packets: 103348
     tx_queue_0_bytes: 114658835
     tx_queue_0_restart: 0
     tx_queue_1_packets: 61601
     tx_queue_1_bytes: 77258944
     tx_queue_1_restart: 0
     tx_queue_2_packets: 94305
     tx_queue_2_bytes: 97486823
     tx_queue_2_restart: 0
     tx_queue_3_packets: 344452
     tx_queue_3_bytes: 483419252
     tx_queue_3_restart: 0
     rx_queue_0_packets: 30966
     rx_queue_0_bytes: 4981061
     rx_queue_0_drops: 0
     rx_queue_0_csum_err: 0
     rx_queue_0_alloc_failed: 0
     rx_queue_1_packets: 137558
     rx_queue_1_bytes: 65059503
     rx_queue_1_drops: 0
     rx_queue_1_csum_err: 0
     rx_queue_1_alloc_failed: 0
     rx_queue_2_packets: 42880
     rx_queue_2_bytes: 7877235
     rx_queue_2_drops: 0
     rx_queue_2_csum_err: 0
     rx_queue_2_alloc_failed: 0
     rx_queue_3_packets: 45911
     rx_queue_3_bytes: 6290352
     rx_queue_3_drops: 0
     rx_queue_3_csum_err: 0
     rx_queue_3_alloc_failed: 0