Re: Reviving schroot as used by sbuild
> "Helmut" == Helmut Grohne writes: Helmut> In this work, limitations with --chroot-mode=unshare became Helmut> apparent and that lead to Johannes, Jochen and me sitting Helmut> down in Berlin pondering ideas on how to improve the Helmut> situation. That is a longer story, but eventually Timo Helmut> Röhling asked the innocuous question of why we cannot just Helmut> use schroot and make it work with namespaces. I'll be honest, I think building a new container backend makes no sense at all. There's a lot of work that has gone into systemd-nspawn, podman, docker, crun, runc, and the related ecosystems. I think an approach that allowed sbuild to actually use a real container backend would be long-term more maintainable and would allow Debian's DevOps practices to better align with the rest of the world. I have some work I've been doing in this space which won't be useful to you because it is not built on top of sbuild. (Although I'd be happy to share under LGPL-3 for anyone interested.) But I find that I disagree with the idea of writing a new container runtime for sbuild so strongly that I can no longer use sbuild for Debian work, so I started working on my own package building solution. I realize that I have not done a good job of being constructive here. I intended to write some blog posts on this topic, but got sucked into work and tag2upload. In terms of constructive feedback: * I think your intuition that sbuild --chroot=unshare is limiting is good. * I would move toward a persistent namespace approach because it is more similar to broadly used container backends. * overlayfs/fuse-overlayfs are how the rest of the world is solving these problems (or snapshots and the like). Directories are kind of a Debian-specific artifact that I find more and more awward to deal with as the rest of my work uses containers for CI/CD. signature.asc Description: PGP signature
Re: Builds that pass locally but fail on sbuild? (Re: Reviving schroot as used by sbuild)
> "Richard" == Richard Lewis writes: Richard> Otto Kekäläinen writes: >> Could you point me to some Debian Bug # or otherwise share >> examples of cases when a build succeeded locally but failed on >> official Debian builders due to something that is specific for >> sbuild/schroot? Until I fixed it, krb5 would not work in a network namespace that only had a lo interface. It ran getaddrinfo with GAI_ADDRCONFIG in its tests, because localhost is discouraged/not allowed in krb5 ticket addresses per RFC 4120. It only talks to itself, but it really wants to talk to itself not on localhost. I patched the sources to work around sbuild chroot=unshare. signature.asc Description: PGP signature
Re: Urgent help with upload of netatalk to prevent being autoremoval from testing
> "Daniel" == Daniel Markstedt writes: Daniel> Hi all, I have drafted a release of the netatalk package Daniel> that addresses 5 critical deb bugs. However, I myself am Daniel> only an uploader in name and don't yet have actual upload Daniel> privileges. And my co-maintainer, who does have privileges, Daniel> has been too busy IRL to assist for quite some time. Daniel> Normally I would be more patient, but right now netatalk is Daniel> slated to get removed from Trixie testing on July 4th due to Daniel> one of the bugs (libgcrypt-config deprecation.) Daniel> For reference, the full list of the bugs to be fixed. Drop a note to that bug indicating an upload is pending waiting sponsorship. That should be sufficient to reset the timer.
Re: Accepting DEP14?
> "Andreas" == Andreas Tille writes: Andreas> Are there any blockers to accept this DEP which I might Andreas> have missed? Honestly, the git-buildpackage default layout is good enough, and dep-14 involves change that doesn't feel like it brings enough value to me. I.E. I think that dep-14 has been around so long and hasn't gotten accepted is a strong suggestion that it doesn't bring sufficient value. And I think that alone is a blocker. signature.asc Description: PGP signature
krb5: ABI Issue--confirm your packages work against 1.4.3 in experimental
Hi folks. I've just uploaded Mit Kerberos 1.4.3-1 to experimental. I'm writing to you because your package links against the main kerberos library (libkrb53) and I'd like you to confirm that the Kerberos support in your package still works against this version. The public ABI and API of MIt Kerberos has been stable since before Woody was released. However MIT reserves the right to change symbols not mentioned in krb5.h (or mentioned only when KRB5_PRIVATE is defined) at any point in time. New symbols are not added to KRB5_PRIVATE without an ABI bump. Unfortunately, some packages end up calling symbols that are private such as krb5_init_ets(). Many years ago--before krb5 was introduced into Debian--this was actually a good idea. however it has been unnecessary and incorrect for any version of kerberos in Debian. MIt Kerberos 1.4 apparently marks the first time when MIT has removed any such symbol. This can cause packages calling such a symbol to break at runtime. That's not good. The solution to this problem is to remove the call to the private symbol. In the case of krb5_init_ets (the common problem), just remove the call. In the case of any other symbols, fix the problem if it is obvious, or ask [EMAIL PROTECTED] for help if it is not. (I'm on that list; you could just ask me, but you will be better off asking a larger list). I'd appreciate it if you would take the time to see if your package works against the new Kerberos library. The easiest way to do this is to build your package or at least the kerberos using parts of your package against the new libkrb5-dev package and confirm there are no warnings about missing prototypes and that your package can successfully link to libkrb5. If you do find problems, please upload a version of your package that fixes the problem (built against the old library) to unstable. Open a serious bug tagged as experimental against the krb5 package asking me to conflict with broken versions of your package. Be sure to include the version of your package that has the fix in the bug description. The above procedure assumes that you don't need functionality from krb5 1.4 to work around private symbols you are using. If that ends up not being the case then talk to me and we'll work something out. Also, if your package is involved in some sort of transition and has limited uploading,we'll need to work on timing with the release team. If for this or any other reason you cannot upload a fix please still open a bug so I'll know that krb5 1.4 will break your package. Thanks for your cooperation in making Debian better and helping me with this transition. Finally, great thanks to Russ Allbery my co-maintainer for all his work on the package. pgpc4Ue7ebKVE.pgp Description: PGP signature
Re: [useless] I am still on the keyring. With my old key.
> "Chip" == Chip Salzenberg <[EMAIL PROTECTED]> writes: Chip> Who does a developer have to fuck around here to get his key Chip> deleted? -- Chip Salzenberg <[EMAIL PROTECTED]> Chip> -- To UNSUBSC Hi. As you are no doubt aware by now, getting your key removed is a great mystery and deep magic requiring much research and perseverance. However as best I can tell delving into the sacred texts, it's a cryptography magic not a sex magic. Now, perhaps what you're trying to do is use a sex magic as a means of coercion to catalyze the cryptography magic. That's certainly an interesting approach. There do seem to be some references to something similar in some related folk traditions. However there aren't really any references to this sort of thing in the sacred texts of cryptography. I'm a bit concerned that cryptography has its own coercion magic--never fully described and only alluded to by the primary tool (the rubber hose [*]). I'm concerned that since cryptography has its own coercion magic, it may not be easy to use another magic for the same purpose. The powers at play may simply not interact well. If you do manage to succeed with this approach then you will have learned something interesting. Now, a few comments on attempting the cryptography magic directly. It's my understanding that the key to such magics--particularly in the Debian tradition--is to harness sufficient energy and focus it on a point. There are apparently techniques that involve public mailing lists for amplification. You do have access to a symbol of power which may give you control of sufficient energy: your old key. Consider carefully the following ritual. Carefully write instructions describing how one not familiar with the Debian tradition could use a key to influence Debian--particularly focusing on a description of the package upload ritual. Of course since you are targeting novices your description should focus on warning about the ways in which such power could be abused; not all novices have sufficient imagination so you'll have to be very explicit. Take this ritual and place along side it your private key. I'm afraid that in order to harness sufficient power you may have to remove the traditional wards around your key. Post the result to debian-devel. I think that the resulting energy--particularly focused so close to your private key--may totally destroy your key in the Debian sphere. BE WARNED. This is the first ritual I've tried to create myself. It involves powers and energies much stronger than I'm used to applying. Energies that strong often lead to karmic backlash. I have not yet calculated the full extent of karmic backlash possible from this ritual; it seems beyond my capabilities. I would strongly advise finishing such a calculation before you begin. I'm certain that the energies involved are great enough that there will be consequences beyond your primary intended effect. Good luck in your quest. -Sam P.S. This is a *joke*. I am not actually advocating disclosing a private key. Good luck in actually getting the key removed through the normal mechanism. [*] I suppose there are sex magics involving rubber hoses. They are beyond my experience and I am not sure how they would interact with cryptography magic. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Boxed Penguin Prototype showcases customization of Debian to build infrastructure server
In order to actually get something done in an electronic office, we need a certain amount of infrastructure. In a large environment, the incremental costs are somewhat visible, but you won't see how much work it took to get there. In practice, starting from ground zero means identifying a large collection of interesting subsystems, then customizing each one, figuring out how to manage and maintain it, deploying it, documenting local procedures and policies, and then moving on to the next one. This turns out to be a huge amount of one-time effort - which doesn't get streamlined or tuned, beyond becoming part of a particular sysadmin's knowledge base. Boxed Penguin (http://www.boxedpenguin.com/) hopes to come up with a general open-source solution to this problem: we hope to construct a set of tools that allow sites to easily and quickly deploy infrastructure. We'd like to draw your attention to our initial prototype, based on Debian GNU/Linux, available at our website. The prototype demonstrates how a site could combine various components of Debian together to set up an infrastructure. Kerberos acts as a central authentication service. SASL and PAM are used to provide security to applications like LDAP and IMAP. AFS is used as a secure, distributed file system for the site's data. LDAP is used to provide a means for distributing account information. Most of the work in the prototype focused on integrating various components. For example scripts are provided to create all the parts of a user account: Kerberos authentication information, an LDAP password entry, AFS volumes for home directories and an IMAP mailbox. Other scripts provide manipulation of group data. The other hard problem we attempted to solve was the integration of the package installation. Because we were creating a unified infrastructure, we knew more about the desired state of the system than the author of any package. For example, we knew that LDAP would be using Kerberos SASL for authentication and thus didn't need an admin password. We wanted to turn this extra knowledge into a simplified installation experience for our users. In most cases we took advantage of Debconf and gave packages the hints we needed. We hope that by bringing our prototype to the attention of the Debian community, we can focus developer interest on problems that pop up when you try and deploy Debian throughout a site or environment instead of on a single machine. For example, while effective, our technique of stuffing debconf configuration in the boxedp-assumptions package could probably be replaced with a better-architected system for providing additional information to packages about containing frameworks. Also, we're interested in Debian's input on the problems we are trying to solve and on how Debian can best be used to solve these problems. Thanks, --Sam
Re: Boxed Penguin Prototype showcases customization of Debian to build infrastructure server
> "Bernd" == Bernd Eckenfels <[EMAIL PROTECTED]> writes: Bernd> Hello Sam, On Sat, Dec 30, 2000 at 11:27:44PM -0500, Sam Bernd> Hartman wrote: >> In order to actually get something done in an electronic >> office, we need a certain amount of infrastructure. Bernd> Thanks for your work. I'm now looking into it. I think Bernd> besides the packages you are working on, for a prototype, Bernd> most of the work which needs to be done, is have some Bernd> documentation. Background info and so on. This is at least Bernd> needed, until your System is truely Plug+Play. Agreed. We have finite time and wanted to make stuff available for people who were interested in looking at it as soon as was reasonable. We will be working on documentation. My priorities for documentation are explaining enough AFS and Kerberos that Debian people can understand what is going on. It would also be important to document exactly what the packages do. Bernd> Since I currently need to set up a shared Account System on Bernd> a Few Linux Servers (CVS File Server, SourceForge Project Bernd> Management and Bugzilla Tracker) I may have a deeper look Bernd> into writing some docu about it. Let me know if you have any questions.
Re: security in testing
> "Gerfried" == Gerfried Fuchs <[EMAIL PROTECTED]> writes: Gerfried> * Sven Luther <[EMAIL PROTECTED]> [2003-05-16 Gerfried> 13:33]: >> Such a package should be as close to possible to the version >> actually in testing, and not depend on packages and/or versions >> that are not yet in testing. Gerfried> So, you request more or less that every developer Gerfried> should backport fixes themself from the usual new Gerfried> upstream version that fixes the problem (and mostly Gerfried> always have new features too) to the version in testing, Gerfried> which might even be older than just one upstream Gerfried> release, due to usual holdups in the transition. It Gerfried> sounds like you like to have every developer be able to Gerfried> do what the security team does. That requires much skill Gerfried> -- much more than most of us possess! I'd actually hope that you would be capable of doing this sort of back porting for any package you maintain. You should certainly be doing this for packages in stable, giving the security team tested patches, rather than having them do the job of maintaining your packages for you. Sure, that's an ideal. And perhaps you don't have these skills yet and are still working on gaining significant skill with your packages and with the languages they are written in. If so, then you should look for co-maintainers who do have the necessary skill sets to provide security updates for your packages. Even if you completely ignore testing security, anything you can do to reduce the work load on the security team will mean that Debian is less behind on publishing security updates and will better help us serve our users. --Sam
[Stefano =)] Bug#198619: Could not perform configuration on libpam0g
[Please cc me; I'm very behind on -devel] I'm very confused by this bug and am sufficiently busy this week that I'm not going to be able to diagnose it right now. Could anyone who has a chance to do so please look at exactly what is failing from a dependency standpoint? I get the feeling I'm missing something about the interactions between pre-dependencies and dependencies and apt. --- Begin Message --- Subject: Could not perform configuration on libpam0g Package: libpam0g Version: 0.76-12 Severity: normal Tags: sid I have tried to install Debian. Then i 've upraded it to SID. The same thing happens if I try to install Debian directly from SID. Apt-get says "Could not perform immediate configuration on libpam0g". On installations done 1 month ago all the apt-get upgrade things works fine. This bug appears only on installations done in this week. This kind of bug then doesnt allow the installation and the configuration of dozens of packets as kdm, gcc and so on... -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux Lan1-700 2.4.20date27.5 #1 SMP Mon May 26 02:37:37 CEST 2003 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages libpam0g depends on: ii libc6 2.3.1-17 GNU C Library: Shared libraries an ii libpam-modules0.76-11Pluggable Authentication Modules f ii libpam-runtime0.76-11Runtime support for the PAM librar _ MSN Foto: condividi, ritocca e stampa le tue foto online http://photos.msn.it --- End Message ---
Re: Transition: new PAM config file handling in unstable
> "Joey" == Joey Hess <[EMAIL PROTECTED]> writes: Joey> Steve Langasek wrote: >> - It will now be possible to choose md5 vs. crypt passwords at >> install time without violating policy. (Currently, a number of >> conffiles are being modified by maintainer scripts in order to >> enable md5 passwords.) Actually making this process >> policy-compliant will require changes to a number of other >> packages prior to release. Joey> It's great to finally have this. Have you considered doing Joey> something to ease upgrades of systems whose admins chose to Joey> enable md5 passwords via passwd's debconf questions? Unfortunately I have some bad news for you. Karl (login maintainer) and I have decided that there will be no question for sarge and that md5 passwords will be used by default. Once there are tools for automated manipulation of the pam config files, then it will be a configuration decision of libpam-modules what the default passwd configuration for pam_unix is. If debconf is available then the user will be asked; otherwise the default will not be changed. But I don't have time to review a design or to do the design myself for sarge.
Re: Drop KRB4 support from HEIMDAL
Does the krb524 functionality disappear from the KDC if you turn off krb4? If so, that will be a problem for current openafs, although probably not for future openafs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Please test krb5-config in experimental
Last night I uploaded a more or less rewrite of krb5-config to experimental. The goal of this rewrite is to significantly reduce the number of cases where users are asked questions or where the resulting configuration is completely wrong. krb5-config is responsible for generating /etc/krb5.conf, which is used by Kerberos implementations in Debian. Testing is valuable both from people who use Kerberos and those who do not. Testing is most valuable if you purge the krb5-config package before testing. Here is expected behavior: * If your site does not use Kerberos at all, you will almost certainly be prompted for a Kerberos realm name. If you enter a Kerberos realm name that Debian has never heard of, you will be prompted for Kerberos servers. If you enter something like ATHENA.MIT.EDU (case sensitive), then you will not. * If dnsdomainname or hostname --fqdn don't provide reasonable results you'll probably be prompted for a Kerberos realm. * If your site uses Kerberos and your KDC configuration is in DNS, then you will not see any prompts at debconf priority above medium. * If your Kerberos realm does not match your DNS domain, it should do a fairly good job of figuring that out. If it doesn't, then I'd definitely like to hear from you--if nothing else, I can add a static hint. * dpkg-reconfigure krb5-config at priority medium or below should allow you to set the realm and should make sure that Debian knows how to find KDCs for that realm. Thanks for your help. --Sam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Please test krb5-config in experimental
I'd recommend coordinating any such model with the upstream Kerberos implementations and with distributions. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Switching /bin/sh to dash without dash essential
Folks, there was a longish discussion on IRC starting about an hour ago about dash and bash. I agree we want to move the default /bin/sh to /bin/dash. However I'm failing to understand why we want dash to be essential. If I'm not using dash as my /bin/sh why do I need it? If the answer is that we really do want it everywhere independent of what /bin/sh is, that's fine. However, that's not obvious to me. So, a proposal for doing a switch with dash not essential. 1) all /bin/sh shells know about each other. 2) The prerm script for a /bin/sh shell finds another /bin/sh shell and updates the symlink if the current /bin/sh link is the one being removed. 3) The postinst for a /bin/sh shell can update the link if it decides that the installed shell would make a better /bin/sh 4) There is a package `the-shell ' that is essential and pre-depends on one of the /bin/sh shells. Variations: 1) You could have a registration mechanism. My assumption is the set is small enough static is good 2) I assume that package operations cannot take place between calling the prerm script and actually removing the package. If that is false, you could make sure that you are changing the link to a configured shell I really don't mind if we go forward with the current proposal. However, I think I and a lot of other people would appreciate clarity, so far not expressed, about why dash needs to be essential. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
> "Luk" == Luk Claes writes: Luk> We want everyone to use dash by default. If someone does not Luk> want to use the default, they are free to do so, but the Luk> default system shell is supposed to always be on the system. Why? I agree something should always provide /bin/sh. I do not understand why the default system shell should be on the system always. The only argument you've given that I understand is that no one wants to do the work necessary to guarantee that /bin/sh is always present and that the default system shell is not essential. If that's the answer, that's a perfectly fine answer, but *say that*, don't just make assertions. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
> "Siggy" == Siggy Brentrup writes: 8 >> I agree we want to move the default /bin/sh to /bin/dash. >> However I'm failing to understand why we want dash to be >> essential. If I'm not using dash as my /bin/sh why do I need >> it? Siggy> So you are complaining about a small package (installed Siggy> size 224) becoming essential while forcing the embedded ppl Siggy> to work around a monster (installed size 1236); numbers Siggy> taken from my Ubuntu laptop where both are essential, I Siggy> hope only for a limited period of time. Hmm. I don't get any complaint about /bin/dash being the default system shell from my mail. Nor do you see me complaining about having /bin/sh scripts be posixly correct. >> If the answer is that we really do want it everywhere >> independent of what /bin/sh is, that's fine. However, that's >> not obvious to me. Siggy> As long as /bin/sh refuses extensions to posix I agree with Siggy> you, but bashism has been a cuss word for years before Siggy> 2004. I don't understand how this has anything to do with anything I said. Siggy> Maybe "posixly-correct-shell" would be a better name. Siggy> Summing up you suggest making a virtual package - No. I suggest a package with no files but with pre-depends and the essential flag. I don't think a virtual package would work correctly at a technical level, although I'd be happy to be shown to be wrong. Siggy> however Siggy> it's called - essential. While I think I grok your Siggy> intentions, I doubt dpkg will follow, please read Siggy> carefully: Siggy> http://www.debian.org/doc/debian-policy/ch-binary.html#s3.8 Read that long ago and read that word for word just now. Can you help me understand what I'm missing? I don't see how what I'm proposing would violate that. >> I really don't mind if we go forward with the current proposal. >> However, I think I and a lot of other people would appreciate >> clarity, so far not expressed, about why dash needs to be >> essential. Siggy> See debian-policy cited above. Again, please help me understand how what I propose would violate policy. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Steve, let's take a step back and calm down. Are you saying that your objection to engineering a solution where dash doesn't need to be essential is that it's not worth the effort? I *think* that was the point of your message but am not entirely sure. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
>>>>> "Steve" == Steve Langasek writes: Steve> On Fri, Jul 24, 2009 at 04:33:21AM -0400, Sam Hartman wrote: >> Steve, let's take a step back and calm down. >> Are you saying that your objection to engineering a solution >> where dash doesn't need to be essential is that it's not worth >> the effort? I *think* that was the point of your message but >> am not entirely sure. Steve> Yes, that's definitely my position. OK, I'm fine with that. I jumped into this mess because several people asserted that we were making dash essential because it was technically required. As best I can tell that is false. It seems like there was a lot of not listening going on, and a lot of throwing around assertions about what is and is not possible without actually any attention to the accuracy of those assertions. That makes me grumpy and so I got involved. I'm happy with the answer of "making dash essential is easier than not doing so and we have not seen a compelling reason to do something else." Steve> From what I can see, Steve> engineering a solution where dash doesn't need to be Steve> essential isn't worth *any* effort, because IMHO, so far Steve> the arguments for being able to remove dash from the system Steve> appear entirely contrived. I think you're being unfair here. There are arguments about technical cleanlyness and design esthetics that seem reasonable. I don't see that these arguments appear contrived. I'm happy to agree with you though that these arguments don't justify the work. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
krb5 transition: upgrading to krb5 1.6.1
Hi, folks. I've just uploaded krb5 1.6.1 to experimental. This is a new version with enhanced plugin support, support for realm referrals, support for storing Kerberos credentials in the Linux keyring rather than on disk, and generally improvements all around. The one big feature that is missing from the Debian packages is support for the LDAP database backend; that's missing because it requires LDAP 2.3. I'd like to upload this to unstable. It will involve a library version bump; the new libraries are backward but not forward compatible. That is,existing software in Debian that uses public APIs and is linked against the old version is expected to continue to work, but new APIs are introduced so software linked against the new libraries may not run against the old libraries. In other words, no soname change, but shlibdeps get bumped. This is your chance to make sure that your software works against the new version of Kerberos before it makes its way into unstable. This is also your chance to work with me if you're concerned about timing of a shlibdeps change for krb5. Samba is of particular concern because from time to time Samba has used internal APIs and so it breaks when these APIs change. I will not consider it a bug in the krb5 package if internal APIs changing breaks something, although I'll be happy to add conflicts as appropriate. I'll also be happy to try and work with you to figure out how to fix your package if it is using internal APIs. The public APIs are anything in headers installed by libkrb5-dev without defining KRB5_PRIVATE. I'm aware of one issue that impacts nfs-utils. Bug #413838 describe a problem where if your server has a common misconfiguration the 1.6 Kerberos libraries on the client will cause mounts to fail. In particular, the kernel only supports DES encryption for NFS. However, many servers are keyed as if they support more modern encryption such as AES. The client tries to request that only DES be used, but this has been broken in 1.6. So, Kerberos negotiates AES or some other strong encryption and then the server tries to feed this to the kernel and fails. This is a bug and MIT will definitely fix it, but I don't think this should hold up an upload to unstable. There is a work around: properly configure the server. Comments are welcome. --Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: krb5 transition: upgrading to krb5 1.6.1
> "Marcus" == Marcus Better <[EMAIL PROTECTED]> writes: Marcus> Russ Allbery wrote: >> Correct. In general, you never want to have Kerberos keys in >> your KDC for a service principal for enctypes that that service >> doesn't support. Marcus> Is there an easy way to find out which enctypes a service Marcus> supports? (And why does the poor admin have to worry about Marcus> this at all?) It's a function of the software. so, read the documentation for the service. In general, anything that just uses the kerberos libraries supports everything--ssh, samba, imap, http, etc. The exceptions tend to be: * NFS - depends on what the kernel supports and the interface between userspace and kernel. * Telnet - only does des. * OpenAFS - generally takes care of itself, but basically only des. There is protocol work underway so that a service can request keys for itself. This could be combined with some mechanism where packages install templates indicating what enctypes they support and it's all automated. That would require the protocol work be finished and cooperation between the krb5 package and the related other packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#482528: heimdal-clients,krb5-user
Yeah, I'm reasonably sure that alternatives are wrong for kadmin. Editor is intended to be used by a user. Kadmin is often used by users but is also quite often used by scripts. Editors also can all work with text files. It's basically not true that you can use a heimdal kadmin against an MIT realm. I can think of basically no situation where they are interchangable. However I can think of many tasks where I'd be equally happy to use ed as Emacs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#566346: ITP: krb5-appl - Kerberos applications and clients
package: wnpp severity: wishlist owner: hartm...@debian.org name: krb5-appl URL: http://web.mit.edu/kerberos/dist/krb5-appl License: MIT Kerberos license (roughly MIT license plus a requirement that if you modify the software you must mark it as modified) description: Contains fairly ancient versions of telnetd, ftpd, rsh and rlogin that support Kerberos authentication Up until the upcoming Kerberos 1.8 release, these applications were part of the main krb5 tree. They are kind of old and crufty, but attempts to kill them off have met with users (and Debian users) who say they are still valuable in certain environments. Reasons cited include that the code base is simpler than things like ssh, it works and is in use, etc. My belief that the security of the rsh and rlogin programs is quite good, although the telnet and telnetd are well below current security standards. However upstream krb5 doesn't want to maintain the applicatinos as part of the main source tree. So, they are being split out. Since Debian users still want them, I'm going to package them. They've been in Debian for years already, so I think this should not be a problem. To look at the WIP packages see git://git.debian.org/git/pkg-k5-afs/debian-krb5-appl.git pgpzgsy54Ey9T.pgp Description: PGP signature
Re: Bug#155583: radiusd-freeradius history and future
> "Matt" == Matt Zimmerman <[EMAIL PROTECTED]> writes: Matt> I think a single "Will you be using NIS?" question would be Matt> justified; this could provide defaults for md5 vs. crypt Matt> passwords and setuid-ness of unix_chkpwd, and so those Matt> questions could be suppressed by default. I disagree. Debian is sufficiently hard to install that developers of security software I've asked to install it have been frustrated to the point of not using it by the number of questions. I believe adding questions about NIS would be inappropriate. I'd rather see a solution where we have some nis support package that makes unix_chkpwd setuid root when that support package is installed.
Re: Bug#155583: radiusd-freeradius history and future
> "Andreas" == Andreas Metzler <[EMAIL PROTECTED]> writes: Andreas> Steve Langasek <[EMAIL PROTECTED]> wrote: >> On Fri, Nov 14, 2003 at 11:37:45AM -0500, Matt Zimmerman wrote: Andreas> [...] >>> > I'd rather see a solution where we have some nis support >>> package that > makes unix_chkpwd setuid root when that support >>> package is installed. >>> This would be even better. >> Yes, that doesn't sound like a bad solution. Andreas> The package-name is nis, but afaict the only possible Andreas> solutions for this would reqire nis to use Andreas> dpkg-statoveride, whis is imho ugly. cu andreas I think dpkg-statoverride is not too bad in this case. I'll talk to the nis package maintainer and see if that's acceptable. If not, nis could install some flag file. The unix_chkpwd could start with root privs, chuck for this flag file with a hard coded path and drop to shadow if the flag file does not exist. --Sam
Re: Bits from the RM
> "aj" == Anthony Towns writes: aj> or overloaded with work, or, for that matter, fixing compromised Debian aj> servers -- do you think it's desirable and possible to: aj> * for confirmed bugs with a known fix, upload a fixed package aj> within a day or two of the patch been sent to the bug log No, I don't think it is always desirable to do this and certainly my maintinance style doesn't work well with this methodology. The problem is there is a fairly high fixed cost to building, testing and doing release management for a package. It takes me about an afternoon to do a PAM or OpenAFS release even if I change one line. OK, for a one line change I can probably get that down to two hours or so. It's a lot easier for me if I batch bugs together and if I did not do so, I'd be even more behind than I already am. I certainly think that expediting package uploads for RC bugs is a critical responsibility I as a maintainer have. But even if someone else claims to have tested a bug, I'm going to be the one signing the package; I'm taking responsibility. So I must spend the time necessary to understand the fix, confirm the fix and do the release engineering cruft I do for every release. Clearly this can be taken too far; pam is an excellent example of a package where I've let things slip enough that I'm having difficulty digging myself out of the hole. But I think dealing with normal bugs with confirmed fixes in a month or two is much more reasonable than a day or two. I'd feel differently if Debian was my primary job or if I found a style of maintaining packages that worked well for me with this goal.
Re: New maintainer behaviour with NMU and LogJam's hijacking
> "Christian" == Christian Surchi <[EMAIL PROTECTED]> writes: Christian> Ari wrote to me in the end of october to ask me about Christian> my intention about logjam packaging. I had an enormous Christian> backlog and I could not be able to reply. Then he filed Christian> a wishlist bug report (#166993) for the new upstream Christian> release for logjam (4.0.0). Upstream web site Christian> (http://logjam.danga.com) reports that 4.0.0 is Christian> released on 29 Oct 2002. Bug report was sent on 29 Oct Christian> 2002 (!). Christian> On 17 Nov 2002 Ari made a NMU for logjam Christian> 4.0.0+cvs.2002.11.17 and another one a few days after Christian> that date, IIRC, without a note to me. I was handling Christian> bugs for logjam, as you can see in BTS (#165281). Build Christian> failure reported by Junichi Uekawa in that bug was Christian> actually a libcurl-dev bug (#169654). I reported and Christian> maintainer closed with an upload. So, honestly after reading your message, I'm not quite sure what you're complaining about. If you're complaining that the NMU was handled improperly and that the communication/policy should have been better, then it seems you're right. The person performing the NMU has already indicated that they are sorry they didn't follow policy and so unless you can give evidence that you think they will continue to fail to follow policy in future then it seems like an honest mistake. If you're arguing that the NMU shouldn't have been done then I think I disagree. Based on the evidence that you presented, our users and the free software community were better served by having that package updated. And frankly no response from October 29 to mid November seems like enough time that an NMU is reasonable. Yes, the NMU should have been to delayed; yes you should have been contacted. But other than your feelings getting hurt, what was the actual harm done to Debian? And yes, your feelings getting hurt is a real concern; it sucks to be a volunteer and to have someone disrespect your work. But communication problems do happen and it seems reasonable to treat them as communications problems and move on with life.
Re: reliable streams over UDP
> "Russell" == Russell Coker <[EMAIL PROTECTED]> writes: Russell> Do we have a library in Debian that provides reliable Russell> stream based communication over UDP? librx from openafs provides this functionality; it may be somewhat more complexity than you are looking for.
Re: New maintainer behaviour with NMU and LogJam's hijacking
> "Ari" == Ari Pollak <[EMAIL PROTECTED]> writes: >> IIRC Ari has caused upset with NMUs before; xscreensaver, I >> believe. (I express no opinion about whether that upload was a >> good idea or not.) Ari> Didn't you sponsor the upload? Um, so? While yes the sponsor is at fault, it seems that you should also take responsibility for your actions. It seems that after that incident you would have had significant desire to learn and follow the NMU policy. So, I'd like to formally ask: have you read and do you plan to follow generally accepted procedures for future NMUs?
Re: New maintainer behaviour with NMU and LogJam's hijacking
> "Ari" == Ari Pollak <[EMAIL PROTECTED]> writes: Ari> I had been taking the full brunt of the responsibility for Ari> the xscreensaver NMU, but since I was a pre-NM at the time Ari> and sponsors of uploads are supposed to follow Debian policy Ari> as well, he ended up taking most of the responsibility. This Ari> was a similar situation; however, I felt it was necessary at Ari> the time considering the circumstances of the package having Ari> not being updated in over a year and a half despite new Ari> versions being out which fixed bugs, and the lack of any Ari> response from the package maintainer until after the NMU. I Ari> still doubt that I would have gotten any response from the Ari> maintainer at all had it not been for the actual package Ari> upload. Do you specifically agree it was wrong in this instance to upload directly to incoming and not to a delayed queue? In future will you agree to include NMU patches in a bug report to the patch and unless there is a strong reason to do otherwise to upload to a delayed queue? I'm asking you these things in hope of making sure we're on the same page. If you don't agree then I'll try to convince you that you're wrong, but if we are both understanding the best practice the same way, then there's really no more to say.
Re: Kernel update for Debian 3.0/i386
Won't removing kernel-source-2.4.18 create a problem for other arches?
Re: debian-kerberos mailing list down?
Yes, the machine had a bad disk crash and I restored the other services but failed to get debian-kerberos working. IT is up now.
Re: /run/, resolvconf and read-only root
Hi. I noticed that in order to implement your read-only root proposal, you propose to modify the pam package. I'm not really sure I see the justification for read-only /. I can see several possible justifications and some of the possible goals conflict. Until you get general consensus on a specific goal, I'm unlikely to accept such changes if they are submitted to me. As a maintainer I want to be able to look at some statement and answer the following questions: 1) Why are people mounting root read-only? 2) When root is read-only, what information is variable and what information should be immutable? Why is this a reasonable categorization? 3) What information needs to go in /var vs /run? This message not withstanding, I will follow any related changes to policy to the best of my ability.
Re: Bug#191037: /run/, resolvconf and read-only root
>>>>> "Jamie" == Jamie Wilkinson <[EMAIL PROTECTED]> writes: Jamie> This one time, at band camp, Sam Hartman wrote: >> Until you get general consensus on a specific goal, I'm >> unlikely to accept such changes if they are submitted to me. >> As a maintainer I want to be able to look at some statement and >> answer the following questions: Jamie> Hi Sam, Jamie> I've just filed the bug with my patch to pam. My goal is Jamie> not specifically a read-only root (although that may be a Jamie> useful by-product of it) but just to remove any program Jamie> state out of /etc. It is my firm belief that programs Jamie> should not be writing anything to /etc. I'm not sure I agree with this goal. I don't specifically disagree yet, but what you are proposing is a change in UNix semantics. If the rest of the world goes along with this, I will, but I'm somewhat unconvinced it is the right direction. I'd certainly feel better if there were a broader consensus than just Debian before moving in this direction. So, for now I'll sit back and see what other people do about /run.
Re: /run/, resolvconf and read-only root
OK, I think my worst fears are realized. You do actually want to solve all the goals I could have imagined you possibly wanting to try try and solve. I think I am very likely to wait until there is a policy change or at least text that would be good guidelines as a policy change before implementing. The thread seems rather long, and my initial concern is that this seems somewhat under thought through.
Re: kernel-{image,headers} package bloat breaks module builders
[I'm responding to Herbert directly to draw attention to this question and make sure I get a response from him. I have also read the rest of this thread even though I am responding to a fairly early message. ] I'm approaching this as the maintainer of the openafs package, which has a kernel module. I suspect other module package maintainers (PCMCIA, ALSA, etc) will have similar issues. I am concerned about the work that this new kernel image organization may create as well as the additional load on the mirrors potentially placed by this scheme. My assumption is that there will be different modversions for each kernel configuration and that as such, I will need to build binary modules packages against each kernel image. If you can guarantee that this is not the case and will not be the case, then my module-specific concerns go away. Even if you accept that the bandwith usage/mirror load/distribution size increase simply from the kernel packages is acceptable, it is not clear that multiplying the number of packages (and thus to an extent some size multiplier) by the number of module packages is also acceptable. Assuming that the number of module packages no in the kernel continues to increase, which I think likely, the problem will only get worse over time. I also am concerned about the amount of work this creates for module maintainers. Now I have to rebuild a lot of packages both when my upstream sources change and when the kernel images change. I had to do this already, but the effort involved is significantly less. I now have to look and make sure the set of images hasn't changed, retrieve the sources (kernel headers packages don't look enough like source trees to satisfy make-kpkg), configure the kernel trees, which involves grabbing the configs from somewhere (either kernel images or the source package) and build modules for each kernel image. The binary modules packages (alsa and pcmcia) especially although I haven't been doing much better of late tend to have an annoying history of not being in sync with the kernel. I'm concerned that this could make things worse. Personally as a user (who has used stock kernel images wherever possible) I'd much rather have modules packages that work than lots of kernel images to choose from.
Re: kernel-{image,headers} package bloat breaks module builders
> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes: Herbert> I doubt the increase is going to be that significant. Herbert> Since most of these will eventually become part of the Herbert> mainstream kernel or get dropped. I hope that is not actually the trend we see. >> image. Herbert> If your module source is properly constructed, you should Herbert> be able to get away with a build-depends on the No, I can't. kernel-package, which is the exported public interface for building modules on Debian does not support this. Convince Manoj to support kernel-headers packages for modules and you have a much more reasonable argument.
Referring what kernel-images to build to the technical committee?
[cc list is an attempt at stakeholders for this issue. If I missed people, I'm sorry. If I annoyed people by ccing them even though they read the list, well I'm sorry too, but there are a fair number of people who tend to want to be explicitly cc'd when an issue pertains to them.] Summary: Herbert has started building 8 different flavors of kernel-image for i386. These flavors correspond to CPU type; for example there is an appropriate kernel for people with 386 machines to run and an appropriate kernel for people with Athlon machines to run. Several concerns have been brought up on debian-devel, and while I believe that discussion has identified the tradeoffs involved, I do not believe we have reached consensus on a direction to follow. While Herbert is the maintainer of the kernel image for i386,I believe the implications of this issue extend far beyond his packages and thus this is an issue where the interests of different developers may come into conflict. Herbert's changes affect those who maintain module packages like ALSA, PCMCIA, I2C and Openafs. OSome have claimed these decisions affect the installation by CDs by taking up a significant chunk of a CD. Concerns were raised about the bandwith and archive space implications. I believe that since debian-devel doesn't seem to be able to come to consensus on this issue, we should refer the issue to a smaller group than will fairly consider all the tradeoffs involved and come up with a global direction for the project on this issue. One concern I have with Herbert's decision is that the i386 architecture is taking what appears to be a different direction than other architectures. I'd rather have a global direction than have each architecture go off and do their own thing. Naturally, the tradeoffs may affect different architcetures differently, so we may end up with a different set of kernel images for each architecture, but the relative weights of the tradeoffs and our overall goals could be decided globally. I propose the technical committee as an appropriate form to decide on this issue, but I am open to other fora. I'd like to summarize my understanding of the tradeoffs that we have identified in the debian-devel discussion so that if we do turn this issue over to the committee, they will know what concerns we have already identified. Please add to the following list if I have missed something. Note that I'm not trying to weight the tradeoffs here; I'm trying to be fairly objective. Comments of the form "That's not important," are not appropriate at this time. cThe goal is to identify the issues and let whatever group we send this to evaluate the weights of the issues. Presumably such a group would ask for public comment on the weightings if they would find that comment useful. performance: By having images optimized for each processor on i386 users should see better performance. I don't believe performance numbers were quantified in the discussion but quantifying performance is probably important to evaluating this tradeoff. Encouraging stock kernel use: By having appropriate stock kernels that meet people's needs we may encourage users to use the kernels. This provides better/more consistent testing of our configurationas well as easier upgrade. Herbert indicated that previosly he did not even use his own kernel image packages because they were not optmized. This should be considered separately from performance, because even if there is not a significant performance win, if many more users would use the stock kernel, the advantages of doing so might justify the change. That is, the perception of whether optimized kernels are needed influences whether people use them and the value of this perception may be differently weighted than the actual reality of the performance. Should build custom: Some argumed that users should build a custom kernel and the distribution was doing them a disservice by trying to provide kernels that met their needs. Archive Size: The more kernel images we have, the more space it takes up in the archive. CD Size: Craig (I believe) claimed that the new kernel images take up a significant fraction of a CD. If the number of CDs a typical users actually has to look at gets too big, then Debian will be an inconvenient distribution. It's all fine that have lots of CDs with optional software on them that you don't need, but if you will need a CD of kernels as well as a base CD, (or if the base CD overflows because of kernels), then that could suck. People already complain we need too many floppies to boot; they would probably be more upset if you need more than 1 CD in typical cases. Bandwith: So, moving these kernel images around takes up network resources. Consider resources used to upload the image, resources used to mirror the images resources used to download the images. I don't actually think resources used to download the images changes much, but we should evaluate all network re
RFC: Thoughts on building modules
One thing that strikes me as excellent about Debian is the build system. The autobuilders and tools make it very likely that package builds are reproducible and a variety of tools like debhelper make it easier to do the "right thing" in many circumstances than doing something wrong. I've come away from this experience convinced that it is very important to have good tools for common tasks. Sadly, I don't think building module packages for modules not in the kernel lives up to the high standards of the rest of the Debian build process.,especially for module packages to work with stock kernels and be uploaded to the Debian archive. These concerns are mostly technical and are to a great extent independent of how many kernel images we have, although obviously if there are a lot of kernel images then autimation is even more important. Manoj's kernel package provides an excellent tool for building custom kernels for end users. It also provides an adequate tool for end users building modules for their kernels. The modules are shipped generally as tarballs that are unpacked into /usr/src/modules. Then, kernel-package generates .debs for each of these modules when make-kpkg modules_image is run. The make-kpkg modules target is intended for maintainers and is somewhat useful. However, it has several shortcomings for official modules package. Because it is run out of make-kpkg it is intended to build multiple modules for a single kernel version. It turns out what maintainers probably want is to build multiple versions of the same module for different kernel versions at once. Also, module maintainers probably want to build on multiple architectures. With make-kpkg this means having an account on multiple architectures. It would be really nice to be able to take advantage of the buildds to build modules for other architectures just as the build non-module packages. So, having established that we have some work to do, let's step back and think about what is going on when you try and build modules. Each architecture has a set of kernel-images that are current. Users running a stock kernel are expected to install one of these images. You as a module maintainer want to make it so that users can install a version of your module for the stock kernel image they have selected. So, for each architecture you want to find out what the current set of stock kernel images are. Normally, there will be at least one old kernel version supported and one or more new kernel versions; there may be multiple flavors/subarchitectures of each kernel version. There is currently no good way to find out what kernel images are available. You could grep through the packages file, but that doesn't exclude images awaiting removal or images for special purposes that are not stock images. Assuming you do manage to find out what stock images exist, you need to build your module for them. There are roughly two approaches you could take: using kernel headers or using kernel source. Apparently some/many modules require a kernel source tree; a kernel headers tree is insufficient. I don't actually know how common this is; I believe the module I maintain could successfully build against a kernel headers package if I tried. If you are using make-kpkg to build your modules then you must have a source tree. For i386 apparently the preferred way (according to kernel-image-i386 maintainer) is to use kernel headers. That may work fine for i386, but other architectures (sparc and m68k were checked) only provide one kernel headers package, not one kernel headers per flavor. This is problematic because at least according to the i386 kernel-image maintainer, we cannot guarantee that modversions symbols will be the same between flavors, so we cannot guarantee that modules built against one set of kernel headers will work with other kernel flavors. So, let's assume you want source for your kernel. On i386 you're all set; you basically just download the kernel source and build against it. On other platforms, it is more problematic. For Sparc, there are patches applied to the kernel in the kernel-image-2.2-sparc package for example. PPC, m68k and ARM appear to actually generate kernel-patch packages for their architectures although I have seen them get out of sync with the kernel images available in the archive. Normally these patches don't seem to affect interfaces my modules care about, so I can be sloppy and just download the kernel source package. However, if we are talking about reproducible builds, these patches matter, or at least an assertion that they will never affect module builds. There's also the issue of dependencies. When building most packages one person is driving the need for rebuilds by changing the source package. Sometimes some library or policy will change and you'll have to rebuild even though there are not source changes you would like to make. However this is fairly rare, and tends not to be arch
Re: RFC: Thoughts on building modules
> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes: Herbert> BTW, this is how the kernel images are organised on Herbert> alpha/i386/sparc. This is misleading. The kernel-image-*-arch packages are much simpler because they do not depend both on a kernel source package and on a module deb package. Also, note that this maximizes work for the module maintainer, which is a valid thing to do, although I'd like to note that we seem to get a much better balance for other porting issues. Finally, it means that I cannot release a module for a new arch without package-installation access to that arch. It's my understanding that source-only uploads only work if there is an existing binary package that depends on the source package being installed, which is not the case for new package source uploads.
Formal request for review: [Sam Hartman ] Referring what kernel-images to build to the technical committee?
Hi. I posted the following message to debian-devel last night and have received agreement with the summary and apparently (it was not explicitly stated) with the committee as a forum from Craig and Herbert. Thus I'd like to ask you to look at this issue. There has been some other discussion in the thread that the following message starts and others have brought up some issues I did not cover in my summary. I recommend reading this discussion. If there are any administrative hoops I need to jump through please let me know. --- Start of forwarded message --- Resent-Date: Wed, 25 Apr 2001 20:30:46 -0400 (EDT) Date: Wed, 25 Apr 2001 20:30:31 -0400 (EDT) Message-Id: <[EMAIL PROTECTED]> To: debian-devel@lists.debian.org CC: [EMAIL PROTECTED], [EMAIL PROTECTED] (module package maintainers), [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] (kernel-image-i386 maintainer), [EMAIL PROTECTED] (concerned about package size) Subject: Referring what kernel-images to build to the technical committee? Reply-to: debian-devel@lists.debian.org From: Sam Hartman <[EMAIL PROTECTED]> Resent-Message-ID: <[EMAIL PROTECTED]> Resent-From: debian-devel@lists.debian.org Resent-Sender: [EMAIL PROTECTED] [cc list is an attempt at stakeholders for this issue. If I missed people, I'm sorry. If I annoyed people by ccing them even though they read the list, well I'm sorry too, but there are a fair number of people who tend to want to be explicitly cc'd when an issue pertains to them.] Summary: Herbert has started building 8 different flavors of kernel-image for i386. These flavors correspond to CPU type; for example there is an appropriate kernel for people with 386 machines to run and an appropriate kernel for people with Athlon machines to run. Several concerns have been brought up on debian-devel, and while I believe that discussion has identified the tradeoffs involved, I do not believe we have reached consensus on a direction to follow. While Herbert is the maintainer of the kernel image for i386,I believe the implications of this issue extend far beyond his packages and thus this is an issue where the interests of different developers may come into conflict. Herbert's changes affect those who maintain module packages like ALSA, PCMCIA, I2C and Openafs. OSome have claimed these decisions affect the installation by CDs by taking up a significant chunk of a CD. Concerns were raised about the bandwith and archive space implications. I believe that since debian-devel doesn't seem to be able to come to consensus on this issue, we should refer the issue to a smaller group than will fairly consider all the tradeoffs involved and come up with a global direction for the project on this issue. One concern I have with Herbert's decision is that the i386 architecture is taking what appears to be a different direction than other architectures. I'd rather have a global direction than have each architecture go off and do their own thing. Naturally, the tradeoffs may affect different architcetures differently, so we may end up with a different set of kernel images for each architecture, but the relative weights of the tradeoffs and our overall goals could be decided globally. I propose the technical committee as an appropriate form to decide on this issue, but I am open to other fora. I'd like to summarize my understanding of the tradeoffs that we have identified in the debian-devel discussion so that if we do turn this issue over to the committee, they will know what concerns we have already identified. Please add to the following list if I have missed something. Note that I'm not trying to weight the tradeoffs here; I'm trying to be fairly objective. Comments of the form "That's not important," are not appropriate at this time. cThe goal is to identify the issues and let whatever group we send this to evaluate the weights of the issues. Presumably such a group would ask for public comment on the weightings if they would find that comment useful. performance: By having images optimized for each processor on i386 users should see better performance. I don't believe performance numbers were quantified in the discussion but quantifying performance is probably important to evaluating this tradeoff. Encouraging stock kernel use: By having appropriate stock kernels that meet people's needs we may encourage users to use the kernels. This provides better/more consistent testing of our configurationas well as easier upgrade. Herbert indicated that previosly he did not even use his own kernel image packages because they were not optmized. This should be considered separately from performance, because even if there is not a significant performance win, if many more users would use the stock kernel, the advantages of doing so might justify the change. That is, the perceptio
Formal request for review: [Sam Hartman ] Referring what kernel-images to build to the technical committee?
Hi. I posted the following message to debian-devel last night and have received agreement with the summary and apparently (it was not explicitly stated) with the committee as a forum from Craig and Herbert. Thus I'd like to ask you to look at this issue. There has been some other discussion in the thread that the following message starts and others have brought up some issues I did not cover in my summary. I recommend reading this discussion. If there are any administrative hoops I need to jump through please let me know. --- Start of forwarded message --- Resent-Date: Wed, 25 Apr 2001 20:30:46 -0400 (EDT) Date: Wed, 25 Apr 2001 20:30:31 -0400 (EDT) Message-Id: <[EMAIL PROTECTED]> To: debian-devel@lists.debian.org CC: [EMAIL PROTECTED], [EMAIL PROTECTED] (module package maintainers), [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] (kernel-image-i386 maintainer), [EMAIL PROTECTED] (concerned about package size) Subject: Referring what kernel-images to build to the technical committee? Reply-to: debian-devel@lists.debian.org From: Sam Hartman <[EMAIL PROTECTED]> Resent-Message-ID: <[EMAIL PROTECTED]> Resent-From: debian-devel@lists.debian.org Resent-Sender: [EMAIL PROTECTED] [cc list is an attempt at stakeholders for this issue. If I missed people, I'm sorry. If I annoyed people by ccing them even though they read the list, well I'm sorry too, but there are a fair number of people who tend to want to be explicitly cc'd when an issue pertains to them.] Summary: Herbert has started building 8 different flavors of kernel-image for i386. These flavors correspond to CPU type; for example there is an appropriate kernel for people with 386 machines to run and an appropriate kernel for people with Athlon machines to run. Several concerns have been brought up on debian-devel, and while I believe that discussion has identified the tradeoffs involved, I do not believe we have reached consensus on a direction to follow. While Herbert is the maintainer of the kernel image for i386,I believe the implications of this issue extend far beyond his packages and thus this is an issue where the interests of different developers may come into conflict. Herbert's changes affect those who maintain module packages like ALSA, PCMCIA, I2C and Openafs. OSome have claimed these decisions affect the installation by CDs by taking up a significant chunk of a CD. Concerns were raised about the bandwith and archive space implications. I believe that since debian-devel doesn't seem to be able to come to consensus on this issue, we should refer the issue to a smaller group than will fairly consider all the tradeoffs involved and come up with a global direction for the project on this issue. One concern I have with Herbert's decision is that the i386 architecture is taking what appears to be a different direction than other architectures. I'd rather have a global direction than have each architecture go off and do their own thing. Naturally, the tradeoffs may affect different architcetures differently, so we may end up with a different set of kernel images for each architecture, but the relative weights of the tradeoffs and our overall goals could be decided globally. I propose the technical committee as an appropriate form to decide on this issue, but I am open to other fora. I'd like to summarize my understanding of the tradeoffs that we have identified in the debian-devel discussion so that if we do turn this issue over to the committee, they will know what concerns we have already identified. Please add to the following list if I have missed something. Note that I'm not trying to weight the tradeoffs here; I'm trying to be fairly objective. Comments of the form "That's not important," are not appropriate at this time. cThe goal is to identify the issues and let whatever group we send this to evaluate the weights of the issues. Presumably such a group would ask for public comment on the weightings if they would find that comment useful. performance: By having images optimized for each processor on i386 users should see better performance. I don't believe performance numbers were quantified in the discussion but quantifying performance is probably important to evaluating this tradeoff. Encouraging stock kernel use: By having appropriate stock kernels that meet people's needs we may encourage users to use the kernels. This provides better/more consistent testing of our configurationas well as easier upgrade. Herbert indicated that previosly he did not even use his own kernel image packages because they were not optmized. This should be considered separately from performance, because even if there is not a significant performance win, if many more users would use the stock kernel, the advantages of doing so might justify the change. That is, the perceptio
Re: RFC: Thoughts on building modules
>>>>> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes: Herbert> Sam Hartman <[EMAIL PROTECTED]> wrote: >> This is misleading. The kernel-image-*-arch packages are much >> simpler because they do not depend both on a kernel source >> package and on a module deb package. Also, note that this >> maximizes work for the Herbert> How does that make it more complex? It has two sets of factors driving changes. Tools designed to make this maintaince process easier will be more complex than tools designed to make maintaining kernel source packages for a single arch easy. Well, at least you have a complexity vs manual effort tradeoff. I argue that currently the tradeoff is way too far on the side of manual effort and that we need more complexity. Note that all of the solutions I discussed involved this complexity. I was objecting to your implication that setting up module source packages was as simple as setting up arch-specific kernel image packages, not saying the complexity was unnecessary. >> issues. Finally, it means that I cannot release a module for a >> new arch without package-installation access to that arch. >> It's my understanding that source-only uploads only work if >> there is an existing binary package that depends on the source >> package being installed, which is not the case for new package >> source uploads. Herbert> Well, kernels/modules have traditionally required this Herbert> kind of access. There's no way around it I'm afraid. -- I'd buy that if all three potential directions I presented in my first message weren't ways around this. Module packages really aren't that different from normal packages; there is a lot of kernel code that is not arch specific. I agree that kernel packages are arch specific and you aren't going to get away from that. However, my point is partially that module packages have different constraints that kernel packages.
Re: openldap question and possible feature conflict
> "Brian" == Brian May <[EMAIL PROTECTED]> writes: Brian> I have got a bug report #95246 requesting Heimdal be Brian> compiled against openldap2. This would enable being able to Brian> store the Kerberos database in the openldap database. All Brian> data is stored in LDAP encrypted, so even if somebody Brian> accesses the openldap database, the Kerberos data is not Brian> compromised. Please don't do this. The performance is fairly bad and the security implications are not so great. (My comments on performance come from Joda forwarded through Assar). For discussions of security, please see discussion on kerberos@mit.edu (archived off http://web.mit.edu/kerberos) and minutes of the last two Kerberos working group meetings at IETF. If you do this, please do not store keys in the database.
Re: Proposing task-debian
> "Joey" == Joey Hess <[EMAIL PROTECTED]> writes: Joey> If these tools become widly enough accepted that we think Joey> everyone should have them available by default, we can make Joey> them standard priority. In the new universe (debbootstrap, tasksel, etc) where a user might never run dselect, what makes sure that in the default configuration, standard priority packages get installed? I seem to be running into a lot of systems I install that end up without ed or emacs20. It's my understanding that if I pick the defaults I really ought to end up with these. [I'm not interested in a flamewar about whether emacs20 should be standard; currently it is.]
Re: postgresql and libssl - Bug#95146
> "Petr" == Petr Cech <[EMAIL PROTECTED]> writes: >> Since this question is currently being referred to legal >> advice, do you want me to move postgresql into non-us, which >> will force any packages depending on it into non-us too, or >> should I leave it alone pending resolution of the legal >> question? Petr> oohhh. it the crypto really necessary? I think, that Petr> building without libssl installed fix it Yes, for most applications, security is really necessary. For most security models, that does mean crypto. We should be encouraging maintainers to help Debian be secure, even if that means moving many packages into non-us.
Re: dm management of wm listings (kdm/gdm/etc..)
> "Ivan" == Ivan E Moore <[EMAIL PROTECTED]> writes: Ivan> Solution?: create a program (update-dm?) that would pull Ivan> the current list of window/session-managers installed on the Ivan> system and build the appropriate config files for whichever You should probably consider whether this program ought to simply be update-menu. Is there any reason not to have a menu of window managers? You could then have the method for the DM only pull window managers. Note this is a serious question; there may well be many good reasons this is a bad idea.
Re: build depends on kernel-headers
> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes: >>> "Aaron" == Aaron Lehmann <[EMAIL PROTECTED]> writes: Aaron> So you're saying it's better to hardcode syscall numbers Aaron> and stuff than using the kernel headers? Sre... Manoj> We already have a process for packages that actually Manoj> do need kernel headers, and are thus dependent on Manoj> particular kernel versions. We do? please explain what it is. Herbert produces kernel headers packages for all flavors of kernels he produces. I do not believe the other arches do this.
Re: build depends on kernel-headers
>>>>> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes: Herbert> Sam Hartman <[EMAIL PROTECTED]> wrote: >> We do? please explain what it is. Herbert produces kernel >> headers packages for all flavors of kernels he produces. I do >> not believe the other arches do this. Herbert> You obviously weren't listening to me when I explained Herbert> this in the bloat thread. If you aren't compiling a Herbert> kernel module, then the flavoued kernel headers packages Herbert> do not exist for you, period. I thought Manoj's comments applied to modules.
Re: build depends on kernel-headers
> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes: Herbert> I won't look at all of them as this is really the Herbert> upstream maintainer's job. This brings up an interesting point. While we should work with upstream maintainers to fix these problems, we should also try to avoid making these programs harder to build on Debian than other distributions. If other distributions are still making headers available in such a way that existing software builds, and we do not, then we make lives harder for both our users and maintainers. Yes, it may be more correct, but we need to be carefule not to correct our users into frustration. Managing careful transition plans is also an important part of correctness.
RFC: Potential solution for module building
So, a week or so ago, I asked for comments on some problems I've been having with the Debian kernel modules build system for modules not in the Linux source tree. I'm only dealing with modules for upload to Debian. The make-kpkg solution seems to work for individuals building modules for their own systems, and any areas where it does not work can probably be addressed with kernel-package bugs. I've received a few comments and have also had several informative side discussions on the issue on IRC and with a few people in person. I believe I'm ready to look at proposing a solution to the problem. First, here is what I want to accomplish: I want to provide a mechanism for building binary modules for upload to Debian in an automated manner. The set of kernel images to build for needs to be determined by the architecture maintainers. For Sparc, modversions are not used so you can probably build one sparc and one sparc64 module. For i386, you need to build a module for each kernel image flavor. Ben wants architecture maintainers to be able to build binary modules to go along with their kernel images. Herbert implied he'd rather see module maintainers set up source packages for each architecture. I tend to be somewhere in between. So, it seems that a solution that allows architecture maintainers to build modules and that allows module maintainers to build modules would be preferable. IN most cases you would choose on a module-by-module basis whether it would be built by the architecture maintainer or by the module maintainer. I propose creating a set of tools--say call them debmodbuilder--to help in building modules. The primary tool would be a script to take a modules config file and an image-set config file and to build modules. The modules config file would specify which modules to build and which packages contained the source tarball. This file would be located in the debian directory of source packages. Architecture kernel-image maintainers could add a module config file to their kernel-image packages to say what modules to build. Module maintainers who maintain modules not build by the kernel-image maintainers could include trivial module config files in the debian directory of their source package to identify that their module should be built. A sample of what a module config file might look like is included near the bottom of the message. The image-set config file would specify which kernel images to build against. For each image you would specify the kernel version and subarchitecture. For example, Herbert's 386 kernel might specify a version of 2.4.3 and a subarchitecture of 386. The subarchitecture is part of the module package name, but not of the module installation location under /lib/modules. The kernel config file would also specify which set of kernel headers to use; this is required because for some architectures like sparc, kernel headers are reused for multiple subarchitectures. This file would be included in the debian directory of the architecture-specific kernel-image source package. It would also be installed as discussed shortly. A sample of what this file might look like is included at the end of the message. In addition to potentially using the tool to help build modules, the kernel image source package would also include a binary package that depended on all the appropriate kernel headers and included a copy of the kernel config file for module builders to use. This would require kernel image maintainers for architectures with binary modules to create such kernel image configuration tool. I'd be happy to work with people to help build automation for this into existing kernel image source packages. Then, kernel image maintainers could build any modules they want to build for their arch, as well as making it is for module builders to build for their arch. I'd also be happy to write the module building tools: I envision tools to: * Build the module debs given a module and image-set config file, integrating the built debs into debian/files. This could be called from the debian/rules file for architecture-specific kernel-image source packages and from the debian/rules files for source packages that module maintainers maintain to build their modules. * Generate appropriate build-depends for module source packages given a module config file. * Generate depends: line for the binary package including the kernel config file given a image-set config file. * Generate stanzas for debian/control given a image-set and module config file set. I'm not sure this is useful, although it could allow you to get the binary line in your source dsc file right. Comments? If I write these tools and they don't suck, will people be willing to try using them? Sample modules config file: Module: openafs # untars into modules/openafs Source-Package: openafs-modules-source TarFile: /usr/src/openafs.tar.gz #sources of module live here Archi
Re: RFC: Potential solution for module building
>>>>> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes: Herbert> Sam Hartman <[EMAIL PROTECTED]> wrote: >> for needs to be determined by the architecture maintainers. >> For Sparc, modversions are not used so you can probably build >> one sparc and one sparc64 module. For i386, you need to build >> a module for each Herbert> I haven't read the whole message yet. But I'd just like Herbert> say that modversions is not the reason to compile modules Herbert> for each kernel-image package. Modversions help you to Herbert> identify when you need to do that. Sure, agreed. I was being sloppy. Basically it's up to you as a kernel-image maintainer to decide what sets of modules you need to build against. Since we are looking for an automated solution, we're going to have to be conservative and may end up building slightly more modules than we strictly need, but we will at least have modules that work.
Re: build depends on kernel-headers
>>>>> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes: Herbert> Sam Hartman <[EMAIL PROTECTED]> wrote: >> This brings up an interesting point. While we should work with >> upstream maintainers to fix these problems, we should also try >> to avoid making these programs harder to build on Debian than >> other distributions. If other distributions are still making >> headers available in such a way that existing software builds, >> and we do not, then we make lives harder for both our users and >> maintainers. Yes, it may be more correct, but we need to be >> carefule not to correct our users into frustration. Managing >> careful transition plans is also an important part of >> correctness. Herbert> This is not something that we're doing. This is a Herbert> decision taken by the upstream kernel maintainer(s). First, it wouldn't be the first time that we had to jump through extra hoops to make upgrading easy simply because an upstream didn't do their job right. However, I don't think there's anything we can really do in that part of the problem space. We are making active decisions related to this problem. Ben is actively removing headers not used by libc6-dev; there may be other things happening as well related to these issues. If this has the net effect that I as an end user find I can't build significant sets of software on Debian without significant effort, but I can build the same software on a distribution that isn't as agressive at being correct with its libc, then we have not served our user community. We do need to encourage people to transition, but we do not want to do so in a manner that causes people to get the impression that Debian is less functional for their needs.
Re: build depends on kernel-headers
>>>>> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes: >>> "Sam" == Sam Hartman <[EMAIL PROTECTED]> writes: >>>>> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes: >>>>> "Aaron" == Aaron Lehmann <[EMAIL PROTECTED]> writes: Aaron> So you're saying it's better to hardcode syscall numbers Aaron> and stuff than using the kernel headers? Sre... Manoj> We already have a process for packages that actually do Manoj> need kernel headers, and are thus dependent on particular Manoj> kernel versions. Sam> We do? please explain what it is. Manoj> We call these packages kernel modules; and we have a Manoj> process by which you inform make where the relevant kernel Manoj> headers are to be found. make-kpkg automates that somewhat Manoj> (and make-kpkg can be used for packages that are not Manoj> kernel-modules, you know). How do I use make-kpkg to build modules with a kernel headers package? I don't see how to do this in the manual, and when I try obvious things I get told that the kernel headers directory is not a kernel source directory. If you had said that we have a process for building modules from kernel sources I'd agree with you, but currently I don't think we have such a process for headers.
Re: Questions to testing/unstable
> "Henrique" == Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: Henrique> AFAIK, I cannot do that. If I build against testing, I Henrique> help the breakage by adding yet another package that Henrique> depends on the outdated libraries that are in testing, Henrique> therefore helping those libraries to be held instead of Henrique> upgraded. It's a positive feedback loop. Unless I Henrique> misunderstand testing, obviously, and such loop does not Henrique> exist. Or your could do shared library versions correctly so both versions can exist. I realize it is hard, especially if your upstream is not committed to multiple major versions/versioned symbols/whatever is necessary, but it is the correct solution and you can certainly strive for it.
Re: moving a package from non-US/main to main?
> "Marc" == Marc Haber <[EMAIL PROTECTED]> writes: Marc> On Sun, 2 Sep 2001 22:49:00 +0200 (CEST), Santiago Vila Marc> <[EMAIL PROTECTED]> wrote: >> However, you can repackage the .orig.tar.gz source and remove >> the non-US bits from it. Then you could upload both source and >> binaries to main. Marc> That would break the principle of pristine sources, though. So, that's not a principle, it's a somewhat desirable goal. For some licenses it may be necessary, but there are many reasons you might have to change the upstream tarball, including for example DFSG problems with part of a program. Marc> Can anybody confirm that CAST is not among the non-USable Marc> offenses? First, CAST is actually going to be less exportable than SHA. CAST is a crypto system family, SHA is a hash. I think software that only uses SHA is likely not to fall under ECCN 5d002 or 5e002 of the US Commerce Control List and thus doesn't fall under the annoying crypto stuff. I.E. I suspect you could have stuck the SHA only version in main, but need to stick SHA+CAST in non-us. Marc> Greetings Marc Marc> -- -- !! No courtesy Marc> copies, please !! - Marc Haber | " Questions are the | Marc> Mailadresse im Header Karlsruhe, Germany | Beginning of Marc> Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Marc> Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29 Marc> -- To UNSUBSCRIBE, email to Marc> [EMAIL PROTECTED] with a subject of Marc> "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Which versions of libraries are developers supposed to compile against?
> "Jules" == Jules Bean <[EMAIL PROTECTED]> writes: Jules> This seems a step back from the old freeze procedure, where Jules> you could upload to frozen (and, I assume, auto-builders Jules> were building against frozen) Well, once your library and all dependencies are frozen you can act as before, uploading to frozen. I assume that autobuilders will build uploads for frozen parts of frozen, or at least we'll have lots of problems if they do not. But yes, our release manager has decided to trade off staggering the freeze/giving optional/ extra more time against the flexibility of library maintainers. It is his job to make these calls and really I think our users come out ahead on the new freeze policy.
Re: moving a package from non-US/main to main?
>>>>> "Marc" == Marc Haber <[EMAIL PROTECTED]> writes: Marc> On 02 Sep 2001 23:18:56 -0400, Sam Hartman Marc> <[EMAIL PROTECTED]> Marc> wrote: >>>>>>> "Marc" == Marc Haber >>>>>>> <[EMAIL PROTECTED]> writes: Marc> On Sun, 2 Sep 2001 22:49:00 +0200 (CEST), Santiago Vila Marc> <[EMAIL PROTECTED]> wrote: >> >> However, you can repackage the .orig.tar.gz source and >> remove >> the non-US bits from it. Then you could upload both >> source and >> binaries to main. >> Marc> That would break the principle of pristine sources, though. >> So, that's not a principle, it's a somewhat desirable goal. >> For some licenses it may be necessary, but there are many >> reasons you might have to change the upstream tarball, >> including for example DFSG problems with part of a program. Marc> I see. So that is not a real problem. Do I simply tar the Marc> sources with non-US bits removed and call that tar Marc> foo.orig.tar.gz, or is there a special procedure? Yes, although you should say what you've done in debian/copyright in the diff. Really, though I would rather see software stay in non-us than lose functionality. Of course this doesn't matter for this case.
Re: build daemon architectures
> "Randolph" == Randolph Chung <[EMAIL PROTECTED]> writes: >> The Automatic Package Building System page[1] lists the build >> daemons with web pages. It does not list those without, >> however. Since my latest libcdaudio packages are considered >> out of date on i386, I was wondering if a build daemon exists >> for that architecture. If you know of a build daemon for an >> architecture other than arm, m68k, powerpc, or sparc (even if >> it doesn't have a Randolph> i386, mips, mipsel, ia64, hppa, alpha, s390 all have Randolph> autobuilders. IT would be nice if we could also list which of those have non-us autobuilders.
Bug#128888: ITP: ssh-krb5 - A version of OpenSSH patched to support Kerberos Authentication
package: wnpp severity: wishlist Hi. AS discussed below, I intend to package OpenSSH using the current Debian sources with patches to allow krb5 authentication. I will use the patches available at http://www.sxw.org.uk/computing/patches/openssh.html. These patches attempt to comply with draft-ietf-secsh-gss-keyex along with some of the more common other types of Kerberos authentication. The Kerberos packaging will follow guidelines agreed on by Debian kerberos package maintainers and included in /usr/share/doc/krb5-config/packaging-guidelines.txt.gz. The package will likely build withe either Heimdal or MIT Kerberos, although the version uploaded to non-us will be compiled against MIT Kerberos. Below is previous discussion on this package attempting to justify the need for yet another ssh package in Debian. --- Begin Message --- Hi. I sent mail to [EMAIL PROTECTED] about tthis a while back. I heard no response. It is my intent to ITP ssh-krb5 as a package at priority extra that conflicts with the existing ssh. I will probably store configuration files in /etc/ssh rather than /etc/ssh-krb5 because I believe that some time after woody releases we will be able to get these changes folded into OpenSSH upstream and then hopefully into the main Debian ssh packages. This is a heads up for the Kerberos and Ssh community in Debian. --- Begin Message --- So I suspect I'm not the only one on this list that would like Kerberized ssh in Debian. However ssh is somewhat of a moving target; here are the things we probably want to support: * The ssh.com sshv1 Kerberos5 protocol (used by MIT among others) * The ssh Kerberos4 protocol (used by CMU and others) (Is this the same as the krb4 in openssh?) * draft-ietf-secsh-gss-keyex (standards track protocol) * The krb5 support in sxw's patches to Openssh 2.5.2 (does anyone use * this? no would be a really really convenient answer) I propose that I talk to the ssh maintainer and get permission to ITP an ssh-krb5 that supports the first three listed protocols.I believe code will exist to do that fairly soon. I'd rather do that than fold in Kerberos support because it is so much of a moving target right now and because it would be asking the ssh maintainer to maintain a lot of third-party patches. Reasonable? ___ Debian-kerberos mailing list [EMAIL PROTECTED] http://mailman.boxedpenguin.com/mailman/listinfo/debian-kerberos --- End Message --- --- End Message ---
Bug#142065: ITP: cyrus2-sasl-mit - MIT Kerberos modules for sasl2
package: wnpp severity: wishlist I'm planning on packaging libsasl2-gssapi-mit, a version of the GSSAPI plugin for libsasl2 compiled against MIT Kerberos. This package has the same source as cyrus-sasl2, but different build environment and options. It's not really possible to avoid having two source packages, even given crypto-in-main. This is the same setup we have for libsasl7 for all the same reasons. I sent the SASL maintainer mail a while back and received no objection. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)
[There are some questions at the end; comments would be greatly appreciated on the questions if you have ever been involved in the release process or library transitions before. This is my first big transition.] The libkrb53 package (providing the MIT Kerberos shared libraries) has been stable for the last eight years. However, in 2006, MIT announced its plans to remove support for the Kerberos 4 protocol [1]. Kerberos 5 has been the current version of Kerberos since the mid 1990s; increasing security and code quality concerns motivated MIT's decision. In the upcoming 1.7 release of MIT Kerberos, the code will be removed. However, for well over 10 years, MIT Kerberos supports building with the Kerberos 4 code disabled. [1] http://web.mit.edu/kerberos/krb4-end-of-life.html I believe in managing things in small chunks. I'd rather handle removing Kerberos 4 independently of upgrading to a new version of Kerberos (1.7). As such, I plan to turn off Kerberos 4 in Debian unstable in the very near future. Only two packages in Debian actually rely on krb4 support: kstart and zephyr. In the case of kstart, I believe disabling krb4 support will be relatively simple. In the case of zephyr, things are more complicated because most of the zephyr community uses krb4 to authenticate access. The zephyr maintainer is well aware of the krb4 issue and has been working to resolve it. I do not believe keeping krb4 support in Debian for zephyr makes sense, especially since it would definitely be removed on the 1.7 release of krb5. Two additional packages (barnowl and owl) link against libkrb4 but use no symbols from that library. However, things are more complicated. The krb4 and krb5 shared libraries are all in the libkrb53 package. Since libraries will be removed, that package name needs to change. I propose to split out each library into a single package per our current best practice. See the version of the krb5 package in experimental for specific details of the split. I propose to upload a version of krb5 to unstable in about a week that is basically identical to the krb5 in experimental. I will include some debconf fixes, a news file, and other minor changes. See the experimental branch of [2] for ongoing work towards this upload. [2] git://git.debian.org/git/pkg-k5-afs/debian-krb5.git Unfortunately, there are a lot of packages that reverse depend on libkrb53. All of these packages will need to be rebuilt. Here's where I need sanity checking. I assume that after the new krb5 has made its way into unstable and has built on all arches, I should send mail to all these packages asking them to upload a new version built against the new krb5. I assume that some time (1 week?) later, I should do a mass bug filing against anything that is still uninstallable in unstable because of a libkrb53 dependency. I assume that doing NMUs to fix these bugs would be appropriate. Do I have things right so far? When I file bugs, do I advise people to upgrade their build dependencies to the version of krb5 that introduces the new library packages? Clearly the packages need to be built against that version for unstable. However it seems like that build dependency would make things like backports harder. Would it be better to have an explicit build dependency or just make sure that things are rebuilt after krb5 is built on all arches? Also, note that the ABI of the libraries that will remain is *not* changing. (In a somewhat related note, the soname of libraries that remain will not need to change for 1.7; we won't expect any transition beyond the krb5 package at that point). So, packages not using the krb4 libraries would actually work fine against the libkrb53 in testing. It seems like if I use an alternative dependency in the symbols files for the new package, I could allow packages rebuilt for unstable to migrate into testing ahead of the new version of krb5. That is, if I made the dependency in libkrb5-3.symbols look like libkrb5-3|libkrb53 (and similar changes for other symbols files), then both the packages in unstable and testing would satisfy the dependencies. It seems like this would significantly reduce the impact of the transition. Am I missing something or would this change be a good idea? Attached is a list of the packages that appear to reverse-depend on libkrb53. Thanks for your consideration and review, --Sam alpine aolserver4-nsimap asterisk-bristuff asterisk-classic audispd-plugins auditd autofs5-ldap balsa barnowl bind9 bind9-host bind9utils bitstormlite boinc-client boinc-manager centericq centericq-fribidi centericq-utf8 cgi-mapserver crossfire-client crossfire-client-gtk crossfire-client-gtk2 crossfire-client-x11 cups cups-driver-gutenprint cupsddk cupsddk-drivers curl cvsnt diatheke dnsutils dovecot-common epdfview etpan-ng evolution-data-server fetchmail flickcurl-utils freeradiu
Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)
>>>>> "Julien" == Julien BLACHE writes: Julien> Sam Hartman wrote: Hi, >> That is, if I made the dependency in libkrb5-3.symbols look >> like libkrb5-3|libkrb53 (and similar changes for other symbols >> files), then both the packages in unstable and testing would >> satisfy the dependencies. It seems like this would >> significantly reduce the impact of the transition. Am I >> missing something or would this change be a good idea? 3Julien> Have you considered uploading a version of krb5 with: - Julien> libkrb5-3 - libkrb4-? - libkrb53 a metapackage depending Julien> on both of the above - libkrb5-dev depending on libkrb5-3 Julien> alone and containing only the files needed to link with Julien> libkrb5-3 That's undesirable because building without krb4 has some fairly significant impacts on non-library parts of the krb5 packages. So I could not actually build with krb4 support disabled. I guess I could do two build passes one with krb4 support and one without (picking up only the krb4 library from the krb4 build pass). If I do something like this why do I want the krb4 libs to end up in a new package we plan to get rid of reasonably soon? Why not stick them directly in libkrb53? (krb4 libs in libkrb53 vs libkrb4-2 seems like aa mostly asthetic issue unless I'm missing something). Assuming that alternatives in the symbols file works, it seems like the only difference between your proposal and my original proposal is that it handles uninstalling libkrb53 somewhat better if one of the packages that replaces files in libkrb53 is installed. It also allows the new krb5 to migrate to testing ahead of waiting for everything to be rebuilt. If the alternatives approach works it means that both approaches allow other packages to migrate to testing. If there is some problem with the alternatives approach, then your approach is a clear winner. I actually think allowing the new krb5 package to migrate to testing is worth a second build pass on the krb5 package, so I'll do roughly what you suggest. I assume that with this approach I don't need to block on anyone for the first upload (the one with libkrb53 still present) and can do so at my convenience. I would appreciate your input on whether there is a good reason to stick libkrb4 in a new package vs sticking it in libkrb53. I'd also appreciate your answer to whether the alternatives approach would work to help sanity check my understanding in this space. Thanks, --Sam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)
>>>>> "Sam" == Sam Hartman writes: >>>>> "Julien" == Julien BLACHE writes: Julien> Sam Hartman wrote: Hi, >>> That is, if I made the dependency in libkrb5-3.symbols look >>> like libkrb5-3|libkrb53 (and similar changes for other symbols >>> files), then both the packages in unstable and testing would >>> satisfy the dependencies. It seems like this would >>> significantly reduce the impact of the transition. Am I >>> missing something or would this change be a good idea? Sam> 3 Julien> Have you considered uploading a version of krb5 Sam> with: - Julien> libkrb5-3 - libkrb4-? - libkrb53 a metapackage depending Julien> on both of the above - libkrb5-dev depending on libkrb5-3 Julien> alone and containing only the files needed to link with Julien> libkrb5-3 Sam> That's undesirable because building without krb4 has some Sam> fairly significant impacts on non-library parts of the krb5 Sam> packages. So I could not actually build with krb4 support Sam> disabled. I guess I could do two build passes one with krb4 Sam> support and one without (picking up only the krb4 library Sam> from the krb4 build pass). Sam> unless I'm missing something). Sam> Assuming that alternatives in the symbols file works, it Sam> seems like the only difference between your proposal and my Sam> original proposal is that it handles uninstalling libkrb53 Sam> somewhat better if one of the packages that replaces files in Sam> libkrb53 is installed. It also allows the new krb5 to migrate Sam> to testing ahead of waiting for everything to be rebuilt. If Sam> the alternatives approach works it means that both approaches Sam> allow other packages to migrate to testing. Ah, I was missing something. It allows us to decouple when we generate a bunch of binary NMUs from when we turn off krb4. When I upload the new package, nothing breaks in unstable, so there is no particular need for the release team to do anything under any time pressure. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)
> "Julien" == Julien BLACHE writes: I really appreciate your help here! Julien> As you note in your second reply, the goal is to decouple Julien> the packaging change from the krb4 dismissal: 1 introduce Julien> libkrb5-3 (Replaces: libkrb53), with libkrb53 depending on Julien> libkrb5-3, libkrb5-3.shlibs pointing to libkrb53, and a Julien> versionned dependency on libkrb53 in libkrb5-dev Julien> 2 once it hits testing, change libkrb5-3.shlibs to point Julien> to libkrb5-3, version the libkrb53 -> libkrb5-3 dependency Julien> and the libkrb5-dev -> libkrb53 accordingly Julien> If you don't do (1), you risk being tied into other Julien> transitions by your rdeps as they'll be picking up Julien> dependencies on libkrb5-3 as they get uploaded in unstable Julien> as part of their own transitions or development cycles. I'm sorry, but I don't see how I get stuck in unstable if I start out with the libkrb5-3 shlibs and symbols files pointing to libkrb5-3 rather than libkrb53. As I understand it, rdeps can only hold me in unstable if moving my package into testing would make them uninstallable in testing. They depend on libkrb53 with a versioned dependency today. A version of libkrb53 that is greater than any existing versioned dependency will be in my package migrating from unstable to testing, so their versioned dependency will be satisfied. I don't know if we do build-dep related blocking today or not, but the build-deps on libkrb5-dev will continue to work. In addition, since libkrb53 will pull in all the krb5 libraries a package that depends on it will actually get the libraries it needs to function. Now, I might hold my rdeps in unstable if for some reason it takes a while for the new krb5 to migrate into testing. However that's no more true than if I added some symbols to one of my libraries and upgraded my versioned dependency. Still that's a reason to leave the shlibs and symbols files pointing at libkrb53 until I make it into testing. The krb4 using packages are all leaf packages, so they will not complicate things until libkrb53 goes away. I trimmed the reply text, but you asked why I need two build passes. The krb5 package includes a bunch of libraries as well as daemons, utilities etc. Building with krb4 enabled does more than build krb4 libraries, and I want to get the affects of building with krb4 disabled for daemons and utilities. Doing two build passes will be easy given my package structure and the package does not take particularly long to build. --Sam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)
OK, so I think we're all set. The plan now is to 1) Build twice, once into build and once into build-krb4. We only pull libkrb4.so out of build-krb4. 2) Move all the libraries out of libkrb53 and libkadm55 (sorry, in my previous mails I was simplifying a bit) except for libkrb4.so.2. 3) Make libkrb53 depend on all the libraries it now contains and libkadm55 depend on the libraries it contains. 4) Set up symbols and shlibs files to point everyone at libkrb53 and libkadm55 as appropriate. At some point after the new krb5 enters testing: 5) Point symbols files at libkrb5-3 and friends--point them at the package that contains the library. When the first release of krb5 1.7 enters debian (probably beta1): 6) Drop libkrb53 (and thus the libkrb4.so.2), libkadm55 from the package. If the old krb4 library fails to work against the new libkrb5-3 in 1.7, add a conflicts line. Otherwise leave the conflicts line off for now. At some point later, add a conflicts line if we did not do so in step 6. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Refactoring the Debtags web interface
> "Brian" == Brian May writes: Brian> Ben Finney wrote: >> I invite anyone interested in knowing how the distinct areas of >> identity, trust, and security intersect with the OpenID system, >> to research the available documentation. >> Brian> ...except openid has serious issues with establishing Brian> identity in a secure manner. Especially if the server Brian> connects to your identity provider using http (seems to be Brian> common practise as far as I can tell). Using http makes Brian> MITM attack easy. Just redirect requests to an identity Brian> provider that always confirms the user's identity. I find it deeply ironic that I'm arguing against security. However, let's remember that we're talking about debtags. It's always important to think about your threat model and about how much complexity you're willing to spend in order to get security. This seems like a case where usability is far more important than security. If the system starts getting abused, we can lock it down more. If someone proposed using openid to do debian.org password resets or to maintain the keyring, I'd be screaming up and down all over the place. I just don't see that the value of attacking the debtags system warrents increased complexity and decreased usability in this instance. --Sam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)
>>>>> "Sam" == Sam Hartman writes: Sam> OK, so I think we're all set. The plan now is to Sam> 1) Build twice, once into build and once into build-krb4. We Sam> only pull libkrb4.so out of build-krb4. 2) This works at least. Sam> 3) Make libkrb53 depend on all the libraries it now contains Sam> and libkadm55 depend on the libraries it contains. Sam> 4) Set up symbols and shlibs files to point everyone at Sam> libkrb53 and libkadm55 as appropriate. It turns out this fails impressively. The problem is that the library packages depend on each other. So, for example, libk5crypto3 is needed by libkrb5-3. If I make the shlibs file for libk5crypto3 point to libkrb53 instead of libk5crypto3, then libkrb5-3 depends on libkrb53. But libkrb53 depends on libkrb5-3 because that is the point of libkrb53 in the new layout. I probably could hack something that would work: use symbols files that point at the split library packages internally and just before the debs are constructed run a sed script on symbols and shlibs. However as you'll recall the only reason we didn't point the shlibs at the new packages initially is to make things easy for unstable packages that get rebuilt while the new krb5 is waiting to migrate to testing. My proposal now is to upload with urgency medium. There are no code changes , I have high confidence that I can shake out any packaging bugs in five days, and that provides a good compromise in my mind at least between not blocking other people too much and having a simple enough transition strategy that I can have high confidence I understand it and that it will work. If that sounds too problematic then I can investigate the option of symbols files with alternatives (I.E. libk5crypto3|libkrb53 in the symbols file. and In addition, either versioned replaces don't work as well for downgrades as unversioned replaces, or replaces on unpacked but not configured packages don't work as well as replaces on installed packages. I'll use unversioned replaces if the user experience is better, versioned replaces otherwise. (I had used unversioned replaces in experimental, but was trying versioned in my current work). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)
> "Steve" == Steve Langasek writes: Steve> Actually, I was meaning to comment on this. Why would you Steve> not simply point the shlibs at the component library Steve> packages at this stage? The only side effect is that the Steve> version of krb5 that includes the split library packages Steve> has to migrate to testing before anything else depending on Steve> these packages can reach testing, but that's not terribly Steve> onerous given that krb5's own migration to testing won't be Steve> tangled up with other packages - this is already a very Steve> "soft" transition, and I don't see the need for extra work Steve> on the shlibs handling. That was the only reason. If it had worked easily it would have been worth it. At this point I'll just keep on top of the package and do everything I can to let it migrate to testing quickly. --Sam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)
>>>>> "Julien" == Julien BLACHE writes: Julien> Sam Hartman wrote: Hi, >> It turns out this fails impressively. The problem is that the >> library packages depend on each other. So, for example, >> libk5crypto3 is needed by libkrb5-3. If I make the shlibs file >> for libk5crypto3 point to libkrb53 instead of libk5crypto3, >> then libkrb5-3 depends on libkrb53. But libkrb53 depends on >> libkrb5-3 because that is the point of libkrb53 in the new >> layout. >> >> I probably could hack something that would work: use symbols >> files that point at the split library packages internally and >> just before the debs are constructed run a sed script on >> symbols and shlibs. Julien> debian/shlibs.local should help for that. There does not seem to be a symbols file override. The package now uses symbols files not shlibs files. (Well, obvious/ly shlibs files are generated for old dpkg-shlibdeps) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Please test krb5 from experimental--even if you don't use Kerberos
Folks, I'd appreciate it if people could try and test version 1.6.dfsg.4~beta1-8 from experimental of the krb5 package. The biggest change is a packaging reorganization. So, while I'm certainly interested in Kerberos users testing the packages, I'm most interested in people other than me confirming that they don't break your system. This really works best from an unstable system. Make sure experimental is in your apt sources. (Note these are only built for i386 now; I'll upload an amd64 build shortly) aptitude update aptitude -t experimental install libkrb53 If that works, then test reverse depenndencies of krb5 such as ssh, the bind9 host command, etc. If they don't give shared library load errors, then things look good; drop me a note. If you notice problems, then please file bugs. If you either want to downgrade or need to downgrade, here are downgrade instructions. They are a bit tricky because of the transition involved. * Downgrading from this version to a previous version can be difficult because of library name changes. Please follow these instructions: - Get the libkrb53 and libkadm55 debs you want to downgrade to -dpkg --force-depends --remove libkrb5-3 libkrb5support0 libdes425-3 libgssapi-krb5-2 libgssrpc4 libkadm5clnt5 libkadm5srv5 libkdb5-4 libk5crypto3 - At this point your system has broken Kerberos libraries - dpkg -i libkrb53*deb libkadm55*deb (using the debs you got above) - aptitude -f install to fix any other packages that may be broken (N.B. a similar version of these instructions is included in the NEWS.debian file. There are two types. There should be a space between --force-depends and --remove. ALso it is libk5crypto3 not libkrb5crypto3; that will be corrected in the next upload) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: group nvram
I'd like to chime in with the general concern that the proposal to remove a bunch of groups from udev seems under-baked and that the current groups have value. I definitely would like to see the tss (tpm) group remain along with the kvm and fuse groups. I think scanner is important as well. I can understand the argument for getting rid of nvram. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#759398: ITP: trust-router - Dynamically configure Trust Between RADIUS Realms
package: wnpp severity: wishlist owner: hartm...@debian.org URL: git://git.project-moonshot.org/trust_router.git http://www.project-moonshot.org/ license: bsd-3-clause Description: The trust router establishes a DH key between two RADIUS servers to protect a RADIUS over TLS session. GSS-API authentication is used between to securely establish this key. The trust router provides a trusted-third-party to manage connections between RADIUS realms and to provide information constraining what connections are permitted. The trust router is used to connect Moonshot Service providers to Identity Providers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/014815379066-0646baf9-9869-4bd1-b409-9fbfa4f81de9-000...@email.amazonses.com
Bug#759159: ITP: shibboleth-resolver - Library to access the Shibboleth Attribute Resolver from Third-Party Applications
package: wnpp severity: wishlist owner: hartm...@debian.org URL: http://www.shibboleth.org/ Source: svn https://svn.shibboleth.net/extensions/cpp-sp-resolver/trunk Description: Shibboleth library to access Attribute Resolver The Shibboleth Service provider consumes information about an authenticated user from SAML and GSS-API , providing services such as attribute mapping, authorization, and attribute resolution. This extension permits a third-party application to access resolved attributes. License: Apache 2.0 I'm packaging this because it is a dependency of the Moonshot GSS-API mechanism, an implementation of RFC 7055 (EAP for GSS-API). Current work can be seen at git://git.project-moonshot.org/shibboleth/resolver.git -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/01481537d429-39b5afac-c8f6-478e-a39d-36080f95f2a7-000...@email.amazonses.com
Bug#759511: ITP: moonshot-ui -Project Moonshot's Identity Selector
package: wnpp owner: hartm...@debian.org severity: wishlist URL: http://www.project-moonshot.org/ source: git://git.project-moonshot.org/moonshot-ui.git License: BSD-three-clause Description: Project Moonshot provides federated access to services combining the best of EAP, RADIUS (over TLS), SAML and GSS-API. This component provides software to manage the local identity store and pick which identity is used for a given service. --Sam pgpX99LMmhJXH.pgp Description: PGP signature
Bug#760411: ITP: moonshot-ui -- Project Moonshot Identity Manager
package: wnpp severity: wishlist owner: hartm...@debian.org URL: http://www.project-moonshot.org/ source: git://git.project-moonshot.org/moonshot-ui.git license: BSD-3-Clause Description: This package manages the Moonshot identity store, permitting users to add and remove identities as well as to select which identity is used ith a given service. --Sam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/01483cfe60fc-8bfa9c51-9af5-49b4-9f26-8f1da55f8e3d-000...@email.amazonses.com
Bug#761868: ITP: moonshot-gss-eap -- A GSS-API Mechanism for the Extensible Authentication Protocol
package: wnpp severity: wishlist owner: hartm...@debian.org x-debbugs-cc: debian-devel@lists.debian.org source: git://git.project-moonshot.org/mech_eap.git license: BSD-3-Clause Description: Project moonshot provides federated access to a wide range of applications. This package adds a GSS-API mechanism supporting EAP authentication and provides the core of Moonshot authentication and authorization. This package provides federated access for applications such as Ssh, NFS, LDAP and IMAP. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/tslioknlpax@mit.edu
Thanks Ftpmaster for all your hard work with the Moonshot Suite
Hi. back in 2011, I gave a talk at Debconf about the value of Debian to people hoping to put together changes across an operating system. I was using my work in Project moonshot as an example; we've been looking at integrating new security services throughout an operating system. Debian has been really great for that because it's easy to modify and easy to add new components, to use it both as a lab environment and a stable system. Today, with the acceptance of moonshot-gss-eap, we have all our softhware in Debian unstable. There are a few patches to other things running around getting in shape, and lots of polishing and future development. However, I want to take a moment to thank ftpmaster for their hard work over the last month doing the "new" review for the Moonshot suite. Some of the packages were complex and pulled code from a lot of places. In preparing to get all the packaging in shape for submission I talked to a couple of FTP assistants at Debconf this year. I'd always been confused why the new queue processing took so long. As I learned what was involved, I realized that actually given the thorough review that is done, it's amazing that new queue takes as short of a time as it does. I also realized that we get a huge and valuable service out of this work,. It's valuable to our users who care about free software and the DFSG, as well as everyone who cares about making sure that Debian is redistributable and legal. Thanks for all the hard work! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/01493ce547da-53f6cce6-4f1f-45d1-ad48-155dfb81b114-000...@email.amazonses.com
Time for compassion and the Init GR
Early morning, Wednesday, November 19, the results of the GR on init system coupling will be announced. No result will make everyone happy. In fact, that morning, some of our developers, users and contributors will be really unhappy. I would be dishonest if I said I didn't hope to be happy and reassured that morning. I suspect we all hope that the project will agree with our position on this complex and emotionally intense issue and reassure us that our values are close to those of the project; reassure us that this is a place where we can safely work together. I don't know who, but I know that for some of the people I care about in the project--people whose opinion I value--that morning will bring disappointment, sadness, frustration and fear. I may well be one of those people. However, Wednesday November 19 and every day after, Debian needs to work together. Today, now, before the results are announced, we have an opportunity to extend compassion and empathy and remind ourselves of the spirit in which we'd like to work together. I'm hoping that we can all take a few minutes to gain empathy for those who disagree with us. Then I'm hoping we can use that understanding to reassure them that they are valued and respected and their concerns considered even when we end up strongly disagreeing with them or valuing different things. Towards that, I ask you to take a few minutes to consider how you will feel if the option other than further discussion that you least favor is selected by the project. Actually, for some of us, the prospect of months of further discussion of this issue itself is likely to have its own negative feelings. For the moment though, I ask that you focus on one of the other options. What do you feel? Disappointment that the project didn't value something important to you? Fear about whether Debian will meet your needs as an OS and community? Sadness? Frustration? Fear when you consider whether you'll be able to get your work done? What actions could other members of the project take to turn some of those feelings around without compromising their beliefs, changing their mind, or giving up on the values that are important to them? I'll answer this question for myself in a moment; if you cannot think of things that would help you, perhaps some of the things that would help me would also be valuable to you. If not, you could find someone you trust and value and work together to see what you could ask for to receive emotional care. It's almost certainly true that others in the project--people you have worked with over the years--will have similar feelings if their least favored option is selected. Some of those people probably disagree with you. I'd ask you to consider extending other members of the project the sort of care that will help you--the actions you were thinking about in the previous paragraph. My hope is that by doing so we can all treat each other with respect and value without compromising our positions. In many cases, it may make sense to extend that care now, to commit now to an attitude of care and respect even when we might be the ones needing that care in a couple of weeks. For myself, here are things that I'd really value in a situation where I'm feeling disappointed, sad and afraid that my values might not match the project's: * Not talking about these tradeoffs in terms of what's right and wrong, but acknowledging that different members of our project have different values. User choice isn't bad any more than combining software to reduce code size is bad. There isn't a right answer. As Russ has explained a number of times in the TC, on debian-vote and on his blog, this is about tradeoffs. I'm sure some people will be happy if the project's values are aligned with theirs. When they take that as far as saying the project made the "right decision" or rejected "bad options," they are not valuing the contributions of those who disagreed with them. * People who disagree with me taking the time to understand my position. "Hey, Sam, what you seem to be saying is this...for these reasons. Have I got it?" That is, people taking the time to make sure they understand me without trying to persuade me. I'm not asking for agreement, simply that I'm valued and my opinions are valued enough to read, understand and confirm that understanding. I feel reassured that someone took the time to consider what I had to say even if they came to a different conclusion. * When true, reassurances that we share common values even in situations where we disagree about how to balance tradeoffs. * Offers to work together/to listen to my opinions in future. "Hey, Sam, I realize the decision didn't go the way you were hoping, but I'm interested in figuring out how within the scope of what we did decide we can best address the concerns you had." I really hope that folks who value user choice will be willing to work with those
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Hi. I've read the original proposal and believe it is generally going in the right direction. things I liked: * didn't pick between dgit/git-dpm/git-pq; documented the common parts * Seemed to really focus on one clear scope. * Discouraged overlay packaging. I've tried to read the arguments, and I'm unconvinced that should be a recommended practice. I'd prefer to simply rule it out of scope: this proposal describes how to package debian and upstream sources together. It does not apply to other cases and does not forbid or recommend them. It doesn't apply to svn. It doesn't apply to overlay packaging. --Sam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/0149a6c75f57-85b0ccf2-2e0c-42cd-9299-f17f889aa95e-000...@email.amazonses.com
Re: Being part of a community and behaving
> "Patrick" == Patrick Ouellette writes: Patrick> On Thu, Nov 13, 2014 at 11:06:08PM +0100, Matthias Klumpp wrote: Patrick> I did not ask for evangelization about how wonderful binary Patrick> logs are, nor for a lesson on how to get the info out of Patrick> systemd with the systemctl command. Patrick> I am glad you like them and they work for you. For me they Patrick> add another level of obfuscation, a speed bump and a Patrick> potential point of failure. All of which are Patrick> unnecessary. Cat , more less , Patrick> grep -- all worked well and continue to do Patrick> so for my text file logs. Awk, emacs, vi, all work on them Patrick> too. My log management tools all expect my old plain text Patrick> formatted logs. I'm confused. Are you saying that cat isn't working for you with systemd on jessie? I'm honestly asking for information here. As best I can tell on my system everything that gets logged gets logged to text log files. Some of it also gets logged to the journal. --Sam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/0149ab9e4869-9d59ba6d-53db-4de0-a43c-841cef1c93bc-000...@email.amazonses.com
Re: Being part of a community and behaving
> "Patrick" == Patrick Ouellette writes: I think this is a bug. On my system things get logged both to the journal and to /var/log/syslog. My understanding talking to systemd folks is that the behavior I'm seeing is intended and that unless you went out of your way to configure something different you should still see stuff logged to text files. So, you might want to ask on #debian-systemd and/or report a bug. --Sam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/0149ac2c2d41-09d0ce56-a56f-4658-8bc5-853515c63387-000...@email.amazonses.com
Bug#769499: syslog-ng-core fails to enable systemd service unit
package: syslog-ng-core severity: important version:3.3.5-4 justification: does not enable systemd unit. syslog-ng-core's postinst does not enable its syslog unit. I'm guessing that including systemd in the dh sequence is not quite doing enough to actually turn it on. Unfortunately dh-systemd is under-documented so I cannot tell where the bug is but I bet an explicit call to dh_systemd_enable will make your users happy. Attached is the buggy postinst #! /bin/sh set -e if [ "$1" = "triggered" ]; then invoke-rc.d syslog-ng stop || exit $? invoke-rc.d syslog-ng start || exit $? exit 0 fi dpkg-trigger register-syslog-ng-plugin # Automatically added by dh_installinit if [ -x "/etc/init.d/syslog-ng" ]; then update-rc.d syslog-ng defaults 10 90 >/dev/null || exit $? fi # End automatically added section exit 0 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/tslppcqmoet.fsf...@mit.edu
Re: init system policy
> "Russ" == Russ Allbery writes: >>> A second option is to migrate on upgrade the uid/gid information >>> into an override in /etc/systemd/system. Requires dealing with >>> a dynamically generated config file in preinst/postinst, though, >>> which means the tools that help proper config file handling in >>> maintainer scripts (ucf, and sometimes dpkg-maintscript-helper) >>> will be of limited help. >> I think I'd be inclined to do this, as a one-time migration, Russ> Yeah, this seems like the right solution to me too. Drop a Russ> configuration fragment in /etc/systemd that overrides the user Russ> and group and then don't touch it again. well, debconf seems like a win here. There's no reasonable default so it's desirable to make it easy for the admin to specify and so you'd probably want to use normal best practice for debconf updates. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/0149c5dd1eb8-694ee9c8-e191-4683-8ced-987af790a4bf-000...@email.amazonses.com
Bug#769907: general: non-sysvinit init systems are made of fail
> "Didier" == Didier 'OdyX' Raboud writes: Didier> Systems cross-craded from Ubuntu to Debian are absolutely Didier> not supported, and I wouldn't be surprised if some of the Didier> issues you're seeing are in some way related to this. I've seen both these issues on pure Debian systems. And I do consider both of them likely to be significant problems on upgrades from wheezy. I've been burned by both of the identified issues on multiple systems. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/tslmw7lztqy@mit.edu
Bug#769907: general: non-sysvinit init systems are made of fail
> "Didier" == Didier 'OdyX' Raboud writes: Didier> Steve's suggestions stands though: separated and actionable Didier> bugs for these two issues filed on the corresponding Didier> packages are way more helpful than a general "non-sysvinit Didier> init systems are made of fail". sure. My assumption of what it means when someone files a general bug is that they're hoping for help from all of us figuring out where the bug belongs. In that spirit. The first issue (fstab now fatally blocks boot) is something the systemd maintainers have considered (as I understand it) and rejected. I don't know that filing a bug that will be immediately wontfixed will be helpful. I don't think sending that issue to the TC is advised. The second issue seems more actionable. I wonder if we can get a bit more detail so we can retitle and reassign. In my case, I've found that with systemd I tend to get a lot less output in some cases than I do with sysvinit, but I haven't figured out what is going on well enough to produce something actionable so I didn't bother trying. If others are seeing that it's perhaps worth exploring. --Sam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/tslegsxzstn@mit.edu
Bug#647740: ITP: libvertfo - library abstracting event loop interfaces
package: wnpp severity: wishlist URL: https://fedorahosted.org/libverto/ Description: libverto provides a common interface on top of libev, libevent, glib, tevent. The goal is to allow development of asynchronous libraries that will work with whatever event loop an application happens to be using Features include automatic detection of which event loops are in a particular process space and support for writing new event loop modules. License: * Copyright 2011 Red Hat, Inc. * * Permission is hereby granted, free of charge, to any person * obtaining a copy of this software and associated documentation files * (the "Software"), to deal in the Software without restriction, * including without limitation the rights to use, copy, modify, merge, * publish, distribute, sublicense, and/or sell copies of the Software, * and to permit persons to whom the Software is furnished to do so, * subject to the following conditions: * * The above copyright notice and this permission notice shall be * included in all copies or substantial portions of the Software. * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE * SOFTWARE. I'm packaging this because it's a dependency for MIT Kerberos 1.10. It's kind of annoying but libverto has not yet been released so I'll probably end up packaging a git snapshot. I'll prod upstream and see if a release can be caused to happen. -- 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/2005173408.0b7a14...@carter-zimmerman.suchdamage.org
Bug#647742: ITP: libradsec - RADIUS over TLS/DTLS/UDP/TCP library
package: wnpp severity: wishlist URL: libradsec branch of http://www.project-moonshot.org/gitweb/radsecproxy.git URL2: http://software.uninett.no/radsecproxy/ Description: libradsec is a library for RADIUS clients and servers This library features support for RADSEC (RADIUS over TLS/DTLS) as well as TCP and UDP transports. License: The following license is a bit misleading because there are GPL dependencies. So effectively libradsec is distributed under GPL2+. However, the intent is to remove the GPL dependencies in the near future and so the license will look more like The source code is licensed under two different licenses, a 3-clause BSD license and the GNU General Public License (version 2 or later). Users of this library may choose which of these suits them best. I'm packaging libradsec because Moonshot (http://www.project-moonshot.org/) depends on it. It has not been formally released yet. It's sort of related to radsecproxy that is already in Debian in that eventually, libradsec may be used as a library by radsecproxy. At that point it might make sense for the libradsec and radsecproxy source packages to be combined. Today, although they come from the same git repository, they come from different branches and different places in the directory tree. There are a couple of header files in common. I cannot upload libradsec to unstable until libevent 2.x makes its way into unstable. -- 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/2005174338.dec664...@carter-zimmerman.suchdamage.org
Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal
For myself, I'd feel a lot more comfortable with DDs seconding than DMs seconding. In my mind, when you sign up to be a DM, you're signing up to do a good job of maintaining one or more packages. In my mind a part of the additional commitment in agreeing to be a DD is to think about the broader issues of the project, for example, the social implications of your decision, to try and help build Debian as a community and team. I think that broader view is important when doing something that is likely to have social consequences like an ITO. So, I would prefer DD seconds to DM seconds. -- 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/013a51e8b51f-2190865a-4871-43ec-a362-56efe361e561-000...@email.amazonses.com
Proposal: remove krb5-appl (rlogin, rsh, telnet, ftp with krb5 support)
hi. A few months ago, Russ Allberry stepped down from co-maintaining krb5-appl. I'm reasonably happy to keep maintaining it, although when we thought about it, we cannot think of anyone using the package. It provides krb5 versions of rlogin, rsh, ftp and telnet. The telnet is insecure and should not be used; even with encryption turned on, it's only DES and has other design defects. The other utilities kind of work, but ssh (with Kerberos authentication if desired) is a much better solution. My proposal is to drop the package from the archive, but I wanted to give others a chance to shout out that I'm wrong and that there's some compelling use-case I've missed. If someone can convince me that the packages are useful I'm happy to spend some effort on them. However, I don't think that's the case. -- 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/0143bfec0433-2cfb39b4-13f4-410f-8db1-52b5581c41bb-000...@email.amazonses.com
Re: Proposal: remove krb5-appl (rlogin, rsh, telnet, ftp with krb5 support)
FWIW, I'm not seeing enough demand that I'm interested in maintaining krb5-appl. I plan to request removal. If there's a debian developer who thinks I'm making the wrong call they should feel free to turn my removal request into a request to adopt the package. --Sam -- 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/0143da7aeaed-262eb51d-bb52-494b-bffc-df7dc16f2633-000...@email.amazonses.com
Re: dpkg-dev: please reject native/non-native version when building native/non-native source packages
control: subscribe -1 > "Charles" == Charles Plessy writes: Charles> The 3.0 (native) format is useful when packaging a work Charles> that is developped and distributed in a Git repository. Charles> Please leave us this possibility. Let me describe the use case I have which is an expansion on the above. I have a bunch of software that I perform daily builds for out of version control (git in my case but the issue applies to other vcs as well). The software does have upstream versions but is not stable enough that upstream release tarballs are useful to anyone. Honestly at this point, I'm not sure anyone will ever find upstream tarballs useful; anyone who is likely to want to build this from source probably has a copy of git and can checkout a tag. There is a packaging branch and an upstream branch. Changes made on the packaging branch increment the debian revision; changes made on the ustream branch eventually involve an increment to the upstream version. Things get dumped into a Debian reprepro repository, and into Ubuntu PPAs. Eventually, things will get stable enough that I'll upload to a PPA. Prior to that, I need a way to build a Debian package including source from a directory without an upstream tar ball. 3.0(git) is not a reasonable option because archive management programs have very little support for it, and because package download tools probably aren't well tested with it. I'm happy to entertain other options rather than 3.0(native) but my requirements are: * support for upstream version * support for debian revision * No need to have upstream sources available to dpkg-buildpackage prior to running it * No need to maintain .orig.tar.gz artifacts produced by dpkg-source and keep the checksums of these artifacts consistent between packages with the same upstream versions. -- 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/0144017b42b6-b65ba883-c94b-472c-89b7-7341c14ce8ab-000...@email.amazonses.com
Re: Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages
>>>>> "Andreas" == Andreas Beckmann writes: Andreas> On 2014-02-05 10:57, Sam Hartman wrote: >> tarballs useful; anyone who is likely to want to build this from >> source probably has a copy of git and can checkout a tag. Andreas> Such a tag corresponds to an upstrema version? yes. >> I'm happy to entertain other options rather than 3.0(native) but >> my requirements are: >> >> * support for upstream version * support for debian revision >> >> * No need to have upstream sources available to dpkg-buildpackage >> prior to running it >> >> * No need to maintain .orig.tar.gz artifacts produced by >> dpkg-source and keep the checksums of these artifacts consistent >> between packages with the same upstream versions. Andreas> All this sounds like it can be done with git-buildpackage Andreas> --git-pristine-tar --git-pristine-tar-commit. Can be set in Andreas> debian/gbp.conf. And maybe dpkg-source Andreas> --single-debian-patch. no, that means I have to maintain the artifact (namely the .orig.tar.gz). The archive software (both reprepro and dak were I to use that) require that the .orig.tar.gz not change checksums. I don't want my build machines to be able to push back to my master repository. Nor do I want to have to release upstream versions if I lose state on my build machines. So this violates my requirements because I have to maintain an artifact of dpkg-source (the .orig.tar.gz) and makesure its checksum never changes. Also, using git-buildpackage is difficult. The build is done by sbuild, which does not call git-buildpackage. -- 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/014401fef5be-d5d021c8-b29f-48df-bfe9-91ce164a4899-000...@email.amazonses.com
Re: debconf managed configuration files
I've tried to do a reasonable job with the krb5-config package of updating a user-managed krb5.conf and keeping it in sync with debconf data. It's quite old and I doubt it's best practice any more but it is an example of how to approach a non-shell-script package. The debconf-managed comment is an inadequate solution. Better than just somping on things and if that's all you have time for, then go for it. However if you can do better please do! -- 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/01440205931b-e931214c-cd15-4377-8835-b4a2e2dcb10d-000...@email.amazonses.com
Re: Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages
> "Neil" == Neil Williams writes: That makes sense and I do something similar as appropriate. Even so, I do not wish to maintain the upstream tarball as a maintained artifact. There are cases where packaging release releases are made. Maintaining pristine-tar commits for daily builds is a worse solution than 3.0(native) or not including source packages in the resulting Debian archive. -- 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/014402578b78-e77d4d79-35bc-4e7f-8a9a-311d3b59207f-000...@email.amazonses.com
Re: Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages
> "Bernhard" == Bernhard R Link writes: As I mentioned I have a packaging branch and an upstream branch. I wish to use debian revisions to reflect packaging changes. It's slightly more complex than changes to debian directory involve a debian revision change; changes to other things involve a upstream version change. As an example I produce both RPMs and Debs. Just as I don't want to increment the upstream version number because of a spec file change, I don't want to increment the upstream version number because I updtaded build-depends in debian/control. Especially when the debian directory isn't even on the upstream master branch. Incrementing the upstream version number (which appears in configure.ac among other places) so I could make changes to files that don't even appear on that branch is an undesirable work flow. I guess I could have a debian upstream version number that differed from the actual upstream version number. That seems undesirable from a user expectations standpoint as well as potentially impacting things in unexpected ways. The bug claims that it is a violation of policy to use 3.0(native) without a.orig.tar.something. I'm actually failing to find that in policy at all. I'm finding some SHOULD level recommendations, but certainly not MUST level recommendations, I can think of reasons why a maintainer might want to voiolate those shoulds. -- 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/014403490b5a-5b32fbed-1099-44ca-b73d-5c1d3514336c-000...@email.amazonses.com
Re: dpkg: is_native version checks in dpkg 3.0 Native
> "Russ" == Russ Allbery writes: Russ> Ian Jackson writes: >> Secondly, there doesn't appear to be any support in policy for >> this restriction. Russ> Policy definitely supports this restriction, as Guillem Russ> pointed out. I want to echo that analysis as one of the Russ> people to have touched that portion of the Policy document. Citation requested. I looked for this today and couldn't find it. -- 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/014404036284-6388572e-e02b-400f-b378-bfbcd745ff2c-000...@email.amazonses.com
Re: dpkg: is_native version checks in dpkg 3.0 Native
> "Russ" == Russ Allbery writes: >> Citation requested. I looked for this today and couldn't find >> it. Russ> Policy lacks a section that clearly defines native and Russ> non-native packages, which is a long-standing bug in Policy. Russ> Currently, that information is in Policy 5.6.12, which is an Russ> inobvious place for it, and worse, is hidden in the definition Russ> of the debian_revision component. However, the intent is to Russ> define native vs. non-native by the version number format Russ> used: OK, we found the same section of policy. Russ> This part of the version number specifies the version of Russ> the Debian package based on the upstream version. It may Russ> contain only alphanumerics and the characters + . ~ (plus, Russ> full stop, tilde) and is compared in the same way as the Russ> upstream_version is. Russ> It is optional; if it isn't present then the Russ> upstream_version may not contain a hyphen. This format Russ> represents the case where a piece of software was written Russ> specifically to be a Debian package, where the Debian package Russ> source must always be identical to the pristine source and Russ> therefore no revision indication is required. OK. I agree that policy 6.5.12 clearly states that if the debian revision is absent: * The software is written for Debian * the source and upstream source must be the same * No revision is required (i think this last is analysis not normative) However, I cannot read that text to imply anything about what happens if the Debian revision is present: * Policy seems silent on whether the software MAY?SHOULD NOT/MUST NOT be written explicitly for Debian (I consider this a feature) * Policy appears silent about whether the source and upstream source are the same/need be the same * Policy seems very silent about whether technical mechanisms that would make it difficult for the upstream source and source to differ are appropriate with a debian revision present. Clearly, if your source and upstream source differ, using technical mechanisms incompatible with that is nonsensical. I claim that 6.5.12 at least is silent on the treatment of packages that have a Debian revision. I agree that 6.5.12 strongly suggests that 3.0(QUILT) packages should have a debian revision. Any thought at all about 3.0(QUILT) raises that to a requirement rather than a strong suggestion. However that seems unrelated to this bug. -- 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/0144044d1318-5b90edcf-54df-4368-8a94-4bf008381306-000...@email.amazonses.com
Re: Call to fork
> "debianfan" == debianfan writes: debianfan>I would like to propose forking Debian if the ctte debianfan> committee selects systemd It's with great hesitation that I jump in here, and I know what I'm doing is wrong. I hope I've earned enough credibility over the years in the project to make a constructive but off-topic comment. In all seriousness. Forking, or creating a Debian downstream because you'd like a different boot approach sounds like exactly the sort of constructive approach that will help you solve your problems and get an operating system you're happy with. Many people have created Debian derivatives. Debian is great for that sort of thing. We even work with people who create Debian derivatives on a regular basis. In this instance I'm quite positive that if interesting technical work is done on such a fork several Debian developers will be delighted to discuss what parts of it can be merged back in. Deriving from Debian is a great way to provide a custom experience. If you find that our boot strategy doesn't work for you and you cannot make the improvements you wish within Debian, then such a fork would be a great way to constructively help us all out. however, the Debian TC list is not the right place to plan or ask about how to create a Debian derivative. -- 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/01441e907282-e61a0b67-b5fd-48ba-b995-1eb813e7772c-000...@email.amazonses.com
Re: Call to fork
Thanks for sharing this. So, you're frustrated and very disappointed because Ddebian, something you cared about deeply has drifted so far away from what you want that you can no longer support it? I hope that if you decide to fork, you succeed in creating something that meets your needs. I hope that where appropriate we (both the Debian community and the broader FLOSS community) can work together where appropriate. Again, thanks for being open and sharing how this is affecting you. -- 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/01442145887a-984e7e4a-29b0-4e71-8a2a-53a8f44c45b9-000...@email.amazonses.com
