• My package is marked for autoremoval from testing

    From Tong Sun@21:1/5 to All on Thu Nov 25 21:50:02 2021
    Hi Mentors,

    I need help.

    My package cannot be upgraded from current version to latest version
    -- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769

    It might have something to do with obsoleted conffile files or it
    might even not. The problem is, I've been trying to understand how the
    conffile files work, and I think I'm doing the right thing, yet my
    package cannot be properly upgraded.

    - I don't understand what breaks and why, from the output of the
    package upgrade log (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769).
    - Thus, I have no idea how to fix it, and all my previous attempts failed. So,

    Please help. The package source is at:

    https://salsa.debian.org/debian/dbab/


    Also, I've been trying to solve it on my own for so long that now the
    good version in testing is marked for autoremoval, for the reason
    that:

    If a package is out of sync between unstable and testing for a longer
    period, this usually means that bugs in the package in testing cannot be
    fixed via unstable.

    However, this is not true in my case. So if I still cannot fix the
    problem by myself by the deadline, would I be able to at least stop my
    package being autoremed from testing?

    Thanks for helping

    ---------- Forwarded message ---------
    From: Debian testing autoremoval watch <noreply@release.debian.org>
    Date: Sat, Nov 20, 2021 at 11:40 PM
    Subject: dbab is marked for autoremoval from testing
    To: <dbab@packages.debian.org>


    dbab 1.5.01-1 is marked for autoremoval from testing on 2021-12-11

    It is affected by these RC bugs:
    999581: dbab: fails to migrate to testing for too long: unresolved RC bug
    https://bugs.debian.org/999581



    This mail is generated by: https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl

    Autoremoval data is generated by: https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rahmatullin@21:1/5 to Tong Sun on Fri Nov 26 07:40:01 2021
    On Thu, Nov 25, 2021 at 03:45:37PM -0500, Tong Sun wrote:
    My package cannot be upgraded from current version to latest version
    -- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769

    It might have something to do with obsoleted conffile files or it
    might even not. The problem is, I've been trying to understand how the conffile files work, and I think I'm doing the right thing, yet my
    package cannot be properly upgraded.

    - I don't understand what breaks and why, from the output of the
    package upgrade log (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769).
    Well those errors are clearly caused by dbab.maintscript saying
    "rm_conffile /etc/dbab", while /etc/dbab is indeed a directory and not a
    file. So it would be helpful if you told us what were you trying to do by
    this. If this is about #958900 then rm_conffile is *not* about removing
    files on purge. You should remove them manually in postrm, but only on
    purge.

    Unrelated, but is the package doesn't function without files downloaded
    from Internet, and even downloads them in postinst, then it should go to contrib. Should I file a bug about this?


    --
    WBR, wRAR

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmGggQ0tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh 0mQP/2LxmE9LXWJOwZLa0NWedGzh7JeGv3LUd3IM54ghj2JT/JrmLPIWNTx6i7Jb V8bdbAyuBmPGVcR1mTQSio3yIZbleij6Ha33nk9C2qEfCEvabhvCr+PND1I6Fd8v AMG+T0aNkrw1pY7NnjFOKlzwBfcDt6owLtpbMdCccFn23SIUy6cCieo1eoLCIUKU 7zjf/9/IDAK7HaLV/3/b13W+sGqVdD97duRqa7uZ9P7tag5r0k5UmGC+DPk2H8fN crLTIs4yPF3amCVZ7J2J+jrDYcXfz5xGE46bBtr+VY/qVdNKqkzm4XVt+mwKgN92 C1Uc1IWhI5nIcXId8PS5sMVJUwALKLBM4AKlfKufJV0jLNNdl3OUtZHnJ49ofcO+ 9FObA6RzylYO5OWiQrxJ8HoMxskVce3hECQjujALwmhR+vfU+UlWzFcbazdy/uCv /mQXESXiwTkr/RmZHJkEfBhEpoXCKH+GdEYf6VTEzry3gFRRfsfMCNMwj6wY0TeK ylz2CTXlELaAQpCMEy582sDQtWkPQzdfVYZ5ndcBBoF+GY48sXyyTWoAn7RYM1Jt wXtak+ZCvL/YcKkGdQBxyY80amsedzC8nCkBWnu+ulKO3Ox6KP9uWfW3GxOh+yOt DSqr1iujurHwfmeeIgVnptdhpXmmi4P0Hr/81KE7JMtKLdJ/
    =8/Xz
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tong Sun@21:1/5 to suntong001@users.sourceforge.net on Thu Dec 2 16:50:02 2021
    Hi,

    I'm having problem with my conffile files, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769

    I.e.,

    ----
    grep: /etc/dbab/dbab.list-: No such file or directory
    cat: /etc/dbab/dbab.addr: No such file or directory
    ----

    They should be there but I have no idea why they are not.

    Is there any way to have more insights into what's going on during the
    package upgrade or conffile files handling?

    thx

    On Thu, Nov 25, 2021 at 3:45 PM Tong Sun
    <suntong001@users.sourceforge.net> wrote:

    Hi Mentors,

    I need help.

    My package cannot be upgraded from current version to latest version
    -- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769

    It might have something to do with obsoleted conffile files or it
    might even not. The problem is, I've been trying to understand how the conffile files work, and I think I'm doing the right thing, yet my
    package cannot be properly upgraded.

    - I don't understand what breaks and why, from the output of the
    package upgrade log (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769).
    - Thus, I have no idea how to fix it, and all my previous attempts failed. So,

    Please help. The package source is at:

    https://salsa.debian.org/debian/dbab/


    Also, I've been trying to solve it on my own for so long that now the
    good version in testing is marked for autoremoval, for the reason
    that:

    If a package is out of sync between unstable and testing for a longer
    period, this usually means that bugs in the package in testing cannot be fixed via unstable.

    However, this is not true in my case. So if I still cannot fix the
    problem by myself by the deadline, would I be able to at least stop my package being autoremed from testing?

    Thanks for helping

    ---------- Forwarded message ---------
    From: Debian testing autoremoval watch <noreply@release.debian.org>
    Date: Sat, Nov 20, 2021 at 11:40 PM
    Subject: dbab is marked for autoremoval from testing
    To: <dbab@packages.debian.org>


    dbab 1.5.01-1 is marked for autoremoval from testing on 2021-12-11

    It is affected by these RC bugs:
    999581: dbab: fails to migrate to testing for too long: unresolved RC bug
    https://bugs.debian.org/999581



    This mail is generated by: https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl

    Autoremoval data is generated by: https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rahmatullin@21:1/5 to Tong Sun on Thu Dec 2 17:40:02 2021
    On Thu, Dec 02, 2021 at 10:46:43AM -0500, Tong Sun wrote:
    Hi,

    I'm having problem with my conffile files, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769

    I.e.,

    ----
    grep: /etc/dbab/dbab.list-: No such file or directory
    cat: /etc/dbab/dbab.addr: No such file or directory
    ----

    They should be there but I have no idea why they are not.
    I guess it was removed by your "dpkg-maintscript-helper rm_conffile
    /etc/dbab" call, which I already pointed at in the reply to your previous
    email about this bug? I have no idea how does it work when passed a
    directory but I wouldn't be surprised if it removes or moves it too.


    --
    WBR, wRAR

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmGo9QEtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh Ek0QAIQd0kGqfio6G8ZDHybdicutgm2IwQUNJLt6PQcPn1j1qWv3axjAZlLARYOu PpUGNADjxZ2eXeWLHd4pINae0OlrGVi2Mgq0N+897MFX4yZFV+53+cDbCZEAj/06 U6BL2I5eq26bj4j5zP3Qwb4PFb3ErgeKONd+Huy5Lug/Zoyo5EdUCee9uQWB+yKF rxlwlZxuW3p4JHv6rRWxzdT11IIFYjJyS/vFL+a4tIinRCJpXFRk202smGN2Qxct QsymBR+11BVQsial8O5L1XhdFdDZISPtaT7Lltauc2WdBvnTQna355v4AaZcOM+U APHq0Fp6n4Td2Ckej1aEf5YkAD+udnx5FNVOsCBmFqv0dTh/7zcmrA4fnSaK81YU LkxdGAy3aLF4HoULkXYahp4HOJ+6jAdsE7GP5qCeMo94k70g9SAY3pFzQ77IkRzk 7gqF15uKNPXR/dKh2KLRHrs1hsiKeTiZq+mlX+N9iY7SdlZOOTG5fxHCj21ICY9E E+p7ZlYMzQOICX2Zo27+L/pqq5WBRvXjIWZA5lUbmCAb7bzIlxtED9IK2aoPZfSU xXJhjFUOTFlAIK2nv9ueTgOC6AA56xitaVCy4cdOIjOe4o93z6byd1CC7oAYjKyY AV98YP38MUPcx38nxu48+H6be0VfJdcn2HElHKtABILTZLDj
    =xGAM
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tong Sun@21:1/5 to suntong001@users.sourceforge.net on Sun Dec 5 05:40:02 2021
    On Sat, Dec 4, 2021 at 11:09 PM Tong Sun
    <suntong001@users.sourceforge.net> wrote:

    On Thu, Dec 2, 2021 at 10:46 AM Tong Sun wrote:

    Hi,

    I'm having problem with my conffile files, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769

    I.e.,

    ----
    grep: /etc/dbab/dbab.list-: No such file or directory
    cat: /etc/dbab/dbab.addr: No such file or directory
    ----

    Oh, sorry Andrey, I didn't notice your following reply. sorry

    Well those errors are clearly caused by dbab.maintscript saying
    "rm_conffile /etc/dbab", while /etc/dbab is indeed a directory and not a file. So it would be helpful if you told us what were you trying to do by this. If this is about #958900 then rm_conffile is *not* about removing
    files on purge.

    The following is what I were trying to do, and yes, I hoped that it
    can be used to fix #958900, as well as doing the following:

    OK, I want to remove all conffile files and reinstall the new ones
    when doing package upgrade, as there isn't much user intervention to
    those conffile files. All are provided by the package.

    So I do `rm_conffile` to the old conffile files when doing package
    upgrade, but the new conffile files provided by the new upgrading
    package did not get installed afterwards, before they were used.

    They should be there but I have no idea why they are not.

    That's why they are there if doing fresh package installation but they
    are not there if doing package upgrade.

    How to properly handle conffile files in such a case?


    You should remove them manually in postrm, but only on
    purge.

    How to do that please?

    I see some scripts under https://wiki.debian.org/DpkgConffileHandling
    that can handle such / specific cases, but there is also a claim of
    "since dpkg 1.15.7.2 this can be done using dpkg-maintscript-helper".

    So, I have 4 ~ 6 conffile files, how to remove them manually in postrm
    but only on purge pls?

    Unrelated, but is the package doesn't function without files downloaded
    from Internet, and even downloads them in postinst, then it should go to contrib. Should I file a bug about this?

    Please don't yet, as I totally don't understand what you want me to
    do, now. Unless you can send me a patch, please let me get this thing
    over first.

    Please, please help.

    Again, the package source is at:
    https://salsa.debian.org/debian/dbab/

    Thanks


    Is there any way to have more insights into what's going on during the package upgrade or conffile files handling?

    thx

    On Thu, Nov 25, 2021 at 3:45 PM Tong Sun
    <suntong001@users.sourceforge.net> wrote:

    Hi Mentors,

    I need help.

    My package cannot be upgraded from current version to latest version
    -- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769

    It might have something to do with obsoleted conffile files or it
    might even not. The problem is, I've been trying to understand how the conffile files work, and I think I'm doing the right thing, yet my package cannot be properly upgraded.

    - I don't understand what breaks and why, from the output of the
    package upgrade log (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769).
    - Thus, I have no idea how to fix it, and all my previous attempts failed. So,

    Please help. The package source is at:

    https://salsa.debian.org/debian/dbab/


    Also, I've been trying to solve it on my own for so long that now the good version in testing is marked for autoremoval, for the reason
    that:

    If a package is out of sync between unstable and testing for a longer
    period, this usually means that bugs in the package in testing cannot be fixed via unstable.

    However, this is not true in my case. So if I still cannot fix the problem by myself by the deadline, would I be able to at least stop my package being autoremed from testing?

    Thanks for helping

    ---------- Forwarded message ---------
    From: Debian testing autoremoval watch <noreply@release.debian.org>
    Date: Sat, Nov 20, 2021 at 11:40 PM
    Subject: dbab is marked for autoremoval from testing
    To: <dbab@packages.debian.org>


    dbab 1.5.01-1 is marked for autoremoval from testing on 2021-12-11

    It is affected by these RC bugs:
    999581: dbab: fails to migrate to testing for too long: unresolved RC bug
    https://bugs.debian.org/999581



    This mail is generated by: https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl

    Autoremoval data is generated by: https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tong Sun@21:1/5 to All on Sun Dec 5 05:20:01 2021
    On Thu, Dec 2, 2021 at 10:46 AM Tong Sun wrote:

    Hi,

    I'm having problem with my conffile files, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769

    I.e.,

    ----
    grep: /etc/dbab/dbab.list-: No such file or directory
    cat: /etc/dbab/dbab.addr: No such file or directory
    ----

    OK, I want to remove all conffile files and reinstall the new ones
    when doing package upgrade, as there isn't much user intervention to
    those conffile files. All are provided by the package.

    So I do `rm_conffile` to the old conffile files when doing package
    upgrade, but the new conffile files provided by the new upgrading
    package did not get installed afterwards, before they were used.

    They should be there but I have no idea why they are not.

    That's why they are there if doing fresh package installation but they
    are not there if doing package upgrade.

    How to properly handle conffile files in such a case?

    Please, please help.

    Again, the package source is at:
    https://salsa.debian.org/debian/dbab/

    Thanks


    Is there any way to have more insights into what's going on during the package upgrade or conffile files handling?

    thx

    On Thu, Nov 25, 2021 at 3:45 PM Tong Sun
    <suntong001@users.sourceforge.net> wrote:

    Hi Mentors,

    I need help.

    My package cannot be upgraded from current version to latest version
    -- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769

    It might have something to do with obsoleted conffile files or it
    might even not. The problem is, I've been trying to understand how the conffile files work, and I think I'm doing the right thing, yet my
    package cannot be properly upgraded.

    - I don't understand what breaks and why, from the output of the
    package upgrade log (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769).
    - Thus, I have no idea how to fix it, and all my previous attempts failed. So,

    Please help. The package source is at:

    https://salsa.debian.org/debian/dbab/


    Also, I've been trying to solve it on my own for so long that now the
    good version in testing is marked for autoremoval, for the reason
    that:

    If a package is out of sync between unstable and testing for a longer
    period, this usually means that bugs in the package in testing cannot be fixed via unstable.

    However, this is not true in my case. So if I still cannot fix the
    problem by myself by the deadline, would I be able to at least stop my package being autoremed from testing?

    Thanks for helping

    ---------- Forwarded message ---------
    From: Debian testing autoremoval watch <noreply@release.debian.org>
    Date: Sat, Nov 20, 2021 at 11:40 PM
    Subject: dbab is marked for autoremoval from testing
    To: <dbab@packages.debian.org>


    dbab 1.5.01-1 is marked for autoremoval from testing on 2021-12-11

    It is affected by these RC bugs:
    999581: dbab: fails to migrate to testing for too long: unresolved RC bug
    https://bugs.debian.org/999581



    This mail is generated by: https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl

    Autoremoval data is generated by: https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rahmatullin@21:1/5 to Tong Sun on Sun Dec 5 07:00:02 2021
    On Sat, Dec 04, 2021 at 11:09:35PM -0500, Tong Sun wrote:
    OK, I want to remove all conffile files and reinstall the new ones
    when doing package upgrade, as there isn't much user intervention to
    those conffile files. All are provided by the package.
    Then they shouldn't be conffiles and shouldn't be in /etc.
    And if you want to drop user modifications you are just breaking the
    Policy requirements.

    So I do `rm_conffile` to the old conffile files when doing package
    upgrade,
    rm_conffile is about preserving user modifications.
    And, again, calling it with a dir is wrong.

    How to properly handle conffile files in such a case?
    If they shouldn't be modified by the user, they should be in /usr.

    --
    WBR, wRAR

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmGsVK0tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh 3pcP/1unxAIbDTz8EGw6DF3FrnnfvGcQhYHsbWDiS2giMbaRj5MYI3gg4k/ZqBth 8OyCQMYksUoUN8RYn2IhgraNqYT1sNy2SEhGC9G+Y4DsfsJzTbQb8NLeyKlE1JOO BTq/5DhYz7QTEVQT4lTfCDR6FVi2g1lVnZrCD/tAp5aD+ZO6QO0G9PCHyUtE5LFu 18tNdXq2fbsh5j/rEQVvs1fSK8KKj4rmWZREjbPvvVUd7T97ET3C7WxLMQlDPTra su23Y9kPSd/Z9OtBq8AFPIxJGHRdaJiSerkIWwCuWA3VLbBvUZzcHEGG8l3M56gY uzoTWM/EWkSRk+3OuNIaTapjwuiQ0xihsvWDq91BPZBS/PTvyQ1zJx54PzMH3D77 l/1PUI6Qg2Wx5G1yOww4NHoFuHA7RACGJrw8waeAV0TxzIIbW9Xhvi9aeY+FUPgg YhNPlp6gKAKnlbIlRwggYSQ9P8vgTRJErmSPR1N8d5bcHztNfjnSEIRfBEsAhSMW sR4ZcJq01W1qOallvjNO0ffW/tiZ+/paJmTEoZBa2DK/QxBHPk9/tgA98K7PvAeh AoyF8dZa/IDtvEMFDf26GotJO3xisyV3kP+zP56VCNLCF9imNmo25Wa3/jm1XBeG ZiJuct2jibDL2QIL0jwnBZGuJ1etA/iovtdUhNSo7E/0mNaw
    =9rm1
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rahmatullin@21:1/5 to Tong Sun on Sun Dec 5 07:10:01 2021
    On Sat, Dec 04, 2021 at 11:29:58PM -0500, Tong Sun wrote:
    You should remove them manually in postrm, but only on
    purge.

    How to do that please?
    The correct way, it seems, would be to follow the suggestion in the
    original bug report and fix the "rm -f /etc/dnsmasq.d/dbab.*" line in
    the 1.3.3-1 postrm. But now you will need to also recover from a bad state
    left by upgrades to 1.5.7-1.

    Unrelated, but is the package doesn't function without files downloaded from Internet, and even downloads them in postinst, then it should go to contrib. Should I file a bug about this?

    Please don't yet, as I totally don't understand what you want me to
    do, now. Unless you can send me a patch, please let me get this thing
    over first.
    I've already filed #1001009. It says what needs to be done. The relevant
    Policy section is 2.2.2.

    --
    WBR, wRAR

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmGsVo0tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh lsAP/2F/hUsGUvNnprMUUb42V/wo00sE/7ho+5kIudEPHobamz+ymcMlKS/CDNjz V62SYn+ZF+Wbls/EHNGj6DEpOfRVQb3/U33lQqNDQO/FlWpOhbOzwptwt6P+Xp78 Mz2NVec32tOR8BHNjAv54gVTpN4vmBnShLezbv0gjtdwRss4jLB1DTnPZbkyYijo 6byYC5t8uJp5Ef43E5CwGdwgXRFu/O+2wyYNESZgM/FRilRfpOZkvN8t2a1RCELl kexIE8rBdIsx/QpuvplBQbTJKJ6UG8RDz9y6gzzv4eb4pE6ViS0JqFayVzhO4pH8 F8JNviFDUq0AWseN+Gc6AXE9bPIbDwqUD8+W+nBcvga5YwHkAybVyx/oSFFDSV36 MYbK7GByevptiaK1MpI2oQ38y6lccKkk/j3RTsYbWCkq6eOdo5EXWNM+/nAVQ/mJ aZ2JW8KBf346JHf7t/F8DaUUZT4Y73vJOsSzWPbanCBdHGvSsU8d7mvd3AzdJF0u 02dJsqK+aXBFbVaSLZ9Lq4m4Dc7ls032/Lc/q08XpFu3DEa91icMqiUBWSDgYajf 3T5GaH8t+/2aZTUuKZ2T93T6YLxJ8PmBlY01vZRsTNdS8h+riaDYu/Oucm5McU/r SBY1uwR8t42QaOAA+HERqY9p3q+nlGuFzqzRteRmoDpc/0yK
    =bBdB
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tong Sun@21:1/5 to All on Sun Dec 5 16:30:02 2021
    On Sun, Dec 5, 2021 at 1:05 AM Andrey Rahmatullin wrote:

    On Sat, Dec 04, 2021 at 11:29:58PM -0500, Tong Sun wrote:
    You should remove them manually in postrm, but only on
    purge.

    But now you will need to also recover from a bad state
    left by upgrades to 1.5.7-1.

    Ah... it is getting more and more complicated. Nobody would be able to
    upgrade to 1.5.7-1 normally, so it is OK to use next good version as
    the fix please? Else, all the upgrade related problems can be easily
    fixed by purging the old version, and installing a brand new version.
    Would that be OK as the fix please? This is really a simple script,
    and I really hope that the debian side won't be complicated by any
    one-off end cases.

    How to do that please?
    The correct way, it seems, would be to follow the suggestion in the
    original bug report and fix the "rm -f /etc/dnsmasq.d/dbab.*" line in
    the 1.3.3-1 postrm.

    I still don't quite understand what you actually mean, but let me make
    a guess (and commit) and you can tell me if it is what you mean or
    not...

    thx Andrey

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stuart Prescott@21:1/5 to All on Mon Dec 6 07:50:01 2021
    On Friday, 3 December 2021 02:46:43 AEDT Tong Sun wrote:
    ----
    grep: /etc/dbab/dbab.list-: No such file or directory
    cat: /etc/dbab/dbab.addr: No such file or directory
    ----

    They should be there but I have no idea why they are not.

    Note that this isn't just about conffile handling in the package, these error messages also highlight bugs in the scripts that this package includes in /usr/sbin.

    * The scripts are assuming that files exist and do not test whether they exist. A conffile can be removed by the admin at any time; the software might not be able to work in that case, but it should exit with an informative error
    message not malfunction.

    * The scripts do not handle errors properly (at all, really). I think you need to go through each script line by line and ask "what might make this command fail?", "can that failure be prevented?", "if not, what should happen after failure?"

    * The scripts have at least predictable temp-file issue that allow an unprivileged user to do arbitrary damage to a system, overwriting any file they choose with a simple "ln -s /some/victim/file /tmp/dbab-map.adblock.conf" prior to the admin installing or upgrading the package, or running that script.

    * maintainer scripts should try very very hard to avoid failing (non-zero exit code) as that failure can be quite awkward to recover from. Failing the postinst because there's a blank line in the config file, for instance, seems pretty harsh.

    regards
    Stuart

    --
    Stuart Prescott http://www.nanonanonano.net/ stuart@nanonanonano.net Debian Developer http://www.debian.org/ stuart@debian.org
    GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rahmatullin@21:1/5 to pkgoyq.xpt@neverbox.com on Tue Dec 7 16:50:01 2021
    On Sun, Dec 05, 2021 at 10:19:44AM -0500, pkgoyq.xpt@neverbox.com wrote:
    You should remove them manually in postrm, but only on
    purge.

    But now you will need to also recover from a bad state
    left by upgrades to 1.5.7-1.

    Ah... it is getting more and more complicated. Nobody would be able to upgrade to 1.5.7-1 normally, so it is OK to use next good version as
    the fix please?
    Are you asking whether you can assume that no system had 1.5.01-1 and then 1.5.7-1 installed, because in that cause it would be impossible to have
    1.5.7-1 configured? That's probably a valid assumption, though I don't
    think what can you assume about systems that tried to update to 1.5.7-1
    and then were rolled back in some unknown way.

    Else, all the upgrade related problems can be easily fixed by purging
    the old version, and installing a brand new version.
    I don't think you can assume this is what was done though. Downgrading to
    the version from testing and pinning it is also a valid way to make the
    apt state consistent again.

    How to do that please?
    The correct way, it seems, would be to follow the suggestion in the original bug report and fix the "rm -f /etc/dnsmasq.d/dbab.*" line in
    the 1.3.3-1 postrm.

    I still don't quite understand what you actually mean,
    I just mean the original bug report already had a suggestion that seems
    correct to me.

    --
    WBR, wRAR

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmGvgJstFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh ND0P/is5JW8HvvvuIBxAUFa2bMP11ijLO8avhfxyVkeZ/m5osbEQ08cObzpQbaWa a43vqfmzs3flYbimUjhZuYloPnLlRmkpIZ/ssF/zHO+cOxSsZhwxfzSHkiyImLmj K1KmxImfLIe5X3wVnjzqpNZAlQQDAWdgVxH7MSxnXD12/7JfkjeYTrAvr1pp3XXV 7rhpT8tT6gw5r0iecV7fS2oiwIOvqsiB0AdjOR+iJMkHszSekCruUxdhVp4IBnNK kfaTvuv+Y1MD8/F4UMy/BerJTjWw7n1qeMJsF/8O4vP7+XdLP3hRQq9W/2E1XEJW YOXzH0L1uGDeB21qicQGpKG2HycBujfB+CNvZSU4P86dnl9MWMi05Hd5NTyd2eWy WqgTsgUh4l1JRXLqsonESzwDlWveyr6HaHqjGLOWG1eRp+tojUdZKamnU7vXan8z CWJ2zJHh+KyqOE/iH9C1B5WSob4r0/T+YxgpJuappLSdXkmTRuoR3N6XDpnJgUEQ 6yqTPA2nAur9OdM1sZ7PoDjM2dRgNBW6U0m/GSy7Zyxyp74jtVt3m2QPfK9w9uQ8 qHXdQn/gOf97g34Xq5L47SVcd3/tLArPLmGEkRX4ru4XeFWj+Tt55yvGtG2Mo6bI DEKOhn4IK8GDJoy+GHyUhhpYBF8sm+nKHGaJFdnW9KCYI4nX
    =se1s
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tong Sun@21:1/5 to All on Tue Dec 7 19:00:02 2021
    On Tue, Dec 7, 2021 at 10:41 AM Andrey Rahmatullin wrote:

    On Sun, Dec 05, 2021 at 10:19:44AM -0500, wrote:

    How to do that please?
    The correct way, it seems, would be to follow the suggestion in the original bug report and fix the "rm -f /etc/dnsmasq.d/dbab.*" line in
    the 1.3.3-1 postrm.

    I still don't quite understand what you actually mean,
    I just mean the original bug report already had a suggestion that seems correct to me.

    Can you give me a simple example package showing how it should be done please?

    It is not that I didn't try my best but the case is I've already tried
    my best to guess what the above means but it seems I guessed wrong
    each time. Thus I need detailed help, those few words only get me
    going around the circles.

    OK, let's start from the beginning:

    How to properly handle conffile files in such a case?

    You should remove them manually in postrm, but only on
    purge.

    That's actually what I've been doing, removing them manually in postrm
    and on purge --

    https://salsa.debian.org/debian/dbab/-/commit/0acfe617f064c5907f999707e37be12c7b9f8328

    But I was told to "using rm_conffile directive from .maintscript file"

    So I did, see -- https://salsa.debian.org/debian/dbab/-/commit/eca5bf35dc20843907b3eb0078a7926117bdf0e8

    But it is causing the above problem with my conffile files, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769

    I.e.,

    ----
    grep: /etc/dbab/dbab.list-: No such file or directory
    cat: /etc/dbab/dbab.addr: No such file or directory
    ----

    They should be there but they are not during upgrade.

    And the fix I got was:

    fix the "rm -f /etc/dnsmasq.d/dbab.*" line in
    the 1.3.3-1 postrm.

    and that's what I did, instead removing them manually in postrm with
    `rm`, I used
    `dpkg-maintscript-helper rm_conffile` instead.

    And now I'm at

    W: maintainer-script-should-not-use-dpkg-maintscript-helper

    I.e., I've gone through a full circle.

    Someone give detailed help please. thx

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rahmatullin@21:1/5 to pkgoyq.xpt@neverbox.com on Tue Dec 7 19:10:02 2021
    On Tue, Dec 07, 2021 at 12:57:37PM -0500, pkgoyq.xpt@neverbox.com wrote:
    How to do that please?
    The correct way, it seems, would be to follow the suggestion in the original bug report and fix the "rm -f /etc/dnsmasq.d/dbab.*" line in the 1.3.3-1 postrm.

    I still don't quite understand what you actually mean,
    I just mean the original bug report already had a suggestion that seems correct to me.

    Can you give me a simple example package showing how it should be done please?

    It is not that I didn't try my best but the case is I've already tried
    my best to guess what the above means but it seems I guessed wrong
    each time. Thus I need detailed help, those few words only get me
    going around the circles.
    Sorry, I'm not going to make an upload a package for this.
    Here are the instructions I meant and I don't know what can be clearer
    than that short of an actual debdiff:

    """
    I see the postrm has

    /etc/dnsmasq.d/dbab.*

    which I take it would have to be dbab-map.*
    """

    OK, let's start from the beginning:

    How to properly handle conffile files in such a case?

    You should remove them manually in postrm, but only on
    purge.

    That's actually what I've been doing, removing them manually in postrm
    and on purge --

    https://salsa.debian.org/debian/dbab/-/commit/0acfe617f064c5907f999707e37be12c7b9f8328
    But #958900 was about files that were not affected by that.

    But I was told to "using rm_conffile directive from .maintscript file"
    This is wrong. rm_conffile is only for cases when a conffile is no longer shipped. This is explained in dpkg-maintscript-helper(1). But /etc/dnsmasq.d/dbab.*, or /etc/dnsmasq.d/dbab, or
    /etc/dnsmasq.d/dbab-map.*, are not even conffiles, as far as I can see (as
    they are not shipped in the package, as far as I can see).

    So I did, see -- https://salsa.debian.org/debian/dbab/-/commit/eca5bf35dc20843907b3eb0078a7926117bdf0e8
    Yup, this is wrong. And /etc/dbab is a dir, so that line is doubly wrong.

    and that's what I did, instead removing them manually in postrm with
    `rm`, I used
    `dpkg-maintscript-helper rm_conffile` instead.

    And now I'm at

    W: maintainer-script-should-not-use-dpkg-maintscript-helper

    I.e., I've gone through a full circle.
    That's not even a circle, these are multiple separate problems, some of
    them unrelated.

    --
    WBR, wRAR

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmGvopwtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh CEsP/2RJo9sOkW8CcSs8w+YY7KF2umms/Aq1eYuH4Uai+9pAXng/RcIcpPtW4asw aJHZildaSka1H6P6MFEF5JSeNuPPUv1UWyytahN0ZKZLZUFxh59DE80lBXBIHp3O NaGw0k5A9TokX8E8+Uus6NRM3meLPr7Biw4I5b1S3TDZf84YxVuDzJOzQxoyGW9L KbevVUujxzAh8LUwck64dbpq7Mdb6x/rtnygptVtGFqtrrQlVDMH91KteYMjOE3L KkDMTqcNqwkAkP7twlCJOq+5OTEpDrbsFkYp1QLa6zgWmNeGKElJ7sIRabEH3AB3 U2FiGs8kh06c5oYEHXUR6D+LHb7hhMoATcReI0TXMJ6tylHmPXD7W6gR6WqS0US7 TxTt3RUa2lyBOwXepftZNCdCOIyGpXG5uSHWKgKZTOm3Il/9VRAK2N7ZVEZ54aA4 RynL83Ro5LM/xpZx4cceD2SbRhUNUpoVLN0Dxw1w05b5k/Q/AxwZ+RHOFn1cJv20 HFDESdpq7vzRk6oVNaeQFLvLUAtplYgV2ZQUYWYZZvZaP6//iHDqfbY3M9yrJeVB ClOOrz8TlNtf46XCQKZbKeZ/euJjX676mj6RoODP9fjonmciYoiW2fNhAcpSb3Bx 6CRAfh2kgAc6hsa07wLZNteLurQEoB04JSHcO693/If3BESj
    =WyjX
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tong Sun@21:1/5 to All on Tue Dec 7 20:00:01 2021
    On Tue, Dec 7, 2021 at 1:06 PM Andrey Rahmatullin wrote:

    On Tue, Dec 07, 2021 at 12:57:37PM -0500, wrote:
    How to do that please?
    The correct way, it seems, would be to follow the suggestion in the original bug report and fix the "rm -f /etc/dnsmasq.d/dbab.*" line in the 1.3.3-1 postrm.

    I still don't quite understand what you actually mean,
    I just mean the original bug report already had a suggestion that seems correct to me.

    Can you give me a simple example package showing how it should be done please?

    It is not that I didn't try my best but the case is I've already tried
    my best to guess what the above means but it seems I guessed wrong
    each time. Thus I need detailed help, those few words only get me
    going around the circles.
    Sorry, I'm not going to make an upload a package for this.
    Here are the instructions I meant and I don't know what can be clearer
    than that short of an actual debdiff:

    """
    I see the postrm has

    /etc/dnsmasq.d/dbab.*

    which I take it would have to be dbab-map.*
    """

    That the 1.3.3-1 postrm, and now the package is at 1.5.7, many
    versions after that. I.e., it was fixed a long time ago, and I presume
    that I don't need to do anything for that.

    OK, let's start from the beginning:

    How to properly handle conffile files in such a case?

    You should remove them manually in postrm, but only on
    purge.

    That's actually what I've been doing, removing them manually in postrm
    and on purge --

    https://salsa.debian.org/debian/dbab/-/commit/0acfe617f064c5907f999707e37be12c7b9f8328
    But #958900 was about files that were not affected by that.

    No, you're right, #958900 is fixes afterward, not in that specific commit.

    But I was told to "using rm_conffile directive from .maintscript file"
    This is wrong. rm_conffile is only for cases when a conffile is no longer shipped. This is explained in dpkg-maintscript-helper(1). But /etc/dnsmasq.d/dbab.*, or /etc/dnsmasq.d/dbab, or
    /etc/dnsmasq.d/dbab-map.*, are not even conffiles, as far as I can see (as they are not shipped in the package, as far as I can see).

    So you are saying that the correct way to do it is this -- https://salsa.debian.org/debian/dbab/-/blob/master/debian/dbab.postrm
    right?

    So I did, see -- https://salsa.debian.org/debian/dbab/-/commit/eca5bf35dc20843907b3eb0078a7926117bdf0e8
    Yup, this is wrong. And /etc/dbab is a dir, so that line is doubly wrong.

    what's the correct way for the fix then?

    remove the dbab.maintscript file, i.e., https://salsa.debian.org/debian/dbab/-/blob/master/debian/dbab.maintscript, right?

    and that's what I did, instead removing them manually in postrm with
    `rm`, I used
    `dpkg-maintscript-helper rm_conffile` instead.

    And now I'm at

    W: maintainer-script-should-not-use-dpkg-maintscript-helper

    I.e., I've gone through a full circle.
    That's not even a circle, these are multiple separate problems, some of
    them unrelated.

    Thanks for your help.
    Sorry for being dense.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rahmatullin@21:1/5 to Tong Sun on Tue Dec 7 22:10:02 2021
    On Tue, Dec 07, 2021 at 01:56:26PM -0500, Tong Sun wrote:
    But I was told to "using rm_conffile directive from .maintscript file"
    This is wrong. rm_conffile is only for cases when a conffile is no longer shipped. This is explained in dpkg-maintscript-helper(1). But /etc/dnsmasq.d/dbab.*, or /etc/dnsmasq.d/dbab, or /etc/dnsmasq.d/dbab-map.*, are not even conffiles, as far as I can see (as they are not shipped in the package, as far as I can see).

    So you are saying that the correct way to do it is this -- https://salsa.debian.org/debian/dbab/-/blob/master/debian/dbab.postrm
    right?
    Right.


    So I did, see -- https://salsa.debian.org/debian/dbab/-/commit/eca5bf35dc20843907b3eb0078a7926117bdf0e8
    Yup, this is wrong. And /etc/dbab is a dir, so that line is doubly wrong.

    what's the correct way for the fix then?

    remove the dbab.maintscript file, i.e., https://salsa.debian.org/debian/dbab/-/blob/master/debian/dbab.maintscript, right?
    Right.

    --
    WBR, wRAR

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmGvzQYtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh FQYP/0XT+0U+2TRrucUx0ez692ZFSv1iHDMvh59RLyQoebxnM9gIwfgiforRk7YI S41XBFPjcPMORjPqFnevRlsb6nZop0O2TaAE4E6u9uDwrU669fBQaGfzK/YuFFoi PC/Po7Ijga89xT60uMYgNZchwwGJLezhgQAAZaEApHSvE4nVUmKpgRmndKU7KNpu U94wRXOLYccOiYbEVY4Oi6c0myHdxQLMJFUTAN5rCMMGmT66Z7MHTOdYfQBAoULC uv114iOL/tIRJdOytuwVkNSF/coKm0P7OmqQ8RSv23HmwgdFTjTa4ax7a3jd0ZjS TTzvXWAqA6feaTTePSwg08W9coWfgsF7CDfX7qlaR8h2z4+/Ae9jXGyRaetYtjUu 6/KIt3UstD4ZhlxgYvw7sFX4gKS/CsHlB3gIZDMMzxsRC+SK4zbmxl4a0Vt2UX7O 52OGjYcFrCwzMbF0SbYDTVvCx6Relx5FchziPdlH3gWfm2ebp1VClaEW+0N1nKfV QmG8hEWx6SmBcFQw0q9NQGU+wIURcIJ6eBfm3I8NxFdoIyEbsSRAGQ0w+cxzYIBL RuyYhiTzWa/0XlDjPAu7GFgH/b1PYtON/OmEIu+XiNnxLDNOzzHfKfkcyC3FJ/Qb e1iUd+gQPYvz1NSlqB2+ylMo7mfIMfX8NpboAyRY3ry67ebT
    =8yWq
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tong Sun@21:1/5 to All on Sat Dec 11 18:00:03 2021
    On Sat, Dec 11, 2021 at 11:50 AM Tong Sun wrote:

    On Tue, Dec 7, 2021 at 4:07 PM Andrey Rahmatullin wrote:

    On Tue, Dec 07, 2021 at 01:56:26PM -0500, Tong Sun wrote:

    right?
    Right.

    ...
    right?
    Right.

    Thanks, one more thing,

    The dbab can upgrade from oldstable (Buster) just fine, but I'm trying
    to remove the conffile files no longer exist since then
    (dbab_1.3.2-2),

    | If the conffile has not been shipped for several versions, and you
    are now modifying the maintainer scripts to clean up the obsolete
    file, prior-version should be based on the version of the package that
    you are now preparing, not the first version of the package that
    lacked the conffile.

    So I did this:

    $ cat debian/dbab.maintscript
    rm_conffile /etc/dnsmasq.d/dbab.adblock.conf 1.5.7-2~
    rm_conffile /etc/dnsmasq.d/dbab.trashsites.conf 1.5.7-2~
    rm_conffile /etc/dbab/dbab.proxy 1.5.7-2~

    However, when I installed my 1.5.7-2 built such a way, I found the
    above files are still there.

    I meant, upgrading from dbab_1.3.2-2 to dbab_1.5.7-2 built in such way.

    What's the problem and how can I fix it? thx

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nilesh Patra@21:1/5 to Tong Sun on Sat Dec 11 19:20:01 2021
    Copy: debian-mentors@lists.debian.org (Debian Mentors List)
    Copy: wrar@debian.org

    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NALlTmz5sYPpus8zv7C7x2gwdT6gafWaM
    Content-Type: text/plain; charset=utf-8; format=flowed
    Content-Language: en-US
    Content-Transfer-Encoding: quoted-printable

    Hi Tong,

    Replying since I am CC'ed, look below :-

    On 12/11/21 10:20 PM, Tong Sun wrote:
    Thanks, one more thing,

    The dbab can upgrade from oldstable (Buster) just fine, but I'm trying
    to remove the conffile files no longer exist since then
    (dbab_1.3.2-2),

    | If the conffile has not been shipped for several versions, and you
    are now modifying the maintainer scripts to clean up the obsolete
    file, prior-version should be based on the version of the package that
    you are now preparing, not the first version of the package that
    lacked the conffile.

    So I did this:

    $ cat debian/dbab.maintscript
    rm_conffile /etc/dnsmasq.d/dbab.adblock.conf 1.5.7-2~
    rm_conffile /etc/dnsmasq.d/dbab.trashsites.conf 1.5.7-2~
    rm_conffile /etc/dbab/dbab.proxy 1.5.7-2~

    However, when I installed my 1.5.7-2 built such a way, I found the
    above files are still there.

    For me, the /etc/dbab/dbab.proxy *did* get removed, and the rest two are still present.
    Logs pasted at the end of this email.
    This is kinda expected I think.

    The reason is because "/etc/dbab/dbab.proxy" is present with the package installation in buster, and
    the rest two files are created during the postinst script. As far as I read the code, please see here[1] rm_conffile
    will work only when the config file belongs to the package, which is not "established" in this case.

    In buster version,

    $ dpkg -S /etc/dnsmasq.d/dbab.*
    dpkg-query: no path found matching pattern /etc/dnsmasq.d/dbab.adblock.conf dpkg-query: no path found matching pattern /etc/dnsmasq.d/dbab.trashsites.conf

    $ dpkg -S /etc/dbab/dbab.proxy
    dbab: /etc/dbab/dbab.proxy

    So I think you will have to manually take care of these two in postinst, I am not sure
    if there is a better way.

    [1]: https://sources.debian.org/src/dpkg/1.21.1/scripts/dpkg-maintscript-helper.sh/?hl=29#L98

    Regards,
    Nilesh

    $ apt policy dbab
    dbab:
    Installed: 1.3.2-2
    Candidate: 1.5.7-1
    Version table:
    1.5.7-1 500
    500 http://deb.debian.org/debian sid/main amd64 Packages
    *** 1.3.2-2 100
    100 /var/lib/dpkg/status

    $ sudo dpkg -i ./dbab_1.5.7-2_all.deb
    (Reading database ... 254432 files and directories currently installed.) Preparing to unpack ./dbab_1.5.7-2_all.deb ...
    Unpacking dbab (1.5.7-2) over (1.3.2-2) ...
    Setting up dbab (1.5.7-2) ...
    Installing new version of config file /etc/dbab/dbab.list+ ...
    curl 'https://pgl.yoyo.org/adservers/serverlist.php?hostformat=dnsmasq&showintro=0&mimetype=plaintext' -o /tmp/dbab-map.adblock.conf
    % Total % Received % Xferd Average Speed Time Time Time Current
    Dload Upload Total Spent Left Speed 100 127k 0 127k 0 0 150k 0 --:--:-- --:--:-- --:--:-- 150k File /etc/dnsmasq.d/dbab-map.adblock.conf updated.
    File /etc/dnsmasq.d/dbab-map.trashsites.conf updated.
    Removing obsolete conffile /etc/dbab/dbab.proxy ...
    Processing triggers for man-db (2.9.4-2) ...

    $ ls -la /etc/dnsmasq.d/dbab.trashsites.conf /etc/dnsmasq.d/dbab.adblock.conf /etc/dbab/dbab.proxy
    ls: cannot access '/etc/dbab/dbab.proxy': No such file or directory
    -rw-r--r-- 1 root root 365 Dec 11 18:04 /etc/dnsmasq.d/dbab.adblock.conf -rw-r--r-- 1 root root 124 Dec 11 18:04 /etc/dnsmasq.d/dbab.trashsites.conf


    --NALlTmz5sYPpus8zv7C7x2gwdT6gafWaM--

    -----BEGIN PGP SIGNATURE-----

    wsF5BAABCAAjFiEEPpmlJvXcwMu/HO6mALrnSzQzafEFAmG06oQFAwAAAAAACgkQALrnSzQzafGq 6w/9E3pPxlt96YAHDgI4RfJX0ebUeeccf+FaEpLudhiKTIcxphCZ5SVYeKbn9T0oOQov9VP6j4mN NcKswgxMU0AqQTDNSlzOPAvs+4EpKStzzwOewtNb8MNYKD2Apx1nxxz3bfKCgDg6V38O+nzjeKjU eXyFhfz0iIxywPZu/Dgs6oHZC+gqrqWIT3UX2+hbMQCrv+86Z8jhRcCW3wW2CT7UvQnDY9TF0gKJ v43fy4sefjCMSWIUZ1G310/AtPdCpEaGZKQYAGDrOE+GwmoPH0YnZvsWc4l28SviM1hk+UqSqMRa vBPrfdE/YvpBDpHWfJIvlEW+n9u0mTH12i9Hbx2muYyWvWYwb4ziu4ZNem5vyE7sDMpWL8m2kgKn aD3FR4UeAnli4ko8lphTbe4Jl5O18+DFW3xyZNXkd41fr475DsobhkWto1THtZgvRT2vMs1+y6IR otg0jEBbpJtl6GmJbBbYqoEgx30YqRM8+7oAvsMNEvr+/okECabPMkDGqzOqnUTx2NzYlt0HL2tP 1UHrYR1qs7hArPUoGGK+2+OzSw54ZkGd487LOcGscVACnAgyLbQ0JEjIUIqIYCOrv3BXWLX7I/q6 depMbwNVmBZOo7Lq12JoLkO3QdrbIFgskWebmo2HkSAW4af/0+qQkwLqGt/51S/4vW5fHE0kGCKy j/k=
    =GeUJ
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)