Re: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]
On 2022-11-10 at 16:37:53, Tollef Fog Heen wrote: > ]] Robie Basak > > > But are you in essence saying that libpam-tmpdir requires that *every > > maintainer script* that runs things as non-root, or starts processes > > that do that, unset TMPDIR first? > > I think it's more wide than that: If you change UID, you need to > sanitise the environment. Your HOME is likely to be wrong. PATH might > very well be pointing at directories which are not appropriate for the > user you're changing the UID to, etc. I believe this is the best practice. For example, sudo typically passes through only a handful of environment variables, such as TERM, to avoid things like insecure PATH entries. For example, if MySQL invoked a binary in PATH and I had a custom script named the same thing that had insecure behaviour when invoked as another user, that would be bad. OpenSSH also sanitizes the environment passed over the connection. Without getting into a debate about systemd, this is one the pieces of functionality it provides, since it runs binaries in a clean environment. You can probably get most of that in a sysvinit script by using `env -i` with a handful of environment variables specifically overridden if necessary. Then it would be very obvious what dependencies the binary had on the outside environment. > > I think the answer to this should probably be established by the > > libpam-tmpdir maintainer and documented first, for fear of someone else > > later coming along and saying that the maintainer script incorrectly > > ignores TMPDIR because we started ignoring it to resolve this bug. So I > > copied debian-devel@ for comment. > > I'm not sure this is libpam-tmpdir specific, but rather a bit more > general: what are the expectations that maintainer scripts can have > about the environment they're running in, and how do we make those > expectations hold? This should probably then be documented in policy. I agree documentation here is helpful. For reference, this was an invocation from `sudo aptitude` as part of a normal package upgrade, which I think is a relatively common situation to be in. Possibly also an initscript helper which enables developers to do the right thing automatically, or a flag to start-stop-daemon, or other tooling would be beneficial to help people easily solve this problem without thinking too much about it. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Re: please use signed git commits (and tags)
On Mon, May 25, 2015 at 01:53:28PM -0300, Henrique de Moraes Holschuh wrote: Commits: trying to change the signature will change the commit hash. So, it works just like amending the commit. In fact, git commit --amend -S will sign/re-sign the commit by creating a new commit, just like any other ammending of commits works. Note that rebase (or anything that changes the commit itself) will cause it to lose the signature, and I don't think git will ask you to sign them again. If you want to sign a rebase or cherry-pick, use -S. git rebase -S will automatically sign commits all rebased commits except those created with git commit, where you'll have to pass -S yourself. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: please use signed git commits (and tags)
On Sun, May 24, 2015 at 03:12:21PM +0100, Iain R. Learmonth wrote: Hi, On Sun, May 24, 2015 at 01:02:38PM +0200, Thomas Koch wrote: Git supports signing of commits since version 1.7.9. Everybody should sign git commits always. What is the overhead on this? I have a 4096-bit RSA key and the overhead is not very noticeable when doing normal development. The only time it seems noticeable is when you're doing a rebase -S. I do recommend using passphrase caching with gnupg-agent (or gnome-keyring, or whatever) when rebasing, though, so you don't have to enter your passphrase repeatedly. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Architectures where unaligned access is (not) OK?
On Sat, Nov 22, 2014 at 09:42:43PM +0100, Jakub Wilk wrote: * Henrique de Moraes Holschuh h...@debian.org, 2014-11-21, 17:34: i386: __asm__(pushf\norl $0x4,(%esp)\npopf); It works! Actually, it works so well it makes puts(hello world) die with SIGBUS. :-( Yeah, that's my experience, too. glibc is not alignment check-safe on i386 and amd64. If you turn it on in an LD_PRELOAD using _init, it segfaults before main. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Bug#765512: general: distrust old crypto algos and protocols perdefault
On Wed, Oct 15, 2014 at 11:47:07PM +0100, Ian Jackson wrote: Joey Hess writes (Bug#765512: general: distrust old crypto algos and protocols perdefault): Instead, it makes sense to adapt workflows that do not trust git hashes, which mostly means making signed tags and commits, and checking the signatures. This is something Debian could improve in many areas, I'm sure. The whole git content-addressable-object-store model relies utterly on the hashes. A signed tag is a (weirdly formatted) GPG-signed text file (the tag) containing the sha1 hash of a text file (the commit) containing the sha1 hash of a binary file (the tree object) containing the sha1 hasshes of the actual files at the top level and of further binary files (tree objects) containing further sha1 hashes of further files and further tree objects. All of these hashes are translated into their preimiages by looking them up in the object store. I've expressed interest in the past for changing the hash algorithm in Git, but the work to do so is significant. It basically means converting every place that has a hardcoded unsigned char[20] and moving it to a struct (later, a union) that can be treated more or less opaquely. If someone is interested in working with me on this, please let me know off-list, and I can provide more information about this. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Bug#765512: general: distrust old crypto algos and protocols perdefault
On Wed, Oct 15, 2014 at 01:58:34PM -0700, Russ Allbery wrote: It's unlikely that you're going to be able to make better cost/benefit decisions about these things than well-informed upstreams for general use cases. Debian is targeted for general use cases. If we were making a security-hardened distribution that chooses security over interoperability across the board, we may well want to make other decisions. Unfortunately, not all upstreams make good decisions. OpenSSL ships with a set of default ciphers that is completely insecure. There is no reason that every application using OpenSSL directly or indirectly[0] should have to disable exportable ciphers, especially since almost nobody uses them (nor wants to). HIGH:MEDIUM:!aNULL is a better default. It's fine to defer to upstream where they have a history of good, prudent decision making, but there are upstreams where that's clearly not the case, and Debian should step in and ship software that doesn't have security holes by default. [0] Including virtually every Ruby script that uses HTTPS. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: bash exorcism experiment ('bug' 762923 763012)
On Fri, Oct 03, 2014 at 09:39:29AM +1000, Russell Stuart wrote: IMO, if Debian has decided the in the default case /bin/sh == dash, then the policy should say #!/bin/sh scripts must work with dash. It then becomes trivial for Developers to test their code conforms with policy. If we allow /bin/sh to be linked to other shells, policy should say those shells must implement all the features /bin/dash implements so that any script that works with dash must also work with them. This isn't possible, as there are some corner cases in which dash and bash work differently, and those are both explicitly supported choices for /bin/sh. These areas are in extensions that are not part of POSIX or the extended set of features required by Policy. As is stands, the one thing you can guarantee we will get from our policy saying #!/bin/sh scripts work with a shell that does not exist and can't be tested against is scripts that have never been tested against that policy. The set of features that Debian's /bin/sh must support is fairly limited. It's not very difficult at all to implement a shell script appropriately. Every shell script I write these days will work in bash, dash, and posh, whether I'm writing it to run on a Debian system or not. If Debian really wants to implement the policy as described, then it should do the work required to produce robust software that conforms with it. In this case that would mean producing a shell that behaves as described, which we make /bin/sh by default. Perhaps a flag to dash stripping all of the features not described in SUSv3 features would suffice. The shell you're describing is posh. It implements exactly those features, and nothing more. Unfortunately, some developers have outright refused to make their software using /bin/sh work with posh, even when provided with a patch (e.g. #309415), to the point that last time I tried to use posh as /bin/sh, the system wouldn't boot. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Allow encfs into jessie?
On Mon, Sep 29, 2014 at 06:43:38AM +0200, Christian PERRIER wrote: Quoting Eduard Bloch (e...@gmx.de): Template: encfs/security-information Type: note _Description: Encfs Security Information Besides using an Evil Debconf Note (;-) ), is there a reason for capitalizing every noun in the note title ? That style of title capitalization is very common in the United States (and Canada, it appears). It's less common in British English. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Standardizing the layout of git packaging repositories
On Fri, Aug 15, 2014 at 08:17:16PM +0200, Marco d'Itri wrote: On Aug 15, Raphael Hertzog hert...@debian.org wrote: - are there other important things to standardize? Do not try to make other people change their workflows without evident benefits (pro tip: standardization in itself is not one) or they will be annoyed and just ignore your work. I send a lot of one-off patches to packages. I like to file a bug and follow it up with a patch. Unfortunately, everybody doing things a different way makes it unpleasant to do that. (And yes, I know about README.source.) Right now, I just build the source package repeatedly until it works, unless the package doesn't build twice in a row, in which case I swear repeatedly and no patch is sent. If there's a standard workflow, it makes my life easier and results in a patch that works better for the maintainer. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Reverting to GNOME for jessie's default desktop
On Thu, Aug 07, 2014 at 10:34:29PM -0500, Gunnar Wolf wrote: Well, it's roughly that time. :) So I'd like to plainly request GNOME is reinstated as the default desktop environment for a number of reasons. One of the reasons put forward for switching to Xfce was size on the installation images; could you (and/or debian-cd) address this? Specifically: 1) Would you want the default CD/DVD image to use a GNOME even if GNOME was unable to fit on a single image? 2) Would the GNOME team consider a less-complete DE for cases where image size is a restriction? ...And I'd like us to consider this point as well: How important are CD images nowadays? Who has a CD that cannot read a DVD? Will they be able to use on said machine a modern desktop environment as resource-demanding as, say, i3 or fvwm? I used to do freelance desktop support (in the US) and there are a decent number of machines that don't have DVD drives. You would be surprised how resistant people are to upgrade their machines. (Also, people give their old, less powerful machines to the small kids.) Most of these machines would work just fine with XFCE, but not GNOME. DVD drives are also less common on non-PC hardware, especially the older stuff that can be readily acquired for less than USD 1000. Also, I always carried a bootable CD with me, because about a third of machines just won't boot off a USB flash drive for any reason. The BIOS says they will, but it's a lie. I've even owned one of these machines (a fairly recent amd64 box). I would recommend keeping CD images around. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Re: people.debian.org will move from ravel to paradis and become HTTPS only
On Wed, Jul 16, 2014 at 11:43:17PM +0100, Steven Chamberlain wrote: Some sites (I mean, deployments) like to use a caching proxy, especially if many machines use the same resource, and/or bandwidth is scarce. Or even just one machine accessing the same resource often. Maybe this won't apply to anything particular on people.d.o, but certainly a lot of websites are breaking this recently by becoming HTTPS-only. Unfortunately, many of these proxies are broken. The Squid version in wheezy doesn't support HTTP/1.1, so trying to use chunked encoding or 100 Continue (which is required for certain applications[0]) simply doesn't work. And simply not working is one of the best failure cases for broken proxies. Using HTTPS ensures that the broken proxy problem is gone. I'm curious to know the rationale for shutting down HTTP access, because if it is to generally protect web browsers doing web-based login and using cookies, that would typically be covered by HSTS. And the privacy-concious may be using the HTTPS Everywhere add-on. I can't speak for DSA here, but I some of the reasons that I went HTTPS-only is that certificates are relatively cheap, pervasive monitoring is not going away, crypto is so cheap computationally on most platforms that there's no reason not to, and broken proxies suck. [0] Git pushes over HTTP with Kerberos, among many others. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: multiarch: arch dependent header file path choice
On Sun, Jun 29, 2014 at 02:44:21AM +0900, Osamu Aoki wrote: Hi, The path for the arch dependent header file seems to have several options. 1) /usr/include/multiarch/*.h 2) /usr/include/multiarch/packagename/*.h 3) /usr/lib/multiarch/packagename/include/*.h I would like to know rationale for each choice, especially between 2 and 3. Choice 1 is just the default location for most headers. Choice 2 is useful if you have multiple versions of the same library. For example, you might want to have the headers for Ruby 2.0 and Ruby 2.1 installed at the same time. They're going to ship mostly the same headers, so putting them in different directories allows them to be co-installable. Some upstreams prefer this location. Choice 3 is for private header files. Most of Glib's headers are of style 2, but it ships one file, which is autogenerated, in this location because it's only intended to be called from other Glib header files. This method is used because on distributions like CentOS that don't have multiarch, these private header files often contain arch-dependent configuration, so they are placed in /usr/lib or /usr/lib64 as appropriate so that the 32-bit and 64-bit packages are co-installable. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: About a mass bug report not based on Sid or Jessie.
On Tue, Apr 22, 2014 at 01:14:57PM -0700, Russ Allbery wrote: Santiago Vila sanv...@unex.es writes: (a) Diffs are not made to be readable, they are made to update things. As those diffs are the result of an automatic processs, you should only need to look at the updated file, not at the diff. Moreover, if they are unreadable, so are the file being diffed itself. Being readable should not be a concern here. This is absolutely not true in Debian's processes. Both the release team and the security team use diffs as first-class artifacts for doing code review. Furthermore, third-parties use Debian's diffs as the basis for security and feature patches. At work, we ship a slightly modified version of Debian's timezone patches for PHP, and we also have used Debian's security patches as well. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Debian default desktop environment
On Tue, Apr 08, 2014 at 07:24:47AM +, Sune Vuorela wrote: On 2014-04-05, Josselin Mouette j...@debian.org wrote: Especially one as minor as the installation CD which has no actual conceivable use today. At least I don't think that anything 86xish that can't boot from a usb stick is wihtin what we should target as 'default experience'. There are a lot of PC systems where the BIOS claims to support booting off a USB stick but it simply doesn't work. This is actually quite a frequent problem, even on newer systems. That's why I carried a bootable CD with me when I did freelance desktop support. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Debian default desktop environment
On Sat, Apr 05, 2014 at 07:57:50PM +0200, Josselin Mouette wrote: Could you please sum up those discussions and explain what kind of changes you would consider to be productive? I can sum up the discussions that were had last time on debian-devel for you, at least as I remember them. * XFCE fits on one installation CD, which is relevant for those people who have slow or expensive Internet access (which is many parts of the developing world). The older machines which may be more likely to be in use in those areas may not have a DVD drive, or downloading 4 GB for a DVD may be prohibitive in time or cost. * It works better on older and less powerful machines[0]. * Some people claim that the interface is more familiar for non-technical people coming from other operating systems. This is the subject of much debate, however. * Similarly, some people dislike the GNOME shell interface and prefer a more traditional desktop environment[1]. * There were concerns about accessibility support, particularly for the blind[2]. [0] I have personally found this to be the case. I've had older machines where GNOME simply took up too many resources and was sluggish, but XFCE ran fine. [1] The very existence of MATE provides some support for this argument, at least. [2] http://anonscm.debian.org/gitweb/?p=tasksel/tasksel.git;a=commitdiff;h=dfca406eb694e0ac00ea04b12fc912237e01c9b5 -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Debian default desktop environment
On Sat, Apr 05, 2014 at 11:32:07PM +0100, Ben Hutchings wrote: On Sat, 2014-04-05 at 18:18 +, brian m. carlson wrote: [...] * There were concerns about accessibility support, particularly for the blind[2]. [...] Which is unfortunately quite bad in most free graphical desktop environments. Is it actually a strength of Xfce? I didn't think it was. I just realized my statement was unclear. I believe some people had stated that GNOME had regressed in accessibility support at the time, and XFCE was a better choice in this regard. I can't say more because I don't have enough knowledge on the subject. Maybe someone else can. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Bug#741930: reportbug: add current init system information
On Tue, Mar 25, 2014 at 08:12:06AM +0100, Thomas Weber wrote: The fact that a lot of people use a variety of shells does not mean that it makes sense to include it in *every* bug report. How important is the user's shell for every database-, web- or fileserver? How for every office application? How important is it for requests to the release team? Every single bug report for these (pseudo)packages will include this information, so it better be important. As Russ pointed out, it's one line. My suggestion was to avoid people wasting time troubleshooting when a small bit of information might help. I know that I prefer having a little extra information than not enough when trying to fix a bug. It's much better to have this information up front than to have to guess about it, especially since many reporters won't think to mention it. If you know that your package might break by using a certain shell, you can use reportbug's scripts. I don't think the maintainers even considered whether debconf would be broken under zsh. I certainly didn't think it would be, or I wouldn't have set zsh as /bin/sh. Also, it doesn't make sense to make hundreds of packages duplicate the same (or worse, slightly different and potentially subtly broken) code, when it could be in one single place. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Bug#741930: reportbug: add current init system information
On Sun, Mar 23, 2014 at 08:41:48AM +0100, Thomas Weber wrote: And while we are at it, do we *really* need the information about /bin/sh in at least a significant share of today's bug reports? You probably want it, because a decent number of people use a shell other than bash or dash as /bin/sh. For example, one might use mksh-static because it's statically linked. Also, someone might try to use zsh as /bin/sh, which doesn't work (it breaks debconf). It's much better to have this information up front than to have to guess about it, especially since many reporters won't think to mention it. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: CUPS is now linked against OpenSSL
On Mon, Jan 13, 2014 at 11:03:04PM -0500, Daniel Kahn Gillmor wrote: Alternately, does anyone know anyone from the polarssl community who we could cajole into patching that TLS implementation into CUPS? I'd like to point out that PolarSSL doesn't correctly implement TLS 1.0 since it doesn't support the mandatory cipher suite. That isn't a practical problem, since nobody implements only that cipher suite, but it is a conformance issue that needs to be addressed. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: GnuTLS in Debian
On Sun, Dec 22, 2013 at 08:12:40PM +0100, Andreas Metzler wrote: How to continue from here/solve this: - #1 Fork LGPLv2.1+ GMP (version 4.2.1) for Debian. This seems like the best idea, as it lets us use newer versions of GnuTLS that support elliptic curves with the minimum amount of pain. #2 Fork GnuTLS 2 for Debian. #3 Hope that GMP is relicensed to GPL2+/LGPLv3+ #4 Hop nettle switches to a different arbitrary precision arithmetic library. #5 Declare GMP to be a system library. I don't think this is actually feasible, due to the way the GPLv2 is actually written. Otherwise, we wouldn't be using GnuTLS at all, since OpenSSL would be satisfactory for everything. #6 Move to GnuTLS3, drop GnuTLS2. Packages which cannot use GnuTLS3 for license reasons will need to drop TLS support or be relicensed or be ported to a different TLS library. I don't think this option is a good idea. It will leave git without HTTPS support, since libcurl3-nss doesn't actually work for HTTPS. libcurl3-nss requires an additional library not in Debian for the crypto support to work at all, and despite me filing bugs, neither the NSS nor the curl maintainers have stepped up to fix this. This also doesn't consider the fact that NSS provides poorer crypto support than either OpenSSL or GnuTLS, although it's getting better. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Fwd: Proposal: switch default desktop to xfce
On Fri, Oct 25, 2013 at 05:49:59PM +0200, Adam Borowski wrote: On Fri, Oct 25, 2013 at 07:51:48AM -0700, Andrew Kane wrote: As someone who deals with a lot of random donated hardware, I can attest that we run into these cases frequently. It may be rare that new systems lack these capabilities, Donated x86 hardware that lacks an USB port? I kind of believe that not. I used to have an x86-64 box that claimed to support booting from a USB stick but steadfastly refused to do so. As someone who until recently did desktop support for years, I can tell you that there are a lot of machines I've encountered that can't boot off a USB stick, and maybe about a third of those don't do DVD. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Proposal: switch default desktop to xfce
On Fri, Oct 25, 2013 at 02:15:02PM -0400, Joey Hess wrote: Also, I was not in a position to try gnome 3.4 myself at all, hardware, and bandwidth wise, until rather too late in the release cycle. I didn't see conclusive proof that gnome 3.4 was really the wrong default for wheezy until I started putting it on end-user machines and seeing them struggle with it, and then be perfectly happy when switched to xfce. (A few such real world tests are much more useful than a metric mutt-load of threads.) I can confirm that XFCE tends to work much better than GNOME on older hardware, and has for years. Back when my iBook G3 was my only laptop, I installed XFCE on it because GNOME eventually became too heavyweight. I can also say that generally people who come from Windows and Mac OS X tend to understand and be able to work with XFCE a little more easily than GNOME, in my experience. I have friends who have seen me use both, and they have generally found GNOME Shell a bit confusing when they've needed to use my laptop. Finally, XFCE provides a bit more customizability out of the box than GNOME does, or at least it did when I switched. I distinctly remember that there were several settings that XFCE provides in the settings dialogs that required arcane trips through the gconf/dconf settings, if they were there at all. It's possible that's changed, though. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Mon, Jul 22, 2013 at 07:17:04PM +0300, Uoti Urpala wrote: brian m. carlson wrote: Since Debian is always in need of developers and volunteers, it isn't objectively reasonable to expect that forking a project will be possible. One thing that needs to be taken into consideration is the *likelihood* that upstream will take development in an undesirable direction, or in a direction that is not acceptable for Debian. If you don't do development, and nobody sharing your views does either, then there's a limit to the extent you can choose your direction just by refusing to follow those that do develop things further. You can't stick with Minix forever even if you think the direction of Linux is undesirable. My point is that Debian developers create lots of great software, and certainly maintain lots of patches to software for which Debian is not upstream. But it's simply not feasible for Debian to be the upstream for all software. I don't think it's controversial to say that Debian developers prefer upstreams that take concerns relevant to Debian and its users into account. Suppose that in the future systemd does go in a direction you don't like. Now would it have done any good for Debian to not adopt it? Not really, if nobody develops a competitive alternative to its functionality. Not using it would only make Debian obsolete for most use cases. And the most realistic way to create a competitive alternative going in a different direction would be to fork systemd, so adopting current systemd would not make moving to such alternatives harder. The vast majority of the work I do on a Linux box, desktop, laptop, or server, does not involve init in any way. It is therefore not accurate to claim that using an init system other than systemd would make Debian obsolete. For example, RHEL 6 and Ubuntu use upstart, and I think it's hardly accurate, based on their significant adoption, to call them obsolete. For example, if an upstream expresses disinterest in supporting non-PC architectures, that may be a bad piece of software for Debian to place in an important role, even if it currently works on all our architectures, since Debian is very portable among different architectures. Of course, this isn't relevant to systemd, as it has no hardware- specific code and supports embedded platforms for which Debian is too bloated. This was meant as an illustrative example of a common problem with upstreams, not as a problem particular to systemd. systemd upstream has made a lot of controversial decisions that Debian may or may not want to support: combined / and /usr, the journal, logging to the kernel ring buffer, lack of portability to non-Linux kernels, and merging udev and systemd are a few examples. If Debian decides that it is preferable for whatever reason not to adopt one or more of these decisions, the willingness of upstream to accept that decision and work with Debian instead of saying, Too bad, so sad, is something that should be considered before making a major change. I'm not saying not to use systemd, I'm just suggesting making a well-reasoned decision. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Mon, Jul 22, 2013 at 02:59:20AM +0300, Uoti Urpala wrote: Whether your argument was honest or not, I think it was a bad one. OK, perhaps you have concerns about the philosophy behind systemd and where that might take it in the future. Such philosophy issues are rather subjective. But your argument objectively fails at the ... and therefore moving to systemd may not be the right choice part. Your concerns, even if taken seriously, do justify such a conclusion. If systemd development goes in a direction you don't like, the rational answer is to fork it and do better if you can. Leaving Debian behind with an inferior init system is not an answer to your concerns. Since Debian is always in need of developers and volunteers, it isn't objectively reasonable to expect that forking a project will be possible. One thing that needs to be taken into consideration is the *likelihood* that upstream will take development in an undesirable direction, or in a direction that is not acceptable for Debian. For example, if an upstream expresses disinterest in supporting non-PC architectures, that may be a bad piece of software for Debian to place in an important role, even if it currently works on all our architectures, since Debian is very portable among different architectures. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Berkeley DB 6.0 license change to AGPLv3
On Fri, Jul 19, 2013 at 04:29:21PM +0200, Ondřej Surý wrote: Hi, would FOSS Exception similar to http://www.mysql.com/about/legal/licensing/foss-exception/ fix the relicensing problem? If so, I will propose Oracle developers to add the FOSS Exception to Berkeley DB licensing. The MySQL FOSS Exception doesn't include 4-clause BSD, so it still might bar some software to create derivative works with Berkeley DB, but the list would be considerably shorter. Or they will need to add the 4-clause BSD license to the exception list. Notably, it's also missing the GPL version 2. This isn't a problem for MySQL, since it's already GPLv2, but there's probably quite a bit of software that is GPLv2 that uses Berkeley DB. Also, there is a wide variety of BSD licenses that are incompatible, as you've pointed out. Personally, I think the easiest and best solution is simply to stick with Berkeley DB 5.3. It avoids all the pain of relicensing and the inevitable licensing bugs that *will* show up. Not to mention that some upstreams will be unamused at Oracle's shenanigans and won't want to support BDB 6. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [Popcon-developers] Encrypted popcon submissions
On Sat, Jul 13, 2013 at 02:33:57PM +0200, Guillem Jover wrote: Hmm, do you have a reference? I've looked in the gnupg git master and stable-2.0 branches and I don't see any obvious mention of this on the NEWS file, or commit messages after a quick search. I'd fine it very strange that such option would disappear, and it would mean that for example dpkg-dev could not use gnupg 2.x at all then. Upstream has indicated an intention to remove multiple keyring support in GnuPG 2.1. I can't find the reference to the explicit statement where Werner said he was going to do that, but you can see opposition on gnupg-users in the following threads: http://lists.gnupg.org/pipermail/gnupg-users/2011-August/042699.html http://lists.gnupg.org/pipermail/gnupg-users/2011-August/042725.html As you can see from the threads above, I agree that it is a bad idea. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [Popcon-developers] Encrypted popcon submissions
On Thu, Jul 11, 2013 at 03:33:21PM +0200, Bill Allombert wrote: GPG=/usr/bin/gpg if [ $ENCRYPT = yes ] [ -x $GPG ]; then POPCONGPG=$POPCON.gpg rm -f $POPCONGPG $GPG --no-default-keyring --keyring $KEYRING --trust-model=always \ I know you're using GnuPG 1.x here, but be aware that upstream has removed the --keyring option in newer 2.x versions, so this will break at some point in the future if GnuPG 2.x gets used. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Switching to mozilla ESR in stable-security
On Sun, Jun 02, 2013 at 12:10:56PM +0300, Andrei POPESCU wrote: On Ma, 28 mai 13, 22:33:03, Moritz Muehlenhoff wrote: As such, we'll switch to releasing the ESR releases of iceweasel and icedove in stable-security. Would it be possible to switch to the Mozilla branding in this case? I suspect not, since we are likely still going to apply the 40 patches that we currently apply. Also, such a major change is likely to break things in a security upload. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: systemd .service file conversion
On Fri, May 31, 2013 at 06:12:38PM +0200, Ondřej Surý wrote: That doesn't mean the toys are not important (...all work and no play...), they are, but they must not stop the inovation. And as we have sacrificed niche architecture and made them non-release, we must be also prepared to do the same with non-linux kernels if we have to. With regard to innovation, FreeBSD has had integration between traffic control and the firewall in pf for a long time. Linux still requires that you assign arbitrary integers as markers and keep them in sync between two different sets of configuration files, and I have never seen a tool to handle this automatically. pf also has had passive OS fingerprinting far longer than Linux has, and it is well-documented and works almost out of the box, unlike iptables on Linux. I would argue that the FreeBSD (and originally, OpenBSD) kernels are far more innovative (and far easier to use) in this respect. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: libnss consolidation (was: X.509 and CA certificates for other purposes (i.e. the IGTF))
On Fri, May 31, 2013 at 12:19:27PM +0200, Bastien ROUCARIES wrote: On Fri, May 31, 2013 at 4:42 AM, brian m. carlson sand...@crustytoothpaste.net wrote: NSS does not support TLS 1.2. Since RC4 is not used securely in TLS, and the only other choice in TLS 1.1 and earlier is block ciphers with CBC, this means that there are no secure choices. I know the lack of TLS 1.2 support has caused customers of $DAYJOB endless heartache with regard to PCI compliance. Not true anymore: https://hg.mozilla.org/projects/nss/rev/5a9fa031aca5 Upstream bug 480514 is still open, and while it may have landed in the main HEAD, it is not in any released version, and not in Debian. It would be irresponsible to transition to NSS when that would mean a regression in security for users. NSS supports fewer algorithms than either OpenSSL or GnuTLS. Please fill bug: Gnutls is really crappy about suid see http://lists.debian.org/debian-devel/2010/03/msg00298.html See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543941 And openssl has problem about license I'm not saying these problems don't exist, but they have no bearing on the fact that OpenSSL and GnuTLS support far more algorithms. Also, it's hard to tell what algorithms and protocols are supported (and how to use NSS at all), since Debian does not include documentation and much of the d.m.o documentation is seriously out of date. We can't expect everyone to switch to NSS without accurate, maintained, and distributed documentation. NSS is also slow to accept patches and new features upstream. It took quite a long time to get TLS 1.1 and TLS 1.2 in, even when not having them in had negative security implications. Finally, does NSS support OpenSSL-style algorithm specifications to select the protocols and algorithms used? Lots of programs expect to be able to pass this information to the library, and parts of e.g. the Postfix configuration would fail to work without it. This functionality is required for PCI compliance, which I'm sure is something lots of Debian's users want. I'm all for crypto consolidation, but only if doing so doesn't cause regressions in security or functionality. Right now, that doesn't seem to be the case. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: libnss consolidation (was: X.509 and CA certificates for other purposes (i.e. the IGTF))
On Thu, May 30, 2013 at 04:04:47PM +0200, Bastien ROUCARIES wrote: Cons: - not all crypto libraries are equivalent; choosing one will exclude some functionality provided by others SEE compat layer - we somehow have to deal with legacy systems that can't convert - adoption of new software that uses something else is harder NSS does not support TLS 1.2. Since RC4 is not used securely in TLS, and the only other choice in TLS 1.1 and earlier is block ciphers with CBC, this means that there are no secure choices. I know the lack of TLS 1.2 support has caused customers of $DAYJOB endless heartache with regard to PCI compliance. NSS supports fewer algorithms than either OpenSSL or GnuTLS. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: systemd .service file conversion
On Mon, May 27, 2013 at 08:38:44AM +0200, Helmut Grohne wrote: On Sun, May 26, 2013 at 10:27:53PM +, brian m. carlson wrote: At the risk of adding another level of indirection, we could add a meta-init format that can generate an appropriate file for any of these. Are you aware of http://wiki.debian.org/MetaInit (packages metainit and dh-metainit)? That work was started like eight years ago. Unfortunately it didn't take off yet. The only package using it is infon. I was not. A meta-init format would make everyone equally happy (or miserable, depending on your point of view), which may be the best way to solve the problem. I fear that consolidation of interfaces is unlikely to occur. As far as I can tell Debian simply lacks the resources to do that. Maybe Joachim Breitner can shed some light on this? I'm happy to work on this if need be. Unless some consolidation of interfaces is going to happen, Debian will simply be unable to support multiple init systems natively. Yes, it sounds like the issue is less of the init scripts themselves, and more how to interact with the init systems (the interfaces). Forcing everybody to use the same init system is going to make a lot of people very unhappy, as we've seen. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: systemd .service file conversion
On Sun, May 26, 2013 at 10:29:25PM +0200, Helmut Grohne wrote: I find it depressing to see four init/rc systems, of which three are mutually incompatible in every single possible aspect. At the risk of adding another level of indirection, we could add a meta-init format that can generate an appropriate file for any of these. Dependency annotation: * sysv: LSB headers * openrc: a shell function * systemd: ini-file / not needed due to socket activation * upstart: another syntax This should be fairly easy to generate from a meta-init format. Socket activation: * sysv: inetd can pass one accepting socket as stdin * openrc: no clue * systemd: sockets passed as fd 3 and higher + environment variables LISTEN_FDS and LISTEN_PID * upstart: socket passed as fd specified in environment variable UPSTART_FDS If the services support socket activation, a sysvinit script could probably pass the FDs using an environment variable and some shell redirection. Alternately a small C wrapper could be used, or this could be pushed into start-stop-daemon. Daemon startup signalling: * sysv: shell script flexibility^Whell * openrc: no clue, guess like sysv * systemd: signalling via dbus, systemd-specific notification mechanism or just assume it to be ready * upstart: tracking via ptrace, tell number of expected forks ahead This would be harder to abstract. Resource limits: * sysv: shell has ulimit * openrc: I guess like sysv * systemd: declarative, ini-file * upstart: declarative syntax We can generate ulimit commands for sysv and openrc and appropriate entries in the systemd and upstart files. How is anyone supposed to write a service that runs with all of them? Disabling service: * sysv: /etc/default/$service is frowned upon, update-rc.d $service disable (or chkconfig if you are on redhat) * openrc: rc-update something * systemd: three levels of off, systemctl disable $service.service, but this gets more complex with lsb init script compatibility * upstart: echo manual /etc/init/$service.override We already have update-rc.d, so we can make it DTRT depending on the actual init system in use. Given the above I do not believe supporting even two of the above in a native way (i.e. without lsb compatibility) is possible for a distribution like Debian. Is there any chance in pushing upstreams to consolidate interfaces in any way to make this easier? A meta-init format would make everyone equally happy (or miserable, depending on your point of view), which may be the best way to solve the problem. I fear that consolidation of interfaces is unlikely to occur. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Debian systemd survey
On Thu, May 23, 2013 at 11:18:04PM +0200, Josselin Mouette wrote: Le jeudi 23 mai 2013 à 22:06 +0200, Marc Haber a écrit : Yes, systemd trying to replace so much of traditional UNIX tools at once and so blatantly breaking the One job one tool principle that has made our platform so successful is one major part of the acceptance issues that systemd has in Debian. I’d bother answering to that, but Lennart already did. Myth #1: http://0pointer.de/blog/projects/the-biggest-myths.html Systemd is just as much monolithic as, say, coreutils. I can use only parts of coreutils if I desire. Also, coreutils does not start services on startup that I do not need. systemd, on the other hand, has spawned systemd-journald, which I do not want or need, which is autorestarted, and which cannot be stopped with service. Since I am not using its functionality, there is no point in having the service running. rsyslog is very capable. Also, traditionally init has been limited to starting and stopping groups of services. It has not been involved in logging, session management, seat management, hotkey handling, or suspend and resume, except perhaps to start and stop the services which perform those functions. However well-intentioned, systemd does a lot more than init traditionally has, and definitely encroaches into areas that were not traditionally init-related. The Unix Way is to use separate processes for separate tasks. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Debian systemd survey
On Thu, May 23, 2013 at 02:10:57PM +0200, John Paul Adrian Glaubitz wrote: On 05/23/2013 11:43 AM, Adam Borowski wrote: Did you include the stats for all projects systemd wants to replace as well? For just one piece: * busybox-syslogd * dsyslog * inetutils-syslogd * rsyslog * socklog-run * syslog-ng-core Well, how many of these are actually used in the real world? rsyslog is priority important and is the default syslog implementation in Debian. It's also the default in Fedora. I think we can be confident that it gets lots of real-world use. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Debian systemd survey
On Fri, May 24, 2013 at 01:45:46AM +0200, Matthias Klumpp wrote: 2013/5/24 brian m. carlson sand...@crustytoothpaste.net: The Unix Way is to use separate processes for separate tasks. ...and this is what systemd does! It's not like we have an event-logger, hotkey-handling and seat-management all in pid0. It is all nicely split into separate processes. The journal is mainly used to produce structured logs and to log the early boot process (which I find *very* nice, it helped me a lot already!), but you can turn it's functionality off[1]. Yes, systemd uses separate processes, but they are not independent. They cannot be independently turned off. If I decide I do not want the journal features, however useful others might think they are, I should not have to resort to chmod and dpkg-statoverride to keep them from running. Let them be optional features which the core systemd can be used without. There will be a reason why it cannot be removed completely too. I think it is valid to see systemd as a compilation of basic tools for a Linux system, which also includes an init-system. The problem is that it would be great as just an init system. I love it as an init system: it boots very, very fast and shuts down very, very fast. But that's all I want it to do: be an init system. I *have* a syslog daemon. I *have* tools to handle hotkeys. It should be a great init system, and (at least be able to be configured to be) *absolutely nothing else*: one small, limited process with PID 1. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: /bin/sh (was Re: jessie release goals)
On Wed, May 15, 2013 at 05:33:44PM +0200, Vincent Lefevre wrote: Though zsh has an option to emulate sh, it may still not be completely compatible. Upstream fixes incompatibilities when it is easy. But some incompatibilities may remain. If sh needs special multibyte (UTF-8) support for some features in UTF-8 locales, there may be a problem with zsh, as in sh emulation mode, multibyte support is completely disabled, and enabling it yields incompatibilities (that's why http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659932 is still there). Some years ago, Apple shipped zsh as /bin/sh for Mac OS X. It broke a lot of things at the time, including some of the autotools. I also tried zsh as /bin/sh, but found that debconf didn't work at all. Don't get me wrong, I love zsh, but without some serious work, it isn't at all a viable candidate for /bin/sh. I use mksh-static for /bin/sh. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: /bin/sh (was Re: jessie release goals)
On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote: This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. It is not better if you don't want proprietary binary-format logs in /var/log with no documented way to turn them off. It is also not better if you want an init that does not dump its own log messages to LOG_KERN. As a reasonably sane person, it had never occurred to me to put non-kernel logs under LOG_KERN for any reason whatsoever. For better or for worse, sysvinit provides a lot of modularity. systemd provides none of that modularity, and there are a lot of things it does that I'd rather disable (or better yet, uninstall) because they're just wrong. When I've used upstart and sysvinit, I've never had functionality that I wanted to disable and remove. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: /bin/sh (was Re: jessie release goals)
On Wed, May 15, 2013 at 02:29:40AM +0200, John Paul Adrian Glaubitz wrote: On 05/15/2013 02:16 AM, Michael Biebl wrote: Am 15.05.2013 01:26, schrieb brian m. carlson: On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote: This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. It is not better if you don't want proprietary binary-format logs in The format may be binary, but it certainly is not proprietary [1] I really can't believe people are still coming up with that non-sense. Maybe because I read it on LWN (http://lwn.net/Articles/468381/): All complaints about UUIDs were quickly overshadowed by another issue once the full proposal was posted: one might charitably say that there is not, yet, a consensus around the proposed new logfile format. In a sense, that is unsurprising, since that format is deliberately undocumented and explicitly subject to change at any time. You'll pardon me if I believe that LWN is a reputable source for information. I have no idea why people assume that a binary format means it can only be processed with a special, proprietary tool. Binary simply means what it means, binary and not text which means it's a more stream-lined and machine-readable format as opposed to a text format with no formatting at all. It means that it works completely differently from every existing Unix log parser on the planet. syslog is hardly no formatting at all. And, when it comes to processing, binary data is actually *easier* to process. Everyone who has ever written a text parser themselves will agree. I have written several, and I still prefer plain text. I want to use the same tools to parse my logs that I have used for years, like logcheck. Text files is the Unix way. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: /bin/sh (was Re: jessie release goals)
On Wed, May 15, 2013 at 02:12:10AM +0200, Michael Biebl wrote: Am 15.05.2013 01:26, schrieb brian m. carlson: On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote: This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. It is not better if you don't want proprietary binary-format logs in /var/log with no documented way to turn them off. http://www.freedesktop.org/software/systemd/man/journald.conf.html Storage=none Silly me. I expected that if I installed systemd, that the appropriate man pages would be shipped with the package: vauxhall ok % man journald.conf No manual entry for journald.conf -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes
On Sat, May 04, 2013 at 12:10:25AM +0300, Timo Juhani Lindfors wrote: Bernhard R. Link brl...@debian.org writes: Once we drop that and only give people the right to modify the software we distribute but no longer the possiblity to do so on their own, the Free we are so proud on gets mood. Doesn't pbuilder make it easy enough for anyone to modify and build the software on their own? The issue with sterile build environments is not just for building packages for normal use. If I'm fixing a bug in a package, I may need to build that package several times, testing different fixes. If everyone assumes that packages will be built in a sterile environment, nobody will care that their packages don't build twice in a row, but that's exactly the situation that I have when trying to test a patch. Also, I'm not going to set up an entire chroot or sbuild or pbuilder environment just to test a patch. Packages should definitely be built for the archive in a clean environment, but they should still build correctly in an unclean one. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Public service announcement about dependencies on gawk
On Tue, Mar 19, 2013 at 07:59:14AM +0100, Andrew Shadura wrote: On Mon, 18 Mar 2013 23:23:45 + brian m. carlson sand...@crustytoothpaste.net wrote: I've seen a lot of cases over the years of packages depending on gawk that do not need it. If you only need a standard nawk (new awk), you do not need to depend on gawk. mawk is smaller and faster and sufficient for almost all needs, and the existence of some awk on the system is guaranteed by base-files. Well, as far as I know, mawk has some sort of terrible UTF-8 support, so it's a no way for many applications. Could you please explain? And if you haven't filed a bug report, could you please do so? Searching Google, the only UTF-8-related bugs I found are bugs mandated by POSIX (and one that updating mawk to 1.3.4 would fix). Also, my original post was inspired by the fact that most packages depending on gawk invoke awk as their binary. In that case, the dependency is wrong and unnecessary. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Public service announcement about dependencies on gawk
I've seen a lot of cases over the years of packages depending on gawk that do not need it. If you only need a standard nawk (new awk), you do not need to depend on gawk. mawk is smaller and faster and sufficient for almost all needs, and the existence of some awk on the system is guaranteed by base-files. If your script does require some feature that is not available in mawk or original-awk, you explicitly need to call gawk, since /usr/bin/awk is an alternative and you cannot assume that it will point to gawk. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Contributor agreements and copyright assignment
On Tue, Dec 04, 2012 at 12:42:33PM -0800, Russ Allbery wrote: Bjørn Mork bj...@mork.no writes: IANAL, but I believe you are wrong there. You give them much wider rights than this by assigning the copyright to the FSF. The copyright owner is free to relicense the work in any way they want. Have you see the copyright assignment contract that you make with the FSF? It would be a breach of that contract for them to relicense the work in any way they want. The contract really does try to address this issue. Yes, but the FSF can still license my (theoretical) contributions under the GNU FDL, and that's enough reason for me never to assign copyright to them, ever. I will say that Debian has in some cases missed out on patches from me because I know the maintainer isn't interested in carrying them forever and upstream requires a copyright assignment. It doesn't help to say, So fix it yourself and provide a patch, if nobody's going to accept a patch. The only work I do where I assign copyright is with my employer. Otherwise, I think it's rude and insulting to ask for carte blanche (or a slightly more limited version of it, in the FSF's case) when I don't get the same in return. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Maildir vs. mbox in Debian
On Thu, Nov 29, 2012 at 05:52:06PM +0100, Adam Borowski wrote: Outside of dpkg, sqlite in non-WAL mode, other databases and virtualbox/ qemu, btrfs is pretty fast. That may be true, but it glosses over how awful performance is on those workloads on btrfs. A single Berkeley DB transaction can literally take minutes. btrfs in its default configuration is completely unusable for any system that uses databases *at all*, which is essentially everything but tiny embedded systems. I won't even use it on /tmp. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Really, about udev, not init sytsems
On Sun, Nov 25, 2012 at 06:49:45PM +0100, John Paul Adrian Glaubitz wrote: On Mon, Nov 26, 2012 at 01:08:31AM +0800, Thomas Goirand wrote: So please just keep in mind that this is annoying some others, and if you don't feel annoyed, just live with the fact you aren't alone in this world, and that some of us prefer a separated /usr partition. Based on which technical merits? I want to have a separate /usr, because I can is not a reason to make things more complex and difficult in the development. I would agree if there was a technical reason, but I don't see any. And, as you see, enabling a separate /usr means extra work. I encourage you to read the archives of this list, where reasons have been given in detail. Also, before using a separate /usr was controversial, many people partitioned their systems with a separate /usr. I have a server that is configured this way. If I were to reinstall it, I might not use a separate /usr, but it is hardly reasonable to make me repartition my disk now. That means extra work for me. (Nor is it reasonable to have init lecture me about it every boot.) -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Do not CC me
On Mon, Nov 26, 2012 at 12:19:18AM +, Dmitrijs Ledkovs wrote: If your e-mail processing machinery cannot handle duplicate messages (due to cross-postings and CC's), maybe you should get an a better email processing machinery. Receiving duplicate emails is inevitable, and trivial to deal with. Is it? I filter mailing lists into a separate folder for each mailing list using procmail (using the RFC 2919 List-Id header). I also have notifications on my cell phone (via my IMAP client) for mail in my inbox and certain other folders, but not mailing lists. So if I receive the CC first, and the mail from the list second, whatever de-duplication I do, I've already been notified that I have a potentially important email in my inbox. Please inform me how I am to go back in time and not receive the notification on my cell phone, or please explain to me why your mail to the list is so important that I should receive notification of it wherever I am and whatever I'm doing. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package
On Sat, Sep 08, 2012 at 10:01:17PM +1000, Dmitry Smirnov wrote: On Sat, 8 Sep 2012 19:37:33 Holger Levsen wrote: optional depends - what?? Thats self contradictory. If a depends it's really optional, it's not a depends, thus that package is buggy and should not be fixed by introducing a nonsense package, but by removing this depends. Not at all, it may appears self contradictory only because debian/control language doesn't have a right term for it. Or perhaps my wording is not perfect. If you got the idea, can you suggest a better word? Imagine a software that builds without a certain -dev package. When present this package may be used to activate an additional (optional) feature. Debian users depend on the package being built in a consistent way. For example, some packages are built with Kerberos support. While this is generally optional for most packages, I'd be very upset if, say, the Debian openssh-server package suddenly lost support for Kerberos because the maintainer or someone doing an NMU didn't have the appropriate -dev package installed, since it would mean that package would suddenly fail to work in a major way for me. Your proposed solution would remove an important safety check. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Proposal: Making Debian compiler agnostic
On Tue, Aug 28, 2012 at 09:27:23AM -0700, Ben Hutchings wrote: Are all alternate compilers expected to implement gcc extensions? Must the code be changed to use appropriate '#ifdef __GNUC__' guards? (And what happens the next time gcc adds a new extension...?) As I've pointed out, clang (and, I believe, the Intel compiler) #define __GNUC__, so this has no effect. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
On Thu, Aug 30, 2012 at 01:15:32AM +0200, Marco d'Itri wrote: Fellow developers, please do not waste your time moving stuff to /lib: it's a task both endless and futile because nowadays it is clear that the upstream maintainers of various stuff do not support a standalone /usr mounted by the init scripts: if /usr is a standalone file system then it must be mounted in the initramfs. So let's just fix initramfs-tools and be done with this forever. Upstream maintainers of various stuff also refuse to provide man pages. Debian does not always do what upstream wants. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Proposal: Making Debian compiler agnostic
On Tue, Aug 28, 2012 at 10:26:37AM -0700, Russ Allbery wrote: Paul Tagliamonte paul...@debian.org writes: On Tue, Aug 28, 2012 at 09:27:23AM -0700, Ben Hutchings wrote: Are all alternate compilers expected to implement gcc extensions? Must the code be changed to use appropriate '#ifdef __GNUC__' guards? (And what happens the next time gcc adds a new extension...?) clang #defines __GNUC__ but isn't completely compatible. In order to test if it's really GCC, you have to check that __clang__ isn't defined. As you can see, this quickly becomes problematic if one must check all the things that the compiler is not to see what the compiler is. clang does a fairly OK job with some of gcc's extentions. Fairly OK is a good way of putting it. It's not reached the level of good, but it's probably workable for most practical purposes. You will get spurious warnings about some things, such as some of the __attribute__ tags, but I don't think I've seen a case where it flatly refuses to compile something or miscompiles it. That said, I've not used some of the hairier gcc extensions. I have some code that uses the __builtin_ia32_* functions for intrinsics that clang refuses to compile because it has different, incompatible intrinsics (#653256). Since clang insists on using __GNUC__, it's difficult to detect whether the compiler really is GCC or whether it's a broken clone (which could be clang or something entirely different). clang upstream does not consider this incompatibility a bug; I do. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: CD sizes again (and BoF reminder!)
On Sat, Jul 21, 2012 at 09:25:50PM +0300, Uoti Urpala wrote: Most of the time taken by cdebootstrap is wasted by dpkg on doing useless file syncs: cdebootstrap --arch=amd64 unstable debian-tree/ from local package cache on ext4: 138 seconds on tmpfs where dpkg can't waste time on useless syncs: 21 seconds (and a significant portion of that is used by package scripts with sleep 1) So at least in this case the biggest performance problem by far is the inappropriate use of fsync() or other disk synchronization primitives, and CPU use for unpacking is pretty much irrelevant. My understanding is that dpkg uses fsync properly; that is, to guarantee the data is on the disk before exiting or doing things that require that data to be present. I don't currently see any bugs on dpkg that indicate that it is calling fsync needlessly or wastefully. If you see that behavior, could you please file a bug on dpkg? -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: /tmp on multi-FS set-ups, or: block users from using /tmp?
On Sat, May 26, 2012 at 02:32:15PM -0400, Ted Ts'o wrote: These days I'd argue that multi-user is such a corner case that it's not worth optimizing for it as far as defaults are concerned. If you're trying to run a secure multi-user system, you need to be an expert system administrator, keep up with all security patches, and even then, good luck to you. (The reality is that these days, no matter what OS you're talking about, shell == root. And that's probably even true on the most unusably locked down SELinux system.) I work for a company that develops software for shared-hosting providers. I can guarantee you that multi-user is far from a corner case. We employ 135 people and are growing, as is the shared-hosting market. For my personal purposes, tmpfs on /tmp is fine. For shared-hosting purposes, tmpfs on /tmp is a DoS waiting to happen. Many web hosting companies overprovision their servers (the business is cutthroat) and memory is very tight. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Node.js and it's future in debian
On Fri, May 04, 2012 at 09:03:55AM +0200, Vincent Bernat wrote: OoO En cette fin de nuit blanche du vendredi 04 mai 2012, vers 06:11, Hamish Moffatt ham...@debian.org disait : Secondly if node.js is usually just used via #!, I'm not sure why it's in $PATH at all - why not in /usr/lib? Neither #!/usr/bin/node nor #!/usr/bin/env node will work then. I have seen a lot of perl scripts in the wild that use #!/usr/local/bin/perl. Users are expected to fix those up themselves. I understand it's an inconvenience, but honestly, if you can't fix up a shebang yourself, you have no business programming at all (and thus using node.js). This is one of the issues that occurs when moving scripts between different systems, just like changing #!/bin/sh to #!/bin/bash for certain scripts coming from RedHat systems. (Full disclosure: I use neither package, although I am more likely in the future to use node.js than the ham package.) -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: switching from exim to postfix
On Tue, May 01, 2012 at 07:47:08PM +0100, Roger Lynn wrote: I have enabled accept_8bitmime in every exim I've installed for the last 10 years and no one has reported any problems. I think the risk of encountering a truly 7 bit MTA in this decade is low enough to be ignored for most purposes. Anyone still using one is likely to find that a substantial fraction of their incoming mail is corrupted. I actually use Sendmail's strict 8BITMIME support to help catch spam. I agree that 7-bit MTAs are essentially gone, but with the volume of spam I receive, I set my mail software to be extremely strict with regard to protocols. Legitimate software (of any sort) generally generates protocol-compliant messages. Malicious and illicit software (and that created by Microsoft) generally does not. Legitimate software also generally has a userbase that will complain about rejected data if the software is not protocol-compliant, which often leads to fixes. I've complained to the listmasters that they send 8-bit data that is not MIME (virtually all of which is spam) under the auspices of the 8BITMIME extension; they refuse to fix this, and as a consequence they have to deal with the occasional piece of undeliverable mail. This is not a knock against the listmasters, just an observation that if you violate the protocols, some places will reject your data. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Node.js and it's future in debian
On Sat, Apr 28, 2012 at 10:41:36AM +0100, Roger Leigh wrote: From a purely pragmatic POV, how many people are using both packages? If the answer is zero, and this seems relatively likely, can't we just add a Conflicts/Breaks and be done with it. Not a great solution, but it doesn't seem like there's a better one if both camps are unwilling to change. Policy specifically forbids this. If Policy did not specifically forbid this, it is my understanding that this would already have been done (and was already done, but was forced to be reverted). -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: debian-multimedia.org considered harmful
On Sun, Mar 11, 2012 at 01:39:13AM +0100, Adam Borowski wrote: On Sun, Mar 11, 2012 at 11:00:30AM +1100, Ben Finney wrote: Your complaint, then, is against those who use the law to restrict your use of your legally-acquired DVD or Blu-Ray disc and disingenuously call it “protection”. It is misdirected against the Debian project. In other words, until non-US comes back, d-m.o can't go away. I think this demonstrates a lack of understanding about non-US. non-US was for things that could be legally used everywhere, but could not be *exported* from the US without serious hassle. non-US was *not* for things which could not legally be used in the US. And I would like to point out, for the record, that it is not only the US that has stupid laws. Yes, we certainly have more than our share, but, for example, Germany has stupid laws that prevent certain video games from being played, and Australia also has stupid video game laws that could be interpreted as being binding against Debian. I'm sure that every country has laws which are problematic; don't blame it all on the US. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: upstart: please update to latest upstream version
On Fri, Feb 24, 2012 at 11:31:38AM +1100, Russell Coker wrote: Finally one benefit of an event based booting system is that it won't become stuck if one daemon hangs. I've had problems in the past when one daemon didn't start up and that prevented other daemons from starting due to the sequential processing of init scripts. The problem with event-based init systems is what to do if init discovers a dependency loop. I know systemd simply *silently* chose not to start one daemon, which happened to be dbus, which made lots of important software (e.g. gdm) simply not work. If we're going to move to event-based booting, this discovery needs to be made *before* the system reboots[0] and init must complain loudly and handle it gracefully anyway. [0] And whatever solution we choose must handle the case where the sysadmin drops local services into the boot process. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: leaks in our only-signed-software fortress
On Sat, Feb 18, 2012 at 11:48:27AM +0100, Thomas Koch wrote: What about a debhelper script that receives an URL (or set of mirror URLs) and a SHA1 and does the download and check? Please use something stronger than SHA-1. SHA-1 has some weaknesses and something like SHA-256 or SHA-512 should be used in new applications. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, Feb 08, 2012 at 03:06:46PM +0100, Adam Borowski wrote: gzip's output is likely to change: * on a different architecture * with different optimizations If either of these are the case (assuming a valid, deterministic, non-arch-specific implementation) then this violates C's as-if rule. The compiled version has to act as if it did exactly what the C said. Optimizations or other transformations that cause the compiled code to violate this are a bug in the compiler. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, Feb 08, 2012 at 11:33:37AM +0100, Bernhard R. Link wrote: On the other hand most uncompressors silently ignore unexpected data after end of file markers. So the compressed file is even more easily tempered with (especially as debsums only stores md5 without size and md5 does not include the size in the hash like the sha* do. So if one can append arbitrary stuff, it is easy prey). This is not true. MD5 and the SHA variants are all Merkle-Damgård constructions, which is what makes them vulnerable to length extension attacks if the compression function is not secure. Merkle-Damgård constructions include the number of bits hashed in the hash. But yes, MD5 is vulnerable to length extension attacks. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)
On Thu, Feb 02, 2012 at 06:08:33PM +0100, Josselin Mouette wrote: Le jeudi 02 février 2012 à 16:12 +, Ian Jackson a écrit : The correct approach it is not to unilaterally decide to do switch to some other half-implemented system, remove support for the previously working machinery, and demand that bug submitters write the compatibility code. The correct approach is to notice you have a perfectly working, fully-implemented system, that works fine across the whole distribution except for a handful of packages, and to remove the compatibility code for the legacy system. The mime-support solution is part of Policy. It is a perfectly working, fully-implemented solution. If you feel that it is obsolescent or obsolete and should be replaced by a different solution, then it's your job to convince other people of that, do the work to make that happen, and request that Policy be amended accordingly. I have yet to see a bug filed on the debian-policy package requesting that. As it is, evince does not display PDFs from mutt. Thus your solution is inadequate, because mutt does not use your solution (and there is no bug filed against mutt to do so). You have thus broken an otherwise perfectly working solution because you don't like it. As a package maintainer, you're going to have to support some things you don't like. If you hate natural alignment and think sparc is awful, you still have to support it or find a co-maintainer who will. However awful you think mime-support is, it's still part of Policy, and agreeing on one system improves the experience for users, which is one of the main purposes of a Linux distribution. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Switching /etc/mtab to /proc/mounts and removing /lib/init/rw
On Wed, Jan 18, 2012 at 03:05:58PM +0100, Goswin von Brederlow wrote: jida...@jidanni.org writes: Forty years of pleasant df(1) and mount(1) reading shattered in one day, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653073 Any update on why the root filesystem is listed by UUID? Is that a problem of busybox mount reporting the long device name to the kernel why real mount uses the short one? It's due to the libata transition. Since drives that might formerly have been hd? are now sd?, there was a debconf question to ask to convert them all into UUIDs. Then it doesn't matter which driver (ide or libata or something else entirely) is being used. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries
On Fri, Jan 13, 2012 at 12:57:37AM +0100, Mike Gabriel wrote: On Fr 13 Jan 2012 00:37:57 CET Stefan Lippers-Hollmann wrote: forked monolithic X.org 6.9 source tree. This is indeed the case. I can't speak for the ftpmasters and Security Team, but honestly I can't see why they would allow this in the archive or in any stable release, respectively. Most likely with little to no bug-/ security fixes since 2005 - or am I missing anything vital in that packaging git? Likewise the current debian/copyright appears to lack all copyright notices of the original XFree86/ X.org code, which makes up, by far, most of the source. The X2Go upstream team will be open to security and feature patches and will love to be pointed at security issues discovered. In the very very very long run there might be someone (we are currently talking about people in Austria being interested in such a project) who refactors NX for latest Xorg code, but currently what we can provide is an active maintenance of NoMachine's code. I think you're missing the issue here. Since X.org 6.9, there's been a lot of bug fixes and improved code. So you're essentially using an obsolete codebase with a new protocol hacked on. The Security Team does not like code copies. Porters do not like patching the same software again and again, except with slight differences that make it impossible to reuse the same patches[0]. The Debian X Strike Force has lots of bugs that need to be dealt with, very likely because of a lack of time and manpower[1]. If your code is a fork of 6.9, then all those bugs that were dealt with previously (or are still present) are probably present in your code. Also, even though X2Go may provide security support for nx-libs, the Debian Security Team still has to issue DSAs and build packages on all of the release architectures independent of X2Go. [0] I have had the joy of assisting the kFreeBSD porters with patching every embedded and modified copy of libgc. [1] This is not a dig at the X Strike Force; they do a very good job with package maintenance and bug handling with the manpower they have. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#655010: ITP: missing-manpages -- manual pages for software missing them
Package: wnpp Severity: wishlist Owner: brian m. carlson sand...@crustytoothpaste.net * Package name: missing-manpages Version : 1 Upstream Author : brian m. carlson sand...@crustytoothpaste.net * URL : https://github.com/bk2204/missing-manpages * License : GPL-2/Apache-2.0/CC-BY-SA-3.0 tri-license Programming Lang: man Description : manual pages for software missing them missing-manpages provides free manual pages for software that does not have them. Note that this is the name of the source package. Currently only manual pages for GCC are available, but it's possible manpages for other packages will be included at some point in the future. This is being packaged separately from gcc because its maintainer is not interested in including manpages in the gcc-4.6 package. The exact name for the binary package containing the gcc manpages is yet to be determined pending feedback from debian-gcc (CC'd). The description for the binary package is as follows: documentation for the GNU Compiler Collection This package contains manual pages for the GNU Compiler Collection. The upstream manual pages cannot be included in main for license reasons, so these (incomplete) manual pages have been written from scratch to replace them. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Fri, Dec 30, 2011 at 07:54:34PM -0800, Josh Triplett wrote: The numerous upstreams which follow this model introduced it specifically *because* of distributions and package management, which they specifically had in mind as a design constraint. The search path behavior, along with the consistent use of .d directories, allows a clean distinction between upstream configuration, vendor/distribution configuration (any changes Debian wants to make to the defaults), sysadmin overrides of the defaults, and sysadmin configuration building on the defaults, without forcing sysadmins to perform manual three-way merges every time they upgrade. It also either (a) prevents upstream from ever changing that default or (b) silently breaks packages for the user. If option foo is set to bar in the upstream configuration and then upstream changes it to baz, the package breaks for the sysadmin. If the configuration were stored in /etc, the sysadmin would get notified by dpkg or ucf and would have an opportunity to change it. So the only sane thing to do is not change the default, ever. This does not sound to me like an especially robust model. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Sat, Dec 31, 2011 at 08:19:47PM +, Lars Wirzenius wrote: If the admin has not changed the config, dpkg and ucf will happily replace the old config with the new one, no questions asked, even when the config is in /etc. So no change there. Right. But if the sysadmin customizes any part of that configuration— even something completely unrelated—which is very likely, then he or she will be prompted. So if the defaults are fine, then the defaults are likely to be fine in the future. If the defaults are not fine, which often they are not, then the sysadmin will be prompted. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: many packages fail to build twice in a row again
On Tue, Dec 20, 2011 at 09:36:47PM +0100, Lucas Nussbaum wrote: On 20/12/11 at 22:01 +0200, Peter Eisentraut wrote: With recent dpkg(-source) changes, many packages are again failing to build twice in a row, because of uncommitted upstream changes. Fixing this was a lenny release goal, maybe it should be one again?!? Most importantly, maybe someone who has access to one of those build grids can run the old tests again, because I feel by accidentally stumbling upon these problems we will not be able to find and fix many of them any time soon. Is it really worth it? There are many ways to work-around this, such as using a temporary git repo to be able to 'git clean' and return to a clean state before each build. If I'm fixing an RC bug, it's very convenient to be able to test a patch and then rebuild with a different patch if necessary. If the package doesn't build cleanly N times in a row, or if there are other problems with the packaging that make it difficult to fix, I usually go on to fix other bugs instead. Also, when I file a bug report, the harder you make it to fix your package, the less likely you are to receive a patch with that report, workaround or not. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [Fwd: [ISC-Bugs #25979] What happened to the dhcp patch in ISC-Bugs #24697 (Debian Bug #616290)?]
On Thu, Dec 15, 2011 at 02:15:11PM +, Ian Jackson wrote: Svante Signell writes ([Fwd: [ISC-Bugs #25979] What happened to the dhcp patch in ISC-Bugs #24697 (Debian Bug #616290)?]): Dear Debian/Hurd, GNU/Hurd and Debian-devel people. This arrived today. Any ideas on how to proceed? Is it possible to create a Hurd-specific fork of the latest ISC-DHCP release? DHCP is an essential package in the Debian Installer. I went and read the Debian bug report. The difficulty seems to be with the patch fix_ftbfs4hurd.dpatch. I have to say that on reading that patch I understood upstream's reluctance. I don't think it looks to me like a correct and appropriate fix for build portability problems. Hurd doesn't support PATH_MAX. So trying to allocate memory based on PATH_MAX isn't going to work on Hurd. However, with glibc (and with POSIX 1003.1-2008) we can simply mark the destination buffer to realpath as NULL and the appropriate amount of memory will be automatically allocated. Not all systems support this, though. I cannot comment on the remainder of the patch, but the PATH_MAX issue is a pretty common one for Hurd, and assuming PATH_MAX is a compile-time constant is a bad idea anyway, since it's not allowed by POSIX. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Switching /etc/mtab to /proc/mounts and removing /lib/init/rw
On Tue, Dec 13, 2011 at 08:54:14PM +, Roger Leigh wrote: If you have a few minutes to spare, some testing of the packages would be appreciated, so make sure there are no corner cases we've missed. Upgrading initscripts should result in /etc/mtab being switched to a symlink at the next reboot. /lib/init/rw will also no longer mount a tmpfs on reboot, though the directory itself will need to remain until wheezy+1, due to the upgrade ordering--packages migrate after initscripts has run its postinst, requiring its continued presence. I'd be grateful for any feedback. You probably want to handle the case where /etc/mtab is a symlink to /proc/self/mounts as well, since it's equivalent, and I know some people (read: at least me) have already made that change. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Bug#648286: ITP: r8168 -- Realtek r8168 device driver for Linux (DKMS version)
On Thu, Nov 10, 2011 at 11:54:01PM +1100, onlyjob wrote: Perhaps you are right, given the time and the skills and the hardware and the person skilled and motivated enough it can be upstreamed. Ideally it should be. IIRC, upstream doesn't want r8168 because supposedly it covers only hardware that is also supported by r8169. They feel that if r8169 is buggy that it should be fixed. Obviously, that isn't helpful at the present moment if the current driver doesn't work for you. Unfortunately, I can't find a reference at the moment, but I do remember reading about it recently. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: segfault error 4 in libpthread-2.13.so X86_64
On Sat, Oct 29, 2011 at 02:55:54PM -0500, Dallas Clement wrote: How can I link with libc6-dbg instead of regular libc6? Thanks. You don't. The files in /usr/lib/debug contain only debugging symbols that have been stripped from the normal binary. You simply link against libc6 as normal and gdb (and other programs) will find the debugging symbols automatically. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#645723: The password
On Tue, Oct 18, 2011 at 02:48:04PM -0700, Jimmy Li wrote: This dialog box happens for any application that asks for the root password (not gksudo). I don't know what caused it, so I can't do anything about it. Please send to the bug a (potentially incomplete) list of programs that do this and you'll have a better chance of someone reassigning the bug to the right place so it can be fixed. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: RFC: Making mail-transport-agent Priority: optional
On Mon, Oct 17, 2011 at 07:20:54PM +0200, Luca Capello wrote: I think that the real question is: how much should Debian GNU/Linux mimic a standard UNIX system by default? I think this is the real question. If standard is a default Unix system, then it needs to have an MTA. I believe this even though I do not use an MTA on most of my systems (and I always use something other than Exim). I'd also like to point out that if we don't ship an MTA in standard, we should also not ship nfs-common, rpcbind, or libtirpc since NFS is used even less often than an MTA and the same rationale for not installing it applies. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: RFC: Making mail-transport-agent Priority: optional
On Sat, Oct 15, 2011 at 09:53:32AM -0700, Steve Langasek wrote: Hear, hear. How do I deliver mail? is a per-system setting, not a per-application setting, and the move towards having MUAs talking SMTP directly to send mail is a flawed model picked up on the Linux desktop from certain other OSes. The right solution here is to fix the MTAs to be configurable from the desktop, and fix the MUAs to use the MTA - *not* to get rid of the MTA. Until you can get an MTA to deliver mail to a smarthost authenticating via GSSAPI with the Kerberos credentials of the sending user, I'm going to keep using mutt's SMTP support. TTBOMK, no MTA in Debian supports outgoing GSSAPI authentication *at all*, let alone with the specific user credentials. Only a few MTAs support per-user configuration on any level at all. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Re: / vs. /usr vs. fsck(8)
On Wed, Oct 12, 2011 at 08:22:09PM -0700, Josh Triplett wrote: Other than tradition, for what reason do you put /usr on a different filesystem? If / and /boot are the same filesystem, then using a filesystem that the bootloader supports is important. At least in the recent past, grub 2 didn't support booting off ext4; there was some problem when doing that. If /usr is a separate filesystem, I can use ext4 there and leave / ext3. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Maintainers, porters, and burden of porting
On Sat, Sep 10, 2011 at 01:27:01PM +, Felipe Sateler wrote: On Thu, 08 Sep 2011 19:34:41 +0200, Andreas Barth wrote: I disagree with let's first remove things. If a package like ruby doesn't build on sparc this bug report is RC exactly as long as sparc is a release arch. The release team has (and does) override such bug reports for testing migration if appropriate. Removing the binary package doesn't help at all but just makes things worse. So please don't do it, especially for packages with reverse dependencies. The big issue (as I understood from the OP) here is that the toolchain is not keeping up. Why should the maintainers of other software be bothered about that architecture? I think the major issue for a particular arch depends on that arch. For sparc, the majority of times I see posts to debian-sparc for porting issues, the problem is a bus error, which is not a toolchain issue. It's a buggy C/C++ code issue in the original package. Alignment issues are also noted on ia64, but there they're not as obvious since they cause a SIGSEGV, not a SIGBUS. In order to assist developers, I tried to write a library to enable alignment check on i386/amd64 for ease of debugging, but the C library does not function correctly with that enabled, so I gave up. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#638322: nfs-common: rpc.statd binds to udp port 631 preventing cups startup
On Thu, Aug 18, 2011 at 05:41:22PM +0100, Ben Hutchings wrote: On Thu, Aug 18, 2011 at 05:39:16PM +0200, Jan Möbius wrote: sometimes rpc.statd binds to port 631 udp which is used by cups. Therefore cups is unable to bind to its port and no printers get discovered. Rebooting the system helps as rpc.statd uses another port afterwards. This is a fundamental problem of the bindresvport() function, and not specific to rpc.statd. Reassigning to general. Actually, according to the manpage: Unlike some bindresvport() implementations, the glibc implementation ignores any value that the caller supplies in sin-sin_port. Fixing this might be a useful way around the problem. I'd code up a patch, but eglibc won't take it without copyright assignment. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Bug#636164: RFP: apt-clone -- ZFS integrated APT package handling utility
On Mon, Aug 01, 2011 at 12:38:13AM +0200, Robert Millan wrote: * Package name: apt-clone Version : 0.7.9nexenta28 * URL : see below * License : CDDL You may want to run this by debian-legal. Last I checked, this license wasn't okay. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: A few observations about systemd
On Wed, Jul 20, 2011 at 04:36:35PM +, Uoti Urpala wrote: I think you're committing exactly the fallacy I described in the part you snipped. You think that excluding people who want a particular kernel is significant when it's a big thing like a kernel. But _any_ case of not supporting something can be described as exclusion. Any time a package is dropped, Debian is excluding the people who want to use that package. Every time a decision is made not to package something people are being excluded. When Debian Linux fails to run on a specific submodel X of hardware Y, people who use that hardware are excluded. Any of those cases can affect a much larger number of people than kFreeBSD support. I think the difference with excluding a package is that nobody is willing or able to do the work. Perhaps the package requires more time than the maintainer has, or it's a very difficult package to maintain and nobody that wants to is able to. In most cases, if a package is buggy on some platform, the porters will either fix it or exclude it from that platform. Nevertheless, we expect Essential packages to work on all of our systems. Since you're interested in changing the status quo (which init is the default), you're obligated to do most of the work to fix whatever breakage occurs. This is true for most FLOSS projects, including the Linux kernel, not just Debian. If it were possible to support every use case and every piece of hardware then things would be different. But it is not possible. You have to prioritize things. And it is exactly the lack of a rational approach to this that I was criticizing above. When a bug goes unfixed and that prevents a user from achieving whatever goal he had, that is no better than someone being unable to achieve what he wanted because kFreeBSD was not available (and in fact I'd say the latter would typically be less severe, as the typical goal would be just play with kFreeBSD for its own sake). The priority is based on who is willing to do the work. I submit patches to software I use if it is buggy because I want the bug fixed *now*, usually because it's impeding my immediate work. If it's that important to me, I have to take some responsibility for fixing it if that's within my capabilities. Many people find kFreeBSD important to them and have consequently done the work to bring it to fruition. It appears that people have stepped up to do the work to bring it to where it is. It also appears that Debian is keeping the FreeBSD kernel; the only safe assumption is that Debian will continue to do so at least for the immediate future. If having systemd as the default init in Debian is very important to you, you should probably put in the work to make it a viable choice for Essential. Right now, the portability problems make it not so. Supporting things like kFreeBSD is a lot of effort to benefit few people. If it's what a volunteer wants to work on then that is his right. But to insist that others should work on it is wrong; project-wide priorities should be based on rational decisions instead. And to compare support kFreeBSD and make Linux work well for a larger number of people and claim that kFreeBSD stands more for inclusion is nothing but bullshit rhetoric. But here, the kFreeBSD porters (just like the porters, for say, sparc) have done most of the work. Yes, maintainers need to accept patches in some cases. But the porters do most of the work because that's what interests them or perhaps because their employers need that functionality or just because it's fun. It's not uncommon to see people maintain software or ports that they may already be using at work. The Kerberos maintainers are an excellent example here. Several HP people help maintain the ia64 port. And as long as their work within Debian is for the benefit of Debian, who cares? If a package simply cannot be used on kFreeBSD, then ok, that happens. Would it be nice if systemd were portable? Yes. But if we assume that it's not, then we have to accept that. The question here is whether we're effectively willing to make a non-portable package part of Essential. The question would be the same if systemd pervasively used unaligned accesses or inb/outb or some other non-portable construct. Would we jettison sparc and ia64 in favor of it? -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: A few observations about systemd
On Wed, Jul 20, 2011 at 08:44:43PM +0200, Ben Hutchings wrote: On Wed, 2011-07-20 at 18:27 +, brian m. carlson wrote: In most cases, if a package is buggy on some platform, the porters will either fix it or exclude it from that platform. Nevertheless, we expect Essential packages to work on all of our systems. [...] Er, no: http://packages.debian.org/squeeze/freebsd-utils I stand corrected. I didn't recall that being essential last time I looked, but it's been awhile. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [Lennart Poettering] Re: A few observations about systemd
On Tue, Jul 19, 2011 at 07:31:59AM +0200, Tollef Fog Heen wrote: | Also, I've installed systemd on my laptop and it logs almost nothing | to the console (verbose on the kernel command line does not help). try doing systemd.log_level=debug as documented in the man page? It's hard to access the manpage on the only system on which systemd is installed when the system won't boot. If everything's working normally, I don't care if it's mostly silent. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Portability of systemd [was: A few observations about systemd]
On Mon, Jul 18, 2011 at 02:50:17PM -0500, Jonathan Nieder wrote: (By the way, I thought kfreebsd and hurd supported openat fine already. It's even part of POSIX. And %m is handled by glibc, not the kernel, so not a problem for our ports.) I know the FreeBSD kernel has supported openat(2) since 8.0, but I don't know if the kFreeBSD glibc has it implemented. If not, it's very likely trivial to accomplish. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [Lennart Poettering] Re: A few observations about systemd
On Mon, Jul 18, 2011 at 11:05:56PM +, Uoti Urpala wrote: I think the important question is whether portability to other kernels is or should be a project's goal, and how much else you're willing to lose for the sake of that goal. I know I would personally be a lot happier with a Debian that supports systemd functionality than with a Debian that can run on a BSD kernel. I ran GNU/kFreeBSD on a server of mine for over a year because it had pf. pf makes OS fingerprinting automatic and a lot easier (at the time, Debian's Linux kernel did not have the osf module) and traffic shaping is much, much easier as well[0]. The Linux kernel has only recently had ipset functionality merged upstream, which pf has had for years. The FreeBSD kernel also had a much, much more responsive scheduler as well (it may still, I don't know). It also supports ZFS, which is very important to some people. The reason I left is because pf stopped working. I agree that GNU/kFreeBSD is not a great desktop platform, but it is an excellent server platform. Also, I've installed systemd on my laptop and it logs almost nothing to the console (verbose on the kernel command line does not help). Logging to syslog is not helpful when the system won't come up to the point of starting syslog. What it *does* log (to syslog), however, is a message that /usr as a separate partition is obsolete, even though this has no effect on systemd at all, other than offending the upstream author. Last I checked, The Unix Way did not involve having important system programs prattle on about irrelevant details. I'll side with supporting GNU/kFreeBSD over systemd any day. [0] Extremely limited bandwidth for incoming Windows SMTP servers, anyone? -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Bug#630753: ITP: snap -- gene finding with HMMs in Eukaryotes and Prokaryotes
On Fri, Jun 17, 2011 at 01:17:10AM +0200, Steffen Moeller wrote: * Package name: snap * URL : http://homepage.mac.com/iankorf/ * License : GPL Description : gene finding with HMMs in Eukaryotes and Prokaryotes It's my understanding (and correct me if I'm wrong) that cells are either eukaryotic or prokaryotic; there isn't a third class. If so, it's probably better to use a term that includes both, since as it reads now, it implies that it handles these two types, but not some unknown third. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Link-time optimization in debian packages
On Mon, Jun 06, 2011 at 01:15:29AM +0200, Adam Borowski wrote: Speed gains for compiled executables are great, though: around 20%[2]. It depends. I have code where using -flto causes no significant improvement ( 2%) in some cases and major performance losses (-7 to -37%) in others. This is not something that is a boon in every case and certainly not something that should automatically be used project-wide. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: distinguish between core and main?
On Sat, Jun 04, 2011 at 05:07:26PM +0200, Harald Dunkel wrote: About the package set dependencies: The core package sets would be self contained, i.e. they would not depend upon packages outside of their own core set. The new main/testing repository would be meant to work with both core/stable and core/testing. I don't think what you want is likely to happen; nevertheless, the priorities system does mandate that packages of higher priority not depend on packages of lower priority. Depending on your needs, you could choose packages of important or higher or those of standard or higher as your core set (this is on sid): lakeview ok % aptitude -q search '~prequired|~pimportant' | wc -l 123 lakeview ok % aptitude -q search '~prequired|~pimportant|~pstandard' | wc -l 249 Most of the important or higher packages are very stable and unlikely to break things at all. Neither Debian nor I guarantee this, though. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: bug reporting workflow is outdated
On Sun, May 22, 2011 at 10:44:35PM +0200, Pedro Larroy wrote: I think expecting having a working smtp on laptops, workstations, etc, is unreasonable these days. You don't have to have an MTA installed. You just have to have some MUA capable of accepting a premade message that can be edited by the user. I don't have a working MTA on my laptop (nor do I want one), but I report lots of bugs using mutt. I suggest that we can make an HTTP based bug reporting method. I think that's a terrible idea. I do not want to constantly check a website to see if I have new messages. Using an email-based method means that someone who needs to contact me about the status of a bug can do so trivially. Besides the fact that *I* think it's a bad idea, apparently the BTS administrators do, too: #277744 is marked wontfix. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Debian x86 32-bits built for i586 !?
On Sun, May 15, 2011 at 09:28:05AM -0300, Henrique de Moraes Holschuh wrote: What are the *exact* differences between code generated for march=i486 to code generated for march=i586? What CPUs would break? With -march=i586, code will be generated that runs on a Pentium without MMX (or later chips) instead of code that runs on any i486 or better. The extra instructions are CMPXCHG8B, CPUID, RDMSR, WRMSR, RDTSC, and MOV (when it's used with a control register)[0]. AIUI, some IDT Winchips do not support these instructions either. With -march=i486, the code will work on any 32-bit or 64-bit x86 processor other than the i386 itself. We originally switched to generating code for the i486 because it was needed for certain C++ support in GCC and libstdc++, although that is no longer the case, IIRC. The -march use, which specifies which instructions may be generated, is different from -mtune, which specifies for which processor the instructions are scheduled. -mtune has been set to i686 (since most 32-bit processors these days are i686) and tuning for the i586 is a bad idea since it was designed for executing 16-bit code efficiently, not 32-bit code. I believe the -mtune value should remain i686. [0] http://www.singlix.com/trdos/pentium.txt -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Writing to /etc/ from a privileged UI
On Wed, May 11, 2011 at 10:54:16PM +0200, Adam Borowski wrote: On Wed, May 11, 2011 at 10:05:40PM +0200, Frank Küster wrote: Not at the same time, but someone might allow a user of a laptop to access their WLAN, but neither accept that an other user of the laptop should be able to use the same network without asking, nor that the keys be written in a system-wide configuration file. Sorry but if you alternate physical possession of a laptop with someone whom you suspect of being hostile, no files are secure as long as they're stored on that laptop. My wireless network uses a RADIUS server to authenticate people against the network Kerberos database. Every user must have an entry in the Kerberos database in order to access the network. While I don't mind if while I'm connected to the network my partner uses the network connection, I certainly don't want him able to access the password that is used for authentication. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Bug#625865: ITP: ocportal -- ocPortal is a Content Management System for building and maintaining a dynamic website
On Fri, May 06, 2011 at 08:33:27PM +0200, Tshepang Lekhonkhobe wrote: I'm curious though, why is there an objection against CMS inclusions in general? When there are many packages which provide similar functionality (whether that is a CMS, a window manager, or whatever) then it's reasonable to ask what the features are for one that will be added to the archive and what makes it better than the alternatives. It happens on occasion that a packager may decide that there is a better tool for their needs and use that instead. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: DM upload permissions in detail
On Wed, Apr 27, 2011 at 10:28:35AM +0200, Torsten Werner wrote: Am -10.01.-28163 20:59, schrieb Philipp Kern: On 2011-04-26, Torsten Werner twer...@debian.org wrote: the first UID with an email address is used by dak. The first being the one with the newest self-sig? No, just the 'first' one. This isn't very clear. The OpenPGP standard doesn't specify a fixed ordering for user IDs, so the order in which the user IDs for a given key are written is undefined. If they're written from a hash/map whose ordering changes every time it's used (think perl's hashes), then the same program can produce different outputs every time. You probably therefore should not rely on the order in which the packets are emitted. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Updating GPG howto (http://keyring.debian.org/creating-key.html)
On Wed, Apr 06, 2011 at 12:15:49PM +0200, Vincent Caron wrote: That's a nice explanation that would fit on http://keyring.debian.org/creating-key.html If someone would like to put it up there, he or she should feel free to do so. Thanks for your help. Sure. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Updating GPG howto (http://keyring.debian.org/creating-key.html)
On Thu, Apr 07, 2011 at 10:26:10AM -0700, Jonathan McDowell wrote: It's not entirely accurate. The point of those lines are to ensure that older (certainly lenny and earlier, I'm not sure when the default changed) versions of GnuPG don't use SHA1 when signing keys (either your own or others). From looking at the source code, it seems that the default digest algorithm for signing both data and keys is still SHA-1. There is some special code to handle DSA keys with the size of q 160 bits, since SHA-1 wouldn't work in those cases. This makes sense since it is the must-implement hash algorithm. So setting these preferences is still recommended for current use. While these preferences do affect key signatures, they also affect other uses as well—uses where SHA-1 is still a bad choice. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Updating GPG howto (http://keyring.debian.org/creating-key.html)
On Tue, Apr 05, 2011 at 05:15:15PM +0200, Vincent Caron wrote: 2/ It is suggested to update gnupg.conf with: personal-digest-preferences SHA256 cert-digest-algo SHA256 default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed Is it still needed with GnuPG 1.4.11 ? This isn't strictly needed with any version of GnuPG. However, these settings choose algorithms which are known to be stronger (avoiding MD5 and the mandatory but somewhat weakened SHA1). Setting default-preference-list specifies which algorithms you prefer in your key's self-signature (which you can always change later). Implementations are forbidden from using algorithms (other than the default must-implement ones) that you do not specify in your self-signature. Using cert-digest-algo chooses the algorithm you will use in signing keys. And finally, personal-digest-preferences is the algorithm you will use when signing data. If you know what you're doing, you can choose the algorithms you prefer here instead of these. If you don't, these are fine choices. 3/ The -gen-key menu has changed from the tutorial, it is now: Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) Again Ana's blog has been updated and it looks legal (and a good idea) to select the (1) option which also generates an ecnryption key in one go. Is that correct ? Yes. It creates an RSA main key (used for signing other keys and possibly data) and an RSA encryption-only subkey. Some people use a subkey for signing as well, but that can be generated later. I recommend using the largest size possible, which IIRC is 4096 bits. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Bug#620808: ITP: payyans -- A python utility to convert between ASCII and Unicode.
On Tue, Apr 05, 2011 at 09:41:27AM +0800, Paul Wise wrote: On Mon, Apr 4, 2011 at 11:03 PM, Ben Hutchings b...@decadent.org.uk wrote: And we already have the 'iconv' and 'recode' commands to do conversion between arbitrary character encodings. These are not character encodings, but specific fonts. See the khmerconverter ITP for some earlier discussion on this: If the same issues apply here, that's fine, but the description is completely wrong. The fonts in question are not ASCII and calling them that is simply not correct. The description should clearly state what the utility does so that people who need it can find it and those looking for iconv or recode determine that it's not for them. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
On Sat, Apr 02, 2011 at 10:30:43PM +0100, Ben Hutchings wrote: On Sat, 2011-04-02 at 23:07 +0200, Bjørn Mork wrote: Josselin Mouette j...@debian.org writes: I wonder what amount of features we are missing for network-manager to do the job; instead of rewriting a daemon from scratch, A daemon will never be able to replace ifupdown. ifupdown will never work correctly. ifupdown works very well for the server use case. Consider that my cable line is hooked up to a box that runs a DHCP server, runs a caching nameserver, and an IPv4-IPv6 tunnel using the sit* interfaces. /etc/resolv.conf should use the local nameserver information, not whatever my ISP provides. According to the package description, when using DHCP, network-manager does whatever it pleases. That's not okay. network-manager does not support the sit* interfaces, last I checked. It has significantly more dependencies. My server does not need wpasupplicant installed. It certainly does not need policykit anything, not even a shared library. It also leaves unused interfaces running, which on my laptop causes long delays when using libpam-krb5 as the attempt to contact the KDC times out. Also, what happens if network-manager crashes? You're introducing failure cases that are not needed. ifupdown doesn't have that failure case. I admit that I use network-manager on my laptop. It's very convenient for that use case. It is completely inappropriate for a server: the package description even says so. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: dh_shlibdeps warnings concerning undefined OpenMP symbols
On Thu, Mar 31, 2011 at 09:35:49PM +0200, Dmitry Katsubo wrote: KiBi, thanks for the hint. It turned out that libgomp is not listed as direct dependency of my library. Does it mean I have to put gcc-4.4 into debian/control - Depends and add -lgomp to LIBS explicitly during the linking stage? You do need -lgomp. You should not need gcc-4.4 in Build-Depends unless your package will not build on any other version (which is a very bad bug), since gcc is build-essential and therefore already installed. You certainly should not need it at runtime. Another problem that arises here: I autodetect OpenMP support using AC_OPENMP() autoconf macro. So if OpenMP is detected, then it is used, otherwise - not (optional enabled by default dependency). How to play correctly in this situation? If gcc 4.3 or higher is installed it should already contain the .so symlink that you need, so simply compile it as normal. No extra build-dependencies are needed. libgraphicsmagick3 is also compiled with OpenMP support (/usr/lib/libGraphicsMagick.a has omp_get_* and GOMP_* symbols undefined), however it does not depend on gcc-4.4. Again, you don't need to depend on gcc. Your package will probably have a dependency on libgomp1, but that will be automatically added if required. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Bug#619059: ITP: libmozilla-ca-perl -- Mozilla's CA cert bundle in PEM format
On Sun, Mar 20, 2011 at 09:26:07PM +, Nicholas Bamber wrote: * Package name: libmozilla-ca-perl Version : 20110301 Upstream Author : Gisle Aas gi...@activestate.com * URL : http://search.cpan.org/dist/Mozilla-CA/ * License : MPL-1.1 or GPL-2+ or LGPL-2.1+ Programming Lang: Perl Description : Mozilla's CA cert bundle in PEM format Mozilla::CA provides a copy of Mozilla's bundle of Certificate Authority certificates in a form that can be consumed by modules and libraries based on OpenSSL. Is this really appropriate for Debian's purposes? I would think that using ca-certificates is probably better since not only are the certificates already in PEM format but the administrator can choose to add, remove, enable, or disable certificates in one central place. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Transitional packages with conffiles
On Wed, Mar 16, 2011 at 02:01:37PM +, Ian Jackson wrote: Well surely the question is: why are the files moved to a different directory ? Why is the package renamed, even ? Do we need to be able to co-install the old and new ISC DHCP clients ?! The original dhcp-client was version 2. dhcp3-client was version 3. These used /etc/dhcp and /etc/dhcp3, IIRC. Someone realized that using version numbers in the name was probably a bad idea, and that dhcp-client was too generic a package name (there are many DHCP clients in Debian). The idea was to abandon the old name and instead choose a new name that was not so generic and at the same time, install the new, version 4 client, using /etc/dhcp. Co-installability was not considered important and thus the transitional package was created so that people will have a working DHCP client. If I'm wrong about any of this, I'm sure Andrew will correct me. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
