Re: Installer: 32 vs. 64 bit
> Or an user error. In either case, I don't get what a 32-bit _x86_ virtual > machine would be good for. Are you teaching some code archeology? Not at all. We're trying to make it compulsory for first year students to have a Unix installation on their personal machine. In practice, this means any of native Linux, native Mac OS, or virtualised Linux. (We've found Cygwin to be confusing, and we haven't looked at WSL.) Since we're trying to get this to scale across a few hundred eighteen-year olds (smart ones, thankfully), we're seeing all sorts of user errors. -- Juliusz
Re: Installer: 32 vs. 64 bit
> Filing a bug on src:virtualbox with severity 'wishlist' or 'normal' for this > issue to discuss it with the maintainer of the virtualbox package(s) seems a > logical thing to do. Unfortunately, we're speaking about running Debian under VirtualBox under Windows, so it would need to be something that happens in VirtualBox upstream.
Re: Installer: 32 vs. 64 bit
> When discussing virtual machines it would be helpful to mention which virtual > machine hypervisor is being used, because the resulting behavior can differ > depending on hypervisor. It was VirtualBox under Windows. The underlying issue was that VT-x was disabled in the BIOS, and hence VirtualBox didn't offer any 64-bit machines. The student tried her best to make it work, I don't think she can be blamed for failing. -- Juliusz
Re: Installer: 32 vs. 64 bit
>> I've been encouraging my students to install Debian on their personal >> machines, and we've found out that a lot of them get the wrong Debian >> installer: >> >> - some of them attempt to install an AMD64 version of Debian in >> a 32-bit-only virtual machine; > Why are they creating 32-bit virtual machines? Perhaps this is a bad > default in the VM manaager? Yes, it was a bad default in the laptop's BIOS (VT-something was disabled). HP's bug, obviously, but it would have made for a better experience if the Debian installer had complained in a comprehensible manner straight away. >> - others attempt to install an i386 version on 64-bit hardware. > This should work, in general. It won't work on a 64-bit system that > only supports EFI boot - and the installer won't be able to report > that, unless it includes a dummy 64-bit EFI program just to do that. It was a recent laptop, and the user had manually enabled BIOS boot. The installer hung with a black screen just after the initial menu. > We should not do in this in the second case, since it is supposed to > work. (But a warning might be reasonable.) Please. -- Juliusz
Re: Installer: 32 vs. 64 bit
> This is not what I get. > - 32bit debian on 64bit machine: this should be working fine > - 64bit debian on 32bit machine: I get the attached message > If it's not what they get, there is some bug and more investigation is > needed. I no longer have access to their machines, so I'm unfortunately unable to check. -- Juliusz
Installer: 32 vs. 64 bit
Hi, I've been encouraging my students to install Debian on their personal machines, and we've found out that a lot of them get the wrong Debian installer: - some of them attempt to install an AMD64 version of Debian in a 32-bit-only virtual machine; - others attempt to install an i386 version on 64-bit hardware. In both cases, the installer crashes with no useful error message (in the former case, it crashes just after installing grub, in the latter case, it crashes straight away). This is a bad user experience, since the students lose a lot of time trying to work out the issue on their own before they ask for an appointment, and end up with the impression that installing Debian "never works". Could somebody please speak with the installer people so they make sure that the installation fails with a friendly user message in both of the cases outlined above? Thanks, -- Juliusz Chroboczek
Re: bash exorcism experiment ('bug' 762923 763012)
- pipefail, - local variables, - array variables. If dash had those features Please don't -- some of us appreciate the fact that /bin/sh is a reasonably minimal shell. Both ksh93 and pdksh/mksh have all three of those, if memory serves. -- Juliusz -- 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/87lhp3q08c.wl-...@pps.univ-paris-diderot.fr
Re: binary data file and endianness and multiarch
Standardising on big-endian is a good idea [...] Except that the endianness war has been won by little-endian That's not what my mail was about. My point is that the issue with the software should be resolved upstream, rather than implementing yet another dodgy hack in dpkg. Which particular encoding upstream chooses should be of no import to Debian, as long as it is arch-independent. Should you have strong feelings one way or the other, please feel free to discuss it with upstream on the appropriate forum. -- Juliusz -- 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/871tqwagog.wl-...@pps.univ-paris-diderot.fr
Re: binary data file and endianness and multiarch
That's not what my mail was about. My point is that the issue with the software should be resolved upstream, in my case, it cannot be resolved upstream, Yes, abandoned software is a problem, unfortunately quite common in the scientific community. (Understandably so, since researchers get funding and kudos for developing new stuff, not for maintaining existing software.) Adam, sorry for the tone of my previous mail. That was uncalled for. -- Juliusz -- 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/87wq8o8w8y.wl-...@pps.univ-paris-diderot.fr
Re: binary data file and endianness and multiarch
The mesh files are stored in binary form, and thus endian-ness is a worry when moving from one platform to another. [...] What is not clear to me right now is how to [store] those data files: is there an endian triplet ? Jérôme, Please try to work with upstream to fix the issue. Byte swapping is essentially free on modern processors (on Intel/AMD, the time for a bswap instruction is hidden by the latency of the memory access), so there's no reason whatsoever not to have arch-independent data files. Standardising on big-endian is a good idea, not only because it is the canonical byte ordering, but also because little-endian arches tend to have more efficient byte-swapping instructions. Please do try. It might seem easier to do your own distribution-specific workaround, but working with upstream will be more productive (and enjoyable) in the long term. -- Juliusz -- 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/87y4t5pyxl.wl-...@pps.univ-paris-diderot.fr
Re: bash without importing shell functions from the environment
Since I’m pretty sure we haven’t uncovered all of bash’s “features”, wouldn’t it be a good opportunity to make a release goal of killing all scripts with a #!/bin/bash shebang? Just to make things clear -- you're advocating #!/bin/sh and running dash as /bin/sh? (Likely alternatives include at least ksh and mksh, formerly pdksh.) --jch -- 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/87d2ajl0mj.wl-...@pps.univ-paris-diderot.fr
Re: all modern desktops need systemd, either send patches or life with it (Re: systemd now appears to be only possible init system in testing)
However, you're doing this during boot, so there *are* no active users, since the system hasn't come up far enough to let anyone log in yet. So it makes sense that you don't get a prompt. Does that mean that the new pid 1 expects users to be logged in before it starts the system? -- Juliusz -- 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/87ppgwcdp5.wl-...@pps.univ-paris-diderot.fr
Re: systemd now appears to be only possible init system in testing
I'm sure the texlive maintainers feel perfectly justified in breaking existing setups and causing packages to FTBFS by doing this. I don't think the comparison between texlive and systemd is quite fair. Texlive updates don't break users' systems, they just make some packages temporarily un-upgradeable. And even if they did break, they wouldn't break the systems of troff users. To some of us, this transition is starting to feel like a rather unsubtle attempt to force systemd down everyone's throat, whether we want it or not. I still believe that this is just bad coordination and bad communi- cation on the part of the systemd packagers, and sincerely hope that this is not a coordinated attack on non-systemd installations. -- Juliusz -- 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/87r41ccdrw.wl-...@pps.univ-paris-diderot.fr
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
I would like to make it co-installable with OpenSSL, but in general, this should be a drop-in replacement until APIs really diverge in a visible way. Yes, it would provide 'openssl', but I intend to place them into a different directory, so you might have to use LD_PATH to get them. That reminds me of what we were trying to do with Xaw in the late 1990s. Short story -- we tried and we failed. I wish you better luck, but I fear that you're setting on a course that will bring you a lot of pain. In the late 1990s, the only widget set that was free, usable and vendor- neutral was Xaw , which was fairly functional but whose appearance was already somewhat dated. https://en.wikipedia.org/wiki/X_Athena_Widgets There were two drop in libraries that were meant to provide binary compatibility with Xaw but with a more pleasant appearance, called Xaw3d and (I think) NextAw. Branden Robinson's plan was to allow the user to select the appearance by setting LD_LIBRARY_PATH to point at one or the other of the Xaw libraries. It worked reasonably well as long as the user was just using the sample applications provided with X. However, real applications would sometimes subclass widgets, which would cause them to crash unpredictably. Whenever we got a crash report against an Xaw application, the first question was does unsetting LD_LIBRARY_PATH fix it?. After XFree86 changed the Xaw ABI with Xaw6, Branden finally gave up, and agreed to make Xaw3d an independent library that applications could link against rather than a drop-in replacement. Then Xaw got obsoleted by Gtk+, and the point became moot. History does not necessarily repeat itself, of course. Thanks for listening to an old man's story. -- Juliusz -- 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/87d2d89hmt.wl-...@pps.univ-paris-diderot.fr
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
Meanwhile, we could try to get ever distro with a clue together, map the versioned symbol diffs that already exist, and see if we can come up with a plan to at least do downstream versioning in a compatible way. Please, please, please speak to upstream first. It's hard work, but some upstreams can be convinced to do the right thing. -- Juliusz -- 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/87ion1gflu.wl-...@pps.univ-paris-diderot.fr
Re: systemd is here to stay, get over it now
me: (I did find his comment funny -- actually, I find the CoC ifself pretty funny --, but I realise that this is an international mailing list and that Austrian-Japanese humour is not necessarily obvious to everyone.) Tollef Fog Heen: Humour [...] does not work very well on large lists. Christan Hofsteadler: I'd suggest you stop with the country-labeling/-generalization, because to me (myself an Austrian) this reads like quite the insult. It appears that you've been proven right, Tollef ;-) -- Juliusz -- 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/87pphj99yk.wl@pps.univ-paris-diderot.fr
Re: systemd is here to stay, get over it now
The problem is that some people bitch endlessly abut how evil systemd is _instead_of_ producing software (not just patches) to replace what systemd offers. Abstracting away from your somewhat offensive choice of language, that's a good point. As far as I'm aware, the only major distribution that has been doing the right thing is OpenWRT, which has recently switched to procd, a locally developed init replacement. git clone git://nbd.name/luci2/procd.git -- Juliusz -- 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/87bnt5i9rw.wl@pps.univ-paris-diderot.fr
Re: systemd is here to stay, get over it now
While I have no interest in joining Norbert in calling for your ban, Having had the pleasure to meet Norbert in person, I have no doubt that he was joking when appealing to the CoC. (I did find his comment funny -- actually, I find the CoC ifself pretty funny --, but I realise that this is an international mailing list and that Austrian-Japanese humour is not necessarily obvious to everyone.) Coming back to the subject at hand, this thread has been pretty productive in showing that I'm not alone in wanting my servers and my netbook to run Debian without systemd (I've given up on my full-fledged desktops, for better or worse), and in showing that it can be achieved with the existing mechanisms (apt pinning). I have good hope that the systemd maintainers will take this minority of users into account in their further development. -- Juliusz -- 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/87zjgoyhwl.wl@pps.univ-paris-diderot.fr
Re: systemd is here to stay, get over it now
Tollef Fog Heen tfh...@err.no wrote: I [...] will try to avoid breaking stuff I expect no less from a Debian Developer. but it's also a use case we don't hit, so breakage there is less likely to be seen by us. We'll do our best to fix it when reported, of course. That is good to hear. It would be even better if actions followed. I'll remind you that this thread started with systemd breaking my system, and a systemd maintainer summarily closing my bug report. Not once, but twice. Summarily dismisisng non-systemd issues, unfortunately, is the kind of attitude that we've come to expect from many (not all) systemd supporters. -- Juliusz -- 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/87d2dky5nl.wl@pps.univ-paris-diderot.fr
Re: Pinning vs. conflicting
You have not yet explained why apt pinning is not enough. Simply because apt is not the only way to install packages. Don't synaptic and/or whatever honor these pins too? I have no idea about synaptic, but there’s e.g. cupt (which works as apt replacement, but probably (didn’t check) handles its configs the same…) and dselect (which uses dpkg and thus is one level “below” apt, and cannot be reasonably expected to use apt’s configs). Isn't the proper solution to add blacklisting support to dpkg, then? (Which should not prevent getting the systemd-must-not-die-but-please-dont-install-it-on-my-system package into the archive.) -- Juliusz -- 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/87ioney6pj.wl@pps.univ-paris-diderot.fr
Re: How to avoid stealth installation of systemd?
Juliusz, can you please paste your apt logs Sent by private mail. Please send it publicly in the Debian bug tracker. Sorry, Thomas, but I'm not quite sure what are the privacy implications of making public the set of packages running on my system. (Probably none, but I'd rather not find out I'm wrong.) -- Juliusz -- 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/87iongvw5f.wl%...@pps.univ-paris-diderot.fr
Pinning vs. conflicting [was: How to avoid stealth installation...]
You have not yet explained why apt pinning is not enough. I'd appreciate an explanation too. I've inserted in my apt/preferences file the incantation given by Vitali F. (to whom thanks) at the very beginning of this thread, and it appears to have the requested effect. I've looked through the whole thread, and I can see the following reasons: - conflicting packages are honoured by dpkg, unlike pinning; - a package can conflict with multiple packages, while you need multiple pinning entries; - there's a number of user-friendly frontends to apt, while pinning requires using a text editor (the horror!). Are there any other reasons to prefer conflicting dummy packages, which, with all due respect to Thorsten and Wookey, are something of a hack. Thanks to everyone who helped, -- Juliusz -- 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/87ha2zqtzn.fsf...@ijon.pps.univ-paris-diderot.fr
How to avoid stealth installation of systemd?
Dear all, A few days ago, after a routine upgrade from testing, the power button on my laptop ceased functioning. I was busy at the time, so I lived with having to remember to type sudo shutdown -h now for a few days; yesterday, I finally took the time to debug the issue. I started with strace -p $(pidof acpid)$, and it took me almost an hour to work it out. It turns out that apt had helpfully installed systemd, so the powerbtn-acpi-support.sh script was detecting a running systemd-logind, and (reasonably enough) going on strike. I was a little bit annoyed at that, so I filed bug 753357, which was immediately closed by Michael Biebl with the following advice: install systemd-shim I reopened the bug and explained that I have no desire to run systemd, that the actual bug is about silently breaking my power button during a routine upgrade, and that perhaps, just perhaps, the systemd maintainers could be so kind as to avoid such issues in the future by adding suitable conflicts to the systemd package. The bug was immediately closed again: Certainly not. So I'm turning to this list for help: 1. Could some competent person tell me the right way to tell apt that it should fail an upgrade rather than installing systemd? I guess I could make a dummy package that conflicts with systemd, but I'm sure there's a better way. 2. Could some kind soul explain to the systemd maintainers that gentle persuasion, while not always the most efficient way to take over the world, is more in line with point 4 of the Debian Social Contract than alternative approaches such as bullying? Thanks a lot, -- Juliusz -- 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/87y4wdyzvz.wl%...@pps.univ-paris-diderot.fr
Re: How to avoid stealth installation of systemd?
gentle persuasion [...] is more in line with point 4 of the Debian Social Contract than [...] bullying? May I suggest that you treat others the way you want to be treated? I am not a Debian Developer. I am not bound by the Social Contract. Are we to expect a higher standard of behaviour from a Debian Developer than from a random user who is pissed off because his system has just been broken? Or is being a Debian Developer power without responsibility, as some of your esteemed colleagues appear to believe? The suggestion to just add conflicts is also not quite helpful. I'm not sure I'm following. There was no reason whatsoever to install systemd on my system, yet it got installed and broke the ACPI scripts. To my untrained eyes, it looks like a conflict is missing somewhere. -- Juliusz -- 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/87simlytv8.wl%...@pps.univ-paris-diderot.fr
Re: How to avoid stealth installation of systemd?
The replies were not just terse, the replies were downright rude. That's hardly the main problem with Michael's behaviour. I reported an actual bug, including conclusions that I got from fourty minutes of tracing the ACPI scripts. Michael closed it straight away, without investigating the issue. I reopened the bug, explaining the problem again. Michael closed it straight away again. I've filed hundreds of bugs against Debian over the last fifteen years. The kind of attitude exhibited by Michael is fairly rare, but when it happens, it harms the whole project by driving users away from the bug tracker. I therefore stand by my point that DDs should be held to higher standards than random users. -- Juliusz -- 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/87egy5yq9k.wl%...@pps.univ-paris-diderot.fr
Re: How to avoid stealth installation of systemd?
Michael closed it straight away, without investigating the issue. Oh, I did. That's why I told you to install systemd-shim. Now could you please reopen bug 753357, or at least allow me to do it? -- Juliusz -- 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/87zjgsykzv.wl%...@pps.univ-paris-diderot.fr
Re: How to avoid stealth installation of systemd?
Juliusz, can you please paste your apt logs showing what pulled systemd in on the system? Sent by private mail. If anyone else wants a copy, please drop me a note. -- Juliusz -- 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/87tx70yhzr.wl%...@pps.univ-paris-diderot.fr
Re: upstart: please update to latest upstream version
Maybe we could have an intermediate goal to patch any daemon to add an option to not fork on start. Yes, please. All the more so since it is effort well-spent, No, this is not an effort well spent. And as already mentioned, running the daemon in foreground has unwanted side-effects, like making the boot process racy. Unless you provide other mechanisms how a daemon can signal that it is ready to process requests. Aren't the two issues orthogonal? Whether the daemon should (double-)fork or remain a child of whoever launched it, and how it signals that any dependencies are ready to be started? (There's a third issue, of course, which is whose environment the daemon should be inheriting -- the sanitised environment of init, or the environment of the shell of whoever is running /etc/init.d/foo start or whatever.) -- Juliusz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lin4hy9l@pirx.pps.jussieu.fr
Re: upstart: please update to latest upstream version
Maybe we could have an intermediate goal to patch any daemon to add an option to not fork on start. Yes, please. All the more so since it is effort well-spent, as it is likely to be useful not only for systemd and upstart, but also for whatever service management daemon comes next. (Note that I didn't say init replacement, since there's no good reason why a service management deamon needs to run as pid 1 -- it could be launched from /etc/inittab just as well.) The runit community have been doing just for the last ten years or so. Since any self-respecting daemon already has a debug mode where it doesn't fork (possibly with other side-effects), it's usually a fairly trivial job. And upstreams tend to be sympathetic to such minimal changes that makes peoples' lives easier. -- Juliusz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877gyrhrfk@pirx.pps.jussieu.fr
Re: Minimal init
No, I don't think so. If these external tools double fork then they are just wrong. Double Forking has been the right way to do it for decades. It has been the default way for most daemons, granted. (Getty is a notable exception.) Demanding from upstreams that they change their software this fundamentally to cater for a new init system is [...] unrealistic Runit has been around for a decade or so. Most daemons known to me have a command-line flag that prevents forking. Remember, preventing forking is about *removing* code from daemons, not adding new code. Adding a flag to avoid forking is a trivial exercice, and it's a rare upstream that will refuse the usually trivial patch. -- Juliusz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hb6epdl9@trurl.pps.jussieu.fr
Making daemons compatible with systemd [was: Minimal init]
From what I've seen in Lennart's posts, adding systemd support doesn't seem to be too complicated. No. No changes at all are necessary to be compatible with systemd. This is a very impressive feature of systemd; at the same time, this is what complicates systemd, and creates a dependency on cgroups. If you have a daemon that forks and creates a pidfile, just say Type=forking PIDFile=/var/run/daemon.pid If you have a daemon that forks and doesn't create a pidfile, systemd will try to guess the main pid. I kid you not. If you have a daemon that doesn't fork and is able to satisfy its dependencies straight away, just say Type=simple If you have a daemon that doesn't fork and needs some time before it can satisfy its dependencies (say, because it needs to create some sockets first) but advertises itself on dbus, just say Type=dbus Finally, if you have a deamon that doesn't fork, cannot satisfy its dependencies straight away, and doesn't advertise itself on dbus, you need to add three lines of code to your daemon (to notify systemd that it's finished initialising), link with an MIT/X11-licensed file provided with systemd, and say type=notify Is that cool? Is that bloat? I say yes to both. -- Juliusz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aac6p3px.fsf...@trurl.pps.jussieu.fr
Re: A few observations about systemd
That is very good and has way more chances of changing the status quo in Debian than any pro- or against-systemd thread on -devel. Just to clarify -- this is not a pro- or against- thread, which, as I've tried to make clear in my initial mail, would be premature. My goal is to get people thinking about the current work being done on next-gene- ration init systems, and it appears that I have succeeded. Let me be more explicit. Over the last few years, we've seen a mul- titude of new init systems appear. The other distributions have been switching like crazy -- as far as I'm aware (I may be wrong) Gentoo went for initng, then switched back to SV init, Fedora switched to upstart and then, within two releases, to systemd, openSuSE switched to upstart, then started switching to systemd, then apparently stalled. This sort of disruption is not good for the users; neither is it good for the developers' morale (a vitally important consideration for a distribution that relies on volunteer labour). Again, this is just my private opinion (and as you know I'm not even a DD, just an enthusiastic user), but I'd like to see Debian wait until the dust settles. I'm acutely aware, however, that waiting only makes sense if Debian developers are aware of the ongoing community-wide debate, and participate in it. Which is why the work of people like Tollef and Scott is so crucially important. So folks -- please relax. Please play with runit, play with initng, play with upstart, play with systemd. Oh, and read djb's thoughts on the subject[1]. When enough Debian developers are competent to have an opinion on the new init systems, the Debian community will naturally converge on the technically correct solution; at that point, fitting the non-Linux kernels into the picture will be a simple matter of hacking. As a final note, Bastien and Ian have outlined a different architecture for a new init system, one that does not rely on running 700 kB of text under pid 1. I happen to agree with their vision. -- Juliusz [1] http://cr.yp.to/daemontools/faq/create.html Please note that I am not suggesting daemontools as a solution, just recommending that people be aware of the rationale behind it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877h7dozj4.fsf...@trurl.pps.jussieu.fr
Re: [Lennart Poettering] Re: A few observations about systemd
It's not like boot speed would be the only reason to avoid shell. I don't think that avoiding shell implies that all the distribution- specific initialisation code must be hard-wired in pid 1. I'd be more sympathetic to the idea of recoding everything in C if the initiali- sation code lived in separate binaries. -- Juliusz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxgah4l1@trurl.pps.jussieu.fr
Re: [Lennart Poettering] Re: A few observations about systemd
| I'd be more sympathetic to the idea of recoding everything in C if | the initialiation code lived in separate binaries. system/ systemd-fsck* systemd-quotacheck* systemd-shutdown* systemd-vconsole-setup* [...] Interesting. Looking at the code, I hadn't noticed these get compiled into separate utilities. Really, it's not that hard coded. Indeed -- they are simply ExecStart:ed by normal systemd units. -- Juliusz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwm2h28g@trurl.pps.jussieu.fr
Minimal init [was: A few observations about systemd]
Not rocket science about ipc only a loop and two signal to catch: - get SIGING: respawn systemd - get SIGUSR2: spawn a sulogin shell - check if systemd child die, respawn it if needed (rate limited) All the funky stuff is done by a child of init. Hmm If you want to support forking daemons, you'll also want a protocol to signal the child that a monitored process has exited, won't you? -- Juliusz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bowqgwmd.fsf...@trurl.pps.jussieu.fr
Re: Minimal init
It seems this problem (double fork) is the basement of using cgroup under systemd ;) I think messing around with cgroups is a ridiculous way to solve this problem. To be fair, systemd also uses cgroups to reliably kill rogue child processes when stopping a service. This is not unlike what BSD-derived shells use pgroups for, I believe. The right answer is simply to change the daemons to give them an option which causes them not to fork. Then you can just have a single supervision daemon which reaps (and restarts, if desired). I haven't done a survey of the available init replacements but this is not a new concept Well, it's already present in SV init : 1:2345:respawn:/sbin/getty 38400 tty1 and I hope that most of them implement it as a possibility. Daemontools, runit, minit, upstart, systemd all do. I don't know about initng. -- Juliusz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/7iy5zu19ux@lanthane.pps.jussieu.fr
Re: A few observations about systemd
I think only supporting Linux is entirely his perogative: It's his project, his time and he can support what he wants. Hmm. I may be wrong, but I was under the impression that he's pushing systemd as the standard init, not just as his hobby project. Josselin may have more information. -- Juliusz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxgbc00q@trurl.pps.jussieu.fr
Re: A few observations about systemd
start-stop-daemon (and/or a new C helper that is run like s-s-d and does some of the same things as systemd) Another architecture would be a daemon that is run from inittab, but yes, your have a point there. -- Juliusz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipqzbzxn@trurl.pps.jussieu.fr
Re: A few observations about systemd
It's actually lighter than sysvinit, from what I've seen so far, $ size /sbin/init /bin/systemd textdata bss dec hex filename 300401320 612 319727ce4 /sbin/init 79369167482188 802627 c3f43 /bin/systemd -- Juliusz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877h7fbxtk@trurl.pps.jussieu.fr
Portability of systemd [was: A few observations about systemd]
It's not a simple portability problem, systemd relies on very complex Linux-specific stuff. Well, having looked at the code, yes and no. Yes, because systemd recodes the whole startup process in C. Translating a lot of distritibution-specific shell code into C is not going to be portable: $ grep '^#.*TARGET' vconsole-setup.c #ifdef TARGET_GENTOO #ifdef TARGET_MANDRIVA #if defined(TARGET_FEDORA) || defined(TARGET_MEEGO) #if defined(TARGET_FEDORA) || defined(TARGET_MEEGO) #elif defined(TARGET_SUSE) #elif defined(TARGET_ARCH) #elif defined(TARGET_FRUGALWARE) #elif defined(TARGET_ALTLINUX) #elif defined(TARGET_GENTOO) #elif defined(TARGET_MANDRIVA) No, because that's not the case of systemd's core. From what I've seen, most of the non-portable code in systemd's core is merely there for convenience. For example, the %m printf descriptor is used extensively, which is just shorthand for strerror. Similarly, openat is used in systemctl in order to implement a virtual cwd -- since systemctl is not multi-threaded, this is easily (albeit messily) simulated with either chdir or by manually concatenating absolute paths. Now I've certainly not read all of the systemd code, but the one exception that I've noticed is the use of cgroups. While cgroups provide systemd with some of its coolest functionality (notably the ability to monitor SV initscripts, and the ability to reliably kill mis-behaving multi-process daemons), I'm not sure to what extent people think this functionality is central to systemd. I think implementing all the required stuff would be an effort comparable to implementing something like KMS or GEM or Gallium3D on FreeBSD. I think that's an overstatement. -- Juliusz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739i3buad.fsf...@trurl.pps.jussieu.fr
Re: [Lennart Poettering] Re: A few observations about systemd
I have not seen any serious attempt at measuring how big this impact actually is I'd expect some important differences between shell script based init and systemd-type init Yeah, that's everybody's intuition too. But Steve is right -- it would be good to see some real benchmarks. -- Juliusz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjq3fc2k@trurl.pps.jussieu.fr
A few observations about systemd
Dear all, Systemd[1] is the currently fashionable next-generation init replacement, intended to replace both System V init and Ubuntu's upstart. Since the Debian systemd package is now operational, I've decided to try running it on my laptop. Here are my observations after three days with systemd. Please note that this mail is not intended to push Debian's policy in one way or another, which would be premature. Note further that any opinions expressed in this mail are mine, and mine only, and that they are subject to change in the future as I grow older and more stupid. The good Systemd works - It is easy to get systemd to work on a Debian system. Just install the systemd package, and reboot after adding init=/bin/systemd to the kernel's command line. (I'm running testing, so I've had to pull a few packages from sid to get systemd to install.) In addition to the issues described on the wiki[1], I'm sufferring from a deadlock on shutdown that is resolved by systemd timing out after a couple of minutes. Systemd is documented - Systemd comes with extensive documentation, in the form of well-written manual pages; additionally, there is a series of (somewhat verbose) blog postings by the author that explain the rationale. (The documentation does need more work, though. For example I couldn't find the complete set of service states, and it took me some time to discover how native and SV services interact.) Systemd makes sense --- Unlike upstart, which I've never managed to get my head around, systemd actually makes sense to me. It has a sane notion of dependency, a relatively sane notion of service, a comprehensible notion of target (the equivalent of a runlevel). While I may not like systemd's obsession with socket activation, it too is a notion that makes sense. Systemd got services right -- What systemd definitely got right are services, in more than one way. ### Services are launched by init With SV init, a deamon is launched by a descendant of whoever started the initscript. The daemon may inherit file descriptors from somebody's login shell, which may end up e.g. preventing a filesystem from getting unmounted. (And no, CLOEXEC is not a solution.) With systemd, services are launched by the init daemon, which has hopefully been able to preserve a clean environment. (This is also the case with all other modern init replacements, notably upstart and runit.) ### Services have a sane life cycle Systemd services have a sane life cycle, and are monitored by systemd in a variety of ways. Thanks to cgroups, systemd is able to reliably kill or restart a service -- no more rogue processes that are left after you've stopped a daemon. (Not everything is perfect, though. Systemd perpetuates SV init's confusion between daemons -- things that keep running -- and initialisation scripts -- things that must be run at some point during the boot process, but don't really have a state.) ### Defining a service is a piece of cake Writing a native service for systemd is a pleasure -- it's a matter of writing a simple config file, in a human-readable syntax (no XML), typically 3 to 6 lines long, and soft-linking it to the right place. Compare that with SV init, where writing an init script takes the best part of an hour and involves getting the syntax of start-stop-daemon wrong at least three times. Most of the features that you'd expect are present, including setuid, redirecting output to syslog, resource limits etc. One thing that I've found missing is the ability to redirect output to a log file in a manner compatible with logrotate (without going through syslog), but perhaps I haven't looked hard enough. The format of a service definition is sane enough to allow for automatic conversion to a different format; I think it would be quite doable to automatically convert systemd's definitions to SV init scripts or to the format of whatever is the next fashionable init replacement after systemd. ### System V initscripts are monitored Unlike all other init replacements known to me, systemd is able to monitor daemons launched from System V init scripts just as reliably as native services. This is an amazingly cool feature. The bad === Systemd is bloated -- Systemd is bloated. It apparently attempts to take over the roles of init, cron, at, inet, ConsoleKit, sethostname, modprobe, mount -a, and probably others. The result is that you end up running 5 lines of C code as PID 1, as compared to the 8000 lines of SV init or the 6000 lines of runit. Systemd is layered strangely For a low-level piece of infrastructure, systemd interacts with a lot of high-level software; while this might be okay for a workstation running Gnome, it makes me wonder whether it will be usable on servers. A cursory look shows that systemd intrinsically depends on D-Bus (the
Re: A few observations about systemd
(I'm the systemd maintainer in Debian)
(Shakes hands.)
| Another case that I've actually been bitten by is that systemd
| hard-wires runlevel 5 in its SV init compatibility code;
It does?
I stand corrected, it's actually part of the configuration (symlink from
runlevel5.target to multi-user.target). Tollef, should the Debian
package change that?
| Systemd is specific to Linux. This is strange, since the only feature
| of Linux used by systemd that doesn't have an exact equivalent on other
| systems, cgroups, is optional in systemd.
TTBOMK, cgroups are not optional.
From cgroup.c, line 270:
if (path_is_mount_point(/sys/fs/cgroup/systemd) = 0) {
log_warning(No control group support available, not creating root
group.);
return 0;
}
Note that this returns 0, which stands for success.
-- Juliusz
pgpHcJz9jiNGq.pgp
Description: PGP signature
Re: A few observations about systemd
This looks quite correct to me? (It's also what's shipped in the package.)
I'm confused, then. After installing systemd the first time, systemd
happily ran the init.d scripts that I had disabled in rc2.d but left
enabled in rc{3,4,5}.d. We can probably agree that this is not the
expected behaviour on a Debian system.
Could you point me at where exactly systemd decides which of the rc?.d
services to start?
-- Juliusz
pgpHT46KhYMBl.pgp
Description: PGP signature
Re: A few observations about systemd
So cgroups is optional, but not really if you want a supported systemd installation :) Yes, and that's exactly what I find worrying about Lennart's attitude: he presumes to impose his policy on you -- you must use Linux, you must use a recent kernel with cgroups enabled, you're not supposed to use shell scripts, etc. I really like systemd, but not to the extent of giving up the ability to pick my own policy. -- Juliusz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739i4dgat@trurl.pps.jussieu.fr
Systemd and rc2.d vs rc5.d [was: A few observations about systemd]
What does systemctl show $service tell you? I've now reconfigured my laptop to have identical rc?.d directories, so I cannot easily reproduce the issue. | Could you point me at where exactly systemd decides which of the rc?.d | services to start? default.target It's linked to graphical.target. How is the right runlevel?.target pulled in? -- Juliusz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tyakbqm8.fsf...@trurl.pps.jussieu.fr
Re: Multiarch bootstrapping
Currently there are still some outstanding issues before we can really start using multiarch. Is there anything upstream maintainers should be doing in order to help? (Except writing makefiles that allow easy cross-compilation, of course.) -- Juliusz pgpmIaWRYiIGs.pgp Description: PGP signature
Cedilla removed from sid, users complain
Hi, I'm upstream for Cedilla [1,2], which has been orphaned and removed from Sid. I'm receiving e-mail from Debian users of Cedilla, asking me what is the suggested replacement. What shall I answer? --Juliusz [1] http://www.pps.jussieu.fr/~jch/software/cedilla/ [2] http://packages.debian.org/lenny/cedilla pgpjyPPSwJ8xE.pgp Description: PGP signature
Re: Cedilla removed from sid, users complain
Thanks to both of you -- I've forwarded your messages to my (soon-to-be former, sigh) users. --Juliusz pgpdCt7J6BkEQ.pgp Description: PGP signature
Re: Cedilla removed from sid, users complain
There is always the option of either recruiting one of those disappointed users to maintain the package, or doing it yourself. Thanks for the suggestion -- but I'm already spending all of my proverbial Copious Free Time on upstream work. It seems a shame to lose a bug-free package when you apparently have users that are going to miss it. I think so too. But I cannot be doing everything. --Juliusz pgphaGWFCz5b8.pgp Description: PGP signature
Re: Bindv6only once again
Why is it that suddenly everyone is an expert in double-stack programming? Brian May: For me, bindv6only=0 seems like an ugly hack designed to make existing applications work without change. Bindv6only=0 is a way to allow servers to be written to listen to just one socket, which allows making blocking accept calls. With bindv6only=1, you need to listen on two sockets simultaneously, which requires some mildly more complex code (either forking or calling select/poll.) (Yes, I know about setsockopt(IPV6_V6ONLY), and I use it whenever possible, but that's not portable.) Henrique de Moraes Holschuh: one probably has to mess with /etc/gai.conf [...] On a dual stack box and any application that does NOT work in ipv6only=1 mode, you likely have to firewall/ACL off IPv4, IPv6, IPv4-mapped-in-IPv6 ([:::a.b.c.d]) and IPv6-compatible-IPv4 ([::a.b.c.d]). Icky. I suspect you don't really don't know what you're speaking about. With bindv6only=0, a v6 socket bound to :: will not accept v4 connections, full stop. With bindv6only=0, connecting a v6 socket to a v4-mapped address will not work, full stop. No amount of tweaking /etc/gai.conf, no amount of firewalling will change the above facts. Juliusz pgpVsWjX2jDN7.pgp Description: PGP signature
Re: Bindv6only once again
With bindv6only=0, a v6 socket bound to :: will not accept v4 connections, full stop. With bindv6only=0, connecting a v6 socket to a v4-mapped address will not work, full stop. That's obviously a typo -- I meant bindv6only=1. Juliusz pgpEstR4godnU.pgp Description: PGP signature
Bindv6only once again
Dear all, I would like to raise the issue of #560238 once again. In netbase 4.38, Marco d'Itri has unilaterally decided to change the value of the net.ipv6.bindv6only sysctl to 1. This change has the following effects: (1) it violates POSIX 2008, Volume 2, Section 2.10.20; (2) it violates RFC 3493, Section 5.3; (3) it breaks software that is written to comply to POSIX, most notably Sun's Java. Now, violating POSIX when there is good reason to do sois not something Debian should shy from -- that's what we have POSIXLY_CORRECT for. However, I don't think that such a decision should be taken lightly, and certainly not without at least some discussion and advance warning. Marco has made this change unilaterally, apparently without discussing it with anyone. While there have been at least two extended discussions of the issue on debian-devel[1,2], Marco has been adopting a low profile, waiting for the discussion to die out on its own and ignoring any objections. I am very much surprised at the Debian community's passivity with respect to what I see as a clear violation of Debian's commitment to collective decision taking. I would like to very strongly request that Marco should revert the change mentioned above. Failing that, I would be grateful if some Debian developer could be so kind as to raise the issue with the Technical Committee. Juliusz [1] http://mid.gmane.org/87r5msss71@molech.giraffy.jp http://mid.gmane.org/87tyqztpu1@pirx.pps.jussieu.fr pgpf8o54viM4o.pgp Description: PGP signature
Re: bindv6only again
What if it is just installed from the tarball? Then that person is still using buggy, non-free software. Proprietary, granted, but why buggy? bindv6only=0 is assumed by both POSIX and RFC 3493. --jch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iq6sylhl@pirx.pps.jussieu.fr
Re: bindv6only again
| bindv6only=0 is assumed by both POSIX and RFC 3493. As the default value, yes. Not as the only possible value. Please stop repeating this legend, it is simply not true. POSIX 2008, Volume 2, Section 2.10.20 is extremely clear that AF_INET6 sockets can be used for IPv4: Applications can use AF_INET6 sockets to open TCP connections to IPv4 nodes, or send UDP packets to IPv4 nodes, by simply encoding the destination's IPv4 address as an IPv4-mapped IPv6 address, and passing that address, within a sockaddr_in6 structure, in the connect(), sendto(), or sendmsg() function. [...] An application can use AF_INET6 sockets to bind to a node's IPv4 address by specifying the address as an IPv4-mapped IPv6 address in a sockaddr_in6 structure in the bind() function. Juliusz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87eihfzsse@pirx.pps.jussieu.fr
Re: bindv6only again
If POSIX-compliant apps may only work with one setting then the standard would say only this setting is compliant with POSIX. Since it does not, Yes it does. Section 2.10.20, see the paragraph titled Compatibility with IPv4. You might argue that having this in the POSIX standard is a mistake, but it is perfectly clear to anyone even vaguely competent that when bindv6only is true, Linux is not compliant with the IPV6 option to POSIX. we must assume that a sysadmin choosing either value results in a POSIX-compliant system. If an application fails to work on such a system it must ipso facto not be POSIX-compliant and hence buggy. Please stop bluffing. Juliusz pgpwhsB5IgzT6.pgp Description: PGP signature
Re: bindv6only again
The apparent consensus is being ignored -- the default value is still - nobody cares about the consensus in the peanut gallery I am not quite sure what to do with this sentence. You have single-handedly broken peoples' systems, with no advance warning. When people have complained, you have either ignored them or bullied them (in #56023, you use phraseology such as you do not understand well sockets programming in response to a helpful and reasonable commenter), and now you're saying that Julien Cristau is the peanut gallery. Marco, this is not the way things are done. - as explained in #560238, it is still not the time to make a choice But you're breaking peoples' systems *now*. And breaking systems tracking *testing*, not unstable! Juliusz pgpZ7J1DdqbSK.pgp Description: PGP signature
Re: bindv6only again
unless I've missed something, I'm under the impression that people agree that the change was a mistake. Not again... What do you mean? The apparent consensus is being ignored -- the default value is still the one that people don't want. On Linux bindv6only is configurable by administrator, I am aware of that. It is the default value that we are speaking about. applications expecting specific setting are broken anyway (on Linux), no matter what RFC says and what default on Debian is. This is of course nonsense. Choosing the default value that is incompatible with all other Unix systems (with the exception of OpenBSD) and then complaining about applications being broken doesn't strike me as a particularly productive attitude. Juliusz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87633e5kpn@pirx.pps.jussieu.fr
bindv6only again
I've been reading through the archives in order to find out if there's been any consensus on the controversial change to the default value of net.ipv6.bindv6only -- and unless I've missed something, I'm under the impression that people agree that the change was a mistake. May I therefore most humbly suggest that Debian should revert the change to the default (/etc/sysctl.d/bindv6only.conf), and thus become once again compatible with what RFC 3493 says and most application developers expect? Juliusz pgp4oeiojkSeX.pgp Description: PGP signature
Bug#531616: RFP: ccl -- Clozure Common Lisp (formerly OpenMCL)
Package: wnpp Severity: wishlist * Package name: ccl Version : 1.3 Upstream Author : Clozure Associates (Gary Byers) * URL or Web page : http://openmcl.clozure.com/ * License : LGPL with Lisp exception Description : Clozure Common Lisp (formerly OpenMCL) Ccl is a high-quality, native code implementation of Common Lisp, derived from the non-GUI core of MCL. It has the following advantages over the high-quality native-code Lisps already included in Debian, such as CMUCL and SBCL: - faster compiler; - comprehensible source code and easy bootstrap; - faster CLOS implementation; - smaller image. Its limitations are as follows: - only works on PPC(64/32), AMD64 and x86 (SSE2 required); - slightly slower on non-CLOS code. I've been using CCL exclusively for a year now, and I'm very happy with it. CCL includes ASDF, works fine with Slime, and should be trivial to integrate within the Debian Common Lisp framework. Juliusz pgp5vTgvZVDro.pgp Description: PGP signature
Upstream bugs in Debian BTS [was: Firefox bugs mass-closed.]
As a maintainer and a user, I have often wondered lately if the practice of tracking numerous upstream bugs in the Debian BTS is something that should be ended. Please don't. I always ask my downstream DDs to forward bugs to me together with the Debian bug number, and to leave the bug open until it is fixed in the Debian version. (I also try to drop a note to the Debian BTS when the bug is closed upstream, indicating the upstream version or changeset.) From an upstream maintainer's point of view, a bug report forwarded From the Debian BTS has particular value. For a start, it has been read, and sometimes reproduced, by your friendly DD[1]. Second, the DD may have thought about it -- there's a good chance he'll provide you with a hint or two. And third, it usually comes with precise version information. If upstream bugs from the Debian BTS are not being attended properly, then somebody f*cked up, either the DD or the upstream maintainer. Juliusz [1] DDs actually are friendly, they just express their friendliness differently from the rest of us ;-) pgp3imcLh5zkW.pgp Description: PGP signature
Firefox bugs mass-closed.
Dear all, I have just received the attached mail. The relevant bit is at the end: As this bug is quite old, I intend to close it if you don't update your bug report in the next 6 weeks. Since this particular bug is trivial to reproduce (ls ~/.mozilla/firefox/), it would appear that the Firefox maintainers are mass-closing bug reports without even checking what they are about. While I realise that it is sometimes difficult to deal with hundreds of old bug reports, there are other ways of dealing with this kind of issue, such as tagging old bugs when they lack submitter input, or at least going through old reports to check whether the information they contain is useful. I certainly did not expect this kind of approach from Debian. I would like to recommend http://www.jwz.org/doc/cadt.html which succintly summarises the impression this kind of action gives. Thank you for your attention, Juliusz Chroboczek pgpkR46Mlau0d.pgp Description: PGP signature ---BeginMessage--- Dear Firefox/Iceweasel user, Thanks for your interest in Firefox/Iceweasel and the bug report you have contributed. Your bug report [0] was done for a version which isn't a part of debian anymore. Debian 4.0 (Etch) was released with version 2.0.0.3. Please reproduce your bug on an updated version of Iceweasel and confirm it still exists, or close it as irrelevant for recent versions. If you don't know or are not sure how to update or close your bug report, please contact me directly, and I'll help you. IMPORTANT: In any case, please provide version info, as we use it to determine the relevance of the bug. As this bug is quite old, I intend to close it if you don't update your bug report in the next 6 weeks. This is the time line for the old bugs cleanup: 1. October 1st - first notice. 2. October 15th - Second notice. 3. October 29th - Third notice. 4. November 12th - Closing the bug. Please help the Firefox/Iceweasel maintainer to help you (: [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=279104 -- Lior Kaplan [EMAIL PROTECTED] ---End Message---
Re: Firefox bugs mass-closed.
Since this particular bug is trivial to reproduce (ls ~/.mozilla/firefox/), it would appear that the Firefox maintainers are mass-closing bug reports without even checking what they are about. Considering that the message which has been sent to you does not close the bug, nor does it do anything but request the submitter or those who have seen the bug to replicate it, it's perfectly reasonable. They are requiring me (the submitter) to take explicit action just to make sure that an easy to reproduce and perfectly current bug report is not closed. This is reasonable? feel free to jump in and help triage. I am already actively helping with those projects for which I know the upstream code intimately. I don't expect to be required to actively participate in all of the Debian packaging efforts I submit bug reports against. Juliusz pgphdKqeM3QA9.pgp Description: PGP signature
Re: Firefox bugs mass-closed.
If you can't find the time to triage old bugs, it's kinda hard to convince a volunteer to do it for you. I am not quite sure what you mean. Are you saying that in order to submit a bug against a Debian package without it being summarily closed, I need to be a member of the development team for that very package? (And yes, I am actively helping with triage of Debian bugs, and have been doing so since the late 1990s. But that's pretty much irrelevant for this discussion.) Juliusz pgpSfnUwFFm9y.pgp Description: PGP signature
Re: Firefox bugs mass-closed.
Also node that many bugs are sometimes hard to reproduce, because you need a very specific environment that the maintainer not always have (e.g. the issue I have is that as a glibc maintainer, I've no large enough and used pam-ldap or NIS setups, and we have some bugs that rot because I don't have either the time or the resource to test them properly). I have no problem with the maintainer (a human being) asking me to do something sensible about my bug report, such as confirming that the bug still happens with the version in experimental, testing on a setup he doesn't have access to, producing a backtrace, running random commands on my system (as long as I understand what they do) etc. What Joey and I are specifically complaining about are three bugs that we have described in enough detail and that are trivial to reproduce. The maintainer did not send us personal mail asking for help; he sent us an automated mass mailing threatening to discard our perfectly valid reports unless we take some arbitrary action. This is clearly not the case that you are describing. Juliusz pgpAklwmaNBm6.pgp Description: PGP signature
Re: Firefox bugs mass-closed.
The insult isn't the request for help. The insult is the implication that if there's no response, the bug will be summarily closed with no attempt made to see if the problem reported is fixed. Very well put. That's exactly the bit that got me annoyed. Juliusz pgp1Cd4Ibr5pe.pgp Description: PGP signature
Re: Why no Opera?
The Firefox monoculture is doing a lot of harm to our community. So, I don't know what monoculture you're referring to. Popcon gives 23000 for iceweasel, 500 for dillo, and 18 for netsurf. (Correct me if I'm wrong, but I believe that konqueror statistics are not significant since it's also used as a file manager.) If that's not a monoculture, I don't know what is. Juliusz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why no Opera?
+ Firefox developers should all know what to compete against, free closed source programs are a means to communicate concepts and benchmarks between developers I think this is a very important point. The Firefox monoculture is doing a lot of harm to our community. Just like Linux learnt a lot from SunOS, GCC benefited from the competition from ICC, Firefox will benefit from the competition with other players in the same niche. And right now, only Konqueror and Opera fit the bill. I won't use it, but I'll be glad to see Opera in Debian. Juliusz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On including 64-bit libs in 32-bit packages (see #344104)
Bear in mind that the 64-bit kernel doesn't offer all the functionality that the 32-bit one does. vm86 is the most obvious thing missing. In arch/x86_64/ia32/ia32entry.S, both the vm86 calls (vm86 and vm86old) are stubbed to sys32_vm86_warning, which just printks vm86 mode not supported on 64 bit kernel and then returns -ENOSYS. If I'm reading the function int10LinuxLoadSubModule in os-support/linux/int10/linux.c right, it shouldn't matter. vm86 will return ENOSYS, which will cause vm86_tst to fail, which will cause the X server to use x86emu instead of vm86. Or am I missing something? Juliusz Chroboczek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CAN-2005-3163: polipo permits reading files outside of web root di
Hi Tom,
(I am the upstream author of Polipo.)
I have just checked the sources of polipo 0.9.8-1, and this bug is
still present. This is a serious security bug, but is mitigated by
the Debian installation.
The bug allows anyone who has access to Polipo's local web server to
read any file that is readable by the Polipo process. The following
factors mitigate the threat:
- by default, Debian's Polipo only listens on 127.0.0.1;
- Polipo is run by the proxy user, who should not have access to any
critical files.
There is, as far as I know, no possibility of an attacker managing to
write a file.
You may work around the issue by adding the line
localDocumentRoot =
to the file /etc/polipo/config.
Still, I believe that this bug should definitely be fixed. Choices
include:
- applying the appended patch;
- upgrading to 0.9.9, which has been out since September 2005.
I hold no opinion on whether this bug should be marked release-critical.
Juliusz
--- /usr/local/src/polipo/polipo-stable-0.9/diskcache.c 2006-05-20 01:33:04.
0 +0200
+++ polipo-0.9.8/diskcache.c2004-10-25 22:26:37.0 +0200
@@ -264,14 +264,10 @@
if(n = localDocumentRoot-length)
return -1;
-i = 0;
-if(key[i] != '/')
-return -1;
-
memcpy(buf, localDocumentRoot-string, localDocumentRoot-length);
-j = localDocumentRoot-length;
-if(buf[j - 1] == '/')
-j--;
+i = 1; j = localDocumentRoot-length;
+if(buf[j - 1] != '/')
+buf[j++] = '/';
while(i len) {
if(j = n - 1)
pgpgaFrNwXEWA.pgp
Description: PGP signature
Re: PDF files and dh_compress
Usually, when I get problems with xpdf on a PDF, it is a PDF 1.5. Either it simply doesn't work, or very slowly, or text search doesn't work in the PDF. Lionel, In my experience, the Xpdf upstream author is very responsive to bugs. If you provide him with a suitable test case, I have no doubt he'll solve your problem. Juliusz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PDF files and dh_compress
I am strongly against compressing PDFs To add insult to injury, PDF 1.5 introduces ``object streams'' which allow compressing arbitrarily long chunks of a PDF file without giving up the random-access properties of PDF. All current Free PDF readers grok PDF 1.5, although as far as I know no Free software can produce PDF 1.5 object streams. Hence the right solution is to fix gs and pdftex to produce object streams, not to work around the limitations of current Free software by gzipping PDF files and thus giving up the (quite amazing) efficiency of the format. Juliusz pgpSAcwT7EVY5.pgp Description: PGP signature
