Bug#298381: ITP: lat -- Ldap Administration Tool
Package: wnpp Severity: wishlist Owner: Guido Trotter <[EMAIL PROTECTED]> * Package name: lat Version : 0.3.1 Upstream Author : Loren Bandiera <[EMAIL PROTECTED]> * URL : http://people.mmgsecurity.com/~lorenb/lat/ * License : GPL Description : Ldap Administration Tool LAT allows browsing LDAP directories and add/edit/delete entries contained within. It can store profiles for quick access to different servers. There are also different views available such as Users, Groups and Hosts which allows to easily manage these objects without having to deal with the intricacies of LDAP. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347203: ITP: millerquest -- non-interactive role-playing simulator game
Package: wnpp Severity: wishlist Owner: Guido Trotter <[EMAIL PROTECTED]> * Package name: millerquest Version : 0.9.1 Upstream Author : Urpo Lankinen * URL : http://www.beastwithin.org/users/olf/games/millerquest/ * License : GPL Description : non-interactive role-playing simulator game Miller's Quest! is a role-playing simulator game. It could also be described as a "fire-and-forget role-playing game". In other words, it is not a role-playing game in the most traditional sense, because there is absolutely no player interaction. The emphasis on this game is the simulation of role-playing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
Bastian Blank wrote: Hi! > The debian kernel team will maintain xen images with the linux-2.6 > source. I currently prepare both xen 3.0 and unstable packages, which > can be hopefully uploaded today. Maintainer will be the kernel team, as > there are heavy dependencies between xen and the kernel. This is great! In the meantime we are working on uploading xen 3.0 to unstable, and our packages I think are almost ready too! We planned to contact the kernel team after the upload to see how to coordinate, but it's nice to know that the kernel part is being taken care of! :) Our packages don't contain any kernel (we wouldn't have uploaded them without asking the kernel team, of course) but we plan on shipping just the xen patch for a kernel.org kernel, just in case someone preffers running a non-debian kernel: is that OK, or should we remove that from our sources? Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, 24 Feb 2006 at 03:30:55 -0800, Steve Langasek wrote: Hi! > Bastian Blank, a member of the Debian kernel team, is looking at integrating > XenoLinux builds into the official linux-2.6 package. I think that's a much > better option, and would strongly encourage anyone interested in Xen > packaging to coordinate with the kernel team on this. We will, of course, thanks! Here is an explanation why ha haven't yet! > (Yes, I'm aware there's a pkg-xen maintenance team on alioth as well; but > AFAICT the maintainer of the current xen package is not a member of that > packaging group, and there's no mention of xen on the wnpp bug page -- > what's up with that?) The current Debian Xen package is very old, and also has some policy compliance problems. We (as in: a lot of people who tried) haven't received any answer by the current Xen maintainer about xen status for a long time (as documented in debian bugs #342249 and #271051) so Jeremy Bouse ([EMAIL PROTECTED]) has set up a project on alioth and invited people who were interested or maintained unofficial packages to join, which some people (5 of them, as Ralph said) did. After that we've been working on preparing a clean release of Xen 3.0 for sid. We probably should have reported to wnpp and -devel before, sorry! Anyway Jeremy was the one who was going to do so, and he planning to do this soon (AFAIK). We had planned to contact the kernel team, but hadn't yet, as we wanted before to have a working hypervisor in sid (even if that meant that users needed to roll their own kernels) and then see if the kernel team was interested in helping us integrating xen better. (We also had planned contacting the glibc team, at that time, asking them if it could be possible to have a non-segmented glibc in debian for us, but that too was to be done later) Everything that the pkg-xen team did and planned till now can be seen in the public alioth mailing list archives. http://lists.alioth.debian.org/pipermail/pkg-xen-devel/ and http://lists.alioth.debian.org/pipermail/pkg-xen-changes/ ! Of course anyone interested in Xen is welcome to join! :) Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 04:37:56PM +0100, Bastian Blank wrote: Hi, > > This is great! In the meantime we are working on uploading xen 3.0 to > > unstable, > > and our packages I think are almost ready too! > > This is insufficient. Either maintain both 3.0 and unstable or none. In > the meantime, the kernel team will maintain both. > I think we have no problem packaging the unstable hypervisor too, as the kernel team provides support for it, after the stable one is in debian! Why don't you join the xen team list, so we can work together on that (contacting the kernel team when all of them are needed). I think having some people both on the kernel and the xen team will be better, of course! On the other hand Xen is not the kernel, so isn't it better if there is a team for it, even if strongly connected with the kernel one? Actually I'm sorry I had mis-read your statement... I thought you were talking just about the kernel while you referred to the hypervisor too! That's why my sentence might have appeared a bit out of context, sorry! So... what do you think we can do now? Can we join our efforts on xen or you strongly think it should be left to the kernel team, and we should just close the alioth project? Thanks! :) Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 04:54:24PM +0100, Julien Danjou wrote: Hi, > As far as I understand, you will just maintain Xen kernel images. (for > dom0 only ?). Actually I think he meant the hypervisors too... Anyway I also think that if the kernel team is going to maintain the kernel images there should be some made for unprivileged domains too! :) > We just have to duplicate our packages to add a -unstable release. > I don't think this is a great deal, at the point we are, we can do it. > Yeah, I think so too... But I'm also for making xen 3.0 enter unstable first, and uploading the unstable branch a bit later! Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 05:20:17PM +0100, Isaac Clerencia wrote: Hi, > Well, if the kernel team answers "left to the kernel team" and you close the > alioth project, I guess you can always move into the kernel team ;) > Yes, we could, of course... But on the other hand I believe that the xen hypervisor and userspace tools are actually different from the linux kernel (as they support multiple kernels and operating systems), even though the linux kernel patch has its right place inside the kernel itself... I agree that we should have probably have publicized more about our intent to work on xen, but at least it was spread all other the BTS in the xen package! And on the other hand we didn't know about Bastian's effort (which was not in the bts under either wnpp or xen), or we wouldn't have started our work without asking him! Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 05:41:53PM +0100, Isaac Clerencia wrote: Hi, > I agree. I just would like to ask that, please, don't disband just because of > disagreement with the kernel team, but try to cooperate anyway. > I don't think we want to! And I hope there is no disagreement (we still don't know)! The reason I think xen would be better served having its own committed team, repository, etc, is that it would be easier for anyone interested in xen to follow just mailing lists dedicated to it and its repository commits, rather than having to closely follow all the linux kernel work, mailing list, etc! Of course I also think it's great to have some people on both, so to have a close coordination between the xen and kernel releases. Also the xen team would need to coordinate with the glibc team (for the segmentation issues) and one day with the d-i team too, in order to try making a Debian/GNU/Xen/Linux (or whatever that should be called) installable directly on a system! Even upstream considers the linux kernel patch, the hypervisor and the tools separate, has separate mailing lists for them, and a separate mercurial repository for linux, even if for now they distribute the linux patch together with xen, until xen is merged into Linus' tree (or at least so Ian Pratt has said). If we can have the xen patch included in the debian kernel, thus pre-dating kernel.org inclusion that's really a good thing! Thanks! Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 06:06:22PM +0100, Bastian Blank wrote: Hi, > It is a sort of kernel. Yeah, it's a sort of kernel, but it's not the linux kernel... And it seems the kernel team is about the linux kernel, not just any kernel, isn't it? > Just to say, how connected xen to linux is: > > For example: There are three kernel trees of xen: > - from xen-3.0-testing, 2.6.12 > - from linux-2.6-xen, 2.6.16-rc4 > - from linux-2.6-merge, 2.6.16-rc3 > All of them have different needs from xen. > > The kernels from xen-3.0-testing and linux-2.6-merge works with a 3.0 > and unstable hypervisor. > > The 3.0 utils only works on the kernel from xen-3.0-testing. The > unstable utils with the other. But with both hypervisors. > That's I think because xen is still young, and is starting just now its distribution integration, and probably will happen a lot less when it will be integrated with Linux (Linus' tree) and the development of xenolinux will proceed at a different pace than the hypervisor. Then probably it will just be that any xen version will have a minimum linux version needed, just as now a lot of other stuff does, and there will be nothing special in it, except the fact that it needs a kernel compiled for the appropriate subarch). > I won't reject the help of volunteers but I strongly think that the > kernel team needs to have its hands on them. > What do other people in the kernel team think? If the majority of them agree fine, otherwise are you sure it's not counterproductive to force xen in the kernel team hands if most of them don't want to touch it, and on the other hand to risk driving away other people who just cannot follow the whole linux business but could work on the xen hypervisor and tools, help coordinate with xen's upstream, debian glibc and d-i, etc! Especially if you and other people who would do both can still do it! :) Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 05:34:44PM -0800, Steve Langasek wrote: Hi, > > Yeah, it's a sort of kernel, but it's not the linux kernel... And it seems > > the > > kernel team is about the linux kernel, not just any kernel, isn't it? > > The dom0 kernel is a Linux kernel built for the Xen hypervisor target. If > Debian is to provide a complete packaged environment for Xen, which is > certainly the goal I'm interested in (and Bastian as well, by the looks of > it), that means packaging (at least) a dom0 kernel; and the only way to do > that which would make the cut for stable is if it's kept synchronized with > the main linux-2.6 package. I think the only reasonable way to do that is > within the kernel team, which means people interested in helping with this > part should consider joining the kernel team. > Yes, we absolutely agree about this! We also would have liked for the patch to be integrated in the kernel team's work and from the xen kernel to be built and maintained by the kernel team (of course we hadn't contacted them yet, so we didn't know before if they were interested or if that would have been possible, so it's great to know that such intrest exists!). Of course I agree that anyone interested in Linux+Xen kernel work should join the kernel team! > For the userspace tools and the hypervisor, clearly there's no reason why > these need to be part of the kernel team repo as long as they aren't going > to be part of the same linux-2.6 source package. As Bastian points out, > though, there does still need to be close coordination between the > hypervisor/userspace tools and the XenoLinux build, because we don't yet > have mix-and-match compatibility. I absolutely agree... That's why I'm kindly asking Bastian to join us and to be on both teams, so he and other people interested in doing both can act as a bridge. > My feeling is that it still makes sense to maintain the hypervisor and > userspace tools in a separate pkg-xen group, and just coordinate between the > kernel and xen teams for this; but that should be sorted out among those doing > the work. I certainly can't see any benefits in terms of source management to > having them in the same svn repo with the kernel, anyway. > Thanks for your comments! > And are any of them applicable as patches to today's 2.6.15 linux-2.6 tree? > I haven't tried, for now... Bastian, have you? What are the results? > > That's I think because xen is still young, and is starting just now its > > distribution integration, and probably will happen a lot less when it will > > be > > integrated with Linux (Linus' tree) and the development of xenolinux will > > proceed at a different pace than the hypervisor. Then probably it will just > > be > > that any xen version will have a minimum linux version needed, just as now > > a lot > > of other stuff does, and there will be nothing special in it, except the > > fact > > that it needs a kernel compiled for the appropriate subarch). > > In the meantime, to the extent this is an issue it probably means that some > of this stuff isn't ready for inclusion in etch. I don't see a point in > uploading two versions of xen to unstable, certainly, if they aren't both > going to work with the provided kernels. > Of course I agree with you that until the kernel team (together with the interested people on the xen team) is able to produce working kernels for at least one version of Xen (and possibly the stable one) it's better for us not to push for its inclusion. We are planning to maintain unofficial packages for sarge (for people that want to use Xen right now) and can do that for etch too, if things don't sort out before release. It would be nice anyway to have some more support for Xen in etch (perhaps non segmented glibcs) even if xen itself is not included! Thanks! Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 05:40:04PM -0800, Steve Langasek wrote: Hi, > FWIW, the policy on kernel patches for sarge was that if it didn't apply to > the kernel sources we shipped, it didn't need to be included as a package in > stable. We're obviously not shipping a 2.6.12 kernel for etch, so I > wouldn't bother uploading that part... > And if they do they can probably be integrated anyway! Ok then, we can probably withraw the patch! Even though that can make things a bit harder for those not running debian kernels since xen is not yet integrated in there... Thanks! Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Mon, Feb 27, 2006 at 01:51:51PM +0100, Sven Luther wrote: Hi, > The kernel patches for XEN should be maintained inside the kernel team and in > linux-2.6, they are free to join the kernel team to handle this, but it is > unacceptable to have some kind of external patch to the kernel floating > around, and having no cooperation between the XEN team and the kernel team > will kind of encourage people to build their own xen kernel from mainline > upstream sources, which i believe is not what we want. > Absolutely true! The current xen team is fully agrees on this position! Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Tue, Feb 28, 2006 at 10:15:39AM +0100, Bastian Blank wrote: Hi, > The current package from pkg-xen is not releasable. > Then why don't you just join and commit your fixes before anybody tried to release it? Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Tue, Feb 28, 2006 at 02:17:45PM +0100, Sven Luther wrote: Hi, > > I can. > > :) > > Guido, be warned that Bastian often communicates with a few monosylabes and > SVN commits :) This doesn't make working with him too problematic usually > though :) > We've been a bit more chatty, for now, but I guess we will survive as long as the commits are agreed by everyone... ;) At this point I propose Jeremy to add Bastian to the pkg-xen alioth project (he's the only one who can do that, I think) and we can go ahead! :) Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Mon, Feb 27, 2006 at 02:29:51PM +0100, Sven Luther wrote: Hi, > I guess that if people are able to find a kernel source tree outside of > debian, they are perfectly capable of downloading and applying a patch too. > > Just include an URL to wherever such a patch is in the README.Debian of the > packages, should be enough. > Yes, this is the current plan! Thanks for your suggestions! :) Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#519408: ITP: lxc -- Linux containers userspace tools
Package: wnpp Severity: wishlist Owner: Guido Trotter * Package name: lxc Version : 0.6.0 Upstream Author : IBM Corporation * URL : http://lxc.sourceforge.net/ * License : LGPL Programming Lang: C Description : Linux containers userspace tools This package contains the lxc-* tools which can be used to manage and debug the container technology included in recent linux kernels. It can be used to start individual softwares or full systems inside an insulated area, with not only its own filesystem (chroot) but also dedicated network interfaces, scheduling, users, etc. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (1001, 'stable'), (501, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#368724: ITP: umview -- A partial user space virtual machine monitor
Package: wnpp Severity: wishlist Owner: Guido Trotter <[EMAIL PROTECTED]> * Package name: umview Version : 0.3 Upstream Author : View-OS team <[EMAIL PROTECTED]> * URL : http://savannah.nongnu.org/projects/view-os * License : GPL Description : A user space partial virtual machine monitor Umview implements in user space the "View-OS: A process with a View" concept, which grants an unprivileged user space process with the possibility to personalize its filesystem and network interfaces. . It is implemented as a daemon which traces a child process, making it see a different view of the world. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#440391: ITP: ganeti -- Virtual server cluster management platform
Package: wnpp Severity: wishlist Owner: Ganeti Debian Team <[EMAIL PROTECTED]> * Package name: ganeti Version : 1.2~b1 Upstream Author : Ganeti Team <[EMAIL PROTECTED]> * URL : http://code.google.com/p/ganeti/ * License : GPLv2 Programming Lang: Python Description : Virtual server cluster management platform Ganeti is a virtual server cluster management software tool built on top of the Xen virtual machine monitor and other Open Source software. After setting it up it will provide you with an automated environment to manage highly available virtual machine instances. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Xen status in lenny?
On Sat, Jul 12, 2008 at 06:01:30PM -0700, Steve Langasek wrote: Hi, > The distro used on dom0 is pretty uninteresting, given that part of the > point of having Xen-style virtualization for servers is to a) be able to run > different OSes in different guests, and b) not to run services in dom0.[1] > Agreed, we shouldn't support arbitrary dom0s, but it would be nice to have one supported way to run dom0 in debian, be it etch or lenny... If we say "run dom0 in etch" at least can we have the limited etch needed for a dom0 to work blessed with an extended support, if not support 2.6.18 in lenny? Thanks, Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317811: ITP: gnome-keyring-sharp -- a set of CIL bindings for the GNOME Keyring API
Package: wnpp Severity: wishlist Owner: Guido Trotter <[EMAIL PROTECTED]> * Package name: gnome-keyring-sharp Version : 0.0.1 Upstream Author : Russell Cloran <[EMAIL PROTECTED]> * URL : http://russell.rucus.net/2005/gnome-keyring-sharp/ * License : LGPL Description : C# bindings for the GNOME Keyring API GNOME Keyring is a system which allows you to store passwords and other sensitive data across GNOME applications. It provides an API to access this information, as well as a daemon to manage it. gnome-keyring-sharp is a set of CIL bindings for the GNOME Keyring API, written in C#. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.11.10tie00 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#208218: ITP: nagios-plugins -- Plugins for the nagios network monitoring and management system
Package: wnpp Version: unavailable; reported 2003-09-01 Severity: wishlist * Package name: nagios-plugins Version : 1.3.1 Upstream Author : Various (will all be listed in copyright file) * URL : http://nagiosplug.sourceforge.net/ * License : GPL Description : Plugins for the nagios network monitoring and management system Nagios is a host/service/network monitoring and management system. It has the following features: o Monitoring of network services (via TCP port, SMTP, POP3, HTTP, NNTP, PING, etc.) o Plugin interface to allow for user-developed service checks o Contact notifications when problems occur and get resolved (via email, pager, or user-defined method) o Ability to define event handlers to be run during service or host events (for proactive problem resolution) o Web output (current status, notifications, problem history, log file, etc.) These plugins are used by nagios to perform the various service checks. Comment: This is the first step of an attempt to get nagios fixed and in a good shape to get shipped with sarge. I've already contacted the Nagios maitainer about this. Guido pgpzlu4UOyrMZ.pgp Description: PGP signature
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
On Wed, May 21, 2003 at 10:05:47AM -0500, Steve Langasek wrote: Hi, > > If the "winning" option is discarded due to quorum requirements, then > given that all non-default options have the *same* quorum requirement, > this is exactly what would happen. > I think this is not inherently true. Since all options are compared two by two one of them could theorically defeat all the others but fail to defeat the default one by the quorum requirement, while at the same time all the others can defeat the default one with the necessary quorum margin... This is, of course, a quite borderline case, but it indeed exists. Bye, Guido -- Guido Trotter Jabber ID: [EMAIL PROTECTED] ultrt on irc pgplxJDaw8rdY.pgp Description: PGP signature
Re: Accepted directory-administrator 1.3.5-1 (i386 source)
On Wed, May 21, 2003 at 12:31:14PM -0700, Brian Nelson wrote: > > directory-administrator (1.3.5-1) unstable; urgency=low > > . > >* New Upstream Version (closes: #176227, #188308, #90276) > > Changelog abuse. This is only a valid entry if all 3 of these bugs were > requests for a new version, which they were not. > The features included in that version (and listed in upstream changelog) solve the problems reported in the other two report... Bye, Guido -- Guido Trotter Jabber ID: [EMAIL PROTECTED] pgpPTT07Zybha.pgp Description: PGP signature
Re: Call for volunteers to join DebConf Committee
Hi, I'd be happy to help, if you don't find any better suited candidate (if you have volunteers who are more expert than me, by all means go for them!!) I definitely have made it to plenty of debconfs, and sure hope to continue the trend. Thanks, Guido -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAM4p=JPE3w-otFF+aB9fXsChn0+thjb93w45s_-V+=wqrne...@mail.gmail.com
Re: Bits from keyring-maint [action required]
Great messaging. Until about 1/2 of the email I was wondering where this was going to go and finding it plausible. Thanks for the morning laugh! Guido On Sat, Apr 1, 2017 at 6:45 AM, Jonathan McDowell wrote: > A potential issue in the DFSG freeness of the Debian keyrings has been > brought to the attention of the keyring-maint team. We have already had > a similar issue[0] in the past with OpenPGP User Attributes (commonly > used to attach images to keys). This was resolved by stripping such data > from the keyrings; they add no extra information that is useful for the > purposes of the keyrings within the project. > > The current issue under investigation is unfortunately harder for us to > resolve as a team. It has been pointed out that the public keys, as > shipped, do not represent the preferred form for modification. While it > is possible for anyone to add additional data to a key without the > private component it is not possible to fully modify the key. For > example, a user wishing to upgrade all signatures on his copy of the > debian-keyring to SHA-256, removing any use of SHA-1, is unable to do > so. > > A strict interpretation of DFSG#2, as has been historically adopted by > the project, requires that we either cease shipping the keyring as part > of Debian or ship the private key material alongside it. Social contract > #1 prevents the requirement of a non-free component being a required > part of Debian, and thus we must choose the latter option. > > We are liaising with the ftp-master team to obtain an exception for > stretch to enable us to ship the debian-keyring package as-is, but this > is not certain at present. In the longer term we will have to ensure > full compliance with DFSG#2. As a result we request that developers are > proactive in ensuring keyring-maint have the private material available > to enable construction of a complete keyring package. This can be sent > to us via the following commands, which will safely export this > sensitive material: > > gpg --armor --export-secret-key | \ >sh -c '$(echo ZWNobyAiWW91J3ZlIGJlZW4gQXByaWwgRm9vbGVkISIK | base64 -d)' | > \ >mail -s 'Key material' keyring-ma...@debian.org > > J. > on behalf of keyring-maint > > [0] https://bugs.debian.org/826713 > > -- > "I can see an opening for the four lusers of the Apocalypse... 'I > didn't change anything', 'My e-mail doesn't work', 'I can't print' and > 'Is the network broken?'." -- Paul Mc Auley, asr
