[devel] Fwd: [#282648] EPERM (try 6) nmap.git=7.80-alt2

[devel] Fwd: [#282648] EPERM (try 6) nmap.git=7.80-alt2

[Vitaly Lipatov]

Уважаемые бдительные хранители ACL на пакет nmap.
Прошу проявить реакцию на моё предложение по переводу nmap на python3.
Обещаю, больше никогда не буду помогать с исправлением пакетов.

https://bugzilla.altlinux.org/38271

-------- Исходное сообщение --------
Тема: [#282648] EPERM (try 6) nmap.git=7.80-alt2
Дата: 30.9.21 8:42
От: "Girar awaiter (lav)" <girar-builder@altlinux.org>
Кому: Vitaly Lipatov <lav@altlinux.org>
Копия: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>, "Dmitry V. 
Levin" <ldv@altlinux.org>, girar-builder-sisyphus@altlinux.org, 
sisyphus-incominger@lists.altlinux.org
Ответить: lav@altlinux.org

http://git.altlinux.org/tasks/282648/logs/events.6.1.log

subtask  name  aarch64  armh  i586  ppc64le  x86_64
     #20  nmap     3:39  5:06  4:55     4:09    3:49

2021-Sep-30 05:32:50 :: task #282648 for sisyphus resumed by lav:
#20 build 7.80-alt2 from /people/lav/packages/nmap.git fetched at 
2021-Aug-28 20:50:02
#40 removed
#100 removed
2021-Sep-30 05:32:50 :: [i586] #20 nmap.git 7.80-alt2: build start
2021-Sep-30 05:32:50 :: [x86_64] #20 nmap.git 7.80-alt2: build start
2021-Sep-30 05:32:50 :: [aarch64] #20 nmap.git 7.80-alt2: build start
2021-Sep-30 05:32:50 :: [armh] #20 nmap.git 7.80-alt2: build start
2021-Sep-30 05:32:50 :: [ppc64le] #20 nmap.git 7.80-alt2: build start
2021-Sep-30 05:36:29 :: [aarch64] #20 nmap.git 7.80-alt2: build OK
2021-Sep-30 05:36:39 :: [x86_64] #20 nmap.git 7.80-alt2: build OK
2021-Sep-30 05:36:59 :: [ppc64le] #20 nmap.git 7.80-alt2: build OK
2021-Sep-30 05:37:45 :: [i586] #20 nmap.git 7.80-alt2: build OK
2021-Sep-30 05:37:56 :: [armh] #20 nmap.git 7.80-alt2: build OK
2021-Sep-30 05:38:11 :: #20: nmap.git 7.80-alt2: build check OK
2021-Sep-30 05:38:11 :: build check OK
2021-Sep-30 05:38:19 :: noarch check OK
2021-Sep-30 05:38:22 :: plan: src +1 -1 =17334, aarch64 +2 -2 =29001, 
armh +2 -2 =27356, i586 +2 -2 =29683, noarch +0 -1 =17471, ppc64le +2 -2 
=28793, x86_64 +2 -2 =30264
#20 nmap 7.80-alt1 -> 20020501:7.80-alt2
  Sat Aug 14 2021 Vitaly Lipatov <lav@altlinux.ru> 20020501:7.80-alt2
  - NMU: disable zenmap build due python2 (ALT bug 38271)
  - NMU: add python3 patch for ndiff (ALT bug 38271)
2021-Sep-30 05:38:22 :: nmap: closes bugs: 38271 38271
2021-Sep-30 05:39:03 :: patched apt indices
2021-Sep-30 05:39:15 :: created next repo
2021-Sep-30 05:39:23 :: duplicate provides check OK
2021-Sep-30 05:39:48 :: dependencies check OK
2021-Sep-30 05:40:10 :: [x86_64 i586 aarch64 ppc64le armh] ELF symbols 
check OK
2021-Sep-30 05:40:32 :: [aarch64] #20 nmap: install check OK
2021-Sep-30 05:40:36 :: [i586] #20 nmap: install check OK
2021-Sep-30 05:40:36 :: [ppc64le] #20 nmap: install check OK
2021-Sep-30 05:40:40 :: [x86_64] #20 nmap: install check OK
2021-Sep-30 05:40:41 :: [armh] #20 nmap: install check OK
2021-Sep-30 05:40:42 :: [aarch64] #20 nmap-debuginfo: install check OK
2021-Sep-30 05:40:46 :: [i586] #20 nmap-debuginfo: install check OK
2021-Sep-30 05:40:49 :: [ppc64le] #20 nmap-debuginfo: install check OK
2021-Sep-30 05:40:52 :: [x86_64] #20 nmap-debuginfo: install check OK
2021-Sep-30 05:40:56 :: [armh] #20 nmap-debuginfo: install check OK
2021-Sep-30 05:41:10 :: [x86_64-i586] generated apt indices
2021-Sep-30 05:41:10 :: [x86_64-i586] created next repo
2021-Sep-30 05:41:17 :: [x86_64-i586] dependencies check OK
2021-Sep-30 05:42:08 :: gears inheritance check OK
2021-Sep-30 05:42:08 :: srpm inheritance check OK
girar-check-perms: access to nmap DENIED for lav: does not belong to 
approved builders list: glebfm ldv
check-subtask-perms: #20: nmap: Operation not permitted
2021-Sep-30 05:42:08 :: acl check FAILED
2021-Sep-30 05:42:26 :: created contents_index files
2021-Sep-30 05:42:35 :: created hash files: aarch64 armh i586 noarch 
ppc64le src x86_64
2021-Sep-30 05:42:37 :: task #282648 for sisyphus EPERM

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] Fwd: [#282648] EPERM (try 6) nmap.git=7.80-alt2

[Pavel Nakonechnyi]

On Thu, 30 Sept 2021 at 08:04, Vitaly Lipatov <lav@altlinux.ru> wrote:
>
> Уважаемые бдительные хранители ACL на пакет nmap.
> Прошу проявить реакцию на моё предложение по переводу nmap на python3.
> Обещаю, больше никогда не буду помогать с исправлением пакетов.
>
> https://bugzilla.altlinux.org/38271

Вы так настойчиво пытаетесь исправить этот пакет, что не могу не
отметить, что nmap в Sisyphus все равно бесполезен: droppriv патч
делает его непригодным для реально работы. Приходится пересобирать.
Ценность данного пакета сейчас только в том, что у него есть Gear
репозиторий, из которого можно собрать рабочую версию. :)

--
 WBR, Pavel

Re: [devel] Fwd: [#282648] EPERM (try 6) nmap.git=7.80-alt2

[Vitaly Lipatov]

Pavel Nakonechnyi писал 30.9.21 20:24:
> On Thu, 30 Sept 2021 at 08:04, Vitaly Lipatov <lav@altlinux.ru> wrote:
>> 
>> Уважаемые бдительные хранители ACL на пакет nmap.
>> Прошу проявить реакцию на моё предложение по переводу nmap на python3.
>> Обещаю, больше никогда не буду помогать с исправлением пакетов.
>> 
>> https://bugzilla.altlinux.org/38271
> 
> Вы так настойчиво пытаетесь исправить этот пакет, что не могу не
> отметить, что nmap в Sisyphus все равно бесполезен: droppriv патч
> делает его непригодным для реально работы. Приходится пересобирать.
> Ценность данного пакета сейчас только в том, что у него есть Gear
> репозиторий, из которого можно собрать рабочую версию. :)
А бага есть об этом? Было бы интересно узнать подробности.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] Fwd: [#282648] EPERM (try 6) nmap.git=7.80-alt2

[Pavel Nakonechnyi]

On Thu, 30 Sept 2021 at 22:33, Vitaly Lipatov <lav@altlinux.ru> wrote:
>
> Pavel Nakonechnyi писал 30.9.21 20:24:
> > On Thu, 30 Sept 2021 at 08:04, Vitaly Lipatov <lav@altlinux.ru> wrote:
> >>
> >> Уважаемые бдительные хранители ACL на пакет nmap.
> >> Прошу проявить реакцию на моё предложение по переводу nmap на python3.
> >> Обещаю, больше никогда не буду помогать с исправлением пакетов.
> >>
> >> https://bugzilla.altlinux.org/38271
> >
> > Вы так настойчиво пытаетесь исправить этот пакет, что не могу не
> > отметить, что nmap в Sisyphus все равно бесполезен: droppriv патч
> > делает его непригодным для реально работы. Приходится пересобирать.
> > Ценность данного пакета сейчас только в том, что у него есть Gear
> > репозиторий, из которого можно собрать рабочую версию. :)
> А бага есть об этом? Было бы интересно узнать подробности.

Багу не заводил, так как сразу по релизу предыдущей сборки написал
Глебу лично, что он не работает (в некоторых случаях).

Вот то, что я тогда отправлял:
```
вот некоторые логи, которые могу дать:
# nmap -d -vvv -p111 -Pn -T4 -A XXX

Initiating NSE at 12:59
NSE: Starting rpcinfo against XXX (10.125.196.48:111).
NSOCK ERROR [15.3860s] mksock_bind_addr(): Bind to 0.0.0.0:365 failed
(IOD #1): Permission denied (13)
NSE: Starting address-info against XXX (10.125.196.48).
NSE: Finished address-info against XXX (10.125.196.48).
NSE: rpcinfo against XXX (10.125.196.48:111) threw an error!
/usr/share/nmap/nselib/bin.lua:70: assertion failed!
stack traceback:
        [C]: in function 'assert'
        /usr/share/nmap/nselib/bin.lua:70: in upvalue 'clamp'
        /usr/share/nmap/nselib/bin.lua:158: in function
</usr/share/nmap/nselib/bin.lua:96>
        [C]: in function 'string.gsub'
        /usr/share/nmap/nselib/bin.lua:177: in function 'bin.pack'
        /usr/share/nmap/nselib/rpc.lua:334: in method 'CreateHeader'
        /usr/share/nmap/nselib/rpc.lua:494: in method 'EncodePacket'
        /usr/share/nmap/nselib/rpc.lua:647: in method 'Dump'
        /usr/share/nmap/nselib/rpc.lua:2785: in field 'RpcInfo'
        /usr/share/nmap/scripts/rpcinfo.nse:92: in function
</usr/share/nmap/scripts/rpcinfo.nse:89>
        (...tail calls...)

Completed NSE at 12:59, 0.02s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Initiating NSE at 12:59
NSE: Starting rpc-grind against XXX (10.125.196.48:111).
NSE: [rpc-grind XXX:111] Could not find nmap-rpc file.
NSE: Finished rpc-grind against XXX (10.125.196.48:111).
без условного droppriv патча тот же скан работает
```

И, как упомянул выше, попытки сделать IPv6 сканы проваливаются, так
как nmap просто не видит IPv6 интерфейсы с droppriv патчем.

Re: [devel] Fwd: [#282648] EPERM (try 6) nmap.git=7.80-alt2

[Vladimir D. Seleznev]

On Fri, Oct 01, 2021 at 09:36:28AM +0200, Pavel Nakonechnyi wrote:
> On Thu, 30 Sept 2021 at 22:33, Vitaly Lipatov <lav@altlinux.ru> wrote:
> >
> > Pavel Nakonechnyi писал 30.9.21 20:24:
> > > On Thu, 30 Sept 2021 at 08:04, Vitaly Lipatov <lav@altlinux.ru> wrote:
> > >>
> > >> Уважаемые бдительные хранители ACL на пакет nmap.
> > >> Прошу проявить реакцию на моё предложение по переводу nmap на python3.
> > >> Обещаю, больше никогда не буду помогать с исправлением пакетов.
> > >>
> > >> https://bugzilla.altlinux.org/38271
> > >
> > > Вы так настойчиво пытаетесь исправить этот пакет, что не могу не
> > > отметить, что nmap в Sisyphus все равно бесполезен: droppriv патч
> > > делает его непригодным для реально работы. Приходится пересобирать.
> > > Ценность данного пакета сейчас только в том, что у него есть Gear
> > > репозиторий, из которого можно собрать рабочую версию. :)
> > А бага есть об этом? Было бы интересно узнать подробности.
> 
> Багу не заводил, так как сразу по релизу предыдущей сборки написал
> Глебу лично, что он не работает (в некоторых случаях).
> 
> Вот то, что я тогда отправлял:
> ```
> вот некоторые логи, которые могу дать:
> [skip]
> без условного droppriv патча тот же скан работает
> ```

Надо патч дорабатывать (и, похоже, некому этим заняться), но я бы ещё
добавил опцию --nodroppriv.

-- 
   WBR,
   Vladimir D. Seleznev

[devel] nmap branching, newbie question, was: Fwd: [#282648] EPERM (try 6) nmap.git=7.80-alt2

[Pavel Nakonechnyi]

Добрый день,

В тему сборки обновленной версии, по истории я не смог понять каким
образом был совершен переход с 7.70 до 7.80.

Я предполагал следующее:
- ветка upstream дополняется оригинальными исходными кодами новой версии
- создается новая ветка, например alt/7.92 на основе upstream
- alt/7.92 дополняется патчами на исходники
- alt/7.92 вмерживается в sisyphus с тем чтобы переписалось содержимое
директории nmap/ на требуемое

И вот последний шаг совершенно непонятен. ours стратегия не подходит,
recursive (и другие) merge вызывает массу конфликтов. Да и при
переходе с 7.70 до 7.80 было сделано что-то иное...

Подскажите, пожалуйста, как поступать в таких случаях?

--
 WBR, Pavel

Re: [devel] nmap branching, newbie question, was: Fwd: [#282648] EPERM (try 6) nmap.git=7.80-alt2

[Vitaly Lipatov]

Pavel Nakonechnyi писал 26.10.21 12:04:
> Добрый день,
> 
> В тему сборки обновленной версии, по истории я не смог понять каким
> образом был совершен переход с 7.70 до 7.80.
> 
> Я предполагал следующее:
> - ветка upstream дополняется оригинальными исходными кодами новой 
> версии
> - создается новая ветка, например alt/7.92 на основе upstream
> - alt/7.92 дополняется патчами на исходники
> - alt/7.92 вмерживается в sisyphus с тем чтобы переписалось содержимое
> директории nmap/ на требуемое
> 
> И вот последний шаг совершенно непонятен. ours стратегия не подходит,
> recursive (и другие) merge вызывает массу конфликтов. Да и при
> переходе с 7.70 до 7.80 было сделано что-то иное...
> 
> Подскажите, пожалуйста, как поступать в таких случаях?
Если бы была возможность, я бы объяснял мантейнеру, что не нужно 
собирать пакеты на основе апстримных репозиториев, а нужно использовать 
официально опубликованные тарболы.
Тогда и не будет таких проблем и лишних действий.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] nmap branching, newbie question, was: Fwd: [#282648] EPERM (try 6) nmap.git=7.80-alt2

[Gleb Fotengauer-Malinovskiy]

[-- Attachment #1: Type: text/plain, Size: 2859 bytes --]

Hi,

On Tue, Oct 26, 2021 at 11:04:43AM +0200, Pavel Nakonechnyi wrote:
> Добрый день,
> 
> В тему сборки обновленной версии, по истории я не смог понять каким
> образом был совершен переход с 7.70 до 7.80.

Честно говоря, я уже забыл, как собирался этот пакет.  Оказалось, так же,
как я последние годы собираю все пакеты, в которых приходится применять
и поддерживать большое количество патчей.

> Я предполагал следующее:
> - ветка upstream дополняется оригинальными исходными кодами новой версии
> - создается новая ветка, например alt/7.92 на основе upstream
> - alt/7.92 дополняется патчами на исходники
> - alt/7.92 вмерживается в sisyphus с тем чтобы переписалось содержимое
> директории nmap/ на требуемое

Всё верно, так и было сделано обновление до 7.80.  По такой же схеме
собраны многие другие пакеты.

> И вот последний шаг совершенно непонятен. ours стратегия не подходит,
> recursive (и другие) merge вызывает массу конфликтов. Да и при
> переходе с 7.70 до 7.80 было сделано что-то иное...
>
> Подскажите, пожалуйста, как поступать в таких случаях?

Да, в этом месте приходится применять небольшую хитрость, чтобы все
исходники совпадали с подготовленным бранчем, а .gear, spec и остальные
файлы остались на месте.  Я делаю это так:

git merge -s ours --no-commit alt/7.80
git read-tree alt/7.80
git checkout @ -- .gear/ alt/
git commit
git reset --hard

On Thu, Oct 28, 2021 at 09:11:30PM +0300, Vitaly Lipatov wrote:
> Если бы была возможность, я бы объяснял мантейнеру, что не нужно 
> собирать пакеты на основе апстримных репозиториев, а нужно использовать 
> официально опубликованные тарболы.
> Тогда и не будет таких проблем и лишних действий.

Странно, этот пакет как раз собран из опубликованного тарболла.

-- 
glebfm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] nmap branching, newbie question, was: Fwd: [#282648] EPERM (try 6) nmap.git=7.80-alt2

[Anton Farygin]

On 30.10.2021 01:34, Gleb Fotengauer-Malinovskiy wrote:
> Да, в этом месте приходится применять небольшую хитрость, чтобы все
> исходники совпадали с подготовленным бранчем, а .gear, spec и остальные
> файлы остались на месте.  Я делаю это так:
>
> git merge -s ours --no-commit alt/7.80
> git read-tree alt/7.80
> git checkout @ -- .gear/ alt/
> git commit
> git reset --hard

Это, кстати, отличный рецепт - я им пользуюсь уже больше года.

Наверное надо где-то его документировать, но проблема в том, что им надо 
пользоваться с пониманием того, что делаешь.