sdbbs's questions

Estou tentando construir gcc-6um pacote fonte no Raspbian Stretch; então eu faço:

apt source gcc-6
cd gcc-6-6.3.0/debian
debuild -b -uc -us

O debuildcomando inicia a compilação completa. Como a compilação trava na minha plataforma, o que eu gostaria de executar é um comando que descompacte as fontes e aplique os patches do Debian, mas pare antes de configurar (para que eu possa aplicar meus próprios patches) - e então eu poderia continuar depois com debuild -b -uc -us -nc.

Existe algum comando que me ajude a fazer isso?

Gostaria de depurar meu aplicativo em gdb, porém com fontes completas de algumas bibliotecas de sistema que eu possa precisar. Por exemplo, em um certo ponto do meu processo de depuração em gdb, chego a uma situação como:

...
(gdb) si
0x00047e28 in std::thread::detach() ()
(gdb) c
Continuing.
...
Thread 1 "myProject" received signal SIGABRT, Aborted.
raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:51
51      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

Não tenho certeza do motivo pelo qual std::thread::detach()não recebo uma sugestão de arquivo de origem (pesquisei manualmente online e descobri que está em libstdc++-v3/src/c++11/thread.cc ), mas raise()recebo o arquivo de origem e a linha ../sysdeps/unix/sysv/linux/raise.c:51.

De qualquer forma, para qualquer um desses, thread.ccou raise.c, como posso descobrir qual pacote de origem em um determinado Debian os inclui? Então eu poderia eventualmente obtê-los apt source [package]e fornecer o caminho para esses arquivos gdbconforme descrito em https://stackoverflow.com/questions/48278881/gdb-complaining-about-missing-raise-c/48287761#48287761 para que eu pudesse percorrer as linhas de origem (e especialmente ver qual função subjacente recebe como argumentos do meu código) ...

Eu tentei apt-file, mas parece que não funciona com pacotes de origem:

$ apt-file search raise.c
gnulib: /usr/share/gnulib/lib/raise.c
gnulib: /usr/share/gnulib/tests/test-raise.c

Legal, mas nenhum deles parece ../sysdeps/unix/sysv/linux/raise.c?!

$ apt-file search thread.cc
c++-annotations: /usr/share/doc/c++-annotations/examples/yo/threading/examples/functorthread.cc
libglibmm-2.4-doc: /usr/share/doc/libglibmm-2.4-doc/examples/thread/thread.cc
omniorb-doc: /usr/share/doc/omniorb-doc/examples/poa/threading/mainthread.cc
rust-src: /usr/src/rustc-1.24.1/src/libcompiler_builtins/compiler-rt/lib/asan/asan_thread.cc
rust-src: /usr/src/rustc-1.24.1/src/libcompiler_builtins/compiler-rt/lib/lsan/lsan_thread.cc
rust-src: /usr/src/rustc-1.24.1/src/libcompiler_builtins/compiler-rt/lib/msan/msan_thread.cc
rust-src: /usr/src/rustc-1.24.1/src/libcompiler_builtins/compiler-rt/lib/tsan/rtl/tsan_rtl_thread.cc
rust-src: /usr/src/rustc-1.24.1/src/libcompiler_builtins/compiler-rt/lib/tsan/tests/rtl/tsan_thread.cc
rust-src: /usr/src/rustc-1.24.1/src/libcompiler_builtins/compiler-rt/test/tsan/race_with_finished_thread.cc
rust-src: /usr/src/rustc-1.24.1/src/libcompiler_builtins/compiler-rt/test/tsan/signal_thread.cc

Ok, apt-filenovamente encontrei algo, mas todos parecem ser falsos positivos, nada corresponde ao esperado libstdc++-v3/src/c++11/thread.cc.

Então, há alguma maneira de procurar arquivos de origem como esse no Debian? Especificamente, estou no Raspbian Stretch no Raspberry Pi 3B+.

Considere o seguinte exemplo:

mkdir /tmp/test2 && cd /tmp/test2
mkdir -p aa/{tmp,src}
mkdir -p bb/aa/{tmp,src}
mkdir -p {dd,ee}/bb
touch {dd,ee}/bb/aa

tree | awk '{print "# " $0}'
# .
# ├── aa
# │   ├── src
# │   └── tmp
# ├── bb
# │   └── aa
# │       ├── src
# │       └── tmp
# ├── cc
# │   └── aa
# │       ├── src
# │       └── tmp
# ├── dd
# │   └── bb
# │       └── aa
# └── ee
#     └── bb
#         └── aa
#
# 16 directories, 2 files

Então, quero encontrar todos os itens chamados aa, e imprimi-los no mesmo formato que ls -la, para poder ver se são arquivos ou diretórios.

