Re: Preparing the m68k port for the future.
Wouter Verhelst wrote: [...] > When I first tried to create this setup, about a month after DebConf5 > (and about around the time when I announced this), it turned out > that it was plain impossible to build a cross-compiler with the > GCC4 code; not with toolchain-source (because that had not been > updated yet to GCC4, so would be useless for this purpose) but also > not with the upstream source and the scripts from kegel.com: Some > internals of the GCC4 code expected that the compiler and the binutils > would be called 'm68k-linux-foo', whereas other bits expected > 'm68k-linux-gnu-foo'. Obviously this could be fixed by someone > familiar with the gcc/binutils build system, but that's besides > the point; the point is that rolling our own, very special, setup > might introduce extra weaknesses (I had warned in Helsinki about the > possibility that a cross-compiler might not produce the very exact > same object code that a native build would, but had not considered > the possibility that there might be bugs in the build system which > would only occur when trying to build cross-compilers). This would > complicate such a setup further. As a semi-retired GCC upstream developer, I have a couple comments here. First, we're aware that building cross compilers is harder than it ought to be, especially building cross compilers to targets that normally use native compilers. There is, however, a lack of manpower to fix these problems. We'd be delighted to get constructive feedback from people actually using a "host-x-host" configuration on a regular basis, assistance integrating Dan Kegel's scripts with the normal build mechanism, and so on. Things may already be better in mainline (GCC 4.2 that will be), as there's been quite a lot of build infrastructure work in this development cycle. Second, we of course cannot guarantee that a cross compiler to target X generates the same code as a native compiler for target X would, given the same input. However, all cases where the cross compiler generates different code from the native compiler for the same input are considered bugs, and if you find them, we want to hear about them. 'We' should be taken to refer to the GCC upstream developers as a collective entity, which at present doesn't really include me. (In other words, please bring bugs, suggestions, offers of assistance, etc. to the GCC mailing lists, *not* me.) zw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy (was: First draft of review of policy must usage)
I'd like to see this say something about what may be assumed of the standard shell utilities, as well as the shell itself, and in particular I'd like to see coreutils bug #339085 addressed [please see the bug log for my personal very strong opinion on which way it should be addressed]. zw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo
I looked at the page: this seems like an appropriate moment to mention something that should be a lot more widely known than it is: sizeof(char) == 1 sizeof(signed char) == 1 sizeof(unsigned char) == 1 Those three equalities are not part of any ABI. They are written into the C standard, in the definition of the sizeof() operator. They will never be false. zw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -Wl,--as-needed considered possibly harmful
> due to the recent dpkg-shlibdeps changes, people have started adding > -Wl,--as-needed into their LDFLAGS. > > THIS IS NOT A GOOD IDEA. > > You are essentially telling gcc to pass an option to the linker without > understanding what it does, and, more specifically, an option that tells > the linker to second-guess the gcc compiler driver. This can introduce > really interesting and subtle bugs that will be difficult to find. To first order, the only scenario I am aware of in which it can cause problems is if someone uses a global variable with a C++ constructor in a shared library, that constructor does critical work for the application the library is linked into, and the application does not reference any symbols whatsoever from the shared library. This is not impossible, but it is so unlikely IMO that the possibliity can be neglected. I have in the past argued for --as-needed to be made the default in upstream binutils; that's how safe I think it is. (Upstream maintainers, conscious of the above and other (isomorphic) corner cases, wanted a distribution to try it on a large scale first. Thus I am very happy to see Debian experimenting with it.) I'm curious what prompted your message. Did a program you use actually break? What was the failure mode? > If there are broken scripts adding too many libraries then it is time to > fix those scripts, not employ an evil hack that makes the symptoms go away. There are a *lot* of broken scripts. Would you like to mass-file bugs on every package that contains a binary that links to libnsl? (this iscommon, thanks to a buggy example in the autoconf manual, but completely unnecessary under glibc for anything other than a small handful of NIS-related programs, which probably have their own copies of that code anyway) How about programs that link to libm, but every symbol they use from libm happens to have been replaced by inline code? (I have seen this happen in real life.) Libraries that are linked against libpthread as a defensive measure for actual use of threads by their users, but only need the stubs in libc for that? (Can causes severe performance hits for single-threaded users of that library.) zw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: testing packages at build
> My god, that was awful. They still haven't fixed cpp -traditional, as > far as I know. Grumble grumble grumble. Bug number? zw
Re: testing packages at build
On Fri, 10 Oct 2003 01:59:25 -0500, Branden Robinson wrote: > On Thu, Oct 09, 2003 at 08:38:17PM -0700, Zack Weinberg wrote: > > > > > My god, that was awful. They still haven't fixed cpp -traditional, as > > > far as I know. Grumble grumble grumble. > > > > Bug number? > > Mumble mumble mumble. Never got around to filing it, figured XFree86 > wasn't such obscure code that that the GCC developers would refuse to > touch it with a ten foot pole, reckoned they might happen upon the > problem independently and fix it with chagrin [...] Well, if we came upon the problem independently we might have fixed it. But I don't know if we did, because I have no idea what the problem is. I have a vague memory of some problems with line numbering under -traditional, but that would only have affected programs that don't use -P, and imake uses -P, doesn't it? Is this even an imake issue? zw
Re: testing packages at build
Branden Robinson wrote: > No, it's a problem for programs that use cpp to parse X resource files. > > In particular, I noticed that xdm broke due to a mangled > /etc/X11/xdm/Xresources file when built with cpp 3.3 instead of cpp 3.2. I do not know enough about what X resource files are supposed to look like to identify this bug for sure. However, I notice that the /etc/X11/xdm/Xresources file from Daniel's experimental X4.3.0 debs appears to have had all its backslash-newlines eaten: | xlogin*login.translations: #override | CtrlR: abort-display()\n | F1: set-session-argument(failsafe) finish-field()\n and I *think* a bug in the handling of backslash-newlines with -traditional was fixed for GCC 3.3.2, which is due out today. Would you please try that version when it comes out, and if it's still broken, file a proper bug report? zw
Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
reopen 95420 quit ... > On Fri, Apr 27, 2001 at 12:22:18AM -0700, Zack Weinberg wrote: > > > > ash 0.3.8-1 incorporates changes in word splitting which break common > > shell scripts, such as /usr/bin/mktexpk and the 'mklibgcc' script used > > when compiling GCC. > > > > #! /bin/ash > > OIFS=$IFS > > IFS=, > > set `echo fnord,a,b,c` > > IFS=$OIFS > > CMD="echo $@" > > $CMD > > Sorry, but this is broken. This assumes that IFS is set to begin with > which may not be the case. I have consulted the Single Unix Standard and can find only dubious justification for this assertion. It never flat out says whether IFS is to be set on entry to the shell or not. However, I note this paragraph: # IFS #Input field separators: a string treated as a list of characters #that is used for field splitting and to split lines into fields #with the read command. If IFS is not set, the shell will behave #as if the value of IFS were the space, tab and newline #characters. (See Field Splitting .) I could read that as requiring that if IFS is unset, then you get "" if you inspect its value, NOT the null string. In any case, your change is a gratuitous divergence from the upstream code and a deliberate breakage of consensus shell behavior. My script functions correctly with every Bourne-descended shell I have access to except ash 0.3.8-1. (In addition to bash, pdksh, and previous versions of ash, I tried the /bin/sh provided by Solaris, HP-UX, IRIX, and Digital Unix, and the /bin/ksh and /usr/xpg4/bin/sh provided by Solaris.) Irrespective of what the standard says, you cannot introduce changes into /bin/sh which make it behave differently from every other shell out there. Especially if they have the potential to break every shell script which uses some feature. I had hoped that you had learned your lesson from the last time you pulled a stunt like this. It seems I was wrong. zw
Re: Bug#95420: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
On Mon, Apr 30, 2001 at 06:34:19PM -0400, Ben Darnell wrote: > This thread is directed at the wrong bug number - the discussion is about > #95430, but the messages are going to #95420. Please adjust the recipients > appropriately in your replies. My apologies, I mistyped the bug number. zw
Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
[EMAIL PROTECTED] on Tue, May 01, 2001 at 07:30:14AM +1000 # Let's try this again reopen 95430 severity 95430 critical retitle 95430 [SECURITY] ash honors IFS in environment quit On Tue, May 01, 2001 at 07:30:14AM +1000, Herbert Xu wrote: > > > I have consulted the Single Unix Standard and can find only dubious > > justification for this assertion. It never flat out says whether IFS > > is to be set on entry to the shell or not. However, I note this > > paragraph: > > It's wrong regardless of whether the shell sets it. The whole point of > saving IFS is so that you can restore it to its original value, which can > be whatever the previous user has set it to, including the case of it not > being set at all. If your code can't handle that, then please don't save > the value at all. Uh, no it can't. I'm talking about self-contained shell scripts, not functions. IFS does not inherit through the environment. Self-contained scripts can count on its being set to "" when execution begins. (tests) ... except that ash does honor IFS from the environment. You realize that this is a gaping security hole, even if IFS is only used to split the results of expansion? You realize that it is trivial to break any shell script on the entire machine that way? Both 0.3.8 and 0.3.7-x are affected by *that* bug, incidentally. [...] > > In any case, your change is a gratuitous divergence from the upstream > > code and a deliberate breakage of consensus shell behavior. My script > > functions correctly with every Bourne-descended shell I have access to > > except ash 0.3.8-1. (In addition to bash, pdksh, and previous > > versions of ash, I tried the /bin/sh provided by Solaris, HP-UX, IRIX, > > and Digital Unix, and the /bin/ksh and /usr/xpg4/bin/sh provided by > > Solaris.) Irrespective of what the standard says, you cannot > > introduce changes into /bin/sh which make it behave differently from > > every other shell out there. Especially if they have the potential to > > break every shell script which uses some feature. > > I can understand how frustrating it is to have your scripts broken by > this. But the fact remains that it's the scripts that are broken, not the > shell. > > Are your functions supposed to be called by other scripts in general? If > so, then it's particularly important to handle the case of an unset IFS. You don't get it, do you? What the standard says is IRRELEVANT. You cannot change consensus shell behavior even if it is in direct conflict with the standard. Find me ONE other implementation of a Bourne shell, which does not set IFS to "" on initialization, ignoring the value in the environment, and which postdates 4.4BSD and SVR4, and I'll shut up. The burden is on you to do this. I believe I have adequately demonstrated what the proper behavior is. zw
Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
severity 95430 critical quit I can keep this up just as long as you can. ... > > (tests) ... except that ash does honor IFS from the environment. You > > realize that this is a gaping security hole, even if IFS is only used > > to split the results of expansion? You realize that it is trivial to > > break any shell script on the entire machine that way? > > Get a clue, Linux does not allow setuid scripts. Irrelevant. Look up IFS in a bugtraq archive. I shan't do your homework for you. > > What the standard says is IRRELEVANT. You cannot change consensus > > shell behavior even if it is in direct conflict with the standard. > > You're the one who doesn't get it. If you are writing shell functions > and you need to save the IFS, then you need to save it properly. You don't seem to comprehend the difference between shell *functions* and shell *scripts*. zw
Re: Bug#95430: acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
> > > Get a clue, Linux does not allow setuid scripts. > > > > Irrelevant. Look up IFS in a bugtraq archive. > > I shan't do your homework for you. > > I did. And guess what, I didn't find one single exploit regarding this > on Linux. Interestingly, I found one exploit that relied on IFS to be set > to work. Okay, I'll concede that this exploit is only theoretical on Linux at this time. I feel it should still be fixed. Should a piece of vulnerable software be written for or ported to Linux, it will then not be exploitable. > > > You're the one who doesn't get it. If you are writing shell functions > > > and you need to save the IFS, then you need to save it properly. > > > > You don't seem to comprehend the difference between shell *functions* > > and shell *scripts*. > > Sorry I misread one of your messages. > > In any case, your script is still broken. I'm only working around this > because a related autoconf breakage (#95447) is very widespread. I stand on my assertion that the script is correct, and the shell is buggy since it fails to follow consensus behavior. However, as you've fixed the bug, I'll let it drop now. zw
autoconf2.13 (was Re: Outdated config.{sub,guess} package list)
Ben Pfaff wrote: > (Maybe it's time to get rid of the autoconf2.13 package > altogether, come to think of it.) It's still needed for just about everything put out by Mozilla, alas (iceweasel et al, obviously, but also libnspr and libnss, which are not just used by moz.org applications). There is absolutely no upstream interest in moving to 2.5x. zw not subscribed to d-devel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
mandate build-arch (was Re: Environment variables, debian/rules and dpkg-buildpackage)
If we're doing something that ultimately requires modification of every debian/rules file *anyway*, can we please make build-arch/build-indep mandatory targets, so that dpkg-buildpackage -B can *finally* (eight years later!) be changed to call build-arch? zw not subscribed to d-devel; please cc: -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Cinnamon environment now available in testing
Steve Langasek wrote: No, that's not the true package relationship. There's no reason that you should always get this added service by default when you install a system with non-systemd init that doesn't need logind. Making this a recommends would be a workaround for bad metadata in the libpam-systemd package; we should fix that problem at its source the right way. I filed bug #746578 against libpam-systemd back in May; I believe the proposed change (depend on systemd-shim | systemd-sysv rather than the other way around) addresses most if not all of this class of issues. It is currently WONTFIXed. Abstractly, I believe the ideal situation would be for all init systems in the archive to be *completely* co-installable, with /sbin/init a symlink under control of the administrator; under no circumstances would installing or upgrading any package change that symlink. (It follows that systems upgraded from wheezy might wind up with systemd _installed_, but sysvinit would remain the active init until the local admin changed things manually. Obviously this would need to be documented.) This would necessitate that all packages depending on specific functionality from the _running_ init be capable of detecting its absence at runtime and gracefully degrading their behavior. That may be nontrivial, but I believe that we need it _anyway_ so that when a system is deliberately converted from one init to another it continues to function more-or-less correctly until next rebooted. Unfortunately, it may be too late for this for jessie :-( zw -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5409f86c.1070...@panix.com
Re: Cinnamon environment now available in testing
On Fri, Sep 5, 2014 at 2:22 PM, Matthias Klumpp wrote: > 2014-09-05 19:52 GMT+02:00 Zack Weinberg : >> Abstractly, I believe the ideal situation would be for all init systems in >> the archive to be *completely* co-installable, with /sbin/init a symlink >> under control of the administrator ... > I did not test this, but AFAIK PID 1 can not be a symlink... I did not test this either, but per http://lxr.free-electrons.com/source/init/main.c#L906 and http://lxr.free-electrons.com/source/init/main.c#L952 the kernel just calls do_execve() on whatever init= parameter it's given or else a short list of defaults (including "/sbin/init"), so symlinks _should_ work normally. zw -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cakcabmgbfkkd+7id3eabrvpdne9ymz0ycxo8l9v3oomqezc...@mail.gmail.com
Re: systemd, again (Re: Cinnamon environment now available in testing)
Matthias Urlichs wrote: > > I also expect the Jessie upgrade to switch to systemd. Because, > frankly and strictly IMHO, doing anything else makes no sense > whatsoever. This is exactly the thing I don't agree with. I think _new installs_ of Jessie should use systemd as init (by default, anyway), but _upgrades_ from Wheezy or prior should continue to use whatever it is they were using before the upgrade, until the administrator takes an additional positive action to convert to something else. And I also think that "additional positive action" should NOT consist of installing or upgrading any package, but rather, something like changing what /sbin/init is a symlink to. (Hence the earlier statement that all init systems in the archive should be coinstallable, and that packages that need functionality provided by one specific system should detect that it isn't available at runtime, and gracefully degrade.) I think this strategy is positively _necessary_ in order to ensure that systems currently running Wheezy can safely be upgraded to Jessie. There are simply too many wacky configurations out there; it is not reasonable to demand that the systemd maintainers test them all; it is also not reasonable to demand that people with wacky configurations take extra steps prior to the upgrade in order to preserve a basically functional system afterward. (Functional enough to log in as root and make repairs, at least. Ideally without having to find another computer on which to search the interwebs for troubleshooting advice.) Even if you think this is not _technically_ necessary -- even if you think the systemd team _can_ reasonably anticipate everything that might possibly go wrong upon a forced changeover in the middle of a dpkg run, on an arbitrarily wackily customized system -- I would argue that it will provide tremendous _psychological_ reassurance to people who might be _worried_ that something will break. "Yes," Debian would be saying, "we recognize that this is a major, disruptive change and we have taken extra precautions to make sure it will only affect you when you are good and ready, and if something _does_ break, you can get back to the way it was very easily." zw -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140906161746.e170824...@panix5.panix.com
Re: Packages to install be default for Stretch
I'd like to provide a data point. On servers that I maintain, this is the complete list of manually-installed packages, excluding packages related to what the server actually _does_ -- that is, this, and nothing else, are what I consider vital to have available on a generic server that no one logs into except for maintenance. This is a virtual machine guest configuration, running a completely monolithic kernel provided from outside the image, hence the absence of most hardware-configuration-related packages. Note also that I always turn off auto-installation of recommended packages, and that this particular server was upgraded from wheezy to jessie in the most straightforward fashion, which *didn't* install systemd, and I haven't bothered changing it. bind9-host (†) bsd-mailx (†) debsums dnsutils (†) iputils-ping less locales (*) logcheck logcheck-database lsof monit needrestart netcat-traditional (†) nullmailer nvi (‡) openntpd openssh-client openssh-server resolvconf strace udev (*) ufw unattended-upgrades unbound whois wget (*) - I don't understand why nothing depends on these. (†) - I am confused by the number of overlapping packages that do this job, and may not have picked the optimal ones. (‡) - vim is insufficiently bug-compatible with Solaris 2.5 vi for my fingers. Relative to the default install, the interesting bits, I think, are: + network and system diagnostic tools + unattended upgrade mechanism + monit (maybe systemd can replace this, but I'm not comfortable enough with it yet) + openntpd + unbound + nullmailer - all documentation - at - tasksel - exim - miscellaneous command-line tools that I can install if I ever need them (e.g. bzip2, cpio) The full package list (again, minus packages defining what the server actually _does_) is attached. zw package.list Description: Binary data
query on use of sys/syscall.h and asm/unistd.h in user code
Hi, I'm with glibc development and I need to know about how some headers are used by user code. Specifically, for the 2.2 release of glibc (which is at least a year away; we're in codefreeze for 2.1 right now) we are thinking about modifying sys/syscall.h. I would like to know: 1. What packages use sys/syscall.h 2. What packages use asm/unistd.h 3. Which of the packages in (1) use the __NR_xyz defines for syscall numbers instead of the SYS_xyz defines 4. Which of the packages in (1) use the _syscall[012345] macros currently defined by sys/syscall.h Please respond directly to me; it's unlikely that many people on this list care, and I'm not on the list. thanks, zw
Re: Bug#37606: /var/spool/texmf/ls-R unwritable
On Thu, 13 May 1999 11:25:10 +0100 (BST), Julian Gilbey wrote: >[Cc'ing to -devel] > >> Package: tetex-base >> Version: 0.9.990406-1 >> >> Out of the box, /var/spool/texmf/ls-R is owned by root and mode 644. >> Therefore all font generation operations get an error: >> >> /usr/share/texmf/web2c/mktexupd: /var/spool/texmf/ls-R unwritable. >> >> Changing it to mode 666 works around the problem, but the right thing >> would be to make mktexupd setgid to some group (daemon?) and make >> /var/spool/texmf/ls-R writable by that group. Possibly the same thing >> should be done to the subdirectories of /var/spool/texmf, mode 1777 >> can be problematic. > >You are correct. A fully working solution which closes the security >holes is not straightforward, though. I am currently working on a >project to solve this problem. In the meantime though, note that the >font _is_ generated and stored, will be found by kpathsea on the next >occasion that it is needed, and will be written into the ls-R file the >next time the tetex cron job runs. Glad to hear all of this. I just have one comment: > - The mktexlsr, mktexdir and mktexupd scripts must not be setuid. >If they are, anyone could run them, which is unnecessary. Any >extra privileges they require will be gained when they are called >from other setuid processes. It seems to me that *only* these three should be setuid, since only these three need elevated privileges. mktextfm, etc. should be changed to write the output into a scratch directory, and have mktexupd move it into place. Yes, this does mean anyone can invoke them, but if properly designed no damage can be done, and this restricts the scope of the changes and the scope of the specially privileged code much better. zw
Re: Bug#37606: /var/spool/texmf/ls-R unwritable
On Thu, 13 May 1999 15:02:40 +0100 (BST), Julian Gilbey wrote:
>> Glad to hear all of this. I just have one comment:
>>
>> > - The mktexlsr, mktexdir and mktexupd scripts must not be setuid.
>> >If they are, anyone could run them, which is unnecessary. Any
>> >extra privileges they require will be gained when they are called
>> >from other setuid processes.
>>
>> It seems to me that *only* these three should be setuid, since only
>> these three need elevated privileges. mktextfm, etc. should be
>> changed to write the output into a scratch directory, and have
>> mktexupd move it into place.
>>
>> Yes, this does mean anyone can invoke them, but if properly designed
>> no damage can be done, and this restricts the scope of the changes and
>> the scope of the specially privileged code much better.
>
>No, absolutely not. If mktexupd is setuid, then anyone can make it do
>anything to the ls-R file, I would guess.
Only if mktexupd is misdesigned; it ought to be capable of validating
updates.
>And having mktex{mf,tfm,pk}
>writing to a scratch directory defeats the purpose of making the fonts
>directory read only, as anyone could then create a corrupt font file
>in the scratch directory and run mktexupd.
This is a problem, but isn't there some simple, efficient way to
validate font files?
zw
Re: Bug#37606: /var/spool/texmf/ls-R unwritable
On Fri, 14 May 1999 19:04:01 +0100 (BST), Julian Gilbey wrote:
>> On Thu, 13 May 1999 15:02:40 +0100 (BST), Julian Gilbey wrote:
>> >> Glad to hear all of this. I just have one comment:
>> >>
>> >> > - The mktexlsr, mktexdir and mktexupd scripts must not be setuid.
>> >> >If they are, anyone could run them, which is unnecessary. Any
>> >> >extra privileges they require will be gained when they are called
>> >> >from other setuid processes.
>> >>
>> >> It seems to me that *only* these three should be setuid, since only
>> >> these three need elevated privileges. mktextfm, etc. should be
>> >> changed to write the output into a scratch directory, and have
>> >> mktexupd move it into place.
>> >>
>> >> Yes, this does mean anyone can invoke them, but if properly designed
>> >> no damage can be done, and this restricts the scope of the changes and
>> >> the scope of the specially privileged code much better.
>> >
>> >No, absolutely not. If mktexupd is setuid, then anyone can make it do
>> >anything to the ls-R file, I would guess.
>>
>> Only if mktexupd is misdesigned; it ought to be capable of validating
>> updates.
>
>How?
The proper location for a file to be installed in /var/spool/texmf is
uniquely determined by its name, right? You hand it a file, and it
puts it where it belongs. No other changes to ls-R are possible via
(this version of) mktexupd
Moot, though, given what you say below.
>> >And having mktex{mf,tfm,pk}
>> >writing to a scratch directory defeats the purpose of making the fonts
>> >directory read only, as anyone could then create a corrupt font file
>> >in the scratch directory and run mktexupd.
>>
>> This is a problem, but isn't there some simple, efficient way to
>> validate font files?
>
>Yes: recreate them and compare the outputs. You don't want to just
>check that the files are valid, but also that they have the correct
>content.
Ok, I give up, we do have to do it your way.
zw
Re: Bug#37606: /var/spool/texmf/ls-R unwritable
On Sun, 16 May 1999 21:31:14 +0100 (BST), Julian Gilbey wrote:
>> >> >And having mktex{mf,tfm,pk}
>> >> >writing to a scratch directory defeats the purpose of making the fonts
>> >> >directory read only, as anyone could then create a corrupt font file
>> >> >in the scratch directory and run mktexupd.
>> >>
>> >> This is a problem, but isn't there some simple, efficient way to
>> >> validate font files?
>> >
>> >Yes: recreate them and compare the outputs. You don't want to just
>> >check that the files are valid, but also that they have the correct
>> >content.
>>
>> Ok, I give up, we do have to do it your way.
>
>Yes, it's something I struggled with a few years ago in our department
>where corrupt fonts had been created: there was no simple way to
>determine this fact without recreating them. (You could compare the
>embedded checksums with those in the corresponding tfm, but how do you
>know that is correct if the tfm is also autogenerated?)
The main reason I didn't want to have mktex{mf,tfm,pk} be setuid is
because they run all sorts of different programs - metafont, gsftopk,
etc. - which can (IIRC) be replaced by the user. Even if they can't,
their inputs can, and the inputs are turing-complete macro languages.
If mktex{mf,tfm,pk} drop privileges before invoking the real generator
programs, I'll be happy.
I would also rather not install suidperl if it can be avoided.
zw
Re: merged /usr vs. symlink farms
Tomas Pospisek wrote: > On 22.08.21 00:11, Guillem Jover wrote: >> I'm personally just not seeing such consensus, despite the attempts of >> some to make it pass as so. My perception is that this topic has become >> such a black hole of despair, that people that take issue with it, are >> simply stepping away. ... > I do not really care which solution will be chosen. I hope it will > be one that doesn't break my system(s) too hard so I'll be able to > ask a search engine and follow the hints and instructions. I'm just a user, but this seems like the right moment for me to speak up: Whether or not / and /usr ever get merged *doesn't affect me as a user.* All the stuff I use will be in my $PATH either way. The benefits, AIUI, are all for people developing or packaging software that has to be compatible with many different Linux distributions, but does not care about portability to non-Linux environments. That simply isn't me. So I don't care if the transition happens or not, nor about the timeframe, and I'd *like* to not have to care about how it gets done. What I *do* very much care about is whether I can trust package installation (of official, stable packages) to not break my systems, and the way this discussion is going, it seems like I might not be able to, and yes, that is disheartening. The chief dpkg maintainer has given clear technical reasons why the approach taken by usrmerge risks breaking people's systems. There is a proof-of-concept in this very thread, demonstrating that the bugs are real. From where I'm sitting, that should have been the end of the argument. Hard stop on further merge-related changes in unstable until a transition plan has been worked out that *won't* tickle dpkg bugs; if that means waiting another release cycle in order to ship dpkg bugfixes, *so be it*. (I reiterate that as a user I don't care whether this transition ever actually happens.) Maybe even revert to non-merged mode in the installer and drop usrmerge from testing and stable, as a precaution. But somehow what I see happening instead, is that Guillem's concerns are being brushed aside, demoralizing him to the point where, if it were me in his shoes, I would have resigned from the entire project; and half the posters in this thread are raring to push ahead with a transition that has a nonzero chance of wrecking one of my servers the next time unattended-upgrades does its thing. (If I understand the issue correctly, it *could* bite on a point upgrade or even a security patch of any system that has already been transitioned the way usrmerge/d-i do it, including all fresh bullseye and now also bookworm installations.) That's a horrifying failure of both technical and social project management. I used the word "nonzero" in the last paragraph intentionally. I don't want to hear any probabilistic arguments why everything should be fine. I want a transition plan that *guarantees* no breakage. That's what Debian has given us end-users for 20+ years and I hate that I might have to worry about not getting it again. And I think several people here owe Guillem an apology. zw
Re: merged-/usr transition: debconf or not?
Marco d'Itri wrote: > On Nov 10, Sam Hartman wrote: > > I'm sorry, but I think the only way in which that horse is dead is that > > no one has proposed patches to dpkg. > Indeed, because the sides of this argument are like three people (one of > them being the dpkg maintainer) versus everybody else. It's not a subject of debate. The dpkg maintainer says that dpkg does not support what usrmerge does, and that it can lead to package corruption. In the previous debian-devel thread on this, it was proven empirically that he is correct. > Since some significant work on dpkg is reasonably not forthcoming Yeah, because _you,_ Marco, prefer to spend your time trying to gaslight the project into thinking there isn't a critical-severity bug in usrmerge. This could have all been over by now if you had rolled up your sleeves and written the necessary patches for dpkg when Guillem originally notified you of the problem (in 2016; #848622; the bug log does not reflect the actual severity, but again that appears to be all on you). zw
Re: merged-/usr transition: debconf or not?
Luca Bonassi wrote: > may I also remind participants in this thread that according to our > Constitution (2.1), no project member is obliged to do work on > anything they don't want to Yes, and it follows that the people who want a change to happen are the people who will have to do the work to make that change happen, including fixing any bugs that are exposed by that change. If they don't want to do that work, and nobody else does either, then maybe the change isn't going to get done. As I said in the previous thread about this, I personally don't care whether merged-/usr ever actually happens. It is not relevant to what I use Debian for. So I am not motivated to do any work to make it happen. But I do very much care that the transition isn't botched, and right now it looks like the greatest risk of the transition being botched comes from proponents who are trying to rush to the end state without fixing all the bugs exposed in the process. Since one of the exposed bugs involves files going missing from Required and Essential packages upon seemingly-unrelated upgrades, during some indefinite period *after* the transition, you can, I hope, see why I feel it necessary to make a stink. > [The bug where files disappear from packages upon being moved from > /bin to /usr/bin or vice versa, after / is a symlink to /usr] to the > best of my knowledge has not been actually observed in the wild > despite this setup being the default for 100% of Ubuntu users who > install/upgrade to 21.10, 100% of new Ubuntu installs since ~2018 > and an unspecified number of Debian installs being the default in > our installer too for the past two stable releases There's a very good reason for that: people aren't doing the package changes that trigger the bug, yet. They can't, because that would break systems where /usr hasn't been merged. If the bug is not fixed I expect it will start causing problems in unstable *after* bookworm, since (as I understand the current transition plan) bookworm+1 development is the earliest that package maintainers may assume /bin is a symlink. The existence of the bug is not in question. A step-by-step reproduction recipe was posted in the previous thread. Losing files from Essential packages when they are upgraded is severity:critical. Therefore: either someone fixes the bug, or the transition will have to be canceled. It appears to me that the tech ctte agrees with all of this. > I dare say it would help their cause a great deal more, instead of > rekindling flame wars on a mailing list, Marco is the person who restarted the argument. I will cheerfully drop the subject again as soon as Marco acknowledges that (a) the bug exists, and (b) it is a hard blocker for the transition. zw p.s. apologies for breaking threading, i'm not subscribed to d-d
Re: dash and hidden bashisms in configure scripts
Speaking as the /de facto/ upstream maintainer of autoconf, is there anything we could do from our end to make it easier for dash to turn $LINENO back on? I don't have a lot of time to work on autoconf at the moment, but this particular issue is important to me. I'd like to see all the configure scripts that *don't* have bashisms in them run at dash's speed on Debian, and the fallback code for when $LINENO isn't available at all is a monstrosity that I would like to scrap. zw
Re: [RFC] changes to rsyslog
> I would thus like to proceed and change the priority of rsyslog from > important to optional, which in turn would mean, it is no longer installed by > default. Do you know of a tool that does what logcheck does, but operating directly on the journal? Logcheck is the only reason I still have rsyslog installed on the servers I maintain. zw
Re: merged-/usr transition: debconf or not?
On Wed, Nov 17, 2021, at 1:37 PM, Sam Hartman wrote: >>>>>> "Zack" == Zack Weinberg writes: > Zack> Therefore: either someone fixes the bug, > Zack> or the transition will have to be canceled. It appears to me > Zack> that the tech ctte agrees with all of this. > > There's a third option. > We sit around in the state where /bin is a symlink, but where you cannot > move files to /usr paths in the package system until the bug is fixed. I guess that is a potential outcome. In a sense we are already in that state, given the installed base of systems where /bin is already a symlink. I don't *like* that outcome; I think it's asking for lots and lots of accidental breakage in unstable post-bookworm, as packages are rebuilt on systems that now have /bin a symlink. But I can't personally offer to fix dpkg, either (way oversubscribed on other projects, and this doesn't seem like a job to be tackled by someone new to dpkg, tbh). > I.E. I don't think the transition is going to get canceled; we're too > far down that path. *Are* we? It seems to me that we could still, at this point, pull usrmerge from testing and stable, push point updates to the installers for all supported releases to flip the default back to non-merged /usr, and advise the installed base to run dpkg-fsys-usrunmess before their next apt upgrade. It'd be ugly but it might well be *less* ugly than being stuck in the state you describe. I understood the tech-ctte to be explicitly holding that option open. The proponents of merged /usr would be unhappy, but that does not bother me. zw
Re: merged-/usr transition: debconf or not?
>>>>>> "Sam" == Sam Hartman wrote:
>>>>>> "Zack" == Zack Weinberg writes:
Sam> There's a third option. We sit around in the state where /bin is
Sam> a symlink, but where you cannot move files to /usr paths in the
Sam> package system until the bug is fixed.
Zack> I guess that is a potential outcome. In a sense we are
Zack> already in that state, given the installed base of systems
Zack> where /bin is already a symlink.
Zack> I don't *like* that outcome; I think it's asking for lots and
Zack> lots of accidental breakage in unstable post-bookworm.
Sam> I don't like that outcome either.
Sam> I think that we have reasonable mitigations for the specific problem you
Sam> describe.
Sam> In particular, we do as I understand it have QA plans to build both with
Sam> merged /usr and without prior to bookworm to catch problems like the
Sam> ones you describe.
Sam> After bookworm releases it's totally fine if programs reference
Sam> filesystem paths like /usr/bin/bash, so long as they don't move where
Sam> things get installed.
I don't think that will mitigate the problem. I think that post-bookworm,
packages like coreutils and libc6 are going to notice, in their upstream
configure scripts, that /bin etc are symlinks into /usr, and start installing
stuff that used to be in / into /usr. Maintainers are going to need to take
positive action to _prevent_ the move, and there will no longer be automation
to detect that files have moved.
Sam> I.E. I don't think the transition is going to get canceled; we're
Sam> too far down that path.
Zack> *Are* we? It seems to me that we could still, at this point,
Zack> [roll back the transition]
Sam> I don't think we would find people to do enough testing to
Sam> validate that was a reasonable thing to do. But also, the usrmerge
Sam> proponents get most of what they wanted even if we're stuck in the
Sam> middle.
That is exactly why I think a rollback should not be taken off the table:
it is very, very bad if the usrmerge proponents get most of what they want
while the rest of the project is left to clean up their mess. The project
cannot afford to reward such misbehavior. I honestly think the social
fallout of allowing that to happen would be *worse* than the social and
technical fallout of forcing a rollback through.
...
Sam> I want to reiterate that the initial process surrounding usrmerge was
Sam> horrible. The dpkg maintainer had what turned out to be legitimate
Sam> concerns that were not reasonably addressed. I think that's in part
Sam> because they were presented poorly and in part because people didn't
Sam> want to hear them. That's a real process failure.
...
Sam> I think people on both sides were unwilling to listen to each other.
I'm an outside observer and I have not followed this argument closely from
the beginning, but my perception of it is much more one-sided than you are
making it out to be. This is what _I_ saw:
- usrmerge was deployed to unstable in late 2014. It's not clear to me
how much testing it got in 2015.
- Reports of it causing problems for dpkg started to appear in early 2016
(e.g. #810499). These seem to have been addressed civilly, but even then
a "well it works for _me_ so :shrug:" attitude from the merged-/usr
proponents is evident in the bug logs.
- The dpkg maintainer filed a severity:serious bug on usrmerge in late
2016 (#848622), saying that it breaks dpkg -S. This is the earliest
instance I can find of Marco in particular overtly blowing off a bug
report that he didn't think was significant ("Over one year of
experience with merged-/usr systems has not exposed any failures",
which is an invalid argument). This bug is also significant in
hindsight because, although not described as such, it appears to me
to have the same root cause as the file lossage on upgrade that you
and I, at least, agree is severity:critical.
- Over the next, um, *five years*, Marco continued to ignore or reject
Guillem's attempts to get him to take problems seriously that were
caused by usrmerge rendering the dpkg database inconsistent with the
file system.
- Marco also reacted hostilely to concerns raised by others, e.g.
Adrian Bunk (#863269).
- Guillem, for his part, has displayed far more patience than I would
have in his situation, repeatedly attempting to explain why there is
a serious problem, offering concrete solutions - that they may not be
practical is not the point; he's done more work toward that end than
anyone else - and never, that I have seen, losing his temper.
At the same time, he has said in so many words that this has caused
him to become burnt out on Debian in general and dpkg maintenance in
part
Re: merged-/usr transition: debconf or not?
Marco d'Itri wrote: > On Nov 18, Zack Weinberg wrote: >> as it has proven to be a genuinely critical problem > No, it has not. In the previous long thread on debian-devel on this subject, someone posted a step-by-step recipe to reproduce a phenomenon where a file that has been moved (in its package) from an installation path of /bin (for example) to /usr/bin, possibly in conjunction with a change to which package owns it, while /bin is a symlink to /usr/bin, will disappear from the file system when the updated set of packages is installed. (I regret I do not have time today to dig up the exact email in question.) Are you seriously claiming that that phenomenon is not a severity:critical bug? zw
Re: merged-/usr transition: debconf or not?
Luca Bocassi wrote: ... > [merged /usr] is the default. It has been the > default for multiple releases of multiple distributions. All Ubuntu > installations that were not using this default are now forcibly > converted upon upgrade to 21.10. > > And yet nobody has actually seen [the file disappearance bug] > happen, to the best of my knowledge. I already explained why that doesn't prove the bug is a non-issue. To the contrary; it means there is an enormous installed base of systems where the bug is latent, waiting to cause problems under conditions which we can reasonably expect to occur shortly after the release of bookworm. Please do not make me repeat myself. zw
Re: merged-/usr transition: debconf or not?
On Thu, Nov 18, 2021, at 8:06 PM, Luca Boccassi wrote: >> On Thu, 2021-11-18 at 16:23 -0500, Zack Weinberg wrote: >> Luca Bocassi wrote: >> ... >>> nobody has actually seen [the file disappearance bug] >>> happen, to the best of my knowledge. >> >> I already explained why that doesn't prove the bug is a non-issue. >> To the contrary; it means there is an enormous installed base of >> systems where the bug is latent, waiting to cause problems under >> conditions which we can reasonably expect to occur shortly after >> the release of bookworm. > > Why would the release of bookworm make any difference? Up until the release of bookworm, all Debian packages must be constructed on the assumption that they _might_ be unpacked on a system that has not yet been converted to merged /usr. Particularly for priority-required packages, this means that no one will be moving files from /bin, /lib, etc to /usr in the bookworm cycle. Post-bookworm, if nothing changes, that assumption will no longer be in force, and people who maintain packages that install files into / will want to simplify their packaging by installing everything in /usr instead. If they also want to change the binary packages that ships some of those files at any point in the same release cycle -- kaboom. zw
Re: merged-/usr transition: debconf or not?
On Fri, Nov 19, 2021, at 3:23 PM, Zack Weinberg wrote: > On Thu, Nov 18, 2021, at 8:06 PM, Luca Boccassi wrote: >>> On Thu, 2021-11-18 at 16:23 -0500, Zack Weinberg wrote: >>> Luca Bocassi wrote: >>> ... >>>> nobody has actually seen [the file disappearance bug] >>>> happen, to the best of my knowledge. >>> >>> I already explained why that doesn't prove the bug is a non-issue. >>> To the contrary; it means there is an enormous installed base of >>> systems where the bug is latent, waiting to cause problems under >>> conditions which we can reasonably expect to occur shortly after >>> the release of bookworm. >> >> Why would the release of bookworm make any difference? > > Up until the release of bookworm, all Debian packages must be > constructed on the assumption that they _might_ be unpacked on a > system that has not yet been converted to merged /usr. Particularly > for priority-required packages, this means that no one will be moving > files from /bin, /lib, etc to /usr in the bookworm cycle. > > Post-bookworm, if nothing changes, that assumption will no longer be > in force, and people who maintain packages that install files into / > will want to simplify their packaging by installing everything in /usr > instead. If they also want to change the binary packages that ships > some of those files at any point in the same release cycle -- kaboom. After having caught up on the thread, I see that the conditions required to trigger the bug are somewhat more complicated, but the point remains: particularly for the packages where a lost file could render the system unbootable, changes that would trigger the bug have been deferred until post-bookworm, *and* we can reasonably expect the maintainers of those packages to *want* to make changes with a high risk of triggering the bug. I imagine the coreutils maintainers are looking forward to getting rid of their list of programs that go in /bin, and the extra debian/rules logic to go with it, for instance (https://sources.debian.org/src/coreutils/8.32-4.1/debian/rules/#L16). zw
autoconf-2.69b released [beta]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
We are pleased to announce beta release 2.69b of GNU Autoconf.
This release includes eight years of development work since the
previous release, 2.69. See below for the detailed list of changes
since the previous version, as summarized by the NEWS file.
Because it has been such a long time, and because some of the changes
potentially break existing Autoconf scripts, we are conducting a
public beta test before the final release of version 2.70. Please
test this beta with your autoconf scripts, and report any problems you
find to the Savannah bug tracker:
https://savannah.gnu.org/support/?func=additem&group=autoconf
Please also send general comments and feedback to .
Please also spread this announcement widely, so that as many Autoconf
users as possible hear about it.
The final release of Autoconf 2.70 is tentatively scheduled for three
months from now. We may make more beta releases during this period.
Here are the compressed sources:
https://alpha.gnu.org/gnu/autoconf/autoconf-2.69b.tar.gz (1.9MB)
https://alpha.gnu.org/gnu/autoconf/autoconf-2.69b.tar.xz (1.3MB)
Here are the GPG detached signatures[*]:
https://alpha.gnu.org/gnu/autoconf/autoconf-2.69b.tar.gz.sig
https://alpha.gnu.org/gnu/autoconf/autoconf-2.69b.tar.xz.sig
Use a mirror for higher download bandwidth:
https://www.gnu.org/order/ftp.html
[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact. First, be sure to download both the .sig file
and the corresponding tarball. Then, run a command like this:
gpg --verify autoconf-2.69b.tar.gz.sig
If that command fails because you don't have the required public key,
then run this command to import it:
gpg --keyserver keys.gnupg.net --recv-keys ED97E90E62AA7E34
and rerun the 'gpg --verify' command.
This release was bootstrapped with the following tools:
Automake 1.15.1
NEWS
* Noteworthy changes in release 2.69b (2020-07-13) [beta]
** config.log properly escapes arguments in the header comment;
config.status --config output is now quoted in a more readable fashion
** Configure scripts now support a '--runstatedir' option, which
defaults to '${localstatedir}/run', and which can be used to place
per-process temporary runtime files (such as pid files) into '/run'
instead of '/var/run'.
** The use of the long-deprecated name 'configure.in' for the autoconf
input file now elicits a warning in the 'obsolete' category.
** Older version of automake and aclocal (< 1.8) are no longer supported
by autoreconf.
** Use of printf is now recommended instead of working around bugs in
echo. The macros AS_ECHO and AS_ECHO_N now expand unconditionally to
'printf "%s\n"' and 'printf %s'.
** Use of the undocumented internal shell variables $as_echo and
$as_echo_n now elicits a warning in the 'obsolete' category.
The macros AS_ECHO and AS_ECHO_N should be used instead.
** When checking for missing templates, autoheader now takes any
templates defined in the inputs of secondary config headers into
account. This makes it possible to use AC_DEFINE for secondary
headers without duplicating the template in the main config header.
** Many macros have been improved to expand their arguments
once and only once. This makes âautoconfâ run faster. However, it
may break configure scripts that did not quote all macro arguments
properly. The âM4 Quotationâ section of the manual explains how to
quote macro arguments properly.
** Several macros that are commonly used early in a configure
script, such as AC_PROG_CC, have been optimized and no longer
invoke as many subroutine macros as they used to. This can expose
several classes of bugs: these are the ones we know about:
- Make sure to explicitly invoke all of the macros that set result
variables used later in the configure script, or in generated
Makefiles.
- Autoconf macros that use AC_REQUIRE internally, are not safe to
use inside of hand-written shell conditional or looping
constructs. Use AS_IF, AS_CASE, AS_FOR, etc. instead.
(See the âPrerequisite Macrosâ section of the manual for
further explanation.)
The set of macros that use AC_REQUIRE internally may change from
release to release. The only macros that are guaranteed *not* to
use AC_REQUIRE are the macros for acting on the results of a
test: AC_DEFINE, AC_SUBST, AC_MSG_*, AC_CACHE_CHECK, etc.
- AC_REQUIRE cannot be applied to macros that need to be used with
arguments. Instead, invoke the macro normally, with its arguments.
** Macros that take whitespace-separated lists as arguments
now always expand macros within those arguments. (Formerly, these
macros would *usually* expand those arguments, but the behavior was
not reliable nor was it consistent between autoconf and autoheader.)
Macro expansion within these arguments is deprecated;
Re: testing OpenSSL 1.1.0 on jessie
Daniel Pocock wrote: > I wanted to try compiling some upstream projects against OpenSSL 1.1.0 > on jessie, without installing the package though. I tried the following: > > dget -x http://http.debian.net/debian/pool/main/o/openssl/openssl_1.1.0c-1.dsc > > cd openssl-1.1.0c/ > dpkg-buildpackage -rfakeroot -j13 > > and it builds but only 4 of the headers appear to install: Start over from scratch with -j1. Seriously. I haven't tested 1.1.0, but the last time I built OpenSSL its makefiles were _catastrophically_ broken with any amount of parallelism. You probably didn't even get a complete build, and the source code may have been damaged. zw
Re: MBF for deprecating Python2 usage
> I think there should be one release which is not shipping > /usr/bin/python before /usr/bin/python should be reused and pointed > at python (>> 2). This should be good enough to get all scripts > actively converted which are not part of the distribution. > > If that release is buster, we should require the use of python2 > instead of python now, document that in policy and provide a lintian > check for that. As an end-user of both Debian and Python, I do not think this timeline is realistic, and I would request the following: 1) Do not remove the base Python 2.7 interpreter (that is, the python2.7, python2.7-minimal, and python2.7-dev packages) from the distribution until the release *after* its upstream end-of-life (with the current schedule, that would be the first release in 2021). 2) Leave the full path /usr/bin/python and the bare command name 'python' referring to Python 2 and only Python 2 - no cleverness, please - until that point. 3) After Python 2 is completely removed from the distribution, the full path /usr/bin/python and the bare command name 'python' should be reserved and unused for at least ten years. zw
