Re: Security concerns with minified javascript code
Paul Wise <p...@debian.org> writes: > On Wed, Sep 2, 2015 at 11:47 PM, Russ Allbery wrote: >> If *no one* has access to anything better than a binary file, then >> possession of that binary file puts you on an equal footing with >> everyone else in the world, which I think is all that we can reasonably >> ask. > We can of course strongly suggest upstreams not throw away their > source files and not modify generated files, instead preserving the > most expressive or information rich formats. Indeed, and for images this is frequently a problem. People construct them using various rich data and then flatten them down to JPEGs or PNGs and throw away all the other information. Of course, even if they keep it, it's often Photoshop files, which is only of marginal utility :/ -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Security concerns with minified javascript code
The below is very much a tangent from the minified Javascript case, and not applicable to that case. Bas Wijnen <wij...@debian.org> writes: > Here's a rule to limit the selection a bit: a file is certainly not > source if it was originally generated from a different file, and has not > been modified. This makes files for which the source has been irrevocably lost non-DFSG-free. I don't think that's a good feature, nor is that the standard that ftpmaster has used in the past for the archive. Admittedly, that's something of an edge case, but I've uploaded PostScript files with that property in one package in the past because they were still the best available documentation for part of a software package (and called this out in debian/copyright, and had the package approved by ftpmaster). An extensive search had been done for the original source (which was originally in an internal IBM documentation generation system), and everyone including IBM was pretty sure that the source was gone forever and will never be found. I think reading "preferred form of modification" from the perspective of upstream is a useful standard because it handles some edge cases like that, and because it feels ethically consistent with free software principles. The goal is that everyone with a copy of the software should be on equal footing. The person distributing the software should have no special access to sources that those receiving the software don't get. If *no one* has access to anything better than a binary file, then possession of that binary file puts you on an equal footing with everyone else in the world, which I think is all that we can reasonably ask. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Security concerns with minified javascript code
Josh Triplett <j...@joshtriplett.org> writes: > That said, we absolutely do need to fix this in Debian: it's not OK to > build packages in main using tools not shipped in Debian, or to ship > precompiled files. As a start, it would help if when JavaScript folks > try to package the packages needed as part of their toolchain, they stop > getting told that their packages are too small, that they shouldn't be > packaged at all, or that they should be combined with other packages > that have different upstream sources and release cycles. I want to highlight this, because it's an important point that I don't think had previously been raised in this thread. There are some communities that make a practice of releasing very small units of code. I understand that our current metadata management and distribution framework makes this less than ideal for the archive, but I think it would be worthwhile investing some effort into fixing that instead of pushing packagers to either not package those components or do a lot more work to try to create rollup packages that aren't what anyone expects. Healthy language communities have their own metadata systems and standardized build systems that allow Debian packaging to be nearly automated, *provided* that we use the same unit of distribution as upstream. If we want to make any headway on the huge Javascript ecosystem, we can't rely on individuals hand-packaging each one of those libraries. We need to be able to use tools to do nearly all the packaging work automatically and ask humans only to do sanity checking and bug triage and the other parts of the work that we can't automate. And that's way harder if they also have to fight with rebundling upstream releases into some other format. I'm not sure how much practical impact this has had, but I know it's come up a few times, just as it's come up occasionally with Perl modules and other packages. If the metadata issues with introducing another ~100 packages in order to model an upstream distribution properly are serious, that would be a great thing that people in Debian could work on fixing, to make it much more likely that we can properly package these tools. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: system upgrade by GNOME (was: system upgrade by systemd)
Philip Hands <p...@hands.com> writes: > Is it not the case that we're actually witnessing is: > Option e): get updates applied only at reboot, with no prior > notification that they are available, such that people who always > suspend, or simply leave systems running all the time get no updates > until something bad happens, and they suffer a forced reboot. > Consequences: Unexpected changes of behaviour which will give a false > impression of being caused by reboots, leading to the impression that > Debian cannot be trusted to maintain behaviour between boots. Often > out of date system. Corrosive loss of user confidence, since they'll > feel like they're not in charge A steady trickle of irrelevant bugs. That this would happen with no prior notification or user approval is absolutely a bug, which I believe everyone involved in this thread has agreed about. I think I saw a message go by indicating that the bug was already located and fixed. Can we take a step back here and figure out what we're still arguing about? I'm wondering if we may all be in vigorous agreement, except for some disagreement over whether we like the GNOME UI for asking the user whether they want this behavior. I personally have some problems with how the GNOME UI interacts with the user, which is part of why I, er, don't use GNOME. But is there a significant bug left here, or are we now just debating whether GNOME gives the user enough warning and enough opportunity to turn this off? I ask because that's a different sort of bug than a bug in system services that could cause bad upgrades to happen without any warning. In particular, I think it's been pretty well-established in this thread that the only involvement systemd has in the whole affair is making available a mechanism for upgrade on reboot that GNOME is (so far as I'm aware) the only consumer of, thus making the subject line a bit misleading. I'm happy to let the systemd packagers decide whether it makes sense to package that with systemd or separately; any bugs of sufficient urgency to warrant a debate on debian-devel seem, to me at least, to be in whatever makes use of that infrastructure without giving the user enough advanced warning. Which, to repeat, appear to have already been identified and fixed? -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Security concerns with minified javascript code
Neil Williams codeh...@debian.org writes: I still find it hard to believe that *so* much code is required to minify JS. The excuse that JS is moving fast is nonsense. The reality would appear to be that nobody actually *cares* about the mess, they just use it. This is almost certainly correct. Usable software needs usable tools. The problem is that this *is* usable for nearly all the people who currently use it, who just run one command to install it and have all those dependencies pulled from a remote repo for them. Because the dependency installation process is so easy, they think no more about adding new dependencies than we think about installing some application with apt that happens to require a bunch of shared libraries. In other words, the people developing and using this tool don't see this as a problem, and therefore don't care about fixing it. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
Re: Security concerns with minified javascript code
Steve McIntyre st...@einval.com writes: Depressingly, it seems a lot of the same web typists don't have any problems with doing the equivalent of curl http://some.site/install.sh | sudo bash . That doesn't mean we have to do the same in Debian. If there's no sensible way to do controlled web development, let's just drop this from Debian *now*. While this is a fair critique of a lot of these systems, I think it's worth pointing out that it's entirely possible to make this sort of development process secure, or at least as secure as Debian is. All it requires is that the dependencies be pulled from a repo via a protocol that checks signatures, and that push access to that repo be relatively controlled. Debian does not exactly have a high standard of comprehensive code audits for everything we push to *our* repos, so we can't really throw stones at other people for having repos full of random software. If they do signature validation on their downloads (and I do realize that some of them don't, but it's entirely possible to keep the same model and just add that), and they have some sort of security update process, they're doing about as well as we do. It's not at all clear to me that we're really in a position to claim the moral high ground here. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
Re: Security concerns with minified javascript code
Bas Wijnen wij...@debian.org writes: On the other hand, shipping packages that cannot be rebuilt with tools from Debian will also result in angry users. For me personally, one of the bigger reasons I use Debian is that we take good care that I can modify everything on my system, and use the modified version. The users you're talking about probably don't care (much) about this, and should have contrib and non-free enabled. Why should code that doesn't meet our standards (compiler in main) be allowed in main? What is the downside of putting it in contrib? Users who don't have contrib enabled can't use it then is a feature, not a bug. Last time I checked, Doxygen includes minified Javascript in all of its generated output. Would we have to move every piece of Doxygen-generated documentation into a separate package so that we could put it in contrib, or strip it from our packages? Maybe someone has fixed this in Doxygen somehow? This is typical of the sorts of problems that I would expect. It would surprise me if this were a smaller project than the GFDL purging. It might be quite a bit larger. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
Re: Security concerns with minified javascript code
Ian Jackson ijack...@chiark.greenend.org.uk writes: Vincent Bernat writes (Re: Security concerns with minified javascript code): In the Debian context, the problem is hard. But if you allow network access and execution of arbitrary code recovered from some random registry, rebuilding the minified version from the unminified one is quite trivial. I know how it sounds. Well, we don't normally consider a program free if the only way users can modify it is something like that. Yeah. The problem is that nearly the entire rest of the free sofware world *does* consider programs like that free. (See the Ruby, Java, and Go communities, among many others, that have standard build and deploy tools that work that way.) And therefore structures their software to assume those capabilities, does not work on removing those dependencies, does not accept patches to improve the situation, etc. This is, *very* widely, considered something that only Debian cares about. I'm not saying that they're right, just that the amount of effort then required to package that software in Debian is huge, and mostly outside the reach of the typical packaging team or packaging volunteer. Our reaction has been varied. The Ruby team put a ton of work into developing a standardized framework for doing the right thing, and took a ton of upstream heat for doing so (some of which continues to this day). For Java, we largely just gave up -- we package some portions of the Java ecosystem, but vast amounts of it are just missing because the problem was too hard, and packaging any major Java application is a huge endeavor. Javascript is particularly challenging because, these days, it's showing up *everywhere* in *everything*, and shipping minified Javascript is widely accepted and nearly universal best practice. So unlike with Java, this doesn't affect just one language community and the applications that come out of that community. It's affecting pretty large swaths of interesting applications managed by a huge variety of different packaging teams. I'm not saying that we should necessarily relax our standards. I completely agree with the standards, and have been very happy to see the motion on similar things, such as Autoconf. But as one of the people who looked at large Java applications in the past and just gave up, I think it's important that we have a realistic understanding of just what we're asking of packagers and the extent to which we're swimming upstream here. Maybe there's some pragmatic approach that I haven't thought of yet that will make this less painful. That's what I'm hoping for. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
Re: system upgrade by systemd
Michael Meskes mes...@debian.org writes: Can anyone tell me which package/configuration is reponsible for systemd running a package upgrade during bootup? I certainly never willingly configured this feature, but still have it. And for the second time it destroyed my system by deinstalling a lot of packages, instead of putting the conflicting packages on hold. unattended-upgrades would be my guess. It's the only package in Debian that I know of that does things like that. (It's independent of init systems; it would do the same if you were running upstart or sysvinit.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
Re: system upgrade by systemd
Michael Meskes mich...@fam-meskes.de writes: PackageKit uses the very same resolver as apt itself does... A log file of what actually happened would be very helpful here, to determine the problem causing the package removal. Just try an update on a recently updated (Sunday) sid system and you'll see see the conflicts. I'm unclear as to what you have installed that triggers this, because I've been using systemd and sid for eons and have never encountered this behavior. (That also makes me pretty sure, pace Steve, that this is not something *systemd* as systemd is actually doing, but some other component.) Is it GNOME Software that you also have installed, per the other message on this thread? Looking at systemd-system-update-generator, it looks like this is a purely optional feature that is only triggered if you use a system upgrade method that uses the /var/lib/system-update staging area. So I think blaming this on systemd is a little odd. I certainly agree that it's a rather serious bug for this to suddenly start happening without your knowledge, particularly when it makes some decidedly bad dist-upgrade choices, but I think the fault here lies with whatever software staged this upgrade. Not with systemd for just doing what it was told by another package. I like having the *choice* of being able to either use apt and upgrade directly, or stage an upgrade and have it happen on reboot. It seems like systemd is providing that choice and supporting both options, which is great. The question, in my mind, is why you're getting surprised with something using the method that you don't prefer. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
Re: Raising the severity of reproduciblity issues to important
Niels Thykier ni...@thykier.net writes: On 2015-08-24 21:24, Santiago Vila wrote: We all want Debian to build reproducibly, but goals are achieved by submitting bugs, changing packages and making uploads, not by rising severities. I agree in general that people should make an effort to improve the situation before trying to solve this by simply inflating the severity. However, in this case, I feel that the reproducibility team has done quite an effort to reach this point already. In your opinion, how much of the archive should be fixed before one can start bumping the severity? * Personally, I considered the 80% fixed is quite convincing, but I would like to hear you take on this. Yeah, Niels speaks for me here too. That was exactly what I was thinking. Putting aside technical issues for a moment, I would also encourage people to think about the social aspects of this. Reproducible builds is one of, if not *the*, most successful large-scale, distribution-wide change that I've seen anyone try to do in Debian for quite a while. It came out of DebConf, it's been very well-handled, the people involved have done all of the things we ask people to do when making global changes but that people rarely are willing to invest the time and energy to do, and throughout this process the reproducible build team have been an absolute model of how to make a change happen in Debian. I feel like this is something that should be rewarded. Personally, I've done so by making reproducible build issues a much higher personal priority for myself than I would otherwise, since this is exactly the sort of project that I want to collaborate with. The social approach taken by the reproducible build team has been so good that it's gotten me to care about something that I originally didn't care that much about. Now, all of that doesn't mean that it has to be a project-wide goal, but I think it's worth considering how we, as a community, want to support a part of our community that cares greatly about something. This is something Debian has generally been fairly good at (with occasional problems and occasional hard choices when there are competing priorities that different people have been enthusiastic about). This one seems to not have as many priority conflicts as many, and people enthusiastically working on clearing every technical bar. For me, this means a *lot*. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
Re: Minutes from the 32bit architectures in Debian-bof
Andreas Barth a...@ayous.org writes: - for i386, there is still sold new hardware with 32bit-only. Are there open issues for i386 (apart from the 32bit-generic ones)? Discussion that we need to get rid of it one day should be started. Can we fully support cross-grading to amd64 before we do that? My remaining i386 systems, and I'm sure I'm not the only one, are systems that I've been continuously dist-upgrading for some time precisely because I don't want to rebuild a system from scratch. If cross-grading were supported, I'd just do that and switch to amd64. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
Accepted webauth 4.7.0-3 (source amd64 all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 20 Aug 2015 19:24:05 -0700 Source: webauth Binary: libapache2-mod-webauth libapache2-mod-webauthldap libapache2-mod-webkdc libapache2-webauth libapache2-webkdc libwebauth-perl libwebauth12 libwebauth-dev libwebkdc-perl webauth-tests webauth-utils webauth-weblogin Architecture: source amd64 all Version: 4.7.0-3 Distribution: unstable Urgency: medium Maintainer: Russ Allbery r...@debian.org Changed-By: Russ Allbery r...@debian.org Description: libapache2-mod-webauth - Apache module for WebAuth authentication libapache2-mod-webauthldap - Apache module for WebAuth LDAP lookup and authorization libapache2-mod-webkdc - Apache modules for a WebAuth authentication KDC libapache2-webauth - Transitional package for WebAuth Apache modules libapache2-webkdc - Transitional package for WebAuth authentication KDC libwebauth-dev - Development files for WebAuth authentication libwebauth-perl - Perl library for WebAuth authentication libwebauth12 - Shared libraries for WebAuth authentication libwebkdc-perl - Perl libraries for WebAuth central login server webauth-tests - Tests for the WebAuth authentication modules webauth-utils - Command-line utilities for WebAuth authentication webauth-weblogin - Central login server for WebAuth authentication Closes: 7961560 Changes: webauth (4.7.0-3) unstable; urgency=medium . * Explicitly Build-Depend on libmodule-build-perl, since it will be removed from Perl core in the next release. (Closes: #7961560) * Mention WebKDC in the description of libwebkc-perl in case someone is searching for packages containing that module. * Add overrides for apache2-module-depends-on-real-apache2-package, which appears to be a bug in either lintian or dh_apache2. Checksums-Sha1: ed6e1670b80fffe7986c7753d8da46fe79b2355b 2952 webauth_4.7.0-3.dsc 22ddf4ce97b243fe6cd996f0e96e85f8fb8a3305 32152 webauth_4.7.0-3.debian.tar.xz 285d84a5f652ec95e306bd1abefcf9542deb05f1 243708 libapache2-mod-webauth_4.7.0-3_amd64.deb 2f34af5c21388d8b6a706bb5cc9b6ba18a06b9a9 100586 libapache2-mod-webauthldap_4.7.0-3_amd64.deb 4abc9c506910293181a1f08cccdcd4079cfbb5f7 121538 libapache2-mod-webkdc_4.7.0-3_amd64.deb ad6d11a2cfecbd7f287dc3264936568bbdacdbb0 59360 libapache2-webauth_4.7.0-3_all.deb 91b0acbbba4ae577de28ff99babe56dcd9e3d3f6 58264 libapache2-webkdc_4.7.0-3_all.deb e0839b6c206f77dc5c65b0fd1510a39c33750cda 115082 libwebauth-dev_4.7.0-3_amd64.deb d223d3dc661eba5d694e1848ccb25e72127dda3b 156826 libwebauth-perl_4.7.0-3_amd64.deb cf5d9e097652c6eea24deaea5c34bfdfb9c8bc6e 96634 libwebauth12_4.7.0-3_amd64.deb 2a33269b1acf431ae42e2b9f32943d9257d69036 129422 libwebkdc-perl_4.7.0-3_all.deb 03758d6926b6766570ad8d8c6a2cfa22f3e2b152 71330 webauth-tests_4.7.0-3_all.deb 9af159bd2d955424895854c78066ff11bb96a826 68466 webauth-utils_4.7.0-3_amd64.deb 34ca65a32e518b5f04043eccfc5ff2b2d5b54c91 129458 webauth-weblogin_4.7.0-3_all.deb Checksums-Sha256: 95e14e8fdb59981d78e3d5c04e4f1524a83f1d27fcd3535019ccb5ae5b7d39ee 2952 webauth_4.7.0-3.dsc 63021df4efa469bf2eca66348c9f2c20e71d9f073b04a547797b7407eadb2da8 32152 webauth_4.7.0-3.debian.tar.xz 023a96f99d0a442435c290b12b2af19a5a29c4c6bb6b71c6fe6e241499b9064e 243708 libapache2-mod-webauth_4.7.0-3_amd64.deb 0fd3a59bceb3b46ac0de9bf2fd94a599cc638fbf96c39ce22f4d8af66aeb2acd 100586 libapache2-mod-webauthldap_4.7.0-3_amd64.deb 14a5ab8eebedb3d3e8ab70dafe355178ee89861aeec3443e447f16bae5a31dcd 121538 libapache2-mod-webkdc_4.7.0-3_amd64.deb 5dc89a0df742d50a9376976936d9fd2b2cdd678dd69149c2bd8b41900b6320e4 59360 libapache2-webauth_4.7.0-3_all.deb 42fbcb36e970a871d73e9255d23985975b5eb893baeb8113ca3a04f7107583fe 58264 libapache2-webkdc_4.7.0-3_all.deb 31f6e356a63b4db65b2273591612ba36eb687558583f13ea1667954e6fd6c7de 115082 libwebauth-dev_4.7.0-3_amd64.deb c5d9f47b7adea8f03d6e7fac7e3d46cec911ae398e7761c55a243a9d50b5ed2c 156826 libwebauth-perl_4.7.0-3_amd64.deb 397ad100bed64455ece00b3e04abd327938e651b7e6cae9027d414a770ba938e 96634 libwebauth12_4.7.0-3_amd64.deb 4fd9612052ee57127150404ea39a9ea63bd8fa9a8fb7f7424490793c8a0f691e 129422 libwebkdc-perl_4.7.0-3_all.deb f7c6638465546062939ad4a303bbcb6a86ff7ce323686fb49a8f144c68ee7e62 71330 webauth-tests_4.7.0-3_all.deb 5f92c3df411c4f02ee243f0deec7b2836396d0c3e0c5ebe3f5b93ea50d583119 68466 webauth-utils_4.7.0-3_amd64.deb 51b1c47810802f5c0b63a9ff741e0c6bc52e92fbfb003880e0e8a054afa165d0 129458 webauth-weblogin_4.7.0-3_all.deb Files: ce64b900dabb5f11e9706e12e28e62ce 2952 web optional webauth_4.7.0-3.dsc ad3b10acc4b096b156fd4c1eaac99e1a 32152 web optional webauth_4.7.0-3.debian.tar.xz c1f44fc152c36ab9301c1290f6e5ce5e 243708 httpd optional libapache2-mod-webauth_4.7.0-3_amd64.deb 263f244d76d31608da21c966767cf44e 100586 httpd optional libapache2-mod-webauthldap_4.7.0-3_amd64.deb 8e7f7a825d066fd3d43481a75bb9aca4 121538 httpd optional libapache2-mod-webkdc_4.7.0-3_amd64.deb 618ad33ff48b19f51ff16f0662e36702 59360
Re: Bug#765632: ForwardX11Trusted set to yes over a decade ago, for release reasons?
Colin Watson cjwat...@debian.org writes: I tried some experiments with ForwardX11Trusted=no today, and frankly, it doesn't even pass the laugh test for usability. Run xterm and try to select something, bam, your xterm crashes with BadAccess. Now, sure, that's telling me that the X SECURITY extension forbids writing to the selection, but giving client software a chance to catch up with the expectation that it should handle such errors is exactly the kind of reason that I chose to deviate from the upstream default in the first place! Now, I didn't do very exhaustive testing or anything, but to me, those ten years haven't actually made a perceptible difference to how X clients respond to failures from the SECURITY extension. If I thought that this was actually useful, it might be worth the pain. But at least I'm not the only one who thinks that this is a dubious benefit for the pain it brings: https://cygwin.com/ml/cygwin-xfree/2008-11/msg00154.html So: I don't think that this decision is realistically just up to me. If I change ssh back to use ForwardX11Trusted=no by default, a bunch of other maintainers are going to be asked to fix their software in various ways: the SECURITY extension may say no to something, but you might reasonably expect that double-clicking in your terminal won't make it explode in your face. Yeah, I think I agree. It would be great if X supported two different types of X forwarding: trusted and untrusted, with apps working in untrusted mode but with more restricted privileges. Should that ever become the case, that would be a great feature to enable. However, right now, there are two different types of X forwarding: the one that works, and the one that causes X apps to crash randomly. Or, in other words, doesn't work. If you want X forwarding that doesn't actually work, just don't use the -X or -Y option at all, and you'll have a much better error message. If someone felt excited about doing the work required to make this feature usable, it sounds like there's lots of low-hanging fruit in the form of X programs that could be taught to support the X11 SECURITY extension. In the meantime, everyone uses ssh -X to forward an X connection that will actually work, and has adjusted to the fact that this grants a lot of power to the remote system. (I've been hearing warnings about being very careful with what hosts you use -X with for something like 15 years. It's not old news.) I've rarely met someone who even knew -Y existed, let alone used it. If there were a real feature benefit, the backwards-incompatibility may be worth it, but given that the feature doesn't actually work, meh. It's hard to get particularly excited about doing work to try to enable it, and it feels really dubious to do it by breaking the command-line option everyone is used to using. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
Accepted krb5-sync 3.1-1 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 18 Aug 2015 21:45:35 -0700 Source: krb5-sync Binary: krb5-sync-plugin krb5-sync-tools Architecture: source amd64 Version: 3.1-1 Distribution: unstable Urgency: medium Maintainer: Russ Allbery r...@debian.org Changed-By: Russ Allbery r...@debian.org Description: krb5-sync-plugin - MIT Kerberos Active Directory synchronization plugin krb5-sync-tools - Kerberos Active Directory synchronization tools Changes: krb5-sync (3.1-1) unstable; urgency=medium . * New upstream release. - Fix ignore regex and errors for krb5-sync-backend silent mode. * Add the upstream release signing key and verify it in debian/watch. * Prefer *.tar.xz in debian/watch to match packaging. * Fix Upstream-Contact email address in debian/copyright. * Add debian/gbp.conf reflecting the branch layout of the default packaging repository. * Update standards version to 3.9.6 (no changes required). Checksums-Sha1: 9754b5ec828aa8088eff91e6e41b36f539e93bd1 1719 krb5-sync_3.1-1.dsc 8fbab31a75a6e88a857706224dd62855b5c14cee 341400 krb5-sync_3.1.orig.tar.xz 91cbf5bc8ff0a938e63d0b2aa04d048ce1e3ec79 16376 krb5-sync_3.1-1.debian.tar.xz 8aafcbb5cc3bf9eb1b62025ae9cca8c234091e87 35822 krb5-sync-plugin_3.1-1_amd64.deb 1492201843212bb04bc741661cba86a0e286d001 53690 krb5-sync-tools_3.1-1_amd64.deb Checksums-Sha256: adcd3bf3d1246f490d8ee41a932fa1767b29b0fa7d75e06fc1ff306f7c406f2f 1719 krb5-sync_3.1-1.dsc b26918d7564e1c03b8ca392ffdf882cfa201789e54a97ed00f043a082a92814e 341400 krb5-sync_3.1.orig.tar.xz fbc1f857785ddd9ef0375e82c0671206b0318eaccbb869603e7f97674261e184 16376 krb5-sync_3.1-1.debian.tar.xz 51de15ce45e132ae7aebe5915bdefd9560c2e870b9386da1d392bf4e6f11e2bd 35822 krb5-sync-plugin_3.1-1_amd64.deb 56d9c1879217b5311ad2e00381ed7c466b24d07a5dfc37b6cc86ae95faebe18c 53690 krb5-sync-tools_3.1-1_amd64.deb Files: 59d6961bc37a95718831cf78b46bd4a2 1719 net extra krb5-sync_3.1-1.dsc 6a0a72aaba64a8185f535571c47ab07d 341400 net extra krb5-sync_3.1.orig.tar.xz 606bf9269c09a330dc488f390b219ae0 16376 net extra krb5-sync_3.1-1.debian.tar.xz fbf0d5f3a1a2c4fbb1e60d1d7f72fdcb 35822 net extra krb5-sync-plugin_3.1-1_amd64.deb 6a4a329d429fcb56dc469dcba4cfe541 53690 net extra krb5-sync-tools_3.1-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJV1AsRAAoJEH2AMVxXNt517cwH/1GyCjokGYqQIlHq/IMuRJGM rOfwSWN3rdkGamxCch6gFtDRqK+fZ9Qhd/Mtrdd11cw22ihwVVMF6Kv5CQa305ex 4K0PYPpgvoSRdNY7G3D36jZQ9+sYC/II9prqNHgqAK1hhMocELblIRb1aAKs6No3 RN7ONF5v9CtaVnc9r93RLzN3xYICFGEIzzWwgo95YDe4KNrRXg2zuNkt78N2qSlb RliYCDGbrMLIyc9inCeAWGqLLioOlcrvTyxC//YBmYiDPtc+erHSUhr/GDUS6ffi GB2CNxLlG/VD62LzvaU250+37ZMdaDcnQ+Bbz4MDb5t53PsBprT1wxeH4M1CYeU= =ftpg -END PGP SIGNATURE-
Re: How to update control file time stamps
Malte Forkel malte.for...@berlin.de writes: Sorry for being unclear. Some of the control files used for packaging end with a time stamp that also includes the maintainers name and email address, e.g. README.Debian and README.source. I'm looking for an easy way to update that footer after editing the file. So unfortenately, touch doesn't help me. If you're an Emacs user, readme-debian-mode will automatically update the timestamp and author on each save of the file. If you're not an Emacs user, and there's no similar macro for your editor, I personally would be tempted to just remove the timestamp line and not bother with it. It's not worth manually updating. It's not required; having it there is just a convention. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
Accepted libnet-duo-perl 1.01-1 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 16 Aug 2015 12:01:54 -0700 Source: libnet-duo-perl Binary: libnet-duo-perl Architecture: source all Version: 1.01-1 Distribution: unstable Urgency: medium Maintainer: Russ Allbery r...@debian.org Changed-By: Russ Allbery r...@debian.org Description: libnet-duo-perl - Perl API for Duo multifactor authentication service Closes: 795734 Changes: libnet-duo-perl (1.01-1) unstable; urgency=medium . * New upstream release. - Fixes FTBFS and JSON decoding with JSON::XS 3.0. (Closes: #795734) * Prefer *.tar.xz in debian/watch to match packaging. * Add debian/gbp.conf reflecting the branch layout of the default packaging repository. * Refresh upstream signing key. * Update standards version to 3.9.6 (no changes required). Checksums-Sha1: 51dbfbd822ea34ca7c5f9e5852d7598231c37a41 1738 libnet-duo-perl_1.01-1.dsc 805c7ed141da33f5f68b54dbb02c31b8dfd75467 48108 libnet-duo-perl_1.01.orig.tar.xz 4b8127c87f7f2d32ddbb23d6f2a95b9f2f74302a 8440 libnet-duo-perl_1.01-1.debian.tar.xz f9887e15a105f4499ed8412bea3eea3f7554109b 90616 libnet-duo-perl_1.01-1_all.deb Checksums-Sha256: 302a72205a6d3ab2f435bb7238c8bad8e513d2baf767586dd5f20be8c281ab89 1738 libnet-duo-perl_1.01-1.dsc 2b765d8330ade153b048b1834fa7f0f7733a86a237536e302d88fb77993dcfac 48108 libnet-duo-perl_1.01.orig.tar.xz d0252b6b4262e658c28761c550cf57087b70df80552c88428338f53c775599f3 8440 libnet-duo-perl_1.01-1.debian.tar.xz 1d55a6fb2d68cb8c05bbc3e095f5178b91173be5aa0f9d458a6aa656937d218c 90616 libnet-duo-perl_1.01-1_all.deb Files: 5d91317e29490384b8ed0e7440109225 1738 perl optional libnet-duo-perl_1.01-1.dsc 37183426facd6195d7fbbaa6c211f826 48108 perl optional libnet-duo-perl_1.01.orig.tar.xz 536cf53d8789889cd85216905efadfc5 8440 perl optional libnet-duo-perl_1.01-1.debian.tar.xz fa4ff7a1fd617cebc62e47d480aced55 90616 perl optional libnet-duo-perl_1.01-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJV0N+0AAoJEH2AMVxXNt51FTUH/RlsjeAPa/PkUy4YNSsvRKBd 0801+Fl7/G3+v5mRdWrWY/ZOVf5RzM+X+cOJc0Ee/ms0OCxbpVBhBXYzntpUYNfV yEJogvTo0VCZA8dF3NKD637ebP/2g+maMLoaBJCBDP+SeHJXUoFdlU3NEdFDDJM5 AdyAB4wvnvgPFl6uOY+VhwhePwHCAIYDD4zRt3SEI28Em7QxteD2ymR8pfT7PZp7 3nc7dLxmyyOALpu+ipsaZesW8eXDKstwQZvzBuXrc7XXX48LJh3G3yoJauy40Hf6 ppLd1bl0IbxMcvkzULy+MEUoTIk/KRJAblRc1/3eayxwRnC4+ASQbj4oirK7stk= =hZ6z -END PGP SIGNATURE-
Re: Debian is not welcome on Microsoft Azure
Dmitry Smirnov only...@debian.org writes: I found it very disappointing that I had to defend Debian against Ubuntu which is stealing our audience by somehow arranging more favourable hosting conditions on Azure. I'm not talking about availability of OS images. According to Information for Non-Endorsed Distributions [1] The Azure platform SLA applies to virtual machines running the Linux OS only when one of the endorsed distributions [2] is used. So naturally my client is concerned that by choosing Debian they won't have benefits of SLA like they would have if they choose Ubuntu because the latter is endorsed. I suspect you're attributing to malice what's probably due to other causes. My bet is that their endorsed list is the stuff that either they've actually tested or that their partners are testing in some formal way, and they're not going to test every Linux distribution, and they don't guarantee that the ones they haven't tested will work. This is sadly very typical of any sort of vendor support. I see this all the time for complex software stacks with support contracts (you can only ask them for support if you run it all on some OS that they support) or for anything that requires hardware support or drivers. It's basically universal in the world of proprietary software. It's possible, I suppose, that money has changed hands to get Microsoft to endorse Ubuntu, but I think it's equally likely that they just looked at the enterprise Linux space to see what the most popular distributions commercial are, and then some other companies reached out to them to see what was involved in getting on the list. Note that one thing in common with all of the supported distributions is that there is a company behind it. (CentOS is on there only because OpenLogic put themselves on the hook for it.) Debian is notoriously hard for companies to actually contact because we don't actually exist as a formal organization, and there isn't a strategic partnerships coordinator who is calling their counterpart at Microsoft and chatting about things like this. I suspect all of those companies have at least one employee whose job it is to set up things like this. It's possible we're not there just because we haven't asked in that sort of a way, or don't sufficiently exist to be able to ask in the way that they would expect. Maybe someone could draft a press release to draw attention to the problem, if we should be concerned? I think it would be tricky to draft a press release that didn't make us sound faintly silly. They don't list Arch or Gentoo or quite a few other distributions either; it's not like they're singling out Debian in particular. They don't list any community-maintained distributions, only ones with companies behind them. This sort of limited support list (however constructed, possibly via business deals with money involved) is pretty much universal in the industry. If, like me, you're not a big fan of capitalism in general, you're probably not a big fan of this manifestation of it, but it's certainly not illegal and, by capitalism rules, not unethical. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
Re: apt-get source linux behaves weird
Daniel Reichelt deb...@nachtgeist.net writes: when I do 'apt-get source linux' with jessie+sid enabled in sources.list, there's no way to select jessie's ksrc version by target release. Neither of these work: - apt-get source linux - apt-get -t jessie source linux - apt-get source linux/jessie [...] Doing an 'apt-get source linux=3.16.7-ckt11-1+deb8u3' works as expected. Yeah, it's been like this forever. I've reported this before. I believe the explanation is that selecting the distribution doesn't work the way that you think it does. It just changes the prioritization used for selecting packages to install, which is then ignored by the source command. (I could have the details wrong; this is vague memory from previous discussions.) It would be great if this could be fixed at some point, since it's really surprising UI behavior. The workaround, as you discovered, is to figure out what version you want with apt-cache show and then specify it with the = syntax. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
Re: Mass bug filing about non free lena image.
Adam Borowski kilob...@angband.pl writes: On Wed, Aug 12, 2015 at 04:28:37PM -0400, Jack Hill wrote: Even if the image were free it is still disparaging to women. From the lintian message [0]: Moreover, Lenna photo has been pointed to as an example of sexism in the sciences, reinforcing gender stereotypes. What exactly is sexist in an image of a woman's face and shoulder? It's pretty typical of a pattern in the software industry for developers to reach for a picture of a beautiful woman when grabbing some picture that they're going to be staring at a lot. That in and of itself isn't particularly sexist (IMO), except that it's part of a pattern where the eye candy is *always* a beautiful woman because the programmers in question are *always* men, and no one bothers to think that this makes things kind of awkward for women who might reasonably identify with the eye candy and wonder if that's how their colleagues are viewing them. All of that is still probably not a huge deal if it were just some stock clip-art image of a clothed woman. A bit eyeroll-inducing, but there are a lot of things like that. However, the image is actually cropped porn, and regardless of one's opinion of porn in general, that *really* plays into that stereotype, and makes it rather hard to read the intention any other way than programmers love looking at naked women. Which feels a bit exclusionary. This is, obviously, not the most burning problem of inequality or social treatment of women that exists in the software industry. Not by a long shot. But if you're familiar with the whole story, it's, shall we say, emblematic and typical of a not particularly attractive or defensable attitude towards women as objects to stare at, which our industry is particularly bad about. If you're *not* familiar with the whole story and don't know it's a Playboy centerfold, I doubt most people would give it a second thought, so I'm quite sure many projects use it in complete and understandable ignorance. It's unfortunately one of those things that looks worse the more of the background you know. All that being said, I personally am a bit dubious that it's worth the effort to remove this. Of course, I'm also someone who thinks we should ignore the conflict between the OpenSSL license and the GPL on the grounds that it's so widely ignored as to come close to estoppel, and realistically no one is going to sue. I think this picture falls into the same category. The bit of institutionalized sexism that it represents is irritating, but I don't think that by itself makes it a great place to spend our effort (particularly our *discussion* effort, which is probably going to have the higher social cost than developer effort), and I think the chances of Playboy ever caring about uses of this picture at this point is so low as to be ignorable. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
Accepted remctl 3.9-2 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 08 Aug 2015 11:16:49 -0700 Source: remctl Binary: libremctl1 libremctl-dev remctl-client remctl-server libnet-remctl-perl php5-remctl python-remctl ruby-remctl Architecture: source amd64 Version: 3.9-2 Distribution: unstable Urgency: medium Maintainer: Russ Allbery r...@debian.org Changed-By: Russ Allbery r...@debian.org Description: libnet-remctl-perl - Perl client for Kerberos-authenticated command execution libremctl-dev - Development files for Kerberos-authenticated command execution libremctl1 - Library for Kerberos-authenticated command execution php5-remctl - PECL module for Kerberos-authenticated command execution python-remctl - Python extension for Kerberos-authenticated command execution remctl-client - Client for Kerberos-authenticated command execution remctl-server - Server for Kerberos-authenticated command execution ruby-remctl - Ruby extension for Kerberos-authenticated command execution Closes: 779764 791666 Changes: remctl (3.9-2) unstable; urgency=medium . * Build against libsystemd instead of libsystemd-daemon. Thanks, Michael Biebl. (Closes: #779764) * Add explicit build dependency on libmodule-build-perl, since it will soon no longer be provided by the perl package. (Closes: #791666) * Add debian/gbp.conf reflecting the branch layout of the default packaging repository. * Refresh upstream signing key. * Update standards version to 3.9.6 (no changes required). Checksums-Sha1: 03d2e2578c45e2ba3084402796edabaf248b6aaf 2245 remctl_3.9-2.dsc 53232a84253a3ab53c42771cebc1026c6a86e4d7 27032 remctl_3.9-2.debian.tar.xz 9259b4da8e950b811227ca0491aa0342e29f7476 68346 libnet-remctl-perl_3.9-2_amd64.deb db18fd4338ad05655e5d55be8a42161903985bd8 94692 libremctl-dev_3.9-2_amd64.deb 664601fd6027c39142ab42fb0455fda6a1cf0876 53776 libremctl1_3.9-2_amd64.deb d5e191db164393e55e2759d11065e110a09f605a 44206 php5-remctl_3.9-2_amd64.deb dd1f366871b1e3bdb0721a366c22378e9190c3ec 41144 python-remctl_3.9-2_amd64.deb 1fda90885d8f11b5d2d742a17238c2719860afb4 88276 remctl-client_3.9-2_amd64.deb 08c21f1b6e014b22e4941265d27ffef9371f5425 92022 remctl-server_3.9-2_amd64.deb e1899251aa4380da10a8cf31efbfe1f9779e8a13 41250 ruby-remctl_3.9-2_amd64.deb Checksums-Sha256: eb0d9bb259aaa69bc2c5b4a0613e13538753586b932682e34c77d5de14939d69 2245 remctl_3.9-2.dsc 40892e101bb640a5064b916de2c7525417d1dfae6f0688d3deca5f0cf52f7a5c 27032 remctl_3.9-2.debian.tar.xz eb5763ec2953a85828a55070e9ac49ee0380d3b0f0eb69da1c429768d8bd7284 68346 libnet-remctl-perl_3.9-2_amd64.deb 9c204850d87e9a256bf8ba463ba90c4901503c5f7c8d2181b1402cc8c2730c8a 94692 libremctl-dev_3.9-2_amd64.deb 83c2144da95ad8865818ce32ef9fa3537e1265d3b5706b1c8fa66506f8848c50 53776 libremctl1_3.9-2_amd64.deb f72a3da6bb1830087ca69c2446ce9a4ef6bfc4ca9be3d1885eca6bbb6e1d58a6 44206 php5-remctl_3.9-2_amd64.deb 63284bb9c1ec0539dd25ba041965a86d869458574c2987b2e2ff2b204231b7a2 41144 python-remctl_3.9-2_amd64.deb 3997498783d07295c7ff1d8b0c0458d8eea0aa712d0874bceaebbd0c9688ffe2 88276 remctl-client_3.9-2_amd64.deb c18835535160924434d58a33a25fa3423fe09d8c42600453219bab7f80647812 92022 remctl-server_3.9-2_amd64.deb f6fa5e0738749ff25bce2fc18226ecdec95fa7323bd9ec25ba2cbe56d7518541 41250 ruby-remctl_3.9-2_amd64.deb Files: 042425fbfd3855c54e998d355cb27621 2245 net optional remctl_3.9-2.dsc 01887bbdefb68f0381d3584d988bd71b 27032 net optional remctl_3.9-2.debian.tar.xz 8a9c83a40643af7e833916803fad2a9a 68346 perl optional libnet-remctl-perl_3.9-2_amd64.deb dc72f3381eccaf20925af50f65982187 94692 libdevel extra libremctl-dev_3.9-2_amd64.deb fa04787d503e5263d8115ab496b793f9 53776 libs optional libremctl1_3.9-2_amd64.deb 4f4a55acb52b095c230fb20ed1d4fad7 44206 php optional php5-remctl_3.9-2_amd64.deb 288f0e59993f167598299e32533ee3fb 41144 python optional python-remctl_3.9-2_amd64.deb 307c56e373ae31c975cf113eff003ace 88276 net optional remctl-client_3.9-2_amd64.deb 1d7c7a13ec836e3b710d1a4fb92e4758 92022 net optional remctl-server_3.9-2_amd64.deb ed27e55c00ea16b13a060f564fcf21b8 41250 ruby optional ruby-remctl_3.9-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJVxkj3AAoJEH2AMVxXNt51EmUIAIkIozuGghxuzOMfSAAOFqRz HbQWjiAooJw8qFlHLw7V5liSaO9tom9TiLOrI1HxSyS032ZKWyhwj4TmRsBw7zxp 023hH4CgId3lrZn9w3c5o4pUk7F6pd7Xs05mX5v8PqhhIhlPeNFzin8vkxbQqghV iMwWoY0CohTofOcScY6oP/wMjbj+ep/RYV2FpcpiYeUkuIiNWAjSz2HBxDO98ehf vkyb0DQXE6WiEHRZUA3Sz2OQQmHfnFrYmeCp3N1bCTXHm7SnHG+qgm/eaZCPqxPF U8u8pNeEo8aUiOLZ+FFvDk8xnoFu9TSKqIcEfClg2ROM3x/lve3UYGSW68HwN/w= =4zCl -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1zo8wu-0005ct...@franck.debian.org
Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide
Vincent Lefevre vinc...@vinc17.net writes: On 2015-07-29 00:21:54 +0200, Antonio Diaz Diaz wrote: A compressed file is like an envelope with a message inside. The objective of the decompressor is to extract the message and deliver it intact to the user. The problem is that data could have been appended to a compressed file (thanks Firefox!), and one wants to detect that and not lose such data, i.e. after the envelope is not necessarily garbage, it may be important data. There were a few long messages to this thread that I didn't absorb in their entirety, so apologies if this is a repeat. But another angle of this is that the discussion is about using lzip *for Debian packages*. In that context, being tolerant of appended data, or *any* other form of modification to the file, is basically pointless. Debian packages are authenticated and protected via cryptographic signatures, which will not match if there are any changes at all to the file, even appending a nul byte. And if the signature doesn't verify, one should treat the package with extreme suspicion, and certainly should not be installing it on a system except in a very controlled environment for investigative purposes. So regardless of the merits or drawbacks of such a feature, it's rather irrelevant to the discussion that we're having here. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87mvy9msvh@hope.eyrie.org
Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide
Antonio Diaz Diaz anto...@gnu.org writes: IMHO, if two options are equally good for the Debian use case but one of them is better for most of the users, Debian should choose the one that is better for most of the users. Else, what is the use of the social contract? That may be a worthwhile factor to take into account *before* we decided something. But that's not the current state. We've already decided on something, and it's already supported by all of our tools. You're asking for a change, which is a huge amount of work. This needs to add significant value for our use case to warrant the effort. Providing a better example for people with completely different use cases is a marginal benefit at best. In one year or two nobody noticed (or cared about) the deficient design of xz? Wow! Yup. To this point, while you're not the only person I've ever seen complain about the design of xz, I can certainly count them on one hand. And that's not just on Debian mailing lists, but also across a variety of other technical mailing lists I follow. That doesn't mean your objections are wrong, and I certainly haven't looked at it in detail. But they don't seem to be widely shared. A selection process that chooses a defective format (lzma-alone), I don't think it's accurate to say that we chose lzma-alone. I think there was some support for using it for upstream tarballs in some early iterations of a new source package format, and then, IIRC, we removed it again. We never, so far as I recall, used it as a compression format for binary packages, and I don't think it was ever widely used. For binary packages, we went from gzip to xz. For source packages, we also support bzip2. However, I wasn't directly involved in that evaluation, so it's possible that I'm misremembering. It is also depressing for me to have to point out the defects in both the xz format and the Debian decision-making process. The current situation should never have happened. Xz should have been evaluated by an expert and rejected outright, instead of wasting one year or two in popularity contests just to reach the wrong decision. I realize that you're quite confident in your expertise here, and quite possibly have reason to be confident, but it might be worth remembering that, to the rest of us, you're just some random person on a mailing list who has written some competing software and wants us to use it. No offense, but we see a *lot* of people like that, and most of them are significantly overstating their claims. So you're facing a fair bit of natural skepticism. If high-quality is desired, then democracy is not the best way of deciding about technical questions. No one made decisions via democracy. The decision to switch to xz was made by consensus, which isn't the same thing. The major objections raised at the time were about the amount of memory required for decompression. I don't recall anyone raising the issues that you're raising now, and there was quite an extended discussion process. I agree that this thread is not helping, but I think it is because Debian is not the place I thought it was. In particular I am very surprised by the insistence on statistics on this thread. IMHO, statistics, specially of the popularity contest kind, are out of place in this decision. This is an ethical and technical decision about using in Debian packaging either: a) a defective format implemented by public domain code that can be easily made non-free, or b) a flawless format implemented by truly free code that will remain free[1]. There are many people here who view software under BSD-style licenses to be more free and hence preferrable than software under the GPL. And others who do not. Therefore, our community welcomes both, and does not react well to aggressive statements like this about how the other set of beliefs is obviously wrong. Also, anyone who describes their own format as flawless raises HUGE red flags for me. It indicates some really scary hubris. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87y4hyh4mt@hope.eyrie.org
Re: How to deal with fixed but open bugs
Nikolaus Rath nikol...@rath.org writes: I'm looking at the bug overview page for src:python3-llfuse (https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=python-llfuse). The first thing it lists is the apparently nasty grave bug #775056. However, this bug only exists in wheezy, it's fixed in both jessie and sid. As far as I can tell, the bug is correctly marked with found+fixed. Therefore, it bothers me a lot that the bug features so prominently on the bug overview page. Every time I look at the page, I first think that there's something that needs my immediate attention. Is that normal / expected (the appearance, not my reaction :-)? This bug has essentially been resolved, so I would have hoped that this is somehow reflected more visibly in the bug overview. You should close this bug with the version in which the bug was fixed. It sounds like you had made the mistake of setting the fixed version directly instead of just closing the bug. That's not how this is designed to work; normally, you should just close the bug with the version number that contains the fix, and everything else will work properly. The commands to manipulate the fixed version are there primarily to fix the version if it was closed with an incorrect version or with no version. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/871tfq5nsw@hope.eyrie.org
Re: Metapackage dependencies: Depends or Recommends?
Paul Tagliamonte paul...@debian.org writes: I'm sure this is personal taste, and in the end it won't matter for most people (except folks who don't install Recommends, but they're going to break their system regardless), I've had Recommends disabled for something like five years. My systems have yet to break. :) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87oaiww4qh@hope.eyrie.org
Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide
Antonio Diaz Diaz anto...@gnu.org writes: I am not discussing a concrete use case. I understand that the defects in xz are usually not a big problem for Debian packages that can be easily downloaded again in case of corruption. What I find wrong here is that by using xz in its packaging system, Debian is sending the message that xz is a good format to use, which is not true for many other use cases. Inversely, by not accepting .lz source tarballs Debian is sending the message that lzip is not a good format to use, While it's possible that people may decide to read such messages into our decisions, that's not really something we have control over, and I don't believe we should alter our decisions on that basis. We should choose the best compression format (or formats) for our particular use case, not choose a compression format on the basis of what sort of message other people may read into that decision for other use cases. and is wasting time, storage and bandwidth recompressing lzip sources: This is probably the strongest argument that I've seen presented on this thread for supporting lzip in *source packages*: not needing to recompress upstream releases that use lzip exclusively (or use only lzip plus other compression formats that we don't want to support). However, it's not at all clear to me that there are enough of those packages to make this use case particularly compelling. There are two different things we can tune in the Debian packaging system here: the compression formats supported for upstream tarballs in source packages, and the compression format used for binary debs and for the Debian-specific portions of source packages. Historically, we've used a broader range of compression formats for the former than for the latter. But supporting a compression format for upstream source should be driven by how much packaging effort it saves, since compression ratios for the source packages isn't all that exciting (they're not downloaded nearly as often, and they're often smaller anyway). For binary debs, we went through a long evaluation process that showed some pretty clear benefits for xz over gzip, and then went through a long transition process. Changing this is hard and time-consuming, and therefore requires a lot of evidence that it's worth the change. When we went from gzip to xz, we saw substantial improvements in deb size that mattered for some use cases. I think to switch to lz compression would require gathering a similar compelling case that lz is sufficiently better than xz right now *for our use case* that it's worth changing. (I believe the whole decision-making process for xz required a year or two.) So, there are two things in Debian that could switch to lzip, and two separate paths forward for making an argument for those two things. I don't think this thread is really helping with either path, and would recommend that you focus gathering of evidence (backed by real numbers and reproducible statistics, the way the xz discussion previously was) for either: 1. Support lzip for upstream tarballs based on the number of upstreams that are using lzip as their preferred compression format and the gains in ease of packaging of that software. 2. Support lzip for binary packages based on some comprehensive advantages specifically for our binary package format over existing compression methods. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87wpxlnzsq@hope.eyrie.org
Re: debian github organization ?
Ben Caradoc-Davies b...@transient.nz writes: On 20/07/15 12:18, Ian Jackson wrote: You're talking as if what is identified is a human being. But of course, it isn't. When you do a git push (or whatever) what is pushed is controlled by the computer you are using. Of course. Humans lack a network interface. Authentication is the process whereby humans use tools they control to prove their identity. The integrity of these tools, the degree of control, and the care with which these tools are used appears to be your concern. Er, you're responding to Ian as if you've never before heard of the concept of using separate authentication credentials for different purposes, but this is a very old and respected technique and a standard security approach. It's a form of privilege separation and roles? Consider, for example, having entirely separate work and personal computing hardware with separate keys. (I highly recommend anyone who isn't self-employed do the latter, btw. It keeps things much simpler, particularly if you change employers.) I wouldn't care that there is only one GitHub account if I was able to designate separate keys for different purposes and control which of them can commit to which repositories. That way, systems can be kept isolated from each other and not have credentials to commit to repositories that are inappropriate for that system. There are some repositories that I would want to treat with a much higher level of care and only allow access from specific hosts. What is your concern? That your workstation might be misused or compromised by someone in your workplace? Key logger? Remote access snooping? And that this compromise might be used for malicious purposes against Debian? Yes, all those things, and innumerable other ways of attacking hosts. GitHub recommend using SSH key passphrases, which provide a degree of protection against machine compromise: https://help.github.com/articles/working-with-ssh-key-passphrases/ Which protects only against a tiny fraction of those attacks. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87si8jbkzy@hope.eyrie.org
Re: debian github organization ?
Ben Caradoc-Davies b...@transient.nz writes: The problem with per-role accounts is the loss of connection and reputation on loss of account. The growth of social media and social coding is changing the workplace. No longer is a role associated with a job. Rather, reputation and authority follow individuals. This is a shock to corporate culture, who are just going to have to suck it up and adapt. The world has changed. Consider the growth of Bring Your Own Device. Do you also discard your Google, StackExchange, and LinkedIn profiles when you change jobs? I think not. GitHub is no different. I get what you're saying (although yes, of course I discard my Google profile when I change jobs -- duh). And indeed it's nice to have ones contributions follow one in GitHub. However, this is entirely orthogonal to Ian's point, which is that this model is inherently insecure. A model where you can spin off separate commit identities for one institutional identity would be ideal. Failing that, people do use multiple accounts because security is more important than coherent identity for their application. In any case, I think it would be great to have one or more Debian organizations on GitHub. Debian's primary objection to GitHub has nothing to do with the questions of identity. I think that was just a side comment. GitHub is not free software. Debian is never going to get past that (nor should it). There are lots of great platforms and great applications out there that aren't free software, but that's not the role that Debian plays in the world. The whole *point* of this project is to develop and use free software. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/877fpvbh0t@hope.eyrie.org
Re: Bug#791857: ITP: daemonize -- tool to run a command as a daemon
Marc Haber mh+debian-de...@zugschlus.de writes: On Thu, 9 Jul 2015 19:18:50 +0200, m...@linux.it (Marco d'Itri) wrote: On Jul 09, Martín Ferrari tin...@tincho.org wrote: I can say that it does: start-stop-daemon misses some functionality you need for programs that don't daemonise and log to stdout/stderr, which is something I needed only last week. Having said that, I think that This looks like a job for systemd. How do I have that functionality on Debian/kFreeBSD? runit, daemontools, supervisor, launchtool... reinventing this wheel is so popular that you can find a wealth of different styles of tread. It looks like you maintain daemon, in fact. :) This is a little like uploading yet another MTA. People are reasonably asking do we need *another* one? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/877fq8ongg@hope.eyrie.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Vincent Lefevre vinc...@vinc17.net writes: On 2015-06-16 09:12:36 -0700, Russ Allbery wrote: There are a lot of really complex things you can do with versioning and cases where that version number is meaningful, but for the vast majority of libraries, I recommend not worrying about it and just always using some simple transform of the SONAME as the version for all symbols in the library. When you bump the SONAME, bump all the symbol versions. When you introduce a new symbol, use the SONAME as the symbol version. This is not strictly correct in that the symbol version doesn't correspond to a specific API (you're adding new symbols with the same symbol version as old symbols), but most of the functionality you lose is just meaningful error messages when running new binaries against too-old versions of the shared library. And it's way simpler to implement. But can this be detected so that a versioned dependency of the shared library can *automatically* be added when the binary packages are generated, avoiding this problem? I'm not sure what this you're referring to. If you mean detecting that you have newer binaries that require a new version of the shared library, and thus the shared library needs to be upgraded, yes, absolutely. Debian solved this problem years and years ago. That's what you're fixing by bumping the version in dh_makeshlibs in the shared library package: signaling that binary packages should have a tigher versioned dependency. debian/symbols does this in an even more sophisticated way. Just in case, by this, you meant the whole problem of shared library upgrades where you *don't* have symbol versions, here's the long-winded explanation for why you need symbol versions and package dependencies don't cut it: It is nearly impossible to solve this problem with package dependencies. Shared library symbol versioning is required to solve the problem properly and without painstaking and very fragile manual work. This is because the problem is not with direct dependencies on a shared library, but rather with indirect dependencies. What happens is that you have some library -- call it liblow1 -- and you have two other libraries that use it -- call them libfoo1 and libbar1. liblow1 does not have symbol versioning. An incompatible liblow2 is released. The user upgrades the system such that libfoo1 is rebuilt against liblow2, but libbar1 is not. Now, some application, app, which is linked against both libfoo1 and libbar1, is started. What happens is that calls to the functions in liblow1 and liblow2 go to one of the two implementations semi-randomly, and one of either libfoo1 or libbar1 is going to break horribly, usually in some very subtle and awful way. There are a bunch of ELF tricks that you can try to do to minimize this, but none of them are 100% effective. However, symbol versioning is 100% effective, since then libfoo1 and libbar1 are linked against specific versioned symbols, there are no symbol conflicts between liblow1 and liblow2, and both get loaded into memory, both are used appropriately, and app works. To try to solve this with dependencies, you have to make liblow2 conflict with liblow1. But this completely breaks shared library upgrades, since now you have to upgrade every program linked to liblow in lockstep, even if there's no risk for that application of loading two versions at the same time, because you can't have both shared libraries on the system at the same time. It also wipes out our dependency resolver, because there are too many conflicts to find a good solution. Alternately, you can do what we're trying to do here, which is add a complex mess of Breaks and Conflicts to all the various consumers of liblow1 and hope that you caught them all. Spoiler: you never catch them all. Particularly since some of them are user programs that aren't even part of the distribution. Shared library symbol versioning makes the problem go away. Package dependencies try to solve the problem at the wrong level. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87vbelye4v@hope.eyrie.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Hendrik Sattler p...@hendrik-sattler.de writes: Am 18. Juni 2015 03:54:56 MESZ, schrieb Russ Allbery r...@debian.org: Shared library symbol versioning makes the problem go away. Package dependencies try to solve the problem at the wrong level. The problem is rather that the package dependency system doesn't look at specific package dependency trees to find conflict between liblow1 and liblow2. Instead it always does this globally. That problem is solvable. You missed the part of my message (which you snipped) where I specifically dealt with this. You cannot make liblow1 and liblow2 conflict without causing tons of other problems, such as preventing partial upgrades and making upgrade solutions infeasible. We want to support coinstallation of different SONAMEs of shared libraries and partial upgrades. These are major, important features for both our users and for our release and library transition process. But you just but the burden on upstreams again. We can add symbol versioning in the Debian packaging even if it's not done upstream. We do that already for some libraries. It's obviously better to do it upstream, though, so that different distributions use the same versioning. It sounds like you're upset about my conclusion for some reason. You're certainly entitled to be upset, but your upsetness is not persuasive to anyone other than you. If you want to effectively argue with conclusion, you're going to have to address my rather extended explanation for why this is the best solution. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87fv5py680@hope.eyrie.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Vincent Bernat ber...@debian.org writes: In libbsd, I see that you started with LIBBSD_0.0. Does this mean libbsd has always used symbol versioning? Otherwise, the start point would be to use the previous SONAME (computed from the previous -version-info), right? There are a lot of really complex things you can do with versioning and cases where that version number is meaningful, but for the vast majority of libraries, I recommend not worrying about it and just always using some simple transform of the SONAME as the version for all symbols in the library. When you bump the SONAME, bump all the symbol versions. When you introduce a new symbol, use the SONAME as the symbol version. This is not strictly correct in that the symbol version doesn't correspond to a specific API (you're adding new symbols with the same symbol version as old symbols), but most of the functionality you lose is just meaningful error messages when running new binaries against too-old versions of the shared library. And it's way simpler to implement. I've used the fully correct symbol versioning on some projects and found that I was generally incrementing the symbol version on just about everything when I changed SONAMEs anyway, and could have saved a lot of maintenance overhead by just using this approach. I wasn't getting much benefit from being more precise. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87d20vaayz@hope.eyrie.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Cyril Brulebois k...@debian.org writes: Niels Thykier ni...@thykier.net (2015-06-15): To avoid confusing myself further, Russ and Neil, are you both talking about the debian/symbols files? I thought Russ might have been talking about versioned symbols at DSO level (e.g. symbol@LOW0 vs symbol@LOW1). I'm pretty sure Russ was indeed talking about versioned symbols at DSO level. Having debian/symbols doesn't solve the issue at hand here. Yup, I was talking about the DSO level. debian/symbols doesn't help (although it's certainly nice for other things). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87k2v4nxu2@hope.eyrie.org
Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide
Thomas Goirand z...@debian.org writes: Did you try using the same pristine-tar xz thing but with a different version of xz-utils, for example the one in Trusty vs the one in Sid? Yup, I do this all the time. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87y4jkwaqd@hope.eyrie.org
Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide
Fabian Greffrath fab...@debian.org writes: This is often the case when few enlightened people tell all the others what they skould prefer by now. I have found another opinion by a Gentoo dev that might shed some light on the topic, or maybe not. https://blogs.gentoo.org/mgorny/2014/02/22/a-few-words-on-lzip -compressor/ It's depressing that it's 25 years later and this still feels like the ARJ vs. ARC vs. ZIP wars in the DOS/Windows ecosystem. Not to mention HQZ and various other things that we had to maintain decompressors for. Lots of heat and smoke, not very much light, and way more different compression formats than there are actually meaningful distinguishing features that could only be implemented in that format, because everyone seems to want to write their own thing. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87twu8w9ei@hope.eyrie.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Simon McVittie s...@debian.org writes: This is a recurring (anti-)pattern: * an ABI-stable, high-level library, say libhigh0, links to a lower-level library, say liblow0 * we have an ABI transition from liblow0 to liblow1 * liblow0 and liblow1 do not both have versioned symbols And this point is the root of the problem. When I'm in a particular tilting at windmills mood, I think we should just stop accepting new shared libraries in Debian that don't use symbol versioning, and make adding symbol versioning mandatory the next time the SONAME changes. I know this is a ton of work for a lot of edge packages where the upstream maintainers are building shared libraries without really understanding how they work, but it's so hard to properly manage library upgrades without symbol versioning. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87y4jm2g0d@hope.eyrie.org
Re: git and https
Philipp Kern pk...@debian.org writes: Perfect is the enemy of good. Debian is already paying the protection money at this point and TBH I don't understand the resistance to add and promote the https:// variant of it. We can still switch to Let's Encrypt once it is available. I don't object to promoting https. I do think we should be careful about what claims we make about MITM protection, since I believe https without certificate pinning does not provide real MITM protection. It does, however, raise the bar against casual eavesdropping if you're already having to pay the CA cartel for other reasons, and that's worthwhile. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87617bjbxw@hope.eyrie.org
Re: git and https
Clint Byrum spam...@debian.org writes: Excerpts from Russ Allbery's message of 2015-05-27 22:23:02 -0700: If you aren't doing certificate pinning, I don't think you can really say this with a straight face. The word is avoids, it is not eliminates. What ever happened to defense in depth? There's no such thing as a perfect solution, but we can at least lock the doors, right? I'm fine with locking the doors. I'm not fine with paying protection money to a Mafia goon who claims they'll lock your windows, and sort of sometimes does. It's the extortion component that pisses me off about HTTPS. In the specific case where we'd recommend using https:// instead of git:// _for Debian's git services_, the cost noted above would not apply for any Debian users because in theory we can use the Debian-specific CA. If we can use a Debian-specific CA, we can do cert pinning, since we're then assuming we have some control over the client. I was assuming a general client where we'd have to play nice with the normal CA roots. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87oal4xocb@hope.eyrie.org
Re: git and https
Roland Mas lola...@debian.org writes: I understand that behemoths such as Iceweasel may take some time to move, but maybe Git could be made to use the TLSA records in DNSSEC? Postfix does make use of them, and SSH uses their SSHFP cousins, so it's not completely an abstract idea. Roland, who spent some time DNSSECing his infrastructure and hoping it'll be worth it in due time. Yeah, that would be really cool. Also, for people coming from Debian hosts talking to the Debian infrastructure, at least in theory we *could* do certificate pinning, which transforms HTTPS into a worthwhile security protocol. It's not exactly trivial to work out the UI and integration problems, and it doesn't help for people not coming from a Debian system (at least as much), but it might be worth considering. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87zj4ozoqq@hope.eyrie.org
Re: git and https
Josh Triplett j...@joshtriplett.org writes: https:// avoids MITM; If you aren't doing certificate pinning, I don't think you can really say this with a straight face. It makes MITM moderately harder, at the cost of giving money to a bunch of exploitative clowns who have no concept of what security means. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87pp5l5l8p@hope.eyrie.org
Accepted webauth 4.7.0-2 (source amd64 all) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 26 Apr 2015 18:53:16 -0700 Source: webauth Binary: libapache2-mod-webauth libapache2-mod-webauthldap libapache2-mod-webkdc libapache2-webauth libapache2-webkdc libwebauth-perl libwebauth12 libwebauth-dev libwebkdc-perl webauth-tests webauth-utils webauth-weblogin Architecture: source amd64 all Version: 4.7.0-2 Distribution: unstable Urgency: medium Maintainer: Russ Allbery r...@debian.org Changed-By: Russ Allbery r...@debian.org Description: libapache2-mod-webauth - Apache module for WebAuth authentication libapache2-mod-webauthldap - Apache module for WebAuth LDAP lookup and authorization libapache2-mod-webkdc - Apache modules for a WebAuth authentication KDC libapache2-webauth - Transitional package for WebAuth Apache modules libapache2-webkdc - Transitional package for WebAuth authentication KDC libwebauth-dev - Development files for WebAuth authentication libwebauth-perl - Perl library for WebAuth authentication libwebauth12 - Shared libraries for WebAuth authentication libwebkdc-perl - Perl libraries for WebAuth central login server webauth-tests - Tests for the WebAuth authentication modules webauth-utils - Command-line utilities for WebAuth authentication webauth-weblogin - Central login server for WebAuth authentication Closes: 783288 Changes: webauth (4.7.0-2) unstable; urgency=medium . * Upload to unstable. * Moved libtime-duration-perl to Depends from Suggests. This is now used unconditionally upstream. (Closes: #783288) * Add debian/gbp.conf reflecting the branch layout of the default packaging repository. * Fix upstream distribution signing key. Checksums-Sha1: 40a2a00352b860e623171f8a0f8af1b51da98242 2930 webauth_4.7.0-2.dsc 9b6d828e26656c05218b46d87763d8c818fbcf1d 31896 webauth_4.7.0-2.debian.tar.xz 364d33119daa2169315599a7c90cfcf368da879e 242056 libapache2-mod-webauth_4.7.0-2_amd64.deb a703b5c04c6bd074316e26fe2716d68eaad32f2d 99520 libapache2-mod-webauthldap_4.7.0-2_amd64.deb 26c9b53fc70d8f9efa158ac03b0d56e2a78fe369 120764 libapache2-mod-webkdc_4.7.0-2_amd64.deb 561c6c615b537f4d419d6657c1ff0377f7828763 59286 libapache2-webauth_4.7.0-2_all.deb 7269a3a8ad274834cc6953aaed36967efeb941ce 58110 libapache2-webkdc_4.7.0-2_all.deb 58eecfb78228df9285620636988368296cc6755f 156816 libwebauth-perl_4.7.0-2_amd64.deb 5d9932da92d3fd1ae96b05c28a07bcf05abf4189 96962 libwebauth12_4.7.0-2_amd64.deb 9fa7ce1e19dab4c222c6776fa8dc777f5d52125a 115364 libwebauth-dev_4.7.0-2_amd64.deb 3225ca720e025ba7b40a26102c736cb48a47f70e 129348 libwebkdc-perl_4.7.0-2_all.deb 19b2312bf1f17e04ee1de2670c60865deea6 71264 webauth-tests_4.7.0-2_all.deb a64b4208f28b74e731d4d04931e581a12441b42f 68350 webauth-utils_4.7.0-2_amd64.deb 68ff1e0905a786f85fcd6ff7c9d4abfa9f9031d7 129328 webauth-weblogin_4.7.0-2_all.deb Checksums-Sha256: c959c91e5075c324102a2a2bf85ae70839ba3fcd8a0795792b3dacfa6b29f18e 2930 webauth_4.7.0-2.dsc 659e0d5013eeb089fef3c9f4e4af7bd68665fa824174ec38b41b4698d8895bc7 31896 webauth_4.7.0-2.debian.tar.xz a81151f4697a110e5b9e2f92a1cedd00d0753ec839e6a4b23013fddee375a3e7 242056 libapache2-mod-webauth_4.7.0-2_amd64.deb 8ce0b180b2538eb9d4fd8de0f2480c6de500488826567d78edafae77f083 99520 libapache2-mod-webauthldap_4.7.0-2_amd64.deb af0df2659772594cc9eb6368d943be0d3221bfcf859a0c7884c976ce21e3034b 120764 libapache2-mod-webkdc_4.7.0-2_amd64.deb bfa24265f962d9c57e64b177335cb11d0b6227d93dce37b2ed88c872f574603e 59286 libapache2-webauth_4.7.0-2_all.deb e64b46b8eb7a99fe0e7b9b68a2fdb26f86990f35eb6e933697a2dd25f7b461b2 58110 libapache2-webkdc_4.7.0-2_all.deb 9433d7b9f7b9c72c09c6c80e9a512c989eeb035b5f22b7187b3472c729a63c12 156816 libwebauth-perl_4.7.0-2_amd64.deb 3c57ff952626b30761d262edcd464e08f3450e6b6b956b83224b0de0b6c4d10b 96962 libwebauth12_4.7.0-2_amd64.deb d21aa0da9b618e84e2783e0008a6d3a2f867b76b97b690c7336c35a4c4455c7e 115364 libwebauth-dev_4.7.0-2_amd64.deb dd6f07cbf7bd569e5655d0bd8b84fbbff892d84bf7352e1d44620151e5f35f16 129348 libwebkdc-perl_4.7.0-2_all.deb 3078383f9c6544102f3a123daf1bc5469a7743a5792f389c40416971cc94c11d 71264 webauth-tests_4.7.0-2_all.deb 8e023167125c33f59fde88cba5cca62c4ae4ee1b7480b8ca5f4ca637039ed546 68350 webauth-utils_4.7.0-2_amd64.deb fd2d9ac5006811222e3fb94cee898e9a49c0672cb45fd0d049c54ad82ec2e3aa 129328 webauth-weblogin_4.7.0-2_all.deb Files: 55b30d6d574e40dcc3abe20b5d0405a5 2930 web optional webauth_4.7.0-2.dsc a95dff0e6c60ead37b1e41b527d00d39 31896 web optional webauth_4.7.0-2.debian.tar.xz 1187db90f39b4d806c9cf539f611b237 242056 httpd optional libapache2-mod-webauth_4.7.0-2_amd64.deb 1cc8a6e9f635a01e6356bfe47bce13a4 99520 httpd optional libapache2-mod-webauthldap_4.7.0-2_amd64.deb e751a4a8fda8c590e35c0c260f63d8f8 120764 httpd optional libapache2-mod-webkdc_4.7.0-2_amd64.deb 72d4f7682bb15f70c2fe75f890485783 59286 oldlibs extra libapache2-webauth_4.7.0-2_all.deb 946677b5f6ca1a6510f488fef309946c 58110 oldlibs extra libapache2
Accepted lbcd 3.5.2-1 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 26 Apr 2015 17:15:58 -0700 Source: lbcd Binary: lbcd Architecture: source amd64 Version: 3.5.2-1 Distribution: unstable Urgency: medium Maintainer: Russ Allbery r...@debian.org Changed-By: Russ Allbery r...@debian.org Description: lbcd - Return system load via UDP for remote load balancers Closes: 779779 Changes: lbcd (3.5.2-1) unstable; urgency=medium . * New upstream release. - Detect libsystemd instead of libsystemd-daemon. (Closes: #779779) * Refresh upstream signing key. * Update standards version to 3.9.6 (no changes required). Checksums-Sha1: 69d3c2cc79c402efead595b556dac5cfdefa4f44 1603 lbcd_3.5.2-1.dsc 52f3a261f9ccae2097b544c9d914aa4180b85ed1 216268 lbcd_3.5.2.orig.tar.xz c45592e0a2abc3667b92fdc8ab866b0bc14ba00d 18516 lbcd_3.5.2-1.debian.tar.xz bd34dbfe7e1fdcad99d1058d289c59898988ee24 59022 lbcd_3.5.2-1_amd64.deb Checksums-Sha256: feb7134cf3dbcdf4427a723e045015ca307cee23a24a77446a6071e6a28d8fea 1603 lbcd_3.5.2-1.dsc e25a59490b3eaca878ed3b703f129a72fb7c1150d5715590abd09f46c277e497 216268 lbcd_3.5.2.orig.tar.xz d1e9fb29a593c3719b68fe14bd1640b2894c50fba7cb2ba0ffae817e89c32f69 18516 lbcd_3.5.2-1.debian.tar.xz 25fae3acfee22e8fd18de2f5be8231d930a9cb9d4642eddffc1a645345c5ed6c 59022 lbcd_3.5.2-1_amd64.deb Files: 788d300ee2c7267c2c0ffc8a936dd12a 1603 net optional lbcd_3.5.2-1.dsc a7f279d219cf04d8d62432f54021c318 216268 net optional lbcd_3.5.2.orig.tar.xz 4357f24274b98fab7e1726d8fb034d97 18516 net optional lbcd_3.5.2-1.debian.tar.xz 76c7611252bc9ae509af2aae6ac83d1b 59022 net optional lbcd_3.5.2-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJVPYmTAAoJEH2AMVxXNt51EbkH/jwGWYWzy0uVqWOIyyUwuyVv Hh3vKFrTjJbANP0RBdaMzjm6NWLzC0hYEpdii6hAcJ/GU3YFR0K+VPOBsGBbOfrP bODUttrl0wTpzKTO28qYWT0LtAUbZfsujbrYIBeqMj7CaJLR9Hn9+NyApGymaFbz FHbCpbao0tFs7bwNNfUN5/nLba0DTgVWSTGr6fUx7ooaCVh+JK49bckpyyMlwN4W apkG7287sUkosJWQL2gxPbwBW2ANokrxv4McGGFE9fkZ/qiCH98BLsRXT7aAN40r KOnCDYIZfiLqnVhG7NfyVQTq7bc9cazxIs/kQY0WllsnYLGxjANduz49ae/Oikw= =vXUj -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1ymxtg-0007xn...@franck.debian.org
Accepted libpam-krb5 4.7-2 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 26 Apr 2015 20:23:59 -0700 Source: libpam-krb5 Binary: libpam-krb5 libpam-heimdal Architecture: source amd64 Version: 4.7-2 Distribution: unstable Urgency: medium Maintainer: Russ Allbery r...@debian.org Changed-By: Russ Allbery r...@debian.org Description: libpam-heimdal - PAM module for Heimdal Kerberos libpam-krb5 - PAM module for MIT Kerberos Changes: libpam-krb5 (4.7-2) unstable; urgency=medium . * Upload to unstable. * Refresh upstream signing key. * Add debian/gbp.conf reflecting the branch layout of the default packaging repository. Checksums-Sha1: 905cfd5f4cae6e03d450c2492ed397f7e4428d87 1679 libpam-krb5_4.7-2.dsc 6db92144dc374f96d0031d7f382bc74701c6490e 25524 libpam-krb5_4.7-2.debian.tar.xz 76e85fabec6481add315e34eef7a3da615df7e2b 87890 libpam-krb5_4.7-2_amd64.deb dfbc81aee81bd06645a4c52000926451dc882447 85042 libpam-heimdal_4.7-2_amd64.deb Checksums-Sha256: c0cf07ab66cceb196bdb761eab156670d1dc4a8e2c0cf8bca98aff5b3f7e2ccd 1679 libpam-krb5_4.7-2.dsc 1cae384741557582b1d943bbea527cf0aef4ee001678e0ea70f35b37fa61330d 25524 libpam-krb5_4.7-2.debian.tar.xz d9bae250ad0ed0c74645ae827a7f5cef8f1b3a60c999ff36d3d0cb6b80887870 87890 libpam-krb5_4.7-2_amd64.deb 4d579fbeaceab544c16762bf87eee12fa26e77415db6a82c8407ab9563a80d7e 85042 libpam-heimdal_4.7-2_amd64.deb Files: 649d8733894b73d8e8ec0f5f4a4b642b 1679 admin optional libpam-krb5_4.7-2.dsc 2897ff91eeae418b53c25cd7ee71efbf 25524 admin optional libpam-krb5_4.7-2.debian.tar.xz 84509b80a10dc39f3ffd07ee4a1221bf 87890 admin optional libpam-krb5_4.7-2_amd64.deb cca0dd55e09df48cd83f83b9b60dbb8d 85042 admin extra libpam-heimdal_4.7-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJVPa3kAAoJEH2AMVxXNt51eogIAKcliSzoTdKiGJVC84LVGEg5 UZkHwjNtx2dQCqj4tWcbW3JJTgyNQlCOPkeuuiQybtgFZ20OSrKXT80J8GMLH4aO gEbqhePcNnSvamfdXrNYkoBsUKI2NOlF03DOyxEPcPC+SxD3LpTtLz0HrVeY4dqA 1p53DeiTNR/j4RBKqswp0CAVKxOESS+DA0gzS894o8QWOxQuIArO2im7N0Lk6Gf6 aRcHuSajRDD9V3hcKK5rymPyvf5vWyRvtmDaGVEl4iKDHZACyzctK9y+YMv7a1kZ y4vwefELKvc19H2OG3/FO/LEEbgSniQNX3SlAa88uEIXyM0eLUy3NWDhgLxtkNo= =pzkK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1ymadq-0007tn...@franck.debian.org
Re: GitHub “pull request” is proprietary, incompatible with Git ‘request-pull’
Stefano Zacchiroli z...@debian.org writes: On Sun, Apr 19, 2015 at 12:13:32PM +0800, Paul Wise wrote: To those of you who are willing to use github for Debian related things, it would be great if you could: Mirror the repositories to alioth so Debian has a backup. I'd rather see it the other way around: advertise the alioth Git repo as the main one (e.g., in Vcs-* fields), and mirror it to GitHub for people who want to contribute via GitHub's pull requests. I mirror the repositories on my own publicly-accessible Git server. Hopefully that's good enough. :) Also accept contributions via email or git request-pull. AOL. Oh, certainly. (Well, like Neil, I've never heard of git request-pull before this thread and have never seen anyone use it, but if someone did, it would be an interesting learning opportunity.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87h9sct4cb@hope.eyrie.org
Re: GitHub “pull request” is useful and can be easily integrated'’
Ben Finney ben+deb...@benfinney.id.au writes: We're told that GitHub has a raft of features that make it superior, until it's pointed out that those features are GitHub-specific and incompatible with collaborators from outside; then, conveniently, the specialness of those features dwindles to insignificance because we can access the repo's commits. It's a UI. The UI is really nice. That's why people use it. But lock-in implies more than a really nice UI that people use because it's superior. Lock-in implies something you're trapped into using even when it's *inferior*, and that's what people are taking issue with. For better or for ill, people use GitHub because it's *a really good product*, not because of some sort of nefarious lock-in strategy that holds people's data captive. The data that's to some extent captive in GitHub (like issues) are not really a strong point for GitHub. There are a lot of better issue trackers out there. (Like *cough* Atlassian, which is a much different conversation.) The repositories and Git management are the very nice features of GitHub, and there's nothing there data-wise you can't pretty trivially extract. It's just a very nice UI. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87lhhot4ey@hope.eyrie.org
Re: debian github organization ?
Marc Haber mh+debian-de...@zugschlus.de writes: Thankfully, git is by far the best VCS on the market and the vast majority of people seem to agree. But imagine the outcry if ten years ago Sourceforge had said our VCS is svn and we don't support anything else. Er, they did, didn't they? I could have sworn that they only supported CVS initially, and then only added Subversion, and getting Git support took forever. Launchpad, similarly, is probably suffering a lot from the decision to only support bzr. (It suffers from some other things as well, such as asset licensing and how difficult it is to stand up your own, but I think the VCS is a major problem right now.) So you're of course right -- there's a tradeoff. However, I still stand by the decision to only support a single VCS, at least when you start, because you can move a lot faster and implement a lot more functionality that people care a great deal about. If you can find the right VCS to use that 90% of people are content with (and I think Sourceforge started there), I think your resources are much better put into adding other features than adding more VCS support. I have no interest in ever using bzr again, but I strongly suspect Launchpad got a lot farther and does a lot more because the choice was made to only support bzr. Now, of course, they need to switch to Git, or at least support it, and that's going to be a ton of work, but I suspect the order in which they did that made for a better system in the long run than if they'd tried to support both bzar and Git (and Mercurial and the other ones that were looking viable) at the start. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/871tjj5lle@hope.eyrie.org
Re: debian github organization ?
Russell Stuart russell-deb...@stuart.id.au writes: On Thu, 2015-04-16 at 23:13 -0700, Russ Allbery wrote: However, I still stand by the decision to only support a single VCS, at least when you start, because you can move a lot faster and implement a lot more functionality that people care a great deal about. Woo, slow down there. Here I was thinking the discussion was about spinning up a server using exist software. Has the discussion moved to writing our own or even modifying something to suit Debian's needs? No. My comment was in the context of a comparison between Sourceforge and GitHub, and I was just making the point that I think this was a wise decision on GitHub's part. It was also in the context of a couple of other packages that are possible contenders for a revision control management framework, both of which have made the same choice, also (IMO) wisely. As for one DVCS to rule the world - that also sounds like a bit of a stretch. While we're pondering whether dropping support for older VCSes is a bit of a stretch, the broader software community is just shrugging and using GitHub. If the goal is to produce a viable free software alternative to GitHub, supporting Subversion or bzr or Mercurial would be nowhere on my list of requirements. Obviously, supporting a choice of DVCSes would be great, all other things being equal. But given the resources available for a free software project, all else is not going to be equal, and there are *lots* of other features that are a much higher priority for more developers than making the diminishing minority of people who don't use Git more comfortable. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87r3rj4470@hope.eyrie.org
Re: debian github organization ?
Milan P. Stanic m...@arvanta.net writes: What about gitolite? It is in Debian, can be used with gitweb and have access control. N.B. I'm biased (maybe) because I use gitolite for my company repositories. gitolite is very nice insofar as it goes. I've used it a lot, and still use it in various places. But it and GitHub are fairly different things. It's just the repository management (with a very nice ACL system), and is the most useful if you're following a hub and spoke model for your repositories. If you want the whole pull request flow, code review, or the many nice API integrations with things like continuous build and test of proposed merges, gitolite doesn't really help. Another approach is Gerrit, which is very nice if you have an up-front code review requirement, but which is hard to package given its substantial Java dependencies. But the world seems to be moving more towards the GitHub pull and fork model than the Gerrit up-front code review model. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87bnim3b8l@hope.eyrie.org
Re: debian github organization ?
Ben Finney ben+deb...@benfinney.id.au writes: Russ Allbery r...@debian.org writes: Funny, this is why I don't get why people are so upset that some use GitHub. Because of how Git works, the impact of lock-in is pretty much limited to the non-repository stuff (issues and so forth). Yet it is exactly those lock-in features that is the basis for arguments to put special effort into the centralised single point of failure. For example, the centralised proprietary GitHub “pull request” is presented as a reason to abandon a decentralised model: Uh, a pull request isn't something proprietary. It was part of the design of Git from the beginning and is based on the workflow of the Linux kernel. What GitHub offers are some nice tools for managing those pull requests that reduces the friction considerably, just like they offer a nice web interface for viewing repositories. Those tools are useful, and I hope they'll be replicated in an open source framework for Git repository management, but they're not lock-in. You can do pull requests without GitHub (and in fact I've done a fair bit of that). So upstream have chosen a proprietary lock-in service for their workflow. That should not put any obligation on others to also submit to proprietary lock-in. Of course not. You don't have to use anything you don't want to use, and no one in this thread is advocating otherwise, at least that I've seen. All that I'd ask is that, if other people want to use GitHub, for you to not be an ass about it, the same way that we don't lecture people for using a proprietary editor to write free sofware. Some of us are willing to reach out to people who are using GitHub and give and take patches from them in their preferred way, particularly right now when there aren't a lot of compelling alternatives to point them to. If you aren't, that's perfectly fine; just please don't get in the way of us who are. There's a whole spectrum of difference within the project about how absolute people want to personally be about only using free tools. Some people are at the end of the spectrum with RMS and are investigating computers with fully free firmware, and more power to them. Other people are using non-free software for some things and free software for other things and are contributing the latter to Debian. And more power to them as well, since they're helping us build the free software community. Sometimes I wonder if people think free software is so fragile that if anyone who works on it ever touches non-free software, everything we built will crumble. I think our community and ecosystem is a lot more robust than that. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/874moe16n4@hope.eyrie.org
Re: debian github organization ?
Steve McIntyre st...@einval.com writes: Ben Finney wrote: Paul Tagliamonte paul...@debian.org writes: So, yes, it's nonfree. Yes, it's controlled by DDs. No, I don't think this should be the Vcs-Git: target. No, I don't think we should endorse GitHub. Yes, we need free tools. Yes, we should contribute to the F/OSS community where upstreams are. That last part seems to deny the D in DVCS. Why are we under such pressure to use one particular centralised service? Agreed - it's really annoying to see everybody clamour for a centralised single point of of failure for git hosting. :-( Funny, this is why I don't get why people are so upset that some use GitHub. Because of how Git works, the impact of lock-in is pretty much limited to the non-repository stuff (issues and so forth). I use GitHub for some things, largely because it makes it easy for people to contribute patches if they're used to that workflow, and it lets me take advantage of some services (like continuous integration builds) that I could but don't feel like building myself. I also push all my repositories to my own Git server with its own gitweb instance, so if GitHub disappears tomorrow, I don't lose anything of much note. Yes, it's a proprietary service and all, but not all proprietary cloud services are created equal in terms of their lock-in and other drawbacks. GitHub is pretty light-weight on that front. That said, something more akin to GitHub (including the nice integration API and fork/pull model) running on a service like Alioth would be very neat. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87iocu1fp5@hope.eyrie.org
Re: debian github organization ?
Iustin Pop ius...@debian.org writes: I think the VCS agnosticism is actually detrimental in this context. It's much easier for the user when every repo is using the same VCS. And consistency makes it very easy, for example, to refer to commits across projects, to standardise pull/clone workflows, etc. +1. VCS agnosticism means you waste a bunch of time making each new feature work with every supported VCS, which can include trying to shoehorn pretty foreign workflows into the model of some other VCS. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87oamn5vfu@hope.eyrie.org
Re: Jessie Release Date: 2015-04-25
Alexander Cherepanov chere...@mccme.ru writes: At the time of posting, there was a bug for unrar in this list. I think this one -- https://bugs.debian.org/774171 , it was fixed the next day. Do I understand it right: a bug in a non-free package could be release-critical for Debian? I thought non-free area is not part of the Debian system... It's RC for the package, but not for Debian. In other words, if the bug isn't fixed, the package would be pulled from the release, but it's pretty unlikely that it would hold up the release itself. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87619aclu7@hope.eyrie.org
Re: aptitude has Priority: standard, why?
The Wanderer wande...@fastmail.fm writes: I remember, years ago, I asked on some Debian list what the intended replacement for apt-cache was, since I'd been told that apt-get was deprecated in favor of aptitude and I'd seen that aptitude did not seem to have equivalents for the apt-cache commands. For a while, we were recommending people use aptitude for upgrades instead of apt-get because the dependency resolver did a better job. That's probably where the deprecated part came from, as that recommendation did get reported that way. However, time marches on, and the apt-get resolver has gotten better. I think both programs have their place. Personally, I'd recommend the apt tool for command-line package installation because I think its defaults are safer and less confusing. But it has no equivalent to aptitude for a curses-based examination of the packages on the system and new packages now available, which is a rather nice feature. In terms of dependency resolvers, I think a reasonably fair way to characterize them is that apt-get errs on the side of caution and can default to refusing to do anything, whereas aptitude tries a lot harder to find a dependency solution that changes the system at the cost of generating a lot of bogus solutions. My personal experience is that, when I have a difficult or complex dependency issue on a system, the *second* solution offered by aptitude is usually better than the only solution offered by apt-get (mostly because apt-get usually gives up), but the *first* solution offered by aptitude is usually awful and sometimes actually destructive. I always found that pattern strange and kind of amusing, but it's surprising how reliable run aptitude and take the second thing it suggests is in resolving weird dependency problems. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/871tk3eqa5@hope.eyrie.org
Re: Misc Developer News (#38)
Jonas Smedegaard d...@jones.dk writes: I don't know all those services, but would be surprised if e.g. launchpad exists as code for self-hosting. Don't get me wrong: I would be _happy_ to stand corrected! Launchpad exists as code for self-hosting. https://dev.launchpad.net/Getting Setting it up is a little like trying to set up dak yourself: it's possible, and people have done it, but it's not common, so it's not painless and may require a fair bit of elbow grease and some swearing. But it is possible; I know people who have done it. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87y4n4z1oo@hope.eyrie.org
Re: Should .a library contains non-reallocatable code?
Bernhard R. Link brl...@debian.org writes: * Russ Allbery r...@debian.org [150222 21:51]: It won't with something more complex on all architectures. I think there are architectures (i386, maybe?) where you can link non-PIC code into a shared library with a performance penalty, and (as mentioned by another) it doesn't matter for code where there's no difference between PIC and non-PIC. But this will definitely break on some architectures (including amd64, IIRC). There's been lots of discussion of this on the Libtool list, and I've had to deal with this from time to time in various upstream projects where I wanted to assemble a shared library from various internal helper libraries. Take a look at all the work that Libtool does to handle convenience libraries for exactly this reason. You are speaking about linking .a helper libraries into a shared object. I'm about the case that a shared library has a dependency on a different static library instead. Oh, you're talking about leaving symbols unresolved in the shared library and requiring that the binary link with both the shared library and some static library at build time? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87d250hxuc@hope.eyrie.org
Re: Should .a library contains non-reallocatable code?
Bernhard R. Link brl...@debian.org writes:
This is wrong. If libbar.so needs libfoo.a then libfoo.a does not
need to be PIC:
echo 'int foo(void) {return 17;}' foo.c
echo 'int bar(void) {return foo();}' bar.c
echo 'int main() {return bar();}' main.c
gcc -c -Wall foo.c
ar rs libfoo.a foo.o
gcc -shared -fPIC -Wall bar.c -o bar.so
gcc -Wall main.c -L. -lbar -lfoo
./a.out
echo $?
works just fine.
It won't with something more complex on all architectures. I think there
are architectures (i386, maybe?) where you can link non-PIC code into a
shared library with a performance penalty, and (as mentioned by another)
it doesn't matter for code where there's no difference between PIC and
non-PIC. But this will definitely break on some architectures (including
amd64, IIRC).
There's been lots of discussion of this on the Libtool list, and I've had
to deal with this from time to time in various upstream projects where I
wanted to assemble a shared library from various internal helper
libraries. Take a look at all the work that Libtool does to handle
convenience libraries for exactly this reason.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
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/877fv9r7pr@hope.eyrie.org
Re: how to remove libsystemd0 from a live-running debian desktop system
Simon Richter s...@debian.org writes: With my embedded hat on, it would be nice if there was an easy way to drop this extra dependency, as it means a lot of essentially dead code loaded on systems that don't use systemd. Like others, I'd be happy to support that as a build profile or build option or something. As upstream, it's already easy to tell all my code that's systemd-aware to stub out that stuff if wanted. But, as you say, I think it's unlikely that this is really the low-hanging fruit for very resource-constrained embedded environments. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/878ufupn32@hope.eyrie.org
Re: how to remove libsystemd0 from a live-running debian desktop system
Nathan Schulte nmschu...@gmail.com writes: On 02/17/2015 11:49 AM, The Wanderer wrote: libsystemd0_is_ dynamically loaded, precisely so that userspace applications can make the decision at runtime as to what to do. What about dynamically linked? Maybe Luke means dynamic linking (necessitating dynamic loading) instead? It's already dynamically linked too. If the argument is that it should be opened with dlopen at runtime, I'm quite confident that there are *many* people on debian-devel who have worked with shared libraries and can spell out many reasons why that's a horrible idea. And it serves no practical, useful purpose. (Removing every package whose name contains the string systemd is not a practical, useful purpose. It's just silly.) What Luke spent thousands of words advocating for is basically what the systemd upstream has *already done* with libsystemd0. One could even say that it's a primary *purpose* of that library. So, yay, I guess? The world is much better than you had thought and already as good as the compromise position you thought you could get! -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87k2zfvqqp@hope.eyrie.org
Re: how to remove libsystemd0 from a live-running debian desktop system
Luke Kenneth Casson Leighton l...@lkcl.net writes: i've documented the process by which it is possible to run some of the debian desktop window managers (TDE, fvwm, twm etc.) without the need for systemd or libsystemd0 or any components related to systemd whatsoever. Alas, the resulting distribution is still hopelessly compromised by the NSA, who might be even worse than Lennart Poettering. To see how deep the tendrils of US government infiltration go, just try removing libselinux1, and marvel at how much concerted malevolent effort has gone into destroying your freedom. Or, alternately, you could research how and why one would use shared libraries in a binary distribution to support optional features. But that's boring, prosaic, and nowhere near as much fun to write about. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87vbj2e4bh@hope.eyrie.org
Re: Bug#777643: general: possibly, some keyboard layouts should use U+22C5 DOT OPERATOR instead of U+00B7 MIDDLE DOT
Christoph Anton Mitterer cales...@gmail.com writes: It seems to be quite logical that actually the dot multiplication sign is meant, it's on the same key then the cross multiplcation sign, and in the group of arithmetic operators. Whether that was intended or not, that's not what people actually did when they made those keyboard layouts. They did not put the dot multiplication sign on that key; they put the middle dot symbol on that key. Those keyboard layouts now exist, and changing something like that is almost never worth the trouble, for exactly the same reason why we're not going to remap the default keyboard layout to be Dvorak even if it's better than QWERTY. If you want a different keyboard layout, you pretty much need to make a different keyboard layout, and then convince people to use that instead of the existing one. Changing an existing one, even if you think it made a logical error, seems like a really bad idea. That's even apart from the fact that diverging from upstream in an area like this seems like an absolutely awful idea. I don't think this is an actionable bug report for Debian. It's an interesting bit of speculation, and it's arguably a consistency flaw, but it's not something that makes sense for us to do anything about. (Based on past history, I suspect the reply to this will be 200 lines about why I'm wrong, so I'll mention in advance that I'm highly unlikely to say anything further on this bug report and I'm happy for others to have the last word.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87lhk5ueu9@hope.eyrie.org
Bug#777089: ITP: python-moto -- Mock framework for boto AWS library
Package: wnpp Severity: wishlist Owner: Russ Allbery r...@debian.org * Package name: python-moto Version : 0.4.0 Upstream Author : Steve Pulec * URL : https://github.com/spulec/moto * License : Apache 2.0 Programming Lang: Python Description : Mock framework for boto AWS library Moto is a library that allows your Python tests to easily mock out the boto library (used to talk to the Amazon AWS API). It supports most of the major AWS services and can be used as a decorator, context manager, or via explicit calls. -- 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/20150204224226.5389.46796.reportbug@lothlorien.eyrie.local
Re: Bug#776992: ITP: python-dicttoxml -- Convert a Python dict or other data type to XML
Russ Allbery r...@debian.org writes: Package: wnpp Severity: wishlist Owner: Russ Allbery r...@debian.org * Package name: python-dicttoxml Version : 1.5.8 Upstream Author : Ryan McGreal r...@quandyfactory.com * URL : https://pypi.python.org/pypi/dicttoxml * License : GPL 2.0 Programming Lang: Python Description : Convert a Python dict or other data type to XML Actually, never mind. There was a license conflict with moto (which was the whole driver for packaging this), since moto is under Apache 2.0. As it turns out, the latest master revision of moto doesn't use this library at all, so I'll just package that instead. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87bnlaab4a@hope.eyrie.org
Bug#776992: ITP: python-dicttoxml -- Convert a Python dict or other data type to XML
Package: wnpp Severity: wishlist Owner: Russ Allbery r...@debian.org * Package name: python-dicttoxml Version : 1.5.8 Upstream Author : Ryan McGreal r...@quandyfactory.com * URL : https://pypi.python.org/pypi/dicttoxml * License : GPL 2.0 Programming Lang: Python Description : Convert a Python dict or other data type to XML Supports converting a wide variety of item and collection Python types, as well as iterable and dict-like objects, into XML, with arbitrary nesting for the collections. Items with a datetime type are converted into ISO format strings. Packaging this as a prerequisite for moto. -- 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/20150203210405.32534.27825.reportbug@lothlorien.eyrie.local
Re: motd handling in jessie
Josh Triplett j...@joshtriplett.org writes: One more (set of) shell scripts spawned at boot time adds incremental complexity, fragility, and yes, a small amount of delay. It might not matter much if you're spending 60 seconds booting a server; on the other hand, with client boot times currently at a few seconds without any optimization, 1s with a little work, and hopefully heading even lower, spawning off even one more instance of /bin/sh than needed (along with miscellaneous other programs invoked from a shell script) seems worth avoiding. I think we're going to have to agree to disagree on this, since I must admit that my reaction to the above analysis is basically eye-rolling. :) Forking off a uname -a in parallel to the rest of what's going on during boot is not going to be noticable. I think you are doing quite a lot of premature optimization here. Sorry, in my response to your question, I thought you were talking about sshd's current Debian default to use PAM and to display the motd through pam_motd, which it does do even for non-password login. I have not tested pam_issue with sshd. Ah, no, I was responding specifically to your suggestion to replace pam_motd with pam_issue. Unless that module does something different than what its man page says it does, I don't believe this is possible. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87r3uhwapa@hope.eyrie.org
Re: motd handling in jessie
Josh Triplett j...@joshtriplett.org writes: But not the Debian default. Debian defaults to UsePAM yes and PrintMotd no, and uses PAM to print the motd. Right, which I think is a bad idea, for the reasons stated earlier in this thread. :) I think the way to go here is to use the update-motd.d stuff to generate an MOTD file at boot, remove pam_motd from our default configuration, and go back to the upstream sshd default of displaying the MOTD file on login. It reduces our divergence from upstream and reduces the complexity of code that we're running during a security-critical code path. In any case, the /etc/issue escapes have a major advantage over every other solution thus-far proposed: they don't actually involve running any extra programs, ever. Not at boot, not periodically, and not at login time. Instead, whatever processes /etc/issue (either agetty or pam_issue) just runs an extra syscall to obtain uname information, and prints it. (And note that Debian's default /etc/issue *already* prints one such piece of information.) And has the disadvantage that it doesn't print the MOTD. It wedges a bunch of extra stuff into the login prompt, at least according to the man page for pam_issue. If you log in with public key authentication, does it even show anything? I bet it doesn't. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87oapm3bxr@hope.eyrie.org
Re: motd handling in jessie
Josh Triplett j...@joshtriplett.org writes: However, I don't think run a pile of scripts to write out a dynamic MOTD at boot time is a sensible default, either. Why not? I'd suggest putting update-motd and update-motd.d into a separate, optional package that users can install if they really want it, and using either static files or /etc/issue escape sequences as the default to avoid running *anything* at either boot or login time. This desire to avoid running something at boot is mystifying to me. Since when do we try to avoid running things at boot, and why would we? It's not like this is going to add any appreciable delay to boot time (and that's not a huge concern anyway). If you log in with public key authentication, does it even show anything? I bet it doesn't. It does, actually, right next to the time of last login. Ah, then its man page is wrong. pam_issue is a PAM module to prepend an issue file to the username prompt If it actually does what the man page says, it's a pretty bad idea and will only work with password authentication. It's also quite likely to break at least some (admittedly dumb) ssh clients, and wouldn't work with PasswordAuthentication (as opposed to ChallengeResponseAuthentication). If it's instead a different variation on pam_motd, that's better. But I think it would still be even better to make the login flow as stupid and simple as possible, not do a bunch of dynamic string expansion in C. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87mw561h93@hope.eyrie.org
Re: motd handling in jessie
Cameron Norman camerontnor...@gmail.com writes: Well we can do both. If these update-motd scripts actually differ in their result day by day, and the server is only rebooted maybe once a week (if not less often), then running them once at boot is not enough. I think we're overcomplicating this. If someone really wants to put data that updates regularly in their MOTD *and* use update-motd.d to do this (we're already into territory that I suspect is pretty rare), we can just tell them to add a call to update-motd to cron or use pam_motd. For me, the interesting question is what we should do by default. We certainly shouldn't remove the code that lets people do more complicated stuff if they really want. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87a91637wf@hope.eyrie.org
Re: motd handling in jessie
Michael Biebl bi...@debian.org writes: Why run this on every boot? The main thing that you want to be up-to-date are things like the running kernel version, and you have no other good way of detecting that, I don't think. It's not like this stuff takes very long to run, and it will happily parallelize. If the update-motd.d interface is supposed to also show information like list of outdated packages, etc, wouldn't some other mechanism to trigger an update, be better. What trigger do you have in mind that would detect that you just rebooted the system into that new kernel that you installed six weeks ago but never used? I suggested a cron job, but maybe there are better ways, like apt hooks, dpkg triggers, etc. A cron job is strictly worse than running it at boot in every metric that I can think of. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87iofu3aq5@hope.eyrie.org
Re: motd handling in jessie
Riley Baird bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch writes: Sort of off topic, but as far as I can tell, the historical purpose of MOTD was to send a message to all users of a system. Is it still used for this? Yes. Stanford used, and presumably still uses, this pretty regularly for head nodes of compute environments to alert users about upcoming downtime and similar issues. Are there other uses of it? The most common use of MOTD in large data centers is to provide a succinct snapshot of relevant information about a system when an administrator logs in. When you have access to 30,000 machines, it's nice to not have to remember exactly what hardware class or kernel a particular server has and instead be reminded when you log in. For example, here's the ERB template we used to generate the MOTD at Stanford (this is neither good Puppet ERB syntax nor good Ruby, but you'll get the idea): % os = lsbdistdescription.gsub(/Debian GNU\/Linux/, Debian) os.gsub!(/Red Hat Enterprise Linux/i, 'RHEL') os.gsub!(/RHEL (\w+) release (\d+) \(.* (\d+)\)/i, 'RHEL \1 \2u\3') os.gsub!(/RHEL (\w+) release ([\d\.]+) \(.*\)/i, 'RHEL \1 \2') processor = processor0.strip.gsub(/\s+/, ) processor = processor.strip.gsub(/\(R\)|\(TM\)/i, '') processor = processor.strip.gsub(/(\w+-Core|Processor|CPU) /i, '') processor = processor.strip.gsub(/(Intel|AMD) /i, '') host = fqdn.downcase product = productname rescue nil if product.nil? product = unknown else product.strip! product.gsub!(/VMware Virtual Platform/i, 'vmware') product.gsub!(/ Server/i, '') product.gsub!(/SUN BLADE /i, 'SB ') product.gsub!(/Precision WorkStation /i, '') product.gsub!(/ MODULE/i, '') end sn = serialnumber rescue nil if virtual == 'physical' and (! sn.nil?) product += , + serialnumber end memory = memorysize if memory.match(/\./) memory.sub!(/0+ /, ' ') memory.sub!(/\. /, ' ') end memory.gsub!(/\s+/, '') swap = swapsize if swap.match(/\./) swap.sub!(/0+ /, ' ') swap.sub!(/\. /, ' ') end swap.gsub!(/\s+/, '') -% %= host % - %= os %, %= architecture % %= processorcount %-core %= processor % (%= product %); %= memory % RAM, %= swap % swap Puppet environment: %= environment %; kernel %= kernelrelease % (%= hardwaremodel %) %= text -% -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/877fwcostv@hope.eyrie.org
Re: motd handling in jessie
Josh Triplett j...@joshtriplett.org writes: That looks really promising. What would it take to get the default /etc/issue changed to include all the necessary information to make the current dynamic motd obsolete? ssh support for /etc/issue escapes, which seems incredibly unlikely. I certainly wouldn't want to add that to ssh were I the ssh maintainers. Note that if we care about ssh logins showing the same message, we could easily enough start using pam_issue, in place of or in addition to the current pam_motd. If people really want to use PAM to do fancy, dynamic stuff with the MOTD, more power to them, but let's please not use a solution with this high of complexity by default. Nearly all normal uses of MOTD are served just fine with some scripts that run at boot and generate a static file, which can then be displayed directly in sshd with PrintMotd (which is the upstream default). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87d263o2wc@hope.eyrie.org
Re: motd handling in jessie
Josh Triplett j...@joshtriplett.org writes: Please, no. Under normal circumstances, the only dynamic bit of the motd comes from uname, and only changes on reboot; updating it via cron just wastes cycles and adds noise to syslog. I'm not particularly convinced that even the existing uname line has much value. So what about this: why don't we move all of that machinery to an update-motd package or similar (priority optional), which can hook into PAM as desired to display its message, and have the default motd of the base system be completely static, with nothing run at boot *or* login? I do feel like we're losing some value by not showing users the uname information by default, and I'd like to still see us update that at boot. I certainly agree that running shell code from PAM by default is not a good idea. That said, by far the best way to handle MOTD is to write out a static file using whatever configuration management system you're using, based on all the information that it gathers about the system (via something like ohai or facter). That lets you flesh out the MOTD with lots of details that are actually interesting. But that's not something Debian needs to be doing; each site can handle that. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/878ugs7qw6@hope.eyrie.org
Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]
Tomas Pospisek t...@sourcepole.ch writes: But isn't subscribing participants natural? Posting to a bug report means participation and thus you'd get the follow-ups. Why would you post to a bug report if you aren't interested in what happens with it, how things proceed/evolve? Most other bug systems require at least a weak authentication step before letting you comment on a bug, so there's some reasonable binding of identity of the person commenting with an email address. This is not true for the Debian BTS. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87d26ahg4x@hope.eyrie.org
Re: Bug#775436: ITP: xlennart -- An XBill fork but with Lennart and SystenD instead of Bill and Wingdows
Ivan Shmakov i...@siamics.net writes: While not a full-scale ad-hominem attack, I’d say that the two differences I know of between the vrms operation and the official FSF position amount to a misrepresentation at best. Are we going to drop that package, too? I don't particularly care enough to argue for dropping it, but I always have kind of wished that the author would rename it. Personally, I just don't name software after people who aren't the author of the software. It feels like unnecessary drama to me, or at least risks it. That goes double for representations of other people in software that they didn't write and didn't choose. It's funny for a bit (I played xbill for about 30 minutes back in the 1990s when it first showed up and laughed at the time), and then it stops being funny. It's not that Bill Gates would ever notice; it's that it's one of those things that makes me feel like a slightly worse person than I was before I did it. I already find it too easy to reduce people to caricatures; intentionally practicing doing so doesn't feel like it leads to any place good for how I think about the world. There are lots of funny things in the world that don't subtlely undermine my ability to see nuance and that don't feel like adding unnecessary drama to my life. To be clear, that's strictly a personal opinion about why I choose not to participate. I don't really care to argue about whether Debian should include the package. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/871tmu46yn@hope.eyrie.org
Bug#775246: general: Debian does wake from suspend. It either hard reboots or remains unresponsive.
John Ammerman palemastervolr...@gmail.com writes: * What led up to the situation? Suspending this computer. * What exactly did you do (or not do) that was effective (or ineffective)? I put my computer to sleep. * What was the outcome of this action? When I wake the computer in any manner it either goes straight to bios and performs a hard reboot or it just remains blackscreened and unresponsive. It happens on two of my desktops. Hi John, Sorry that you ran into this. It's a known bug with a kernel update that was pushed to the stable release, and should be fixed shortly. See: http://womble.decadent.org.uk/blog/linux-suspendresume-regression-in-debian-78.html -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/8761cbxwg4@hope.eyrie.org
Re: length of a package extended description
Don Armstrong d...@debian.org writes: It would probably be ideal if there was a better way of indicating which latex modules were in each texlive package than currently, but until a better method is found, this is probably the best of bad options. +1. I cannot overstate how useful it is to have this sort of thing appear in a field searchable by apt-cache. We have enough packages with this issue that maybe it would be worth designing some other way to allow this, but until then, please keep the lists in packages like this or firmware-linux-nonfree so that apt-cache search can find the right package. And having at least *some* description for humans to view with a pager and forward search is really nice. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/878uhbux9y@hope.eyrie.org
Re: motd handling in jessie beyond
Christoph Anton Mitterer cales...@scientia.net writes: On Wed, 2014-12-31 at 12:04 -0800, Russ Allbery wrote: I think UsePAM yes is the only sane default for Debian, though, and people who choose to change that default are legitimately on their own. I've used UsePAM no for many years without any real issues, as you said it depends what you want (account locking, etc.)... and in general I feel it's a bad thing if Debian says if you don't use our defaults, you're screwed and on your own... Well, there's you're on your own and then there's you're screwed. The former doesn't need to imply the latter. In this case, the you're on your own means expect to have to manually reproduce a lot of the work that PAM was otherwise going to do for you. If you open the hood and remove the transmission, it's reasonable to expect to have to spend a fair bit of time working out how to get the car to go again. That doesn't mean that the radiator should therefore explode. :) But apart from that, I don't see much problems from the OpenSSH side here, the only thing necessary is that one has an up-to-date /etc/motd (i.e. regularly created). Yeah, exactly. In this case, all you lose is a basically cosmetic feature. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87sifujtdf@hope.eyrie.org
Re: motd handling in jessie beyond
Christoph Anton Mitterer cales...@scientia.net writes: For the OpenSSH server this is dependent on wheter UseLogin and/or UsePAM directives are being used or not, the later which has a configuration file default of yes in Debian (but not in upstream's default config or default value). I think UsePAM yes is the only sane default for Debian, though, and people who choose to change that default are legitimately on their own. It's way too hard to try to cope with all the odd things that can happen when PAM has been disabled. If you set this to no, you don't even get session and account handling, so you lose Kerberos ticket setup, may lose account locking and expiration, and all sorts of other stuff that is managed via PAM. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/8761cregcb@hope.eyrie.org
Accepted libpam-krb5 4.7-1 (source amd64) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 25 Dec 2014 19:36:00 -0800 Source: libpam-krb5 Binary: libpam-krb5 libpam-heimdal Architecture: source amd64 Version: 4.7-1 Distribution: experimental Urgency: medium Maintainer: Russ Allbery r...@debian.org Changed-By: Russ Allbery r...@debian.org Description: libpam-heimdal - PAM module for Heimdal Kerberos libpam-krb5 - PAM module for MIT Kerberos Changes: libpam-krb5 (4.7-1) experimental; urgency=medium . * Upload to experimental due to release freeze. * New upstream release. - Add no_update_user option to disable the normal update of PAM_USER after user canonicalization. - Suppress spurious Heimdal password prompt when using PKINIT. - Map unknown realm errors to PAM_AUTHINFO_UNAVAIL. - Treat more error codes as incorrect passwords for better compatibility between MIT client libraries and Heimdal KDCs. - Add version number when module options were added to the man page. * Remove erroneous branch information from Vcs-Git. * Fix debian/copyright to match the correct upstream licensing. * Update standards version to 3.9.6 (no changes required). Checksums-Sha1: 891770e59656a732cc5a698b3649b85db12d0db0 1679 libpam-krb5_4.7-1.dsc a28bbd0e592cd2f44a8acb949ff5cf38acba191c 381156 libpam-krb5_4.7.orig.tar.xz 239016931f0db26e9ecb388b4c995796d7f0d6f2 23188 libpam-krb5_4.7-1.debian.tar.xz 7cabdf14cbcfe7a9d6d4ea988b4b2322a49092d1 87792 libpam-krb5_4.7-1_amd64.deb 2c6df9a1e731fb639af332a289779bb8b1f6acf9 84928 libpam-heimdal_4.7-1_amd64.deb Checksums-Sha256: 45e1e614ec1b6d4c40b214d2e281a573d3bf05792e3a2900a77e6c8b29b8a127 1679 libpam-krb5_4.7-1.dsc 2421ad5ee0ff7c6c7c6094babaf1a3c5c0f7f2c33e22c50a8735df791d436e29 381156 libpam-krb5_4.7.orig.tar.xz ea789ca074ddafdce1ea0a688ec611ab7c18eaff5bbf21daff25b6cf89e9a67d 23188 libpam-krb5_4.7-1.debian.tar.xz 4447bf14492fd3fada327d8f33936b5c37099681abf6467416be9ed0da8f67e1 87792 libpam-krb5_4.7-1_amd64.deb 15edc349f1d005f50f402df5e36212b2b52ca6217ce06cf6d25feef5e18eb9ac 84928 libpam-heimdal_4.7-1_amd64.deb Files: ebb9ffab2760ad92591943b42ee76337 1679 admin optional libpam-krb5_4.7-1.dsc 60085cb7bbc5b0416d5b34adb7e28c41 381156 admin optional libpam-krb5_4.7.orig.tar.xz 528f9c9b81edc282b262134db3d8bfbd 23188 admin optional libpam-krb5_4.7-1.debian.tar.xz 0eddacfad96b2ff7c924b278d3b59259 87792 admin optional libpam-krb5_4.7-1_amd64.deb 12a1a75ec05e1d36b763e01f8b93e5dd 84928 admin extra libpam-heimdal_4.7-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJUnNtlAAoJEH2AMVxXNt51N20H/jqup4vySAaI4AXTmWeAu56f /xh/ky8OVvzm4V4boSQX0shEXT0oL3hVAmevijmg0Amx05dxcronuGGH6OQiI8yC 9a2DQnprYe8DFk5Xrcx82YIEjwjQbpyE/yUWAjf+OqiceKepMrE00qbPicCAggG7 OZJx9IyA10URixG59nDsYuZvfHPk6X0rDb69CuzEcoUJXaO9GjEcj0FguDARVZ7+ GX40XMy4O93hnWC2HbknqfZbKov+nfON0cAYi1RHQ+wqHPoTIZFc9OAPz8mxcPh5 vdRm3NcpTbBR/aogRR6w6IHUSmsJ+RGe9CFE7ejBEAsKpnnL6BqfKl7zHCaZIA0= =h3Ng -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1y4mmd-0004xr...@franck.debian.org
Re: one package altering other package's postrm
Ian Jackson ijack...@chiark.greenend.org.uk writes: Guillem Jover writes (Re: one package altering other package's postrm): As mentioned before, just add a versioned Breaks against the cron package not supporting that, do not mangle its maintainer scripts. ... If using current apt with APT::Get::Purge=true or --purge, or the aptitude TUI and marking cron for purge, the conflicting package will get purged before the other package is even in the picture. Isn't this combination rather dangerous ? The result would appear to be that switching to systemd-cron would first purge the cron package, discarding any local changes to /etc/crontab (and other config files owned by cron). I think Apt::Get::Purge=true or --purge during upgrades is rather dangerous inherently. One is basically telling apt full steam ahead, and destroy anything too slow to keep up, no looking back! I much prefer a multi-step process of apt upgrade, apt-get autoremove, and then purging removed packages some time (days) later after I've had some time to notice broken things. If you use --purge during upgrades, I think you should expect some things to break and for your local configurations to occasionally get wiped out. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87h9wwdebi@hope.eyrie.org
Re: one package altering other package's postrm
Alexandre Detiste alexandre.deti...@gmail.com writes: Would it be OK / ugly / forbiden to do a rm -f /var/lib/dpkg/info/cron.postrm in systemd-cron preinst script ? This is needed to avoid that /etc/cron.allow /etc/cron.deny disapears when cron is purged but systemd-cron still needs those. (from v1.5.1) In http://anonscm.debian.org/cgit/pkg-cron/pkg-cron.git/tree/debian/postrm : # if [ $1 = purge ]; then #rm -f /etc/cron.allow /etc/cron.deny # fi Well, ideally this is something that should be coordinated with the cron package. How do the other cron replacements, like bcron, handle this? It feels cleaner to me to have cron be aware that systemd-cron (or some other package) has taken over those files, instead of making other packages do edits of the package metadata. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87iohf5fba@hope.eyrie.org
Re: Technical committee acting in gross violation of the Debian constitution
Enrico Weigelt, metux IT consult enrico.weig...@gr13.net writes: What about the enforced replace on dist-upgrade, which at least produces lots of extra work and can easily cause systems being unbootable ? It's an urban legend that people are getting all upset about even though it's not actually true? Right now, there is a pre-upgrade step that you have to take (apt-get install sysvinit-core prior to dist-upgrade) to avoid switching to systemd [*]. That's certainly not the best imaginable UI, but there's nothing enforced about an upgrade that you can easily avoid with one preliminary step. Those of us who have been using Debian for a while and have gone through many dist-upgrades will remember several releases where there were pre-upgrade steps we had to take for dist-upgrade to succeed, including some that could make the system unbootable if forgotten. It's never ideal, but, once again, people are confusing the normal variation of Debian releases with the end of the world because the letters systemd happen to be attached. (This is not to say that we shouldn't aspire to doing better when we can. Only that people are getting unnecessarily panicked about this.) [*] It's possible that you may also have to add a pin and/or install systemd-shim, but hopefully not. I think if a pin is also necessary, there's a bug somewhere, although I haven't investigated it myself and don't know how easy it would be to fix that bug. Regardless, one step or two, we can certainly document this in the release notes even if it doesn't get better before the release. We should definitely sort out the exact working instructions for what we ship with jessie and get them into the release notes before we release. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87y4qkekn3@hope.eyrie.org
Re: DE features dependent on Systemd
Svante Signell svante.sign...@gmail.com writes: On Wed, 2014-12-03 at 16:55 +, Simon McVittie wrote: On 03/12/14 14:46, Svante Signell wrote: If more granularity is needed, what's hindering introduction of even more groups: like an image group and splitting the fb0 to more devices? Or even subdirectories like /dev/snd/* for audio etc. This does not actually solve the same problem as logind's uaccess, or ConsoleKit's udev ACL (which was an older version of the same general idea): it just splits it up into a larger number of orthogonal instances of the same problem, which is that group membership makes a poor encoding for temporary permissions. Have you ever heard about openafs? Yes (I was one of the developers for years), and I'd agree with the statement that group membership makes a poor encoding for temporary permissions. It's hard to clean up afterwards. What point were you trying to make by referencing OpenAFS? I don't see the relevance. If you're referring to the (broken) representation of PAGs as manufactured UNIX groups, that's exactly why we got rid of that on Linux in favor of using the keyring instead, since using groups caused all sorts of weird problems and issues. And that was with assigning a unique new GID for every session and never trying to use it for any actual group things on the local system. OpenAFS still generates the group since some stuff relies on it, but the primary representation of the PAG is now in the session keyring. The GID thing was always considered a hack in the OpenAFS development community. It was only used because we lacked a good alternative that more correctly represented that information. When NFSv4 development sparked the modern Linux keyring data model, we were delighted to switch (and then got very frustrated by the GPL-only tags on various keyring features, but that's another argument). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87fvct4r76@hope.eyrie.org
Re: DE features dependent on Systemd
Svante Signell svante.sign...@gmail.com writes: So I wish you a happy life with current (Debian chosen) technology, it is perfect! No more problems with bugs popping up or people being unable to boot their desktop computers/servers. Merry Christmas :) Thanks! Yeah, it's a pretty nice present, and I'm quite happy about it, although it's going to be a few years before it propagates into my current work (where we're using Ubuntu LTS for complicated reasons). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/871toda6z4@hope.eyrie.org
Re: Technical committee acting in gross violation of the Debian constitution
Christoph Anton Mitterer cales...@scientia.net writes: On Thu, 2014-12-04 at 21:14 +0100, Marco d'Itri wrote: FastCGI is another thing that almost nobody can afford when hosting a significant number of web sites. Why not? When I've investigated in mod-php vs. cgi vs. fcgi, the fcgi turned out to have roughly the same performance as mod-php (plain cgi of course much worse). FastCGI, at least the normal way I've seen it deployed, sets up a running daemon for each script that's running via FastCGI. (You can spawn those dynamically to some extent, but that's fairly limited, and then you're mostly reproducing a standard CGI environment with extra complexity.) If your web site hosting has unbounded numbers of untrusted scripts that it may be running (I've had to solve this problem for unique script counts over one million), that FastCGI environment is rather... challenging to set up. In the long run, that sort of sandbox environment is dying for other reasons, and people are gravitating towards application platforms like Drupal that pose other, different maintenance challenges. But FastCGI is not a replacement for standard CGI if you actually fully used the capabilities of standard CGI (merits of allowing that aside -- it's hard to turn insecure things off when tens of thousands of people have written lots and lots of web sites assuming that behavior). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/871tofx8v8@hope.eyrie.org
Re: Technical committee acting in gross violation of the Debian constitution
Enrico Weigelt, metux IT consult enrico.weig...@gr13.net writes: Same for me. If there really is some functionality which some DEs really need, why not having an entirely separate tool for that ? Anyways, I still didn't understand why udev is bundled within systemd. And I don't understand why you think your personal level of understanding is interesting to the hundreds or thousands of people on this list. Apparently, although you don't understand this, you don't care enough about your lack of understanding to go do the mild amount of research required to figure out why both of those decisions were made. It's not like anyone's hiding the reasoning. Both decisions have been discussed dozens of times over the past two years on this mailing list and many other archived mailing lists around the Internet. You could also just politely ask the people who made those decisions if you really can't find the answer. (Being a polite person, I'm sure that you would understand that an answer would be a favor to you, and wouldn't use that just as an excuse to argue with people about their decisions.) If you are curious and wanted to understand, there are many obvious resources available for you to use. You might not *agree* with the decisions or the reasoning behind them, but that's not the same thing as not *understanding*. Please, either go do the research required to answer your own question, or don't, but stop telling all the rest of us about your lack of understanding. At this point, this sort of message is essentially a troll, since someone will see it, be unable to resist the urge to be helpful, try to explain the reasoning *yet again*, and off we'll go down the same futile merry-go-round of argument. Each time someone explains or asks for an explanation for the motivation for systemd to them again, a kitten dies. Please, think of the kittens. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87tx1atz1c@hope.eyrie.org
Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie
Matthias Urlichs matth...@urlichs.de writes: Non-standard inittab entries should surely be displayed and warned about, but IMHO that's not sufficient reason to not switch the other 99.99% who never touched their inittab. In the server world, I'm pretty sure you are significantly underestimating the number of systems with a custom inittab, although automatic handling of all the various ways to spawn a useful serial console would cut down the numbers somewhat. But we're pretty late in the release cycle to do enough analysis to try to figure out what those all are. (Where I've worked, this has always been custom, replacing /etc/inittab with a local configuration file, so the analysis isn't trivial.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/8761dzf9qh@hope.eyrie.org
Re: Technical committee acting in gross violation of the Debian constitution
Noel Torres env...@rolamasao.org writes: It is a gut feeling also, and one that has been widely expresed by others, (with better and worse words) that Debian server admins will not be pleased with an init system which is bigger and does not use shell scripts to start system services. And many of us who actually *are* Debian server administrators have said repeatedly that your gut is wrong, in the innumerable versions of this conversation that have happened over the past two years. This idea that systemd is somehow aimed at desktop environments and is not useful or a good idea for servers is complete nonsense. I say this as someone who barely uses desktops at all and who has been running large-scale server environments professionally for twenty years, and who has had extensive conversations on this topic with professional colleagues in environments ranging from a hundred servers to hundreds of thousands. Obviously, there are some server administrators who disagree with me, just like there are some desktop users who don't like systemd, and some embedded developers who don't like systemd (and others who love it and think it will help their work immensely). The opinions about systemd do not at all break along the lines that you have imagined. Given that, could you please stop trying to divide Debian's users into artificial opposing camps, and then trying to play those camps off against each other? I really don't think that Debian needs yet more attempts at forming in-groups and out-groups and excluding people based on what they use Debian to do. The decision about the default init system to use for Debian was made with an eye to *all* of Debian's users and all of their varying use cases. You are certainly entitled to disagree with that decision on its merits, but if you're going to claim that it was made solely for desktop users while ignoring server administrators or embedded users, directly contradicting the statements of the people who were actually involved in that decision-making process, you're going to need some really good evidence to back up that assertion. Not just a gut feeling. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87zjbd33to@hope.eyrie.org
Re: Technical committee acting in gross violation of the Debian constitution
Josh Triplett j...@joshtriplett.org writes: gnome Depends: gnome-core, which Depends: gnome-user-share, which Depends: apache2-bin (or apache2.2-bin in stable, which is a transitional package depending on apache2-bin in unstable). Also, just in general, popcon is not going to be particularly helpful in getting a count of servers, since they often come in large numbers in single locations, and there's often an institutional policy against running things like popcon that expose details of internal configurations to any outside party. Stanford wasn't even willing to run popcon on any institution server, let alone companies with more locked-down production environments. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/8738952q7a@hope.eyrie.org
Re: systemd, fstab, noauto and nofail
Adam Borowski kilob...@angband.pl writes: There's currently no way to express which mounts are needed for which functionality. While that's true, I'm not sure that fine-grained control of this is required here. We can get a long way with just a way to indicate whether a mount is important or unimportant. And that, in turn, is exactly what nofail is for, which is already supported. The problem is that people haven't been using it, because nothing has forced them to use it or told them that they should have been using it, since sysvinit essentially marks every mount nofail in terms of the practical effects of its behavior. This sounds like a failure to provide a _non-fatal_ error message. I wish there were some way to reliably deliver to the user non-fatal boot error messages. But for both the desktop and the server case, it usually requires quite a bit of effort to go look at the boot messages. They generally scroll by rather quickly, servers often have unattended consoles, and the desktop boot messages are usually hidden pretty quickly by the desktop manager. * systemd: in preinst, check if any fstab lines without noauto or nofail are not currently mounted -- if so, abort the installation as it would result in an unbootable system. Yeah, this is the solution I've been proposing. I also like the idea of not having ssh depend on all local file systems to be mounted. I think it's going to be pretty rare to have a system that has /lib and /etc mounted but can't start ssh. In theory, that's possible with a split / and /usr, but as we've discussed in other threads, that's an extremely unusual configuration these days. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87r3wvw4o7@hope.eyrie.org
Re: systemd, fstab, noauto and nofail
Jonas Smedegaard d...@jones.dk writes: Quoting Russ Allbery (2014-11-22 18:01:12) I also like the idea of not having ssh depend on all local file systems to be mounted. I think it's going to be pretty rare to have a system that has /lib and /etc mounted but can't start ssh. In theory, that's possible with a split / and /usr, but as we've discussed in other threads, that's an extremely unusual configuration these days. It surprises me that it is considered extremely unusual: It is an option offered in stable debian-installer without any advanced trickery (just select LVM and pick the last option) - I quite commonly use that, and would be surprised if I am alone in that. Sorry, I didn't express that very well. I know that people do partition / and /usr separately; what I was going to say and then didn't is that the *error* case is extremely unusual. In other words, if you can mount /, you're probably going to be able to mount /usr, because it's generally on the same disk. What's extremely unusual is a local / and a network-mounted /usr, or other sorts of split situations where it's at all likely that mounting / would succeed but mounting /usr would fail. The question, though, is can we express this requirement properly? We do need to make sure that /usr is mounted before ssh is started, but we don't really want to wait for mounting all the random other file systems that someone might have. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/8761e7vxs4@hope.eyrie.org
Re: systemd, fstab, noauto and nofail
Noel Torres env...@rolamasao.org writes: Many thanks I do not understand, then, how this is different from what sysvinit's mountall.sh does (or at least what I understand it does). As I understand it, sysvinit didn't care whether mountall.sh succeeded or failed. So even if a bunch of mounts failed, it went on to boot the system, including everything that wasn't supposed to start until after all file systems were mounted. That meant that some folks have systems that they think are happily booting with sysvinit with a bunch of failing mounts, and, when they switch to systemd, things that declare a dependency on mounted file systems never start because the file systems aren't successfully mounted. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/874mtsypcc@hope.eyrie.org
Re: Pre-Depends: init-system-helpers
Bastien ROUCARIES roucaries.bast...@gmail.com writes: Le 19 nov. 2014 21:33, Russ Allbery r...@debian.org a écrit : Yes, absolutely. Likewise for cron jobs, etc. That's something that I don't think we're doing a great job of right now, and really should improve. Could lintian help here ? Yes, although it's tricky. If a package has only an init script, and that init script has a custom action to do the right thing for log rotation, then running that with service or /etc/init.d is actually okay. But those are the patterns that we should otherwise be wary of. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87y4r5et3p@hope.eyrie.org
Re: init system policy
Jonas Smedegaard d...@jones.dk writes: Seems to me this is a similar limitation as for config.d structures - as an example apache2 is now far more modular than in the past but I no longer as sysadmin get notified what exactly has changed when I upgrade a system with customizations, as I did in the past thanks to the monolithic configfile being a conffile. There was some discussion about this a while back, and I vaguely remember that systemd comes with a tool that will tell you exactly what you're overriding. I'm not sure if that work got all the way to producing a nice Debian-aware tool or not. Personally (and this is just a wishlist), I'd love to have functionality similar to apt-listchanges that would (optionally) show me a report of every change to any unit file that I've overridden on each upgrade. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87tx1tet03@hope.eyrie.org
Re: Bug#769907: general: non-sysvinit init systems are made of fail
Sam Hartman hartm...@debian.org writes: 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 suggestion that I made (I think in one of the OpenSSH bugs about this) was that, during a transition from sysvinit to systemd, we could check for any file systems listed in /etc/fstab but not currently mounted on the system, and warn the administrator that mount points that are defined but always fail will be handled differently under systemd. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87egsxepd5@hope.eyrie.org
Re: Pre-Depends: init-system-helpers
Bob Proulx b...@proulx.com writes: No. That is too late. By the time you are disabling something it has already been installed and started in postinst scripts. Using policy-rc.d is the only way to prevent unknown anythings from being enabled before installing. Ah, yes, that's true. P.S. Related to this is that I really think that if you want a daemon running and install it and the package can configure it and start it then it should do so. If you don't want something running then don't install it. Or remove/purge it. I am not advocating any change that would get in the way of making an installation not start a daemon that it can do so. The chroot case really is a special case. Yes, the general Debian practice is to assume that, if you install a daemon, you want the daemon running. If that's not the case and you don't want it to start even temporarily, you're correct that policy.d is the only mechanism to achieve that. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87k32rhwp2@hope.eyrie.org
Re: Pre-Depends: init-system-helpers
Jonas Smedegaard d...@jones.dk writes: Which implies, I believe, that any other way of starting daemons should also respect policy-rc.d if it can lead to automated triggering. Example: if a logrotate snippet uses update-rc.d force-restart ... then suppressing that deamon with policy-rc.d will be circumvented when cron triggers log rotation. Yes, absolutely. Likewise for cron jobs, etc. That's something that I don't think we're doing a great job of right now, and really should improve. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87bno3hqwm@hope.eyrie.org
Re: Pre-Depends: init-system-helpers
Simon McVittie s...@debian.org writes: If you meant service, I think the answer is that's a bug. service intentionally doesn't respect enabledness either, under at least sysvinit and systemd, so it's a bug even in the absence of policy-rc.d. Right, service is a tool for the local administrator. service should be exactly the same as running the /etc/init.d script directly under sysvinit, except with a sanitized environment and respecting an upstart or systemd init system and its way of doing things if that's what one is using. That means a manual service start should override any policy.d setting just like running /etc/init.d/service start would. I think the valid options for logrotate are either invoke-rc.d, or something that uses package-specific knowledge that a particular operation won't start the daemon if it isn't already running. Yup. invoke-rc.d if it's safe and won't start a service that's not already running, otherwise something specifically crafted for that service that has the right semantics. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/8761eaj2rt@hope.eyrie.org
Re: init system policy
Simon McVittie s...@debian.org writes: I can see the functional regression (minidlna is running as a totally unprivileged user now, and can't read my music any more!) but not the security hole: its default user presumably has as little access as nobody, so I don't see how that's insecure? The scenario I'd be concerned about is if the init script were modified to run the program as a different user that was subject to, say, a SELinux policy. Changing users back might escape additional security measures like that. Another scenario is if the default Debian user conflicted with some user on the local system that was already being used to do something else. In general, I would treat anything involving running daemons as users other than the intended user as a potential security vulnerability unless proven otherwise, given how fundamental user and group are to the entire UNIX security model. 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, Yeah, this seems like the right solution to me too. Drop a configuration fragment in /etc/systemd that overrides the user and group and then don't touch it again. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/877fys6wqz@hope.eyrie.org
Re: on reloading services from logrotate
Helmut Grohne hel...@subdivi.de writes: There is a fourth one that restarts/reloads services: logrotate Please excuse a little excursion into the inhomogeneity of signalling services from logrotate. I did a little bit of research and came up with the following numbers (sid i386+all main): - 360 packages shipping logrotate files - 192 with scripts (e.g. reloading a daemon) - 64 using invoke-rc.d - 34 invoking /etc/init.d/something directly - 24 killing via pidifle - 13 using killall (I couldn't believe it at first) - 7 using start-stop-daemon (the policy has an example) - 6 using the service wrapper mentioned above (some overlaps: e.g. [ -x /etc/init.d/foo ] service foo reload) We had a discussion on the Policy team about this a while back, and I think our consensus was that everything in Debian, like logrotate and cron jobs and so forth, should use invoke-rc.d. But I think there were some caveats to that, and I don't remember the full context. I suspect it's a buried unresolved Policy bug. Hm. My brain is trying to surface some observation about how using a signal on the PID was safer in some situations than using invoke-rc.d. Maybe in cases where the daemon is running but policy.d says it shouldn't be? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87r3x05crt@hope.eyrie.org
Re: init system policy
Sam Hartman hartm...@debian.org writes: Russ == Russ Allbery r...@debian.org writes: 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. Ah, sorry, I mixed two threads. Yes, for the original author's problem, where the user should configure the user/group for the daemon, debconf makes sense. I had mixed that up with cases where people modified init scripts to run things under a different user than the default, which is a somewhat harder problem. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87d28jvr2h@hope.eyrie.org