Se eu fizer o típico findwith execof ls -a- então os diretórios em si não serão impressos como itens, mas sim seus conteúdos:

$ find . -name aa -exec ls -la {} \;
total 0
drwxr-xr-x 1 user None 0 Feb 19 11:59 .
drwxr-xr-x 1 user None 0 Feb 19 12:00 ..
drwxr-xr-x 1 user None 0 Feb 19 11:59 src
drwxr-xr-x 1 user None 0 Feb 19 11:59 tmp
total 0
drwxr-xr-x 1 user None 0 Feb 19 11:59 .
drwxr-xr-x 1 user None 0 Feb 19 11:59 ..
drwxr-xr-x 1 user None 0 Feb 19 11:59 src
drwxr-xr-x 1 user None 0 Feb 19 11:59 tmp
total 0
drwxr-xr-x 1 user None 0 Feb 19 11:59 .
drwxr-xr-x 1 user None 0 Feb 19 11:59 ..
drwxr-xr-x 1 user None 0 Feb 19 11:59 src
drwxr-xr-x 1 user None 0 Feb 19 11:59 tmp
-rw-r--r-- 1 user None 0 Feb 19 12:00 ./dd/bb/aa
-rw-r--r-- 1 user None 0 Feb 19 12:00 ./ee/bb/aa

Se eu usar ls -lad {}/isso, imprimo explicitamente apenas os nós do diretório, então os nós do arquivo não são impressos, mas recebo um erro "Não é um diretório":

$ find . -name aa -exec ls -lad {}/ \;
drwxr-xr-x 1 user None 0 Feb 19 11:59 ./aa/
drwxr-xr-x 1 user None 0 Feb 19 11:59 ./bb/aa/
drwxr-xr-x 1 user None 0 Feb 19 11:59 ./cc/aa/
ls: cannot access './dd/bb/aa/': Not a directory
ls: cannot access './ee/bb/aa/': Not a directory

Se eu tentar algum tipo de bashcondicional diretamente na linha de comando, ele falha:

# test
$ [ -d aa ] && echo dir || echo file
dir

