Re: Do we need a conflict of interest policy?
On Saturday, February 8, 2025 9:09:55 PM MST Theodore Ts'o wrote: > I'm a bit dubious about a ChatGPT authored Conflict of Interest (COI) > policy because most of them that you will find on-line, and thus what > a Large Language Model (LLM) will regurgitate, are meant for > orgaizations where you have a small body of people who vote. > > So for example, if you serve on the board of a church, or a non-profit > orgaization like Usenix, or the Rocky Enterrise Software Foundation > (RESF), if there is a motion where you might benefit depending on how > the decision comes out, the CoI policy will mandate that you abstain > from voting on the motion. This is where the "refrain from > participating from a decision" language might come from. > > Howeer, it is quite common that someone with that potental conflict of > interest is often a subject matter expert. For example, if you are a > primary owner of a general contracting company, then you will know a > lot about building construction; so if the vote is about which company > should be hired, the board would *want* to hear your insights. So > typically the conflict of interest would be disclosed, the expert > would give their opinions, insights, and other expertise to the board > --- and then the expert might abstain from voting on the actual motion > if they were a board member. > > The problem is that in Debian, we rarely vote when we make decisions. > This does happen, of course, such as when the Technical Committee > votes on something that might be a very close call. In that case, it > would make sense for a TC member who might have conflict of interest > to step aside. > > However, many decisions take place via discussion / debates on public > mailing list --- so what does refrain from participating in a decision > mean in that context? That the people who might have the most > expertise must not participate in the debate? That > seems counterproductive. So there, probably the best you could do > is to make sure people should be asked to disclose conflicts of > interest up front, although in many cases, it might be obvious (for > example if the e-mail address has canonical.com). > > Another such situation is if a maintainer makes a decision as it > relates to a package where they are the primary maintainer. This case > can get quite ticklish, because very often, they *are* one of the > primary experts about the package; that's why they are the maintain > the package. And that might also be why a company decided to hire > them. For example, I got hired by Google because I was the ext4 > kernel maintainer, and I did make changes that made it easier for > e2fsprogs to be built on ProdNG, which was a Debian variant for use > internally at Google[1]. > > [1] "Live Upgrading Thousands of Servers from an Ancient Red Hat >Distribution to 10 Year Newer Debian Based One" >https://www.usenix.org/system/files/conference/lisa13/lisa13-merlin.pdf > > The changes that I made din't compromise Debian at all (I doubt anyone > noticed, since they din't cause any changes in the binary packages > generated by e2fsprogs' debian/rujles file for Debian. But this was a > decision that was made that benefited Google, *and* Debian because it > meant that we got a lot more testing on thousands and thousands of > servers runnig in data centesr al over the world. Is that a "conflict > of interest"? Lots of similar scenarios happened where Debian > Maintainers were hired by Canonical, and did work while being paid by > Canonical in a way that substantially benefited Debian *and* Ubuntu. > > Should people in these sorts of situations be "not allowed to > participate in decisions" as the package maintainer because of some > silly ChatGPT authored policy? I think not. > > Ultimately, this is a case where I think we do have recourse already, > which is if a package maintainer makes a decision which is detrimenta > to Debian, that decision can always be appealed to they TC. > > So I could imagine COI policies for specific, small bodies in Debian > where decisions get made via voting, such as the TC. > > However, I don't believe it makes sense for large bodies; for example, > excluiding people from voting on a GR just because they might have a > conflict of interest means that we could potentially depriving people > of their franchise, which I think would be a Bad Thing. So if someone > adopted this as a constitutional amendment, I would vote against it. > > The final thing I would note is that our structure means that in some > cases, the ultimate authority rest with the DPL. So I'm not sure we > *can* have a COI policy that applies to the DPL without it making a > fundamental change to our governance structure. The wise DPL would > delegate their authority if there wasa clear conflict of interest, of > course. And if a DPL abuses their authority, then they can be voted > out at the next election. But saying that the DPL "must not > participate
Re: Why are cinnamon-core and cinnamon-desktop-environment still in version 6.2?
On Wed, Feb 05, 2025 at 12:44:31PM +0100, Fabio Fantoni wrote: > Il 05/02/2025 12:19, kindusmith ha scritto: > > In Debian 13, all components of cinnamon have been upgraded to 6.4 or > > above, but cinnamon-core and cinnamon-desktop-environment are still > > lower versions of 6.2 > > > Hi, I haven't made the new version of those metapackages yet because at the > moment it would only be a version bump of the cinnamon components, I should > first do some tests of clean installations to check if it is necessary to > modify other parts. > Cinnamon comes originally from Linux Mate and Clement Lefebrvre - maybe follow what they package as their desktop as a basis for the full desktop metapackage if you haven't before?? > For now I know that I should remove vino from the recommended ones but I > don't know exactly which remote access system would be best to replace it > with. > > gnome-remote-desktop would be good, but unfortunately it has parts tied to > gnome, x2goserver which is now an alternative to vino seems to me to be > poorly supported (from a quick look, I could be wrong) and if I remember > correctly it is active by default at installation so it might not be a great > choice, regarding xrdp and others I had tried something many years ago, but > I am not up to date. > Ideally, yes, don't pull in masses of GNOME. It does seem that a lot of people rely on Cinnamon at least partly because it's lighter weight and needs fewer resources. if you can make cinnamon more self contained, that might be a lot better. [Several of the Debian desktop metapackages need cleaning up IMHO - don't feel bad that this is being asked of you.] > Does anyone have any advice on this? > I'd suggest RDP in some form: Microsoft seem to be going this way for suggested interaction with WSL and Red Hat have dropped VNC because it doesn't work well with Wayland. If people really want VNC, then TigerVNC is there in Debian for all architectures. Hope this helps, All the very best, as ever, Andrew Cater (amaca...@debian.org)
Re: cinnamon and VNC/RDP/remote access
On Sat, 08 Feb 2025 at 14:18:28 +, Andrew M.A. Cater wrote: > On Wed, Feb 05, 2025 at 12:44:31PM +0100, Fabio Fantoni wrote: > > For now I know that I should remove vino from the recommended ones but I > > don't know exactly which remote access system would be best to replace it > > with. Since nobody seems to have asked this question yet: Is accepting remote access from other machines considered to be a core part of the functionality of Cinnamon? If not, then maybe it doesn't need a remote desktop server to be part of a default installation, especially if there is no particularly suitable candidate? GNOME pulls in gnome-remote-desktop *because* it's relatively tightly integrated with the rest of GNOME - gnome-remote-desktop relies on implementation-specific interfaces built into libmutter and gnome-shell for its benefit; gnome-control-center has built-in UI for enabling and disabling remote access via gnome-remote-desktop (and/or ssh), so that it can be off-by-default but easy to enable if/when desired; and GNOME upstream considers gnome-remote-desktop to be part of their overall "product". But if similar statements aren't true for Cinnamon, then perhaps it doesn't need feature parity on this particular point? For example looking at MATE and Xfce, I don't see an obvious remote-desktop service. > If people really want VNC, then TigerVNC is there in Debian for > all architectures. Note that there are two flavours of remote access with rather different requirements and expectations, orthogonal to the specific protocol that's used. The traditional Unix approach to VNC was for the remote user's login to be into an entirely new, independent desktop session, like a GUI equivalent of logging in with ssh. Outside the Unix world, I believe this approach is basically equivalent to Windows Terminal Services. A local user can't see or interact with GUI applications started by the remote user, and vice versa, even if they are both logged in as the same uid. Xvnc, tightvncserver and tigervnc-standalone-server are examples of this approach if I understand correctly. gnome-remote-desktop, krfb, wayvnc and the now-unmaintained vino are more like the way remote access has traditionally been done on Windows and macOS desktop systems, where the remote user's login is remote-controlling an existing desktop session. This is less like a GUI equivalent of ssh, and more like a GUI equivalent of conspy or vtgrab, with applications started by either the local or remote user being visible and interactable for the other. tigervnc-scraping-server and tigervnc-xorg-extension seem to be implementations of this approach. Neither of those two approaches is a drop-in replacement for the other. > I'd suggest RDP in some form: Microsoft seem to be going this way > for suggested interaction with WSL and Red Hat have dropped VNC > because it doesn't work well with Wayland. Are you sure that's why Red Hat have de-emphasized VNC? VNC and RFB are both general-purpose protocols for remote keyboard/video/mouse, and in principle it shouldn't matter where you got the pixels from or where you're sending keyboard and mouse events to. The important difference between X11 and Wayland for remote access is that in X11, individual X11 clients are powerful enough to act as a remote access server, and the X11 server is largely powerless to prevent them from doing so (vino was an X11 client like any other, which is why it worked in Cinnamon despite having been designed for GNOME). With Wayland, ordinary applications do not have complete control over the compositor via the Wayland protocol, and remote-access servers like gnome-remote-desktop, krfb and wayvnc need to use a more-powerful out-of-band mechanism, often specific to one compositor implementation (mutter, kwin and wlroots, respectively). I believe gnome-remote-desktop always supported running under GNOME in Wayland mode (with video capture via GNOME-specific mechanisms that provide a Pipewire stream from the compositor), but if I remember correctly it was originally a VNC server, then it gained RFB support and was able to provide both protocols for a while, then VNC was removed. I don't know the specific reasoning for that - presumably some problem with either the VNC protocol or its specific implementation of VNC, combined with wide enough availability of RFB clients that VNC was no longer considered particularly interesting - but I think it's more likely to have been orthogonal to X11 vs. Wayland. If what you're thinking of is VNC servers that connect to an existing X11 session (like tigervnc-scraping-server or vino), then you're right to say that they can't work under Wayland, but that's a fact about their implementation of video capture and input event injection rather than a fact about the VNC protocol specifically. Or, if what you're thinking of is VNC servers that provide their own independent X11 display (like Xvnc), rather than "doesn't work well with Wayland" it would be mo
Re: Why are cinnamon-core and cinnamon-desktop-environment still in version 6.2?
Il 08/02/2025 15:18, Andrew M.A. Cater ha scritto: On Wed, Feb 05, 2025 at 12:44:31PM +0100, Fabio Fantoni wrote: Il 05/02/2025 12:19, kindusmith ha scritto: In Debian 13, all components of cinnamon have been upgraded to 6.4 or above, but cinnamon-core and cinnamon-desktop-environment are still lower versions of 6.2 Hi, I haven't made the new version of those metapackages yet because at the moment it would only be a version bump of the cinnamon components, I should first do some tests of clean installations to check if it is necessary to modify other parts. Cinnamon comes originally from Linux Mate and Clement Lefebrvre - maybe follow what they package as their desktop as a basis for the full desktop metapackage if you haven't before?? Hi, Mint created more fork or other software not packages for Debian, not enough time for maintain also them and some unfortunately they don't have enough people and time to maintain them well upstream so I don't think it's good to add them. For now I know that I should remove vino from the recommended ones but I don't know exactly which remote access system would be best to replace it with. gnome-remote-desktop would be good, but unfortunately it has parts tied to gnome, x2goserver which is now an alternative to vino seems to me to be poorly supported (from a quick look, I could be wrong) and if I remember correctly it is active by default at installation so it might not be a great choice, regarding xrdp and others I had tried something many years ago, but I am not up to date. Ideally, yes, don't pull in masses of GNOME. It does seem that a lot of people rely on Cinnamon at least partly because it's lighter weight and needs fewer resources. if you can make cinnamon more self contained, that might be a lot better. [Several of the Debian desktop metapackages need cleaning up IMHO - don't feel bad that this is being asked of you.] Sporadically I take a look and see if there are any improvements to the metapackages, unfortunately it happens quite rarely, especially the tests on multiple combinations (only core or complete with or without recommended etc...) but unfortunately it can take a long time for example the ubuntu ones of which some packages are different so much that before 24.04 I didn't have time for good tests (which I did before the lts versions of ubuntu) and unfortunately the default installation from the cinnamon metapackages doesn't seem good to me (then there is also the increase in the use of snaps which "worsens" some things or even just makes them heavier, but that's another thing) If there are any suggestions for improvement they are welcome. Does anyone have any advice on this? I'd suggest RDP in some form: Microsoft seem to be going this way for suggested interaction with WSL and Red Hat have dropped VNC because it doesn't work well with Wayland. If people really want VNC, then TigerVNC is there in Debian for all architectures. Hope this helps, All the very best, as ever, I would also prefer rdp (instead vnc) and gnome-remote-desktop it seems good but unfortunately in some parts it is strictly tied to gnome components and there is currently no one working on a fork tied to cinnamon components. There is xrdp although not very good from a quick test and put only as a further alternative. There is rustdesk that seems interesting but is not in the repository (there is only an RFP). For now I replaced vino with x11vnc, not very good from a fast test but better the vino.Then when something better is found (and preferably also with wayland support) I will replace it. Tigervnc if I remember correctly, when I tried it years ago it wasn't bad, but I don't think it has a simple enough configuration for beginners (something was changed or added?), so I haven't tried it again, since for the metapackage I'm looking for something simple and fast that's also good for beginners. Anyway I didn't have time to do a thorough research and testing of all the software, I just did a quick search and a quick test of some software before doing cinnamon-desktop-environment 6.4.0, so if you have more experience with remote access programs (present in the repository) feel free to recommend them and I will consider them for further improvements. Andrew Cater (amaca...@debian.org) OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1095520: ITP: qwprot -- quakeworld protocol headers
Package: wnpp Severity: wishlist Owner: Lee Garrett X-Debbugs-Cc: debian-devel@lists.debian.org, deb...@rocketjump.eu * Package name: qwprot Version : HEAD Upstream Contact: QW dev group * URL : https://github.com/QW-Group/qwprot * License : GPLv2 Programming Lang: C Description : quakeworld protocol headers quakeworld protocol headers. This header file protocol.h is used to ensure that the game server (mvdsv) and the game client (ezquake) always speak the same protocol version. This packages will be a build dependency for both packages. I intend to maintain this package under the Debian games team umbrella.
tag2upload update
Hello, I last wrote on 3rd December. Since then, we have - completed development of the three node design for tag2upload, with end-to-end integration testing -- see src:dgit in sid and dgit-team/tag2upload-service-manager.git on salsa - liaised with listmaster and got a list for archiving the tag2upload robot's processing mail - liaised with the DPL to create the tag2upload Delegates delegation - liaised with DSA and got three VMs and three role accounts created, for the three nodes for which the design calls. We are now spinning things up on those VMs and will ask for beta testers soon. Thanks to the formorer for the listmasters, Andreas our DPL, and special thanks to Philipp Kern of DSA for figuring out the hosting with us. -- Sean Whitton signature.asc Description: PGP signature
Re: Do we need a conflict of interest policy?
I'm a bit dubious about a ChatGPT authored Conflict of Interest (COI) policy because most of them that you will find on-line, and thus what a Large Language Model (LLM) will regurgitate, are meant for orgaizations where you have a small body of people who vote. So for example, if you serve on the board of a church, or a non-profit orgaization like Usenix, or the Rocky Enterrise Software Foundation (RESF), if there is a motion where you might benefit depending on how the decision comes out, the CoI policy will mandate that you abstain from voting on the motion. This is where the "refrain from participating from a decision" language might come from. Howeer, it is quite common that someone with that potental conflict of interest is often a subject matter expert. For example, if you are a primary owner of a general contracting company, then you will know a lot about building construction; so if the vote is about which company should be hired, the board would *want* to hear your insights. So typically the conflict of interest would be disclosed, the expert would give their opinions, insights, and other expertise to the board --- and then the expert might abstain from voting on the actual motion if they were a board member. The problem is that in Debian, we rarely vote when we make decisions. This does happen, of course, such as when the Technical Committee votes on something that might be a very close call. In that case, it would make sense for a TC member who might have conflict of interest to step aside. However, many decisions take place via discussion / debates on public mailing list --- so what does refrain from participating in a decision mean in that context? That the people who might have the most expertise must not participate in the debate? That seems counterproductive. So there, probably the best you could do is to make sure people should be asked to disclose conflicts of interest up front, although in many cases, it might be obvious (for example if the e-mail address has canonical.com). Another such situation is if a maintainer makes a decision as it relates to a package where they are the primary maintainer. This case can get quite ticklish, because very often, they *are* one of the primary experts about the package; that's why they are the maintain the package. And that might also be why a company decided to hire them. For example, I got hired by Google because I was the ext4 kernel maintainer, and I did make changes that made it easier for e2fsprogs to be built on ProdNG, which was a Debian variant for use internally at Google[1]. [1] "Live Upgrading Thousands of Servers from an Ancient Red Hat Distribution to 10 Year Newer Debian Based One" https://www.usenix.org/system/files/conference/lisa13/lisa13-merlin.pdf The changes that I made din't compromise Debian at all (I doubt anyone noticed, since they din't cause any changes in the binary packages generated by e2fsprogs' debian/rujles file for Debian. But this was a decision that was made that benefited Google, *and* Debian because it meant that we got a lot more testing on thousands and thousands of servers runnig in data centesr al over the world. Is that a "conflict of interest"? Lots of similar scenarios happened where Debian Maintainers were hired by Canonical, and did work while being paid by Canonical in a way that substantially benefited Debian *and* Ubuntu. Should people in these sorts of situations be "not allowed to participate in decisions" as the package maintainer because of some silly ChatGPT authored policy? I think not. Ultimately, this is a case where I think we do have recourse already, which is if a package maintainer makes a decision which is detrimenta to Debian, that decision can always be appealed to they TC. So I could imagine COI policies for specific, small bodies in Debian where decisions get made via voting, such as the TC. However, I don't believe it makes sense for large bodies; for example, excluiding people from voting on a GR just because they might have a conflict of interest means that we could potentially depriving people of their franchise, which I think would be a Bad Thing. So if someone adopted this as a constitutional amendment, I would vote against it. The final thing I would note is that our structure means that in some cases, the ultimate authority rest with the DPL. So I'm not sure we *can* have a COI policy that applies to the DPL without it making a fundamental change to our governance structure. The wise DPL would delegate their authority if there wasa clear conflict of interest, of course. And if a DPL abuses their authority, then they can be voted out at the next election. But saying that the DPL "must not participate in a decision", per the ChatGPT authored statement, I would argue does't work given what trust and power we vest in the DPL. Cheers, - Ted
