Re: Bug#1035528: ssh-audit: Please update the debian package
On Fri, May 05, 2023 at 06:24:00AM +, Robert Ernst wrote:
> Hello Martin,
>
> thank you for creating Bug report #1035528
>
> The missing update might be due to a broken watchfile.
> I already sent a MR a week ago. But the maintainer ChangZhuo Chen (陳昌倬)
> replied with cryptic messages via E-Mail, never accepted
> the Merge Request and then stopped replying to mails. I also would be
> interested to have progress here.
Sorry, I did not submit review result into salsa. Please check
https://salsa.debian.org/debian/ssh-audit/-/merge_requests/4 again.
--
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
https://czchen.org/
Key fingerprint = BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B
signature.asc
Description: PGP signature
Re: ssh-audit: Please update the debian package
Quoting Robert Ernst (2023-05-05 08:24:00) > I already sent a MR a week ago. But the maintainer ChangZhuo Chen (陳昌倬) > replied with cryptic messages via E-Mail, never > accepted the Merge Request and then stopped replying to mails. I also > would be interested to have progress here. Please have a bit more patience; "a week ago" is not "never". - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
Re: DEP 17: Improve support for directory aliasing in dpkg
Hi, On 04.05.23 20:26, Helmut Grohne wrote: From my point of view, the ultimate goal here should be moving all files to their canonical location and thereby make aliasing effects irrelevant. Do you confirm? Yes, that would solve the problem for the current transition without any changes in dpkg. There will be some small aliasing effects still, e.g. ldd will probably output the linker path from the ELF ABI instead of the canonical linker path, but nothing major. What I'm concerned about is that, whether we like it or not, we're still (d|r)efining interfaces here, and that affects future development, including future transitions. As such, I do not see aliasing support in dpkg as complementing the forced file move approach with lots of workarounds such as diverting dpkg-divert. Rather, I see them as exclusive strategies. Yes, absolutely. No one can coordinate two groups that don't even agree on the scope of the work or whether a definition of the scope is even necessary before beginning. Each of these strategies has significant downsides. In combining the different strategies, we combine their downsides, but since their benefit is shared, we do not gain anything in return but increase the price to pay. For this transition, yes, but we need to think beyond that. Any workaround we introduce here will need one release to be rolled out, one release to be stable, and one release to disappear. We can, in many but not all cases, introduce dependencies to enforce a particular ordering and reduce that by one release cycle. We're too late to roll out workarounds in the bookworm cycle, so we can deploy them with trixie at the earliest. Essential packages cannot contain diversions, so we need support from all installers (debootstrap, cdebootstrap, mmdebootstrap) or leave file paths for Essential packages as they are, delaying the end of the transition until forky. Making the workarounds obsolete before that will allow us to finish the transition earlier and thus reduce the effort of future transitions. For the users, nothing changes, they have had the files moved forcefully years ago. At the same time, there is little overlap in the groups that would implement the different strategies, so there is no person who would need to decide what they are working on to the detriment of the other option. On the flip side, if dpkg (and thus dpkg-divert) is to gain aliasing support, I see no reason (and benefit) to diverting dpkg-divert. Me neither. The problem is, we have no commitment from anyone to implement aliasing support. Volunteering Guillem hasn't worked, I don't really have time to do more than "best effort", and I don't know many other people even looking into that, so we cannot decide on that strategy. Can you explain why you see combining these strategies as something worth exploring? It will get something done on the way to finishing the transition until forky, even if dpkg changes don't manifest, but can provide a solution in trixie if they do. then a package containing /bin/foo and a package containing /usr/bin/foo now have a file conflict in dpkg. Not sure if that is a problem, or exactly the This case already is prohibited by policy section 10.1. It can only happen as a temporary state during a file move (from / to /usr and from one package to another). Yes, but from a technical point of view we cannot rely on Policy, it only allows us to assign blame, but that will not fix the error message a user is experiencing. With the status quo, dpkg will not detect the file conflict, which may or may not be the desired result, but it will not flag an error during execution. With two file names being diverted to the same name, it is likely (again, I haven't tested) that installation of the conflicting package will be aborted unless there is a Replaces: in effect, which is something that whatever tool is calling dpkg will need to deal with. behaviour we want. Probably the latter, which would allow us to define a policy "if aliased paths are diverted, the diversion needs to match", which in turn would allow the conflict checker during alias registration to verify that the aliased diversions are not in conflict. If we do not modify dpkg to improve aliasing support, then yes, such a scenario will require a Conflicts declaration or a different measure averting this problem. No, that would require the package declaring the diversion to conflict with itself, that makes no sense. We need to clarify the interface for dpkg-divert here (i.e. create Policy), and that interface will need to be supported by both the diverted dpkg-divert and the one shipped with dpkg. As of now, the one in dpkg will happily register diversions for aliased paths, but to my knowledge, none have been registered, and the diverted dpkg-divert does not exist yet, so we have full freedom to define what the policy should be. My proposal would be to put the onus on the
Re: DEP 17: Improve support for directory aliasing in dpkg
Hi, * Simon Richter [2023-05-05 17:59]: - it is not an error to register a diversion for an alias of an existing diversion, provided the package and target matches, this is a no-op - it is not an error to unregister a diversion for an alias of a path that has been unregistered previously, that is a no-op as well How do you distinguish between aliased diversions and "real" ones? Because if you allow the registration of duplicate diversions, the following can happen: - Package A is installed, preinst creates a diversion - Package B is installed, preinst creates the same diversion - Package A is uninstalled, postrm removes the diversion Now package B has lost its diversion. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: DEP 17: Improve support for directory aliasing in dpkg
Hi, On 05.05.23 18:36, Timo Röhling wrote: - it is not an error to register a diversion for an alias of an existing diversion, provided the package and target matches, this is a no-op - it is not an error to unregister a diversion for an alias of a path that has been unregistered previously, that is a no-op as well How do you distinguish between aliased diversions and "real" ones? Because if you allow the registration of duplicate diversions, the following can happen: - Package A is installed, preinst creates a diversion - Package B is installed, preinst creates the same diversion - Package A is uninstalled, postrm removes the diversion That's why the package and target need to match -- so by extension package B may not divert a path that package A already diverts. With dpkg-divert as it is, this works because no aliasing support exists. A diverted dpkg-divert that generates additional diversions would need to catch this case, reject it and restore the previous state, same as an aliasing aware dpkg-divert. Simon OpenPGP_signature Description: OpenPGP digital signature
Bug#1035566: ITP: gl4es -- OpenGL 2.1/1.5 to GLES 2.0/1.1 translation library title
Package: wnpp Severity: wishlist Owner: Cheng Li X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: gl4es Version : 1.1.4 Upstream Author : ptitSeb * URL : https://github.com/ptitSeb/gl4es * License : MIT Programming Lang: c Description : OpenGL 2.1/1.5 to GLES 2.0/1.1 translation library This is a library provide OpenGL 2.x functionality for GLES2.0 accelerated Hardware (and of course also support OpenGL 1.5 function, so metimes better than when using GLES 1.1 backend) There is also support for GLES 1.1 Hardware, emulating OpenGL 1.5, and some OpenGL 2.x + extensions. This package contains the shared libraries
Bug#1035570: ITP: omemo-dr -- OMEMO double ratchet for Python
Package: wnpp Owner: deba...@debian.org Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org, pkg-xmpp-de...@lists.alioth.debian.org * Package name: omemo-dr Version : 0.99.1 Upstream Author : Philipp Hörist * URL or Web page : https://dev.gajim.org/gajim/omemo-dr/ * License : GPL3 Programming Lang: Python Description : OMEMO double ratchet for Python Initial codebase was forked from python-axolotl, which is a Python 3 port of libaxolotol-android. The library is defined as a ratcheting forward secrecy protocol that works in synchronous and asynchronous messaging environments. This is a new dependency of Gajim >= 1.8.
Re: DEP 17: Improve support for directory aliasing in dpkg
On 2023-05-05 Simon Richter wrote:
[...]
> My proposal would be to put the onus on the client registering the
> diversion:
[...]
> - packages are encouraged to register both diversions
Hello,
That seems to be a rather ugly user interface, ("There is dpkg-divert on
Debian, but because the usrmerge you need to invoke it twce to be
sure"). Will we need to have a meta-transition years from now trying to
get get rid of the double diversions?
cu Andreas
Re: Work-needing packages report for May 5, 2023
If you write to me again or one of yours, I'm going to denounce youuu El vie, 5 may 2023 2:42, escribió: > The following is a listing of packages for which help has been requested > through the WNPP (Work-Needing and Prospective Packages) system in the > last week. > > Total number of orphaned packages: 1221 (new: 1) > Total number of packages offered up for adoption: 157 (new: 0) > Total number of packages requested help for: 58 (new: 0) > > Please refer to https://www.debian.org/devel/wnpp/ for more information. > > > > The following packages have been orphaned: > >rbdoom3bfg (#1035299), orphaned 4 days ago > Description: Doom3 BFG edition game engine > Installations reported by Popcon: 82 > Bug Report URL: https://bugs.debian.org/1035299 > > 1220 older packages have been omitted from this listing, see > https://www.debian.org/devel/wnpp/orphaned for a complete list. > > > > No new packages have been given up for adoption, but a total of 157 > packages > are awaiting adoption. See > https://www.debian.org/devel/wnpp/rfa_bypackage > for a complete list. > > > > For the following packages help is requested: > >apache2 (#910917), requested 1664 days ago > Description: Apache HTTP Server > Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom >apache2-suexec-pristine backuppc bfh-container-server >courier-webadmin cvsweb debbugs-web debian-edu-router-deployserver >(125 more omitted) > Installations reported by Popcon: 96337 > Bug Report URL: https://bugs.debian.org/910917 > >apparmor (#1006872), requested 423 days ago > Description: user-space parser utility for AppArmor > Reverse Depends: apparmor-notify apparmor-profiles >apparmor-profiles-extra apparmor-utils content-hub-testability >dbus-broker dbus-daemon dbus-tests debian-cloud-images-packages >dovecot-core (24 more omitted) > Installations reported by Popcon: 192263 > Bug Report URL: https://bugs.debian.org/1006872 > >autopkgtest (#846328), requested 2346 days ago > Description: automatic as-installed testing for Debian packages > Reverse Depends: debci-worker sbuild-qemu > Installations reported by Popcon: 1177 > Bug Report URL: https://bugs.debian.org/846328 > >balsa (#642906), requested 4239 days ago > Description: An e-mail client for GNOME > Reverse Depends: balsa > Installations reported by Popcon: 590 > Bug Report URL: https://bugs.debian.org/642906 > >cargo (#860116), requested 2214 days ago > Description: Rust package manager > Reverse Depends: dh-cargo python3-setuptools-rust rust-all > Installations reported by Popcon: 2914 > Bug Report URL: https://bugs.debian.org/860116 > >chromium (#1016047), requested 282 days ago > Description: web browser > Reverse Depends: chromium chromium-driver chromium-l10n >chromium-shell node-puppeteer qunit-selenium >x2gothinclient-minidesktop > Installations reported by Popcon: 24559 > Bug Report URL: https://bugs.debian.org/1016047 > >courier (#978755), requested 854 days ago > Description: Courier mail server > Reverse Depends: courier-faxmail courier-filter-perl courier-imap >courier-ldap courier-mlm courier-mta courier-pcp courier-pop >courier-webadmin couriergrey (3 more omitted) > Installations reported by Popcon: 747 > Bug Report URL: https://bugs.debian.org/978755 > >cron (#984736), requested 788 days ago > Description: new maintainer need > Reverse Depends: apticron autolog backintime-common bcron >btrfsmaintenance buildd checksecurity clamtk cricket cron (25 more >omitted) > Installations reported by Popcon: 207983 > Bug Report URL: https://bugs.debian.org/984736 > >cyrus-imapd (#921717), requested 1546 days ago > Description: Cyrus mail system - IMAP support > Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev >cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication > Installations reported by Popcon: 387 > Bug Report URL: https://bugs.debian.org/921717 > >debtags (#962579), requested 1058 days ago > Description: Debian Package Tags support tools > Reverse Depends: packagesearch > Installations reported by Popcon: 1345 > Bug Report URL: https://bugs.debian.org/962579 > >dee (#831388), requested 2484 days ago > Description: model to synchronize multiple instances over DBus > Reverse Depends: dee-tools gir1.2-dee-1.0 gir1.2-unity-7.0 >libdee-dev libunity-dev libunity-protocol-private0 libunity-tools >libunity9 zeitgeist-core > Installations reported by
Re: DEP 17: Improve support for directory aliasing in dpkg
On Fri, 5 May 2023 at 17:38, Andreas Metzler wrote:
>
> On 2023-05-05 Simon Richter wrote:
> [...]
> > My proposal would be to put the onus on the client registering the
> > diversion:
> [...]
> > - packages are encouraged to register both diversions
>
> Hello,
>
> That seems to be a rather ugly user interface, ("There is dpkg-divert on
> Debian, but because the usrmerge you need to invoke it twce to be
> sure"). Will we need to have a meta-transition years from now trying to
> get get rid of the double diversions?
It is not the prettiest thing but it is a very clever solution.
Perhaps it could be mitigated with an addendum that makes it optional,
and to be used only when strictly needed, after all moving files
within the same package is fine, it's only the combination of moving
location _and_ package that causes problems. In other words:
- every package is forcefully canonicalized as soon as trixie is open
for business
- the moratorium on moving files from bin/ sbin/ lib/ _and_ to other
packages at the same time is maintained from bookworm till trixie, and
will lifted after trixie ships, and applies implicitly to all the
~2000 binary pkgs that are affected by the above
- the moratorium can be bypassed by a maintainer if and only if the
appropriate conflicts/replaces/diverts as discussed in this thread are
put in place and left there for as long as needed (TBD whether this
means for trixie's cycle or for trixie+1)
In practice, I suspect that out of ~2000 packages shipping bin/ sbin/
lib*/, only a small fraction would end up needing to further move
files out to other packages, so the divert dance requirement can be
restricted only to those. This way impact is minimized, required
testing is smaller, and we get in the final state on day one of trixie
dev cycle.
Moving files between packages already requires busywork anyway, so a
bit more won't hurt that much, especially if we figure out a way to
provide the functionality with a dh addon or such to do the heavy
lifting.
Kind regards,
Luca Boccassi
Re: DEP 17: Improve support for directory aliasing in dpkg
Hi, On 06.05.23 07:11, Luca Boccassi wrote: - every package is forcefully canonicalized as soon as trixie is open for business You will also need to ship at least - /lib -> usr/lib (on 32 bit) - /lib64 -> usr/lib64 (on 64 bit) as a symlink either in the libc-bin package or any other Essential package, to fulfill the requirement that unpacked Essential packages are operational. Simon OpenPGP_signature Description: OpenPGP digital signature