$ find . -name aa -exec [ -d {} ] && ls -lad {}/ || ls -la {} \;
find: missing argument to `-exec'
ls: cannot access '{}': No such file or directory
ls: cannot access ';': No such file or directory

Então, como posso usar find . -name aa, para que eu obtenha esta saída:

drwxr-xr-x 1 user None 0 Feb 19 11:59 ./aa/
drwxr-xr-x 1 user None 0 Feb 19 11:59 ./bb/aa/
drwxr-xr-x 1 user None 0 Feb 19 11:59 ./cc/aa/
-rw-r--r-- 1 user None 0 Feb 19 12:00 ./dd/bb/aa
-rw-r--r-- 1 user None 0 Feb 19 12:00 ./ee/bb/aa

No meu servidor Ubuntu, acho muito útil que netstat -tulpntambém mostre o nome de usuário conectado sshd(aparentemente, essa impressão de nome de usuário é específica para sshd) - infelizmente, essa impressão também é truncada:

$ sudo netstat -tulpn | grep 'PID\|user1'
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:12345           0.0.0.0:*               LISTEN      1620557/sshd: user1
tcp6       0      0 :::12345                :::*                    LISTEN      1620557/sshd: user1

No exemplo acima, o nome de usuário completo é user1234, mas devido ao truncamento, só consigo ler user1.

Ainda mais infelizmente, descobri que esse truncamento está codificado no netcatlimite de largura da linha de saída do Netstat :

Infelizmente, a largura da coluna PID/Nome do programa no netstat é codificada com hardcode, #define PROGNAME_WIDTH 20então não há como obter a saída completa do netstat diretamente. Além disso, você acaba com 19 caracteres e um espaço no final.

A mesma resposta também recomenda:

No Linux de hoje, pode-se usar sudo ss -natppara obter as informações completas formatadas de forma um pouco diferente, mas com o nome completo:

... infelizmente, ssnão imprime o nome de usuário do usuário conectado sshdcomo netstatfaz:

$ sudo ss -tulpn | grep user1
$

$ sudo ss -tulpn | grep 12345
tcp     LISTEN   0        128              0.0.0.0:12345          0.0.0.0:*      users:(("sshd",pid=1620557,fd=10))

tcp     LISTEN   0        128                 [::]:12345             [::]:*      users:(("sshd",pid=1620557,fd=11))

Então, como posso obter uma saída idêntica ou semelhante à saída de netstat -tulpn, mas que imprima os nomes de usuário completos conectados a sshd?

Minha versão do netstat é:

$ netstat --version
net-tools 2.10-alpha
Fred Baumgarten, Alan Cox, Bernd Eckenfels, Phil Blundell, Tuan Hoang, Brian Micek and others
+NEW_ADDRT +RTF_IRTT +RTF_REJECT +FW_MASQUERADE +I18N +SELINUX
AF: (inet) +UNIX +INET +INET6 +IPX +AX25 +NETROM +X25 +ATALK +ECONET +ROSE -BLUETOOTH
HW:  +ETHER +ARC +SLIP +PPP +TUNNEL -TR +AX25 +NETROM +X25 +FR +ROSE +ASH +SIT +FDDI +HIPPI +HDLC/LAPB +EUI64

Eu tenho um diretório chamado pubem um servidor Ubuntu 20.04, que desejo proteger contra exclusão, e encontrei https://askubuntu.com/questions/504151/how-to-prevent-directory-from-being-deleted-by- usuário então eu tentei:

$ sudo chattr +i pub

Bom o suficiente, agora quero verificar se esse atributo foi definido:

$ lsattr pub
--------------e----- pub/__pycache__
--------------e----- pub/file1.py
--------------e----- pub/file2.py
--------------e----- pub/file3.py
--------------e----- pub/file4.py

Então, eu obtive o conteúdo do diretório listado, mas não obtive o diretório listado, que é o que eu queria.

Quer dizer, se pelo menos me desse uma entrada para pub, eu estaria bem - mas aqui eu recebo todas as crianças e NÃO o que eu pedi... é tão incrivelmente estúpido.

Acontece que há uma lsattr -Ropção para "recursiva", que eu esperava fornecer uma saída como acima - mas quando eu a executo, ela simplesmente desce para o __pycache__diretório.

Então, como você lsattrcria um diretório apenas, para que você possa ver se conseguiu a coisa certa com chattr?

Acabei de perceber que historynão produz nada em um subshell. Vou tentar mostrar contando linhas - primeiro uma verificação de sanidade com echo:

$ echo a | wc -l
1

... e em um subshell:

bash -c 'echo a' | wc -l
1

De fato, esperamos uma saída de linha em ambos os casos. Agora, para history:

$ history | wc -l
681

... mas em um subshell:

$ bash -c 'history' | wc -l
0

... historynão retorna nenhuma linha.

Por que isso acontece - e como posso obter historyo subshell para gerar o histórico do shell atual (incluindo os comandos da última sessão)?

Estou tentando hackear um pacote MSYS, então encontrei https://www.msys2.org/wiki/Creating-Packages/ - como exemplo:

git clone "https://github.com/msys2/MSYS2-packages"
cd MSYS2-packages/flex
makepkg -sCLf

Então, se eu executar isso, eu crio as fontes e recebo um pacote.

Agora, digamos, eu altero algo na fonte do pacote flex e quero reconstruir.

Eu tentei o makepkg -sCLf, mas esse comando realmente exclui o diretório de origem - incluindo meus hacks - e, portanto, esse comando em particular não pode ser usado para criar um pacote com hacks/arquivos de origem alterados.

Que comando eu poderia usar em vez disso, para compilar (espero que apenas) os arquivos alterados na fonte e para compilar um pacote dessa fonte?

Estou um pouco confuso sobre o que exatamente debifaz.

Eu estava construindo o OLA, e encontrei este post: Erro ao construir .debs para BBB com o mais novo OLA 0.9.7... – Grupos do Google onde eu tinha visto:

cd ola-0.9.7  
debuild  
# (... wait ...)  
sudo debi

Então, eu criei com debuild, e obtive esses .debs como resultado:

$ ls -1 ../*.deb
../libola1_0.10.7-1_armhf.deb
../libola1-dbgsym_0.10.7-1_armhf.deb
../libola-dev_0.10.7-1_armhf.deb
../ola_0.10.7-1_armhf.deb
../ola-dbgsym_0.10.7-1_armhf.deb
../ola-python_0.10.7-1_all.deb
../ola-rdm-tests_0.10.7-1_all.deb

O problema é que, quando instalei o OLA pela primeira vez através dos pacotes binários (Raspbian), antes dessa compilação, acabei com os pacotes ola libola1 ola-rdm-tests ola-pythoninstalados (que eu havia desinstalado antes da compilação).

Então, eu não tenho certeza, se eu apenas executar debio , terei apenas esses pacotes instalados, ou ele instalará todos os .debs que foram gerados (incluindo -dbgsyme -devpacotes, que neste caso em particular, eu não preciso)?

Em outras palavras, se eu quiser apenas alguns desses pacotes .deb instalados, é melhor fazer apenas sudo dpkg -i [package1] [package2] ..., em vez de usar sudo debi?