/run (was: Alpha build progress and suggestions for helping)
On Mon, 5 Sep 2011, Bob Tracy wrote: > I noticed another change in "the way things are done" which is a clear > violation of the principle of least astonishment: it appears "/var/run" > is now symlinked to "/run" following a recent upgrade I applied. This > broke "radvd" which wants to put its PID file in a subdirectory of > "/var/run" (/var/run/radvd). Yeah, it's probably a bad idea for "radvd" > to be doing that, but moving "/var/run" without looking for side-effects > was a bad idea too. > > As a rule, I like as little filesystem I/O on the root fs as possible. > If "/run" on a fresh installation is a separate filesystem (maybe even a > tmpfs type), I could understand the change. Otherwise, "/run" isn't the > brightest idea the powers that be ever unleashed on us. Just my > opinion, and worth what you paid for it :-). It will be a tmpfs: http://lwn.net/Articles/436012/ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620870 http://wiki.debian.org/ReleaseGoals/RunDirectory -- # TRS-80 trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \ # UCC Wheel Member http://trs80.ucc.asn.au/ #| what squirrels do best | [ "There's nobody getting rich writing ]| -- Collect and hide your | [ software that I know of" -- Bill Gates, 1980 ]\ nuts." -- Acid Reflux #231 / -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1109061432390.3...@motsugo.ucc.gu.uwa.edu.au
Re: Alpha build progress and suggestions for helping
On Tue, Sep 06, 2011 at 07:22:27AM +1200, Michael Cree wrote: > On 06/09/11 04:07, Bob Tracy wrote: > > On Sun, Sep 04, 2011 at 01:21:52PM +1200, Michael Cree wrote: > >> (...) > >> Many have failed because of a broken ghostscript install. Unfortunately > >> the newest ghostscript failed to build but I plan to have a closer look > >> at that in the next couple of days. So ignore any packages with the > >> error: "Can't find initialization file gs_init.ps." > >> (...) > > > > I don't know what the latest version is, but "9.02~dfsg-3" should build > > fine with any sane tool chain. > > No it does not. It FTBFS with the new multiarch toolchain because it > makes incorrect assumptions about the locations of system include files. > See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639073 Harumph! I *did* say "sane" toolchain :-). Mine's old enough to qualify under the circumstances, but as we've discussed previously, my environment isn't the official one that buildd boxes have to use. I admit the move to arch-specific includes has the potential to be a big win from multiple perspectives when the smoke clears. Until then... Forgive my ignorance, but is the "multiarch toolchain" idea something that other UN*X-like OSs are adopting? The way things have traditionally been organized under "/usr/include" on the various UN*X and UN*X-like OSs hasn't scaled well over the past 35 years, and the resulting mess is going to be painful to sort out. I noticed another change in "the way things are done" which is a clear violation of the principle of least astonishment: it appears "/var/run" is now symlinked to "/run" following a recent upgrade I applied. This broke "radvd" which wants to put its PID file in a subdirectory of "/var/run" (/var/run/radvd). Yeah, it's probably a bad idea for "radvd" to be doing that, but moving "/var/run" without looking for side-effects was a bad idea too. As a rule, I like as little filesystem I/O on the root fs as possible. If "/run" on a fresh installation is a separate filesystem (maybe even a tmpfs type), I could understand the change. Otherwise, "/run" isn't the brightest idea the powers that be ever unleashed on us. Just my opinion, and worth what you paid for it :-). --Bob -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110906025608.ga26...@gherkin.frus.com
Re: Alpha build progress and suggestions for helping
On 06/09/11 04:07, Bob Tracy wrote: > On Sun, Sep 04, 2011 at 01:21:52PM +1200, Michael Cree wrote: >> (...) >> Many have failed because of a broken ghostscript install. Unfortunately >> the newest ghostscript failed to build but I plan to have a closer look >> at that in the next couple of days. So ignore any packages with the >> error: "Can't find initialization file gs_init.ps." >> (...) > > I don't know what the latest version is, but "9.02~dfsg-3" should build > fine with any sane tool chain. No it does not. It FTBFS with the new multiarch toolchain because it makes incorrect assumptions about the locations of system include files. See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639073 Cheers Michael. -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e652173.6040...@orcon.net.nz
Re: Alpha build progress and suggestions for helping
On Sun, Sep 04, 2011 at 01:21:52PM +1200, Michael Cree wrote: > (...) > Many have failed because of a broken ghostscript install. Unfortunately > the newest ghostscript failed to build but I plan to have a closer look > at that in the next couple of days. So ignore any packages with the > error: "Can't find initialization file gs_init.ps." > (...) I don't know what the latest version is, but "9.02~dfsg-3" should build fine with any sane tool chain. The issue with "gs_init.ps" is a version mismatch between the packages needing it, and the package providing it. Get "ghostscript*", "gs-*", and "libgs9*" consistent as to version, and the "gs_init.ps" issue goes away. --Bob -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110905160735.ga23...@gherkin.frus.com
