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
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?
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?
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?
>>>>>> "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
particular.
There's no "both sides were unwilling to listen" when all one side is
bringi
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: [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: 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: 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: 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 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
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=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; if
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
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: 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
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: 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 matth...@tenstral.net wrote: 2014-09-05 19:52 GMT+02:00 Zack Weinberg za...@panix.com: 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
Accepted pngcrush 1.7.65-0.1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 01 Jul 2013 10:17:54 -0400 Source: pngcrush Binary: pngcrush Architecture: source amd64 Version: 1.7.65-0.1 Distribution: unstable Urgency: low Maintainer: Kapil Hari Paranjape ka...@debian.org Changed-By: Zack Weinberg za...@panix.com Description: pngcrush - optimizes PNG (Portable Network Graphics) files Closes: 612934 648128 657855 662471 678436 Changes: pngcrush (1.7.65-0.1) unstable; urgency=low . * NMU to fix the more serious problems with this dormant package. * New upstream release (Closes: #657855, #612934). - Should now build with libpng 1.5 (Closes: #648128). - No longer crashes when adding more than two text chunks (Closes: #678436). - Upstream has switched to .xz tarballs, follow suit. - patches/*: Normalize file names. - patches/local_Makefile_adjustments.diff: Refresh. Use -Wl,--as-needed to pull in -lm only if actually required. Do not attempt to override configuration macros defined by the system pngconf.h. - patches/local_version_skew_warning_only_if_verbose.diff: Refresh. * Build-depend on libpng-dev (Closes: #662471). * Bump to debhelper compatibility level 9 and dh-ify. * Install upstream changelog. * Standards-Version: 3.9.4 (no further changes required). Checksums-Sha1: 01e152477889c1c9f3485a667a101f3e9e8bbb40 1891 pngcrush_1.7.65-0.1.dsc f2e2496f7a16177528278dc58ed4ac2afe5fd227 57944 pngcrush_1.7.65.orig.tar.xz a3aded44c6db0ddd2246c78c825a5347784f917b 13932 pngcrush_1.7.65-0.1.debian.tar.xz 7791ee8ae5a8fff7dee4903390e1d869d00a09c6 60228 pngcrush_1.7.65-0.1_amd64.deb Checksums-Sha256: e633d1706f0f2d58d9e6a825514b0e18ff0af92764b8afffe2e6d39a8454392b 1891 pngcrush_1.7.65-0.1.dsc e9b51dab35a561de2b53721fdc9b3bbc93842e438efaf33e438dc219bd215528 57944 pngcrush_1.7.65.orig.tar.xz a19435578bcd09fbf46b649294f9f92bd3d110856e45b5e765861a368ec6f7d0 13932 pngcrush_1.7.65-0.1.debian.tar.xz 7a024a64aec2604cd14ec2440c06a6546c53bb1a6bea7f2702262aa490535271 60228 pngcrush_1.7.65-0.1_amd64.deb Files: 139159d8c7060c5a2c0df3f4fdf5233f 1891 graphics optional pngcrush_1.7.65-0.1.dsc b4130246c14c1cffc6c2014ff86f1008 57944 graphics optional pngcrush_1.7.65.orig.tar.xz aaa494128c56cfbe7d0cff5bb645005b 13932 graphics optional pngcrush_1.7.65-0.1.debian.tar.xz 689ddc7c5bfe486a69eedba820b6ec95 60228 graphics optional pngcrush_1.7.65-0.1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCAAGBQJSQ4CoAAoJEFK2u9lTlo0bLTYQANOOIL+lWiF02BW+/syGe5iI 5o8gKlUFMDq6SRXtjtiu5PBHe8z2t3LvB4/S6KJBrT2rveX3s6tJEPRr/gFHxb0a FCK1Sm186B6YFGXXy+2GazJw5uKFw3yYUvbI+T6FvSfM/n1OeTSJEBqxO/PJk0Zb rM2nQ7ktYkyHvpBHC7s/Sp6SzU5nH+jqAjVAaPBOeb5ukFU5ON5sJXFWrt/Rz0ZJ afB+Enec0CwqpSrkSfdSPMqG5E9NluPL5PudCPXK3QYRv4BSCxKtI0g+Deg9QmyQ SeVsmDu3PFaODl0QnlsxLRfkUwX+7NawD0PBNJ9ESToL7YlTxYTSIeXQRtvanH68 96RvpvF2SmgNfQWc3sVZGQpgIZSUZGgGvRyEIIfWCjMZdZ77OL6iUnJ1NN1psh4I 7SZFiEhSyWabsfM84gwILv7wgBITAXMnB4IE7YetYLH0885u5lUWD3gBz+sqAKJu 4LC6ELg6J+O4gLs+sQXEjiaDPbTUYY3NHcUmRkhUTXsg+HVZoUtgJCd3HPnVN0Xn Jhn06F98IJA+pOtTy6dgOloAdmBHhtpLZgAiX3wEIoy9NH5xlP4QzkVjOjncWTGL EiZLNLv+PBtietXFSGoklti4Iw+dg29lVBP3CwexmiA7odOSpTOc6QSCEdXRV4vS 4UEeURriWCHr8eYVyNAD =8RJx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1vozkv-0006ll...@franck.debian.org
Accepted monotone 0.45-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 14 Nov 2009 12:38:19 -0800 Source: monotone Binary: monotone monotone-server monotone-doc Architecture: source all amd64 Version: 0.45-1 Distribution: unstable Urgency: low Maintainer: Debian Maintainers for Monotone monotone-deb...@nongnu.org Changed-By: Zack Weinberg za...@panix.com Description: monotone - A distributed version (revision) control system monotone-doc - A distributed version (revision) control system - documentation monotone-server - A distributed version (revision) control system - server scripts Closes: 444153 537719 541758 542287 549386 555652 Changes: monotone (0.45-1) unstable; urgency=low . * New upstream version. - Major changes to key handling, see NEWS and UPGRADE for details. - Database schema upgrade is required. - Now properly skips files with unsupported names, instead of crashing (closes: #444153). - Incorporates 00-upstream-fix-shebang-for-bash-script.diff. * Bump version for automatic database migration in monotone-server.postinst. * Backport upstream fix for 'mtn clone' documentation (closes: #555652). * Adjust LSB header in monotone-server.monotone.init to match update-rc.d settings, and force those settings to be applied on upgrade from 0.44-2 or earlier (closes: #542287). * Build-depend on poppler-utils | xpdf-utils, as the latter may be dropped from squeeze (closes: #549386). * Force-disable testsuite if built with root privileges (closes: #537719). * New template translations: - Russian, thanks to Yuri Kozlov (closes: #541758). - Italian, thanks to Vincenzo Campanella (no bug). * Update all template translations with debconf-updatepo; this had not been done since 2006. Fortunately, the templates have not changed in at least that long, so no fuzzies are introduced. * Fix copyright boilerplate on most template translations. Convert French translation to UTF-8. * Add a README.source to the debian directory. * Policy 3.8.3; no changes required. Checksums-Sha1: b0f85806761793d10bbbc6d19e88f409e94a60c1 1482 monotone_0.45-1.dsc 73a1fd623d6ea14993d7bb39dfc6d5ad6d7e75cb 4670611 monotone_0.45.orig.tar.gz eb4c271184a548b05a11b523bbdc8af41a6ca5f4 31661 monotone_0.45-1.diff.gz a6e2b25aeb05bc745c11821f9234df0913fe2e5c 10530 monotone-server_0.45-1_all.deb 26522172c7e1d2b133f59abe0c3ab55bcba64f48 2335822 monotone-doc_0.45-1_all.deb c2cd06f66f3ce23f766266dc0b0eed2b79d1ca89 1910740 monotone_0.45-1_amd64.deb Checksums-Sha256: a39aab014a08df633efb7e24c7fa6b3310244804025db17d357c9f143aaf3f1b 1482 monotone_0.45-1.dsc dfe9f3771daace02bc3e3fc4e3da58b913d7932c9f016c59eb57e8673ae634c1 4670611 monotone_0.45.orig.tar.gz f8d1e2bd3764c75e03e662a94839ba41e100020824749b2070415d9ca8e89aa0 31661 monotone_0.45-1.diff.gz 086544a6daa35cca8d54cd0b36d87a179df9fa8ca7e3066193b17ec7d00ba6a8 10530 monotone-server_0.45-1_all.deb eda51cdd0df8d24b7ee2a39e6bdf89a826fa6c4765c3e63f6f97e92220f2f79a 2335822 monotone-doc_0.45-1_all.deb 45caee3258e1c508d74f406886120a1a9bec899d1e6861ed7a5277debcf8caa5 1910740 monotone_0.45-1_amd64.deb Files: c4bec19d5df2de67bd6ef1abb010ad52 1482 vcs optional monotone_0.45-1.dsc 7b5b83dee18e62a35a34ed658061e363 4670611 vcs optional monotone_0.45.orig.tar.gz a4de4f3a8d46910b4ac5da2d8c1c40c8 31661 vcs optional monotone_0.45-1.diff.gz 276d438a9e178449539cf2b62f2b94c7 10530 vcs optional monotone-server_0.45-1_all.deb 85579e1de86f963036e07c02fd53e2fa 2335822 doc optional monotone-doc_0.45-1_all.deb 7918eb7224792dd32210a71c8b17db94 1910740 vcs optional monotone_0.45-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFK/108x9kwJZ3/qtQRAjWXAJ9igY22bs9mcjUxb+eEr84WhA4MegCfUYM5 hc+A6+2AERNR4nvytk2Ildw= =6wHd -END PGP SIGNATURE- Accepted: monotone-doc_0.45-1_all.deb to main/m/monotone/monotone-doc_0.45-1_all.deb monotone-server_0.45-1_all.deb to main/m/monotone/monotone-server_0.45-1_all.deb monotone_0.45-1.diff.gz to main/m/monotone/monotone_0.45-1.diff.gz monotone_0.45-1.dsc to main/m/monotone/monotone_0.45-1.dsc monotone_0.45-1_amd64.deb to main/m/monotone/monotone_0.45-1_amd64.deb monotone_0.45.orig.tar.gz to main/m/monotone/monotone_0.45.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted monotone 0.44-2 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 16 Jul 2009 22:10:33 -0700 Source: monotone Binary: monotone monotone-server monotone-doc Architecture: source all amd64 Version: 0.44-2 Distribution: unstable Urgency: low Maintainer: Debian Maintainers for Monotone monotone-deb...@nongnu.org Changed-By: Zack Weinberg za...@panix.com Description: monotone - A distributed version (revision) control system monotone-doc - A distributed version (revision) control system - documentation monotone-server - A distributed version (revision) control system - server scripts Closes: 527314 530143 Changes: monotone (0.44-2) unstable; urgency=low . * Rebuilt against properly versioned botan packages (closes: #527314). * Use #!/bin/bash for script that uses bash arrays (closes: #530143). * Policy 3.8.2; no changes required. . monotone (0.44-1) UNRELEASED; urgency=low . * New upstream release. * Revert to unversioned boost build-dependencies now that we have boost-defaults. Checksums-Sha1: 4891d1a732c34c86c143fe6bc207b0560809efc8 1465 monotone_0.44-2.dsc 9aa8d8de8906cd1d69b992e08b61a0ffce1c7f91 4626622 monotone_0.44.orig.tar.gz 53f09b0f414a5d9fca4839325d90b31f39b30671 28525 monotone_0.44-2.diff.gz f269c9e6b9fe58608a5f169a064e3ab91d7ec6d1 9520 monotone-server_0.44-2_all.deb b5546de14d75e303b937c5f61e45662809d7a63d 2326250 monotone-doc_0.44-2_all.deb ca9a5b75edffde6b71b1d68177c907b9126e9e08 1876168 monotone_0.44-2_amd64.deb Checksums-Sha256: d4c3acebe1ce01ecb056a2033875eb4f3378e205cfe129bd4032dbbc81828635 1465 monotone_0.44-2.dsc 7e2b8f369d99178fae3d9a436c14039d0617578429ded6d098a0c78b2c5265f5 4626622 monotone_0.44.orig.tar.gz c76ce93934490f4bd2c8f0d2dbfc7e7457aa55686e4db8d258143a40dd7328c7 28525 monotone_0.44-2.diff.gz 09878fc8404c9533fe46e7fb8b3b6764e896d33a391307d773a98ace0664 9520 monotone-server_0.44-2_all.deb 61d73a478a844ad3ab9dc249938de131c1db77cbf7a641209e031f4c8f2da587 2326250 monotone-doc_0.44-2_all.deb 0c4be8d70147d936d27d3353c9fb1dea42661b12e5e1b04471b046182a8b477e 1876168 monotone_0.44-2_amd64.deb Files: da2ff0585ff5c1115d1dcf10899acba4 1465 vcs optional monotone_0.44-2.dsc 5520b8dbda513df0382b3fbce8a508d3 4626622 vcs optional monotone_0.44.orig.tar.gz 0b63a2127dce1fff2672443797425144 28525 vcs optional monotone_0.44-2.diff.gz 36083ff2314a678b4766d8e08414b04f 9520 vcs optional monotone-server_0.44-2_all.deb 5aae6f0a6506d7c89acf5cb62a9c7324 2326250 doc optional monotone-doc_0.44-2_all.deb 2524fb6cf996bd8b636172a7cf627d38 1876168 vcs optional monotone_0.44-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKZQSax9kwJZ3/qtQRAtDwAJ9IRI6tNWswt68He+N26fiY+z20qgCcCAYl BVD7tVly4WtI7k2e2KPKzX4= =pHYt -END PGP SIGNATURE- Accepted: monotone-doc_0.44-2_all.deb to pool/main/m/monotone/monotone-doc_0.44-2_all.deb monotone-server_0.44-2_all.deb to pool/main/m/monotone/monotone-server_0.44-2_all.deb monotone_0.44-2.diff.gz to pool/main/m/monotone/monotone_0.44-2.diff.gz monotone_0.44-2.dsc to pool/main/m/monotone/monotone_0.44-2.dsc monotone_0.44-2_amd64.deb to pool/main/m/monotone/monotone_0.44-2_amd64.deb monotone_0.44.orig.tar.gz to pool/main/m/monotone/monotone_0.44.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-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
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
Accepted monotone 0.43-3 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 12 Apr 2009 13:01:34 -0700 Source: monotone Binary: monotone monotone-server monotone-doc Architecture: source all amd64 Version: 0.43-3 Distribution: unstable Urgency: low Maintainer: Debian Maintainers for Monotone monotone-deb...@nongnu.org Changed-By: Zack Weinberg za...@panix.com Description: monotone - A distributed version (revision) control system monotone-doc - A distributed version (revision) control system - documentation monotone-server - A distributed version (revision) control system - server scripts Changes: monotone (0.43-3) unstable; urgency=low . * Verified to build with libboost1.38-dev, add to boost alternatives. * Change backtrace-on-crash mechanism to use glibc's backtrace() instead of gdb; less informative, hopefully more robust. Checksums-Sha1: 17552f0e956692a2c13a2bbe0392e6c683d14f59 1536 monotone_0.43-3.dsc 5b675f6d8bcb8db89de97e3ec6d423c1cf9d68ba 29193 monotone_0.43-3.diff.gz 51c7d0383304e126b21e2bfaaa96854ba4b4ac1c 9518 monotone-server_0.43-3_all.deb 441af110bc0932d9509d4df9eee8221e1433ae58 2325772 monotone-doc_0.43-3_all.deb ba188e025690eea955985f26dc38feb2f636 1866060 monotone_0.43-3_amd64.deb Checksums-Sha256: 2b6d61af8c8d6cdd869d0b194383c7f9767a65bff6d32881eb1a0aa792de 1536 monotone_0.43-3.dsc 39fd180b89a4a83dfca59adfaa862bcc1b8693ec907f7ff40eb015be53ffbecd 29193 monotone_0.43-3.diff.gz 648e7c6e2dd87a753683774ecf40796f98a77cc5ab6154863d8d6c8598c1f71d 9518 monotone-server_0.43-3_all.deb 235875c8646a09d3801af982abac956b3492de702fc0f3df7a415e6afc84c43e 2325772 monotone-doc_0.43-3_all.deb 637367f17e663cfb0e1c179fa29051e91c0065564de351d88158002c2caecaea 1866060 monotone_0.43-3_amd64.deb Files: c36b7aefff95c3f9d2c47837f570ebe1 1536 vcs optional monotone_0.43-3.dsc 864f09c5c18c0503f50b46cf252857fd 29193 vcs optional monotone_0.43-3.diff.gz 6c6994dc06c47e2395721ac7479e3694 9518 vcs optional monotone-server_0.43-3_all.deb 0ca58d4f0fb05d3a0975a059da009e00 2325772 doc optional monotone-doc_0.43-3_all.deb 3887981df2df273896f15aa7907d4e93 1866060 vcs optional monotone_0.43-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJ5MTTx9kwJZ3/qtQRAlwyAJ9azKyCQp7TzaHa6bbRCa6J2A4b3QCfTNdk NARWoQ6eMhZB1ZD71QaBMBw= =zY0J -END PGP SIGNATURE- Accepted: monotone-doc_0.43-3_all.deb to pool/main/m/monotone/monotone-doc_0.43-3_all.deb monotone-server_0.43-3_all.deb to pool/main/m/monotone/monotone-server_0.43-3_all.deb monotone_0.43-3.diff.gz to pool/main/m/monotone/monotone_0.43-3.diff.gz monotone_0.43-3.dsc to pool/main/m/monotone/monotone_0.43-3.dsc monotone_0.43-3_amd64.deb to pool/main/m/monotone/monotone_0.43-3_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted monotone 0.43-2 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 06 Apr 2009 17:00:59 -0700 Source: monotone Binary: monotone monotone-server monotone-doc Architecture: source all amd64 Version: 0.43-2 Distribution: unstable Urgency: low Maintainer: Debian Maintainers for Monotone monotone-deb...@nongnu.org Changed-By: Zack Weinberg za...@panix.com Description: monotone - A distributed version (revision) control system monotone-doc - A distributed version (revision) control system - documentation monotone-server - A distributed version (revision) control system - server scripts Changes: monotone (0.43-2) unstable; urgency=low . * Using quilt for patches to upstream code. * Backport upstream fix for unreliable test spawn_redirected_hook_helper; should fix FTBFS on powerpc and mips. * Temporarily introduce a mode where the fatal signal handler invokes gdb to print a stack trace, and activate it in the testsuite. This will hopefully reveal the cause of the alpha and sparc FTBFSes. Temporarily add build-dep on gdb for this. Checksums-Sha1: cbed546045972ed0477271e377676975ab9bcffc 1522 monotone_0.43-2.dsc d21cb8baed2067c401a658109996d7637246ab1d 29396 monotone_0.43-2.diff.gz cda938857a9ab3413af8b562788e615a906ed594 9514 monotone-server_0.43-2_all.deb aac1133b32de6aca43dd7594a7bda9ec36dab7b3 2325770 monotone-doc_0.43-2_all.deb 4d52099b6efc277496a6e24fb9d8a29f48d06b90 1866178 monotone_0.43-2_amd64.deb Checksums-Sha256: ce3fcfc8442e33867c643962773a6f9c3630a1a9efe299afca59d20fc021 1522 monotone_0.43-2.dsc 2628dd417d538c8398081dbf751a21273c4c24b1703deec02626656cfd9f3d4e 29396 monotone_0.43-2.diff.gz 28d94cdc63b7ae849e0e907c7206abdd153d20174d9e199ab111306760e32ab4 9514 monotone-server_0.43-2_all.deb 2681b8a2386359787519e7e2350f9f3c21ee9089897b9957d36e531bc9ae5947 2325770 monotone-doc_0.43-2_all.deb ea889798a72b3350c663bda3d7d611c92343b2725231d284f89a56b1a0ab7516 1866178 monotone_0.43-2_amd64.deb Files: d7a324acf44f3de21808c3a36a051aba 1522 vcs optional monotone_0.43-2.dsc 10b04083f3c82344fe0e630c0b3649ca 29396 vcs optional monotone_0.43-2.diff.gz a6fe7a265720cf1e50b176cae9434878 9514 vcs optional monotone-server_0.43-2_all.deb 2f9689f3fbb70c07d6bf8633d6a06f30 2325770 doc optional monotone-doc_0.43-2_all.deb 129ccbb6c632fefd8c867e403a8eb13a 1866178 vcs optional monotone_0.43-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJ3mlXx9kwJZ3/qtQRAm+LAJ4wvO/H1oVeRwyCx9EtYzMdi23cDwCeJ86X +lzFfy/o0Tk7TWh9tk+VAWE= =DZS2 -END PGP SIGNATURE- Accepted: monotone-doc_0.43-2_all.deb to pool/main/m/monotone/monotone-doc_0.43-2_all.deb monotone-server_0.43-2_all.deb to pool/main/m/monotone/monotone-server_0.43-2_all.deb monotone_0.43-2.diff.gz to pool/main/m/monotone/monotone_0.43-2.diff.gz monotone_0.43-2.dsc to pool/main/m/monotone/monotone_0.43-2.dsc monotone_0.43-2_amd64.deb to pool/main/m/monotone/monotone_0.43-2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted monotone 0.43-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Mon, 23 Mar 2009 13:08:44 -0700
Source: monotone
Binary: monotone monotone-server monotone-doc
Architecture: source all amd64
Version: 0.43-1
Distribution: unstable
Urgency: low
Maintainer: Debian Maintainers for Monotone monotone-deb...@nongnu.org
Changed-By: Zack Weinberg za...@panix.com
Description:
monotone - A distributed version (revision) control system
monotone-doc - A distributed version (revision) control system - documentation
monotone-server - A distributed version (revision) control system - server
scripts
Closes: 318509 320565 512035 512996 520808
Changes:
monotone (0.43-1) unstable; urgency=low
.
[ Zack Weinberg ]
.
* New upstream version (closes: #512035).
- Upstream no longer bundles any dependent libraries (closes: #318509).
- Options are now supported in $EDITOR (closes: #320565)
- Many bugs have been fixed since the last Debian package, and several
important new features added. Users are strongly encouraged to read
the upstream NEWS file, especially if they run netsync servers.
.
* po/es.po: New Spanish debconf template translation, thanks to
Fernando González de Requena (closes: #512996).
* debian/control: Add library dependencies. Allow use of boost1.35-dev
or boost1.37-dev as alternatives to plain boost-dev. Add ${misc:Depends}
to monotone and monotone-doc Depends: lines.
* Include a manpage for mtnopt.
* Fix two bad linebreaks in mtn.1 (Closes: #520808).
* Add missing 'set -e' to monotone-doc.postinst.
* Tweak handling of config.sub/config.guess for build reproducibility.
.
* debhelper compat level 7
* section changes for squeeze
.
[ Richard Levitte ]
.
* Policy 3.8.1:
- Create /var/run/monotone in the monotone-server init script instead
of shipping it in the package, to accommodate systems where /var/run
is erased on boot.
Checksums-Sha1:
5c95b20dd352412252733ad897ce44eaeed3ba69 1510 monotone_0.43-1.dsc
e945ecd64991bbe29c45e08ec78636f2900a0880 4612840 monotone_0.43.orig.tar.gz
169e961f1668fb9460150fd0d28575b1d0e9fc24 26899 monotone_0.43-1.diff.gz
314cc31549eb98981dc224887eaf1191f457c3dc 9524 monotone-server_0.43-1_all.deb
7090c661d9f4e8796edf6cbf4a372e409687bdaf 2325762 monotone-doc_0.43-1_all.deb
b534d41ddd9c9fd86e6e305d6fee6e0efcd6b13f 1865488 monotone_0.43-1_amd64.deb
Checksums-Sha256:
e2cad05fcdfdd9a871bbd399721ff1ac745fb868dcdf65dd9c28068067eb6b74 1510
monotone_0.43-1.dsc
a759095f0daaa4607a234959a3d0001109420ef5d5b348b0ec1961bba6fa310a 4612840
monotone_0.43.orig.tar.gz
5dd4a583892e7fa0c36d3badbc36bdf4394e5fc4a9dc48a8eded9fbc3898a464 26899
monotone_0.43-1.diff.gz
8e8eb4aa8715e72c85eababb94c0084b0a6f6706fcb8e86c30590979ad9a1afd 9524
monotone-server_0.43-1_all.deb
121670862724fa783e64497561c3ec1fcaf59538cdf7de239ff8e44cfdbac142 2325762
monotone-doc_0.43-1_all.deb
ae6a7592aee23020eab08db5a63654221b9d1cb78e223b0a33408eba7d4fc14d 1865488
monotone_0.43-1_amd64.deb
Files:
f62db85090a39c51163a7df16fa81386 1510 vcs optional monotone_0.43-1.dsc
b9c4971a2aaa7a2be453aa18cb350176 4612840 vcs optional monotone_0.43.orig.tar.gz
ce9342174e97fec43e0060e467e753af 26899 vcs optional monotone_0.43-1.diff.gz
e82cfcf5a4640a9709fae83a46539f27 9524 vcs optional
monotone-server_0.43-1_all.deb
e587b5780a1fca3f77a58002cca2dfdc 2325762 doc optional
monotone-doc_0.43-1_all.deb
ff520742d3d09394911e8baa45a596eb 1865488 vcs optional monotone_0.43-1_amd64.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQFJ1z7Tx9kwJZ3/qtQRAhRiAJ0QmmBpkNYauVQVJSyrEL2zoQqfhACgoxvE
CsSEIY2K5Kz9luX7C0Nm1K0=
=2Vlk
-END PGP SIGNATURE-
Accepted:
monotone-doc_0.43-1_all.deb
to pool/main/m/monotone/monotone-doc_0.43-1_all.deb
monotone-server_0.43-1_all.deb
to pool/main/m/monotone/monotone-server_0.43-1_all.deb
monotone_0.43-1.diff.gz
to pool/main/m/monotone/monotone_0.43-1.diff.gz
monotone_0.43-1.dsc
to pool/main/m/monotone/monotone_0.43-1.dsc
monotone_0.43-1_amd64.deb
to pool/main/m/monotone/monotone_0.43-1_amd64.deb
monotone_0.43.orig.tar.gz
to pool/main/m/monotone/monotone_0.43.orig.tar.gz
--
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted monotone 0.40-6 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 24 Jul 2008 15:00:35 -0700 Source: monotone Binary: monotone monotone-server monotone-doc Architecture: source all amd64 Version: 0.40-6 Distribution: unstable Urgency: low Maintainer: Debian Maintainers for Monotone [EMAIL PROTECTED] Changed-By: Zack Weinberg [EMAIL PROTECTED] Description: monotone - A distributed version (revision) control system monotone-doc - A distributed version (revision) control system - documentation monotone-server - A distributed version (revision) control system - server scripts Changes: monotone (0.40-6) unstable; urgency=low . * dump-test-logs.sh: always exit unsuccessfully, to prevent masking an unsuccessful test run. * syntax_errors_in_.mtn-ignore test: eliminate fragile dependency on details of error messages / order of output. Checksums-Sha1: 9661be0ca7ce9f1b53410afd06e82fea1af88ab9 1435 monotone_0.40-6.dsc 82eff0072ac680e751d52de05f4ac122db503503 12181 monotone_0.40-6.diff.gz fccfcdb97f94172df9e0c4b17530efef68c4546d 9246 monotone-server_0.40-6_all.deb af9a6e009a60907d8b739c308bd1431b9cecceb5 2259488 monotone-doc_0.40-6_all.deb deaec5a5b98415559a7c09462c671dd2d7c54ef4 2421938 monotone_0.40-6_amd64.deb Checksums-Sha256: d35601162c09945ba972426219e74a31416a3227851025bad2802d354a1fb5c1 1435 monotone_0.40-6.dsc 16aa74e08ff7a186f6ddcdaa81982f5a24e17a3c59b2d535ae870ce9b04aa663 12181 monotone_0.40-6.diff.gz b96a955e3534601e338a74e83460a93ebf01387a3a84e4c4ad1c331d2a300b79 9246 monotone-server_0.40-6_all.deb 9cf69b5f62372288035a471ca70ac1ff46cd8f7a816b914966925df84be1fcf4 2259488 monotone-doc_0.40-6_all.deb e155bc80215bd787f6b7f94558ce61b50d575209bb808520602cf3f18b4f442a 2421938 monotone_0.40-6_amd64.deb Files: fd188d8ec1443f6c22e31c13928abda3 1435 devel optional monotone_0.40-6.dsc 51c33f05383856b8d19f631606c25aa1 12181 devel optional monotone_0.40-6.diff.gz d469551878df3deb25b23e0f7d379313 9246 devel optional monotone-server_0.40-6_all.deb e8f0798efb23ea79e7496a1b6f91a1a4 2259488 doc optional monotone-doc_0.40-6_all.deb e25d2e7fdec19ae80de48aab74368c49 2421938 devel optional monotone_0.40-6_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFIihLGx9kwJZ3/qtQRAhS9AJ9ASBYbkXJhIdySulSEJHBLSnP1lwCfUWCV 1RGZrdQhm7wmKObTnVYdPYA= =21yC -END PGP SIGNATURE- Accepted: monotone-doc_0.40-6_all.deb to pool/main/m/monotone/monotone-doc_0.40-6_all.deb monotone-server_0.40-6_all.deb to pool/main/m/monotone/monotone-server_0.40-6_all.deb monotone_0.40-6.diff.gz to pool/main/m/monotone/monotone_0.40-6.diff.gz monotone_0.40-6.dsc to pool/main/m/monotone/monotone_0.40-6.dsc monotone_0.40-6_amd64.deb to pool/main/m/monotone/monotone_0.40-6_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted monotone 0.40-5 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 08 Jun 2008 18:55:02 -0400 Source: monotone Binary: monotone monotone-server monotone-doc Architecture: source all amd64 Version: 0.40-5 Distribution: unstable Urgency: low Maintainer: Debian Maintainers for Monotone [EMAIL PROTECTED] Changed-By: Zack Weinberg [EMAIL PROTECTED] Description: monotone - A distributed version (revision) control system monotone-doc - A distributed version (revision) control system - documentation monotone-server - A distributed version (revision) control system - server scripts Closes: 476155 Changes: monotone (0.40-5) unstable; urgency=low . * Backport from upstream development tree: - fix for broken ssh_agent support - testsuite hardening against unusable network, and DISABLE_NETWORK_TESTS environment variable support - improved contrib/dump-test-logs.sh * debian/rules: Set DISABLE_NETWORK_TESTS when running the testsuite; this may cure the mips buildd problems for real. Also, implement support for DEB_BUILD_OPTS=parallel rather than probing available CPUs. * monotone binary package Suggests: monotone-doc and monotone-server (Closes: #476155) Checksums-Sha1: 66cc188e6bc2dc1fe8050cdfb686ad69df3489eb 1435 monotone_0.40-5.dsc 040796532dd68fe4dc70412fe0f85245e07ef571 12007 monotone_0.40-5.diff.gz 72754df29cab06891aa27a1bf52a1c655032900b 9244 monotone-server_0.40-5_all.deb 2e59e1a83abf1635bbc95f0c3440888197c110bf 2259470 monotone-doc_0.40-5_all.deb f02f9b7c82ab08359339baf34429d21abf70a8a5 2421798 monotone_0.40-5_amd64.deb Checksums-Sha256: 0969b5304f31483a6e6247a3702d0d70f7243c59365aa34e7bad4319ec3e6540 1435 monotone_0.40-5.dsc c0fee8aaef4d4791c2eea8b97c6e842c09a422a154ec23a5446ad2dd29e12e14 12007 monotone_0.40-5.diff.gz 31de3896b8a7642e3a292a4217cb5b37dd09b5246d92d065471a99f3fe7753e9 9244 monotone-server_0.40-5_all.deb c6c57ee27f14e56dd994d8e6f1a47ccd8a52e167843b5ed0a5bf53ccf0861a95 2259470 monotone-doc_0.40-5_all.deb 6575085f102552a5798c670830ecddef9139db2eb6f4afa79e61b17789dd1155 2421798 monotone_0.40-5_amd64.deb Files: 0c06cbce83abb301ba5ffb04a3a498e5 1435 devel optional monotone_0.40-5.dsc 3034906baded187e319b8b6923843b68 12007 devel optional monotone_0.40-5.diff.gz 3f475dec93e8929f2b6cf466052b180b 9244 devel optional monotone-server_0.40-5_all.deb 000f7bdc5e950945d66b58184bfa7d4d 2259470 doc optional monotone-doc_0.40-5_all.deb 4bbd2bb6cdd8138bb89d0f4b94a93cd9 2421798 devel optional monotone_0.40-5_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFIeTFcx9kwJZ3/qtQRAtMYAJ426mPNuPd2ukmKzmvXRO/SejioDACdExrx MUEVBVt6svLwLmCH6exxl2o= =Czjy -END PGP SIGNATURE- Accepted: monotone-doc_0.40-5_all.deb to pool/main/m/monotone/monotone-doc_0.40-5_all.deb monotone-server_0.40-5_all.deb to pool/main/m/monotone/monotone-server_0.40-5_all.deb monotone_0.40-5.diff.gz to pool/main/m/monotone/monotone_0.40-5.diff.gz monotone_0.40-5.dsc to pool/main/m/monotone/monotone_0.40-5.dsc monotone_0.40-5_amd64.deb to pool/main/m/monotone/monotone_0.40-5_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted monotone 0.40-4 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 28 May 2008 23:48:47 -0400 Source: monotone Binary: monotone monotone-server monotone-doc Architecture: source all amd64 Version: 0.40-4 Distribution: unstable Urgency: low Maintainer: Debian Maintainers for Monotone [EMAIL PROTECTED] Changed-By: Zack Weinberg [EMAIL PROTECTED] Description: monotone - A distributed version (revision) control system monotone-doc - A distributed version (revision) control system - documentation monotone-server - A distributed version (revision) control system - server scripts Closes: 483018 483090 483155 Changes: monotone (0.40-4) unstable; urgency=low . * Corrected .diff.gz including regeneration of Makefile.in. (Closes: #483090, #483018) * monotone-server.postinst, monotone-doc.postinst: help out dpkg with directory-symlink conversion. (Closes: #483155) * Install ucf baselines in /usr/share/monotone instead of getting them from /usr/share/doc/monotone/..., per Policy 12.3. Checksums-Sha1: 1e01ee3c1f3e94590ee4562fe55ef5acdf27d289 1432 monotone_0.40-4.dsc 2f6ac5fa814ff08eb83bbfd52ee10f8b3d85a8fa 7993 monotone_0.40-4.diff.gz c8bc27deb19b2d00170086eadd845a486b4df540 9254 monotone-server_0.40-4_all.deb 0b6a5ed591165fd05ba6bee37e66c645de0ec4bd 2259484 monotone-doc_0.40-4_all.deb 19a715f653934ec957b55c042b14fbd37bb71b48 2586044 monotone_0.40-4_amd64.deb Checksums-Sha256: 08bae05be47c82e633e1a6dd856f96368f9ebaeff7a11cbce5a8ee5fc5de9bf7 1432 monotone_0.40-4.dsc 77eb219bd76481a9d912d0884d604fac4feeac2f076c0e3b5a24a0cdcd12a462 7993 monotone_0.40-4.diff.gz eb02dceada569949c131da59dc8fa944f858b0737ed70d4b948a0db43336f1bc 9254 monotone-server_0.40-4_all.deb a2af46e7e6e83e8acf4e646b4d09df54367cb9580fd2c6a9cbd8d1ca1a163b39 2259484 monotone-doc_0.40-4_all.deb 0e087b09408eda76702c22c88e79ba4abf42f4f990b07f4e2d4105b813610397 2586044 monotone_0.40-4_amd64.deb Files: 73ea8613ee60ac8f915da58586f2ceb0 1432 devel optional monotone_0.40-4.dsc 1ad7a6d69a6e5e05563b7099cc1dde19 7993 devel optional monotone_0.40-4.diff.gz 7b2d56439a649ea2b1e31394d02c55b5 9254 devel optional monotone-server_0.40-4_all.deb 284fa8bce75ecfaa19674edc319fc063 2259484 doc optional monotone-doc_0.40-4_all.deb 2c5454ce32c928c57b460474ec6e860e 2586044 devel optional monotone_0.40-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIQUEOx9kwJZ3/qtQRAkF2AJ9uYjz5/g4VR/K1cHg657nJ0DbEzgCfRW+u WUvGvkrscWihvAjZFK4lKdI= =YnT9 -END PGP SIGNATURE- Accepted: monotone-doc_0.40-4_all.deb to pool/main/m/monotone/monotone-doc_0.40-4_all.deb monotone-server_0.40-4_all.deb to pool/main/m/monotone/monotone-server_0.40-4_all.deb monotone_0.40-4.diff.gz to pool/main/m/monotone/monotone_0.40-4.diff.gz monotone_0.40-4.dsc to pool/main/m/monotone/monotone_0.40-4.dsc monotone_0.40-4_amd64.deb to pool/main/m/monotone/monotone_0.40-4_amd64.deb -- 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]
Accepted monotone 0.37-4 (source all amd64 powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 26 Nov 2007 17:01:18 -0800 Source: monotone Binary: monotone monotone-doc monotone-server Architecture: all amd64 powerpc source Version: 0.37-4 Distribution: unstable Urgency: low Maintainer: Debian Maintainers for Monotone [EMAIL PROTECTED] Changed-By: Zack Weinberg [EMAIL PROTECTED] Description: monotone - A distributed version (revision) control system Changes: monotone (0.37-4) unstable; urgency=low . * debian/rules: Turn compiler optimization back on by default. Doh! Hopefully this shrinks hppa builds to the point where we don't need -mlong-calls. Since the accidental use of -O0 in 0.37-[23] seems to have been responsible for the unexpected successful builds on Alpha, try -O1 on that architecture. Implement DEB_BUILD_OPTIONS=noopt while we're at it. * Backport upstream's relicensing of the manual under the GPL, since we (and upstream) may technically have been violating the GFDL by not including its text in the manual proper. Source and binary packages now contain no content not distributable under GPLv2 or a more permissive license. * debian/copyright: Point specifically to GPLv2 (upstream specifies GPLv2-or-later, let's not be exercising the 'or later' part unless and until they do). Fix typo. Files: 1f3de1d696dfe177008b3e67bf04151d 18286 devel optional monotone-server_0.37-4_all.deb 20751b312c95143bd75dada51f7bc54b 21503 devel optional monotone_0.37-4.diff.gz 93df06020850c41abbcaf80ac5ff3332 927 devel optional monotone_0.37-4.dsc 44683db14c6c025fb96b400f8785af5f 2132536 doc optional monotone-doc_0.37-4_all.deb 53342b3646547b9f61e36f6e3d6e0284 2647702 devel optional monotone_0.37-4_powerpc.deb 58128f7625da592285a08bbc765dda42 2562644 devel optional monotone_0.37-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTq/Vx9kwJZ3/qtQRApldAJ4rFOGod1ZALq9t/dnnyM/xJl78xgCgtJtM Nh2aqlAPucf0tIl0L2objKk= =J0FI -END PGP SIGNATURE- Accepted: monotone-doc_0.37-4_all.deb to pool/main/m/monotone/monotone-doc_0.37-4_all.deb monotone-server_0.37-4_all.deb to pool/main/m/monotone/monotone-server_0.37-4_all.deb monotone_0.37-4.diff.gz to pool/main/m/monotone/monotone_0.37-4.diff.gz monotone_0.37-4.dsc to pool/main/m/monotone/monotone_0.37-4.dsc monotone_0.37-4_amd64.deb to pool/main/m/monotone/monotone_0.37-4_amd64.deb monotone_0.37-4_powerpc.deb to pool/main/m/monotone/monotone_0.37-4_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted monotone 0.37-3 (source all amd64 powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 12 Nov 2007 07:16:05 + Source: monotone Binary: monotone monotone-doc monotone-server Architecture: all amd64 powerpc source Version: 0.37-3 Distribution: unstable Urgency: low Maintainer: Debian Maintainers for Monotone [EMAIL PROTECTED] Changed-By: Zack Weinberg [EMAIL PROTECTED] Description: monotone - A distributed version (revision) control system monotone-doc - A distributed version (revision) control system - documentation monotone-server - A distributed version (revision) control system - server scripts Changes: monotone (0.37-3) unstable; urgency=low . * debian/rules: Cross-compilation and lintian fixes. * Clean up usage of - in debian/mtn.1. Files: 389e458dd65cd37ae9ef20cb8c6b161d 10849 devel optional monotone_0.37-3.diff.gz 5c5ddb7b5389f926ed7112a78fdba3fd 2354340 devel optional monotone_0.37-3_powerpc.deb 7f9815c90a0812185373c1d78c00bf98 17832 devel optional monotone-server_0.37-3_all.deb c873189b4c233933acfb499eb2ac44ea 2442600 devel optional monotone_0.37-3_amd64.deb 6ad106f589d8cd69b36cece0927ad692 927 devel optional monotone_0.37-3.dsc ef294d51e901411414d787a0f7441ed9 2130886 doc optional monotone-doc_0.37-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHQDd1x9kwJZ3/qtQRAv7uAJ41eH+by2o80wjylEq189VbdchVjwCgpXrX ZYj4R9uC8fZmuF0n5cxYyAU= =vVVL -END PGP SIGNATURE- Accepted: monotone-doc_0.37-3_all.deb to pool/main/m/monotone/monotone-doc_0.37-3_all.deb monotone-server_0.37-3_all.deb to pool/main/m/monotone/monotone-server_0.37-3_all.deb monotone_0.37-3.diff.gz to pool/main/m/monotone/monotone_0.37-3.diff.gz monotone_0.37-3.dsc to pool/main/m/monotone/monotone_0.37-3.dsc monotone_0.37-3_amd64.deb to pool/main/m/monotone/monotone_0.37-3_amd64.deb monotone_0.37-3_powerpc.deb to pool/main/m/monotone/monotone_0.37-3_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted monotone 0.37-2 (source all amd64 powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 04 Nov 2007 11:53:17 -0800 Source: monotone Binary: monotone monotone-doc monotone-server Architecture: all amd64 powerpc source Version: 0.37-2 Distribution: unstable Urgency: low Maintainer: Debian Maintainers for Monotone [EMAIL PROTECTED] Changed-By: Zack Weinberg [EMAIL PROTECTED] Description: monotone - A distributed version (revision) control system monotone-doc - A distributed version (revision) control system - documentation monotone-server - A distributed version (revision) control system - server scripts Closes: 437978 Changes: monotone (0.37-2) unstable; urgency=low . * Do not error out if $HOME exists but is inaccessible. Should fix mips(el) FTBFS. * Fix bashisms in monotone-server scripts. Thanks to Glen Ditchfield for finding this problem and providing part of the fix. * In monotone-server.postinst, set permissions and ownership of just-created directories whether or not we created the monotone user. Thanks to Michael Berg for doing almost all the work on this bug. (Closes: #437978) * Reincorporate debian/changelog entries for versions 0.27-1 and 0.27-1.1. These versions were once uploaded to Debian but their entries got lost from the official changelog somehow. * Switch from cdbs to a handwritten rules file based on debhelper examples. Restore Build-Depends/Build-Depends-Indep distinction and monkey with the rules so that dpkg-buildpackage -B doesn't build the documentation. This gets us out from under the present nonavailability of some of the B-D-Is on some of the buildds. * Info files moved to monotone-doc. Other cleanups to that package. * Do not install the boilerplate ABOUT-NLS file in any of the packages' documentation directories. * Improve short descriptions. Files: 4525e7d119d3b74d40987ae3bd882c88 7117 devel optional monotone_0.37-2.diff.gz 882593c45337c96033abc67f20294896 926 devel optional monotone_0.37-2.dsc 26d9b41728da0702508619eedad1a6cf 2442526 devel optional monotone_0.37-2_amd64.deb cda19114a41d82cde1fa106c320943f6 2354280 devel optional monotone_0.37-2_powerpc.deb 602a8a173e477e021a7e39ee6a9b6183 2131202 doc optional monotone-doc_0.37-2_all.deb 0ca002e1d06184d694a9bfcb033f8535 17792 devel optional monotone-server_0.37-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHM6Upx9kwJZ3/qtQRAl5fAJ9lsp8IzATVYxCHad5+upfkh059/gCfem2D gJ9lWjfNBYiiGcn3poeHBKc= =P2gx -END PGP SIGNATURE- Accepted: monotone-doc_0.37-2_all.deb to pool/main/m/monotone/monotone-doc_0.37-2_all.deb monotone-server_0.37-2_all.deb to pool/main/m/monotone/monotone-server_0.37-2_all.deb monotone_0.37-2.diff.gz to pool/main/m/monotone/monotone_0.37-2.diff.gz monotone_0.37-2.dsc to pool/main/m/monotone/monotone_0.37-2.dsc monotone_0.37-2_amd64.deb to pool/main/m/monotone/monotone_0.37-2_amd64.deb monotone_0.37-2_powerpc.deb to pool/main/m/monotone/monotone_0.37-2_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted monotone 0.36-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Aug 2007 15:06:51 -0700 Source: monotone Binary: monotone monotone-doc monotone-server Architecture: source amd64 all Version: 0.36-1 Distribution: unstable Urgency: low Maintainer: Debian Maintainers for Monotone [EMAIL PROTECTED] Changed-By: Zack Weinberg [EMAIL PROTECTED] Description: monotone - A distributed version (revision) control system monotone-doc - A distributed version (revision) control system monotone-server - A distributed version (revision) control system Closes: 434604 Changes: monotone (0.36-1) unstable; urgency=low . [ Richard Levitte ] * New upstream release. . [ Zack Weinberg ] * Bump debhelper build-dep to (= 4.2.0) per cdbs docs. * Run testsuite during build. * Drop libboost-filesystem-dev build-dependency. * monotone-server.postinst, monotone-server.postrm: Do not assume full pathnames of ucf or adduser. Use ucfr as well as ucf. At purge time: - do not assume ucf, adduser, or debconf are available (closes: #434604). - if not asked to manage the database, do not delete it. - if deleting the database and there is a hot journal, delete that too. - delete editor backups of ucf-managed conffiles. - expunge the auto-generated key's passphrase from /etc/monotone/passphrases and if that leaves the file empty, delete it. - do not delete the monotone user or group if leaving /var/lib/monotone on the filesystem. * Bump boost build-deps to (= 1.34.1-2) for packaging changes that make the configure script find the single-threaded version of libboost-regex. * Re-enable -DBOOST_SP_DISABLE_THREADS; the above should render it unnecessary. This eliminates the sole divergence from upstream. * Correct invalid assumption in tests/invalid_--root_settings that the build directory is not a subdirectory of /tmp. * Build-depend on patch, for the sake of the testsuite. Files: 204b34c9c7ba27ebfeabea376426d961 955 devel optional monotone_0.36-1.dsc 932aae7289a83ded055eac1e99fcde38 4871586 devel optional monotone_0.36.orig.tar.gz 199822ed24a1065ff78a762999d296fb 966 devel optional monotone_0.36-1.diff.gz 2efd43cf5f1b277b27b52be273d4247d 53550 devel optional monotone-server_0.36-1_all.deb c289b1598c6dbe5039a56d1b69163aed 3025174 doc optional monotone-doc_0.36-1_all.deb 474bc99eed7dbae3d01dd93ac2dbf926 2796372 devel optional monotone_0.36-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGzzg1x9kwJZ3/qtQRAkZ+AJ9DztxEBCpHiVzbGBdX9l/TQYMEBQCgqGZ/ nM3mrfDC5Q41wAbFKJs+m9U= =upPe -END PGP SIGNATURE- Accepted: monotone-doc_0.36-1_all.deb to pool/main/m/monotone/monotone-doc_0.36-1_all.deb monotone-server_0.36-1_all.deb to pool/main/m/monotone/monotone-server_0.36-1_all.deb monotone_0.36-1.diff.gz to pool/main/m/monotone/monotone_0.36-1.diff.gz monotone_0.36-1.dsc to pool/main/m/monotone/monotone_0.36-1.dsc monotone_0.36-1_amd64.deb to pool/main/m/monotone/monotone_0.36-1_amd64.deb monotone_0.36.orig.tar.gz to pool/main/m/monotone/monotone_0.36.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted monotone 0.35-2 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 13 Jul 2007 08:39:58 -0700 Source: monotone Binary: monotone monotone-doc monotone-server Architecture: source amd64 all Version: 0.35-2 Distribution: unstable Urgency: low Maintainer: Debian Maintainers for Monotone [EMAIL PROTECTED] Changed-By: Zack Weinberg [EMAIL PROTECTED] Description: monotone - A distributed version (revision) control system monotone-doc - A distributed version (revision) control system monotone-server - A distributed version (revision) control system Closes: 432657 Changes: monotone (0.35-2) unstable; urgency=low . * Collapse Build-Depends-Indep into Build-Depends to work around a buildd bug. (Closes: #432657) * Correct Ludovic Brenta's address in Uploaders. * Enable parallel make on multiprocessors. . [ Ludovic Brenta ] * monotone-server.postrm: do not blindly erase /var/lib/monotone on purge; instead, delete only the default database (created in the postinst), and only delete the directory if empty. Files: 4a8520d08c246451aba548895447d794 948 devel optional monotone_0.35-2.dsc fafeb89135b17b7b9fc190ea01a38bf3 8639 devel optional monotone_0.35-2.diff.gz 8f017178f617f50fbfa10635b4d7693d 50942 devel optional monotone-server_0.35-2_all.deb bb7e14297dfe27a6605def1255cc4386 3019560 doc optional monotone-doc_0.35-2_all.deb 2d29f8a0196c3e4f62564629c3b9aaa0 2761724 devel optional monotone_0.35-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGl9kJx9kwJZ3/qtQRAgqoAKCaAXutkEz08ebvEa5HkIF/rvXqlACeL/P/ D+3rMN/tkE4HaCItDzTGTmk= =HVLO -END PGP SIGNATURE- Accepted: monotone-doc_0.35-2_all.deb to pool/main/m/monotone/monotone-doc_0.35-2_all.deb monotone-server_0.35-2_all.deb to pool/main/m/monotone/monotone-server_0.35-2_all.deb monotone_0.35-2.diff.gz to pool/main/m/monotone/monotone_0.35-2.diff.gz monotone_0.35-2.dsc to pool/main/m/monotone/monotone_0.35-2.dsc monotone_0.35-2_amd64.deb to pool/main/m/monotone/monotone_0.35-2_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted monotone 0.35-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 10 Jul 2007 08:23:00 -0700 Source: monotone Binary: monotone monotone-doc monotone-server Architecture: source amd64 all Version: 0.35-1 Distribution: unstable Urgency: low Maintainer: Debian Maintainers for Monotone [EMAIL PROTECTED] Changed-By: Zack Weinberg [EMAIL PROTECTED] Description: monotone - A distributed version (revision) control system monotone-doc - A distributed version (revision) control system monotone-server - A distributed version (revision) control system Closes: 415496 418213 422936 425907 427687 427845 429832 431797 Changes: monotone (0.35-1) unstable; urgency=low . [ Zack Weinberg ] * New upstream release. (Closes: #418213, #427845, #429832) * Backport post-0.35 upstream fixes for boost 1.34. (Closes: #425907) * Rebuild against new boost. (Closes: #427687) * Drop tetex-bin as build-dep alternative. Add build-deps on all of texinfo's suggested packages, to ensure docs build. (Closes: #422936) * New Dutch template translation (Closes: #415496). * Add build-dep on po-debconf to ensure correct construction of monotone-server's templates file. * Add a somewhat out-of-date, but better than nothing, manpage. * Simplify the rules file a bit. . [ Richard Levitte ] * Package adopted by a team, presently Richard Levitte and Zack Weinberg, with sponsorship by Ludovic Brenta. Thanks to Shaun for his work to date. (Closes: #431797) Files: 356a3d541483f8e3f961a89e9dcc1117 976 devel optional monotone_0.35-1.dsc 9b53046dda8ba7549fa5ce765e14fa65 4857094 devel optional monotone_0.35.orig.tar.gz 446d4919f97b5e31eec5e71235d65e2d 7898 devel optional monotone_0.35-1.diff.gz 46ae5fd4f6e834b5f855b2ab173049a7 50712 devel optional monotone-server_0.35-1_all.deb dac22367dff9108bad234188f575dcb8 3019378 doc optional monotone-doc_0.35-1_all.deb 5e64ca291b151714cf7e365cda5958d7 2761528 devel optional monotone_0.35-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGk/9Bx9kwJZ3/qtQRAh0gAJ4pKsqRwl4XJT1uaQ5NXew93UkuxACgn17K 27RiQXdbpnHeO6vC88VnBzw= =lstC -END PGP SIGNATURE- Accepted: monotone-doc_0.35-1_all.deb to pool/main/m/monotone/monotone-doc_0.35-1_all.deb monotone-server_0.35-1_all.deb to pool/main/m/monotone/monotone-server_0.35-1_all.deb monotone_0.35-1.diff.gz to pool/main/m/monotone/monotone_0.35-1.diff.gz monotone_0.35-1.dsc to pool/main/m/monotone/monotone_0.35-1.dsc monotone_0.35-1_amd64.deb to pool/main/m/monotone/monotone_0.35-1_amd64.deb monotone_0.35.orig.tar.gz to pool/main/m/monotone/monotone_0.35.orig.tar.gz -- 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: 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: 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 | CtrlKeyR: abort-display()\n | KeyF1: 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: 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
My god, that was awful. They still haven't fixed cpp -traditional, as far as I know. Grumble grumble grumble. Bug number? zw
Accepted zangband 1:2.7.1-0.1 (hppa source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 3 Sep 2002 11:51:58 -0700 Source: zangband Binary: zangband Architecture: source hppa Version: 1:2.7.1-0.1 Distribution: unstable Urgency: low Maintainer: Eric Leblanc [EMAIL PROTECTED] Changed-By: Zack Weinberg [EMAIL PROTECTED] Description: zangband - A single-player, text-based, roguelike game Closes: 54399 54424 78887 137814 141849 159039 Changes: zangband (1:2.7.1-0.1) unstable; urgency=low . * NMU * New upstream version. * More robust and cautious upgrade procedure which prevents old .raw files from being used with new versions (closes: #54399) - I can't test this. If you still experience crashes when entering shops, please file a new bug. * Create placeholder .raw files at package installation time, with safe permissions (closes: #54424) * Include X driver and tiles (closes: #78887) - I'm building just one binary. If you can't stand having xlibs installed just for this package, let me know. * Upstream corrected help for spin the wheel gambling (closes: #137814) * Added Roguelike,Dungeon menu hints (closes: #141849) * This version will start (closes: #159039) Files: 8d69ba87002192c85a28cc5c2b966a48 626 non-free/games optional zangband_2.7.1-0.1.dsc 4a01cb84fc4452910ce905ad62adef33 2267159 non-free/games optional zangband_2.7.1.orig.tar.gz 5499d9e7c485e7e38cfd445f5b135483 7445 non-free/games optional zangband_2.7.1-0.1.diff.gz ed45b0e88180e4d326a022ffe6851bf3 1510132 non-free/games optional zangband_2.7.1-0.1_hppa.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Debian! iD8DBQE9iQRj5m0u66uWM3ARAuFlAJ9/PpXy/S3NDqOcgwmLvjHaaaBr/wCdER+Z pp+BnT3tbiHRtLXrR7M1a3w= =EEbM -END PGP SIGNATURE- Accepted: zangband_2.7.1-0.1.diff.gz to pool/non-free/z/zangband/zangband_2.7.1-0.1.diff.gz zangband_2.7.1-0.1.dsc to pool/non-free/z/zangband/zangband_2.7.1-0.1.dsc zangband_2.7.1-0.1_hppa.deb to pool/non-free/z/zangband/zangband_2.7.1-0.1_hppa.deb zangband_2.7.1.orig.tar.gz to pool/non-free/z/zangband/zangband_2.7.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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
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 spacetabnewline 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 spacetabnewline 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 spacetabnewline 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#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: 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 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
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
