Re: cdrtools
On Fri, 2006-08-11 at 23:55 +0200, Joerg Schilling wrote: > Linking a GPLd program against a non-GPLd library does not make the library a > derived work of the GPLd program. but it does mean you may distribute the resulting binary only if you make the library source available under the GPL, and if the library's license does not allow this then you may not distribute the binary -- Edward Allcutt <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Looking for co-maintainer for mercurial
On Tue, Feb 26, 2008 at 12:05:46AM +, Stephen Gran wrote: > This one time, at band camp, Aaron M. Ucko said: > > Julian Andres Klode <[EMAIL PROTECTED]> writes: > > > > > BTW, I think that hg is now the only VCS package which is not maintained > > > in its > > > own VCS format. (or are there other packages, too?) > > > > $ apt-cache showsrc rcs | grep Vcs > > Vcs-Browser: http://git.debian.org/?p=users/rfrancoise/rcs.git > > Vcs-Git: git://git.debian.org/git/users/rfrancoise/rcs.git > > cvs is IIRC maintained in svn. So that would make hg the only VCS package maintained in a VCS inferior to itself? :P signature.asc Description: Digital signature
Re: Bug#411617: ITP: ivtv-firmware -- firmware for the ivtv kernel driver
On Tue, 2007-02-20 at 07:26 +, Ian Campbell wrote: > 2. You may not copy, modify, rent, sell, distribute or transfer > any part of the Firmware except as provided in this Agreement, and > you agree to prevent unauthorized copying of the Firmware. I'm not sure how the Debian project can prevent unauthorized copying... -- Edward Allcutt <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: FHS and /var/www
On Sun, Jul 20, 2008 at 07:32:33PM +0200, Carl Fürstenberg wrote: > On Sun, Jul 20, 2008 at 16:34, Stephen Gran <[EMAIL PROTECTED]> wrote: > > This one time, at band camp, Carl Fürstenberg said: > >> FHS 2.3 specifies in > >> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM > >> to use /srv for "Data for services provided by this system", for > >> example /srv/www for web root. > >> In the policy, the section > >> 9.1.1(http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.1) > >> specifies that FHS 2.3 is mandatory, except for some exception, and > >> the use of /var/www isn't included in that list. > >> > >> Should we force all httpd:s to use /srv/www instead of /var/www, or > >> should an exception to the policy be added? Per > >> http://wiki.debian.org/Apache2LennyGoals it states that apache2 has > >> support for /srv/www, but it's still defaulting to /var/www. > > > > Please no. The layout of /srv/ is specifically said to be undetermined, > > so we can't actually rely on any paths in /srv/. I think the current > > setup is fairly good, actually - by default simple site layouts work out > > of the box, and don't interfere with more complicated setups that are > > free to use arbitrary hierarchies in /srv. > > > > Cheers, > > > > > > So you "vote" for an exemption from FSH in this case, as per 9.1.1? I believe he's claiming that there is no exemption needed, and I agree. Quoting from the URL you provided: Purpose /srv contains site-specific data which is served by this system. To me "site-specific" implies "not installed by the package manager". I believe it's quite reasonable for apache, CVS, etc. to set up a default location under /var so long as the local administrator can configure them to use whichsoever path is preferred according to local policy. The footnote implying that distributions MAY install files under /srv is very far from a SHOULD. I think by far the easiest way for Debian to "take care not to remove locally placed files" is to never but things there in the first place. signature.asc Description: Digital signature
Re: How to detect if inside a buildd chroot
On Tue, 2007-09-25 at 13:14 +0300, Lars Wirzenius wrote: > ti, 2007-09-25 kello 11:55 +0200, Simon Richter kirjoitti: > > Sebastian Dröge schrieb: > > > does somebody know about a solution to check whether one runs in a > > > buildd chroot or not? I need this to prevent hal from starting in buildd > > > chroots (via invoke-rc.d from postinst) as it breaks there because of > > > several reasons, including no /sys mounted. > > > > My chroots have /proc and /sys mounted, but I'd still be grateful if hal > > didn't start. > > Would policy-rc.d be helpful for this situation? According to /usr/share/doc/sysv-rc/README.policy-rc.d all you need is a /usr/sbin/policy-rc.d (inside the chroot) containing: exit 101 Is there a reason the abovementioned isn't part of "standard" Debian chroots such as those on buildds? -- Edward Allcutt <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
On Wed, 2007-09-26 at 11:26 +1000, Hamish Moffatt wrote: > On Wed, Sep 26, 2007 at 01:03:38AM +0200, Bastian Blank wrote: > > m-a don't need build-essential. It needs the compiler (nothing else like > > libc headers) for the kernel. The debian linux headers already depends > > against the correct compiler. > > Maybe so, but "m-a prepare" installs it. I don't know why it doesn't > just depend on it instead. Perhaps because the specific compiler needed depends on what the current kernel was compiled with? I thought that was the reason linux-headers depended on a specific compiler version. -- Edward Allcutt <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
On Wed, 2007-09-26 at 00:26 -0500, Manoj Srivastava wrote: > On Tue, 25 Sep 2007 22:10:52 -0400, Edward Allcutt <[EMAIL PROTECTED]> said: > > > Perhaps because the specific compiler needed depends on what the > > current kernel was compiled with? I thought that was the reason > > linux-headers depended on a specific compiler version. > > Has that ever been the case? I've had modules compiled with > a different gcc that I had when I compiled the kernel, and never had an > issue so far. I could well be wrong but I thought there may be some problem with compiling modules with gcc-4.1 when the kernel was compiled with gcc-3.3. -- Edward Allcutt <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: lilo removal in squeeze (or, "please test grub2")
On Mon, 24 May 2010, Stephen Powell wrote: To the best of my knowledge, it is the *only* bootloader which supports setting an initial text video mode *and* does not use any sectors outside the master boot record and outside of a partition. If I'm wrong about that, someone please correct me. grub2 supports loading its core.img from a dedicated partition instead of embedding it in the first "cylinder". This does require switching to the GPT partitioning scheme which may or may not be acceptable to you. -- Edward Allcutt -- 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/alpine.deb.2.00.1005241244200.1...@emallcut-x.pc.teamgleim.com
Re: Stepping the clock during boot
On Tue, 3 Aug 2010, John Hasler wrote: I wrote: Well, it's a reason. But note that such backward stepping would only happen when your clock is really screwed up. brian writes: It actually used to happen every reboot of my server, which is why I'm aware of the dovecot problem. When ntp (or ntpdate, I'm not sure which) would correct the time, the clock would move backwards 30 seconds or so and dovecot would crash. I can add an "X-Starts-Before: dovecot" line to protect dovecot. I think that ideally chrony would replace hwclock as provider of $time when present but I don't know how to arrange that... You could append +chrony to the $time line in /etc/insserv.conf as a local fix. You might be able to ship a /etc/insserv.conf.d/chrony that to that effect but I'm unsure whether that would replace or add to the existing line. I couldn't find documentation on exactly how the /etc/insserv.conf.d files work. -- Edward Allcutt -- 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/alpine.deb.2.00.1008031008260.2...@jago.allcutt.me.uk
Re: Trimming priority:standard
On Fri, 12 Sep 2014, Josh Triplett wrote: * telnet: dead for 19 years. Used only by those who misspell 'nc' and hope for no 0xff bytes. A slight exaggeration. A client that uses the actual telnet protocol is still invaluable for managing various fairly stupid devices. Given the rarity of telnet for login, and the common use of telnet for a text connection to random ports, how insane would it be to make interactive invocation of telnet default to being clean and transparent (without the crazy escape characters), and require an explicit option to *enable* non-transparent operation? I'd regard that as highly inconvenient. More inconvenient than retraining fingers to nc (although I'm biased since I've already done that). Regardless, this is in no way an argument for keeping telnet in standard. -- Edward Allcutt -- 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/alpine.deb.2.02.1409121556060.18...@pandora.retrosnub.co.uk
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
On Tue, 3 Jan 2012, Marco d'Itri wrote: It does not matter, this is needed strictly for the time of the upgrade process. Just how short do you expect this to be? I'm sure many of us dist-upgrade daily and (shock! horror!) don't reboot after each upgrade. We also don't expect existing processes to break or become inaccessible after an upgrade. I mean, I'll probably cope, but it's not quite the smooth, seamless experience that I generally expect. -- Edward Allcutt Who doesn't expect to reboot unless the kernel has changed. -- 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/alpine.deb.2.00.1201031538580.20...@pandora.retrosnub.co.uk
Bug 644138: kcc and heimdal-client both install /usr/bin/kcc
Hi devel, These packages do not remotely have the same functionality: kcc: Kanji code filter heimdal-clients: Heimdal Kerberos - clients kcc appears to have shipped /usr/bin/kcc approximately since 1997. heimdal-clients introduced /usr/bin/kcc in September 2011 and #644138 was filed shortly thereafter. The bug was closed by upload: * Add conflicts with kcc to heimdal-clients. Closes: #644138 and reopened the next day as "not an appropriate use of Conflicts". Quoting policy 10.1: Two different packages must not install programs with different functionality but with the same filenames. (The case of two programs having the same functionality but different implementations is handled via "alternatives" or the "Conflicts" mechanism. See Section 3.9, `Maintainer Scripts' and Section 7.4, `Conflicting binary packages - `Conflicts'' respectively.) If this case happens, one of the programs must be renamed. The maintainers should report this to the `debian-devel' mailing list and try to find a consensus about which program will have to be renamed. If a consensus cannot be reached, _both_ programs must be renamed. It has now been five months without either maintainer raising this. -- Edward Allcutt -- 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/alpine.deb.2.02.1203031820140.1...@jago.allcutt.me.uk
Re: socket-based activation has unmaintainable security?
On Thu, 7 Feb 2013, Salvo Tomaselli wrote: Yes but the xinetd process keeps the socket open, then on new connection forks and gives the service the fd of the new connection, retaining the fd for the listener part. Which means that on every connection it has to fork (and that's extremely slow). Only true for "nowait" entries. "wait" entries will pass the listening socket to the process which then accepts connections itself. -- Edward Allcutt -- 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/alpine.deb.2.02.1302071512200.20...@pandora.retrosnub.co.uk
Re: ca-certificates: no more cacert.org certificates?!?
Le 24/03/2014 14:23, Raphael Geissert a écrit : Anyway, I strongly recommend that nobody waste their time on an issue which in a couple of years will be much less relevant thanks to DANE. If only people actually used DNSSEC and DANE - Chromium/Google Chrome dropped support for the latter due to the lack of use[1]. [1]https://www.imperialviolet.org/2011/06/16/dnssecchrome.html I believe you are mistaken. That blog post is about Google's own design for "DNSSEC stapled certificates" . Not DANE. On Mon, 24 Mar 2014, Peter Palfrader wrote: DNS servers have supported them for years; RFC3597 is over a decade old by now. TLSA records were defined by RFC6698, which was issued in August 2012. -- Edward Allcutt
Re: Request for testing: /run and initscripts
On Fri, 15 Apr 2011, Roger Leigh wrote: This I really don't get. There was no error reported, and we're using this logic: if [ ! -L /var/run ] && [ -d /var/run ]; then echo "guest environment detected: Migrating /var/run to /run" ( # Remove /run first, so all contents get moved rm -fr /run && mv /var/run / && ln -fs /run /var/run ) || ( echo "Can't move /var/run to /run and replace with symlink; please fix manually."; exit 1 ) fi So, er, /var/run is going to be missing for an appreciable length of time. Is this acceptable? Also, if /var is not on the / fs mv is going to fall back to a recursive copy, which: - races with anything using /var/run - breaks named pipes and sockets[0] - other badness (I'll assume there's more than immediately comes to mind ;) [0] mv unlinks then mknods fifos and sockets, but cannot restore a link from the new inode to any processes which already have an fd open I'm assuming this is the degenerate fallback case when you can't use mount --bind, but I think we can still do better. Why not "ln /var/run /run" in this case and switch the symlink and actual location after the next "boot"? If some guest environments skip all of rcS then I'd hope they make some other provisions for "at boot" cleanup and other tasks. Otherwise the best we can do is document these changes in the release notes as something the local admin needs to take care of. -- Edward Allcutt -- 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/alpine.deb.2.00.1104151315410.30...@pandora.retrosnub.co.uk
Re: Request for testing: /run and initscripts
On Fri, 15 Apr 2011, Roger Leigh wrote:
On Fri, Apr 15, 2011 at 01:38:34PM +0100, Edward Allcutt wrote:
Your assumption is correct in that this is a fallback. This is the
special case for chroots, also co-opted for vservers, which don't "boot"
per se, and don't run the rcS scripts. The consequence of this is that
we can't do any setup at boot time; the chances are that no filesystems
will be mounted at all, and if there are, we don't have any control over
that process. This means that the migration in postinst is unfortunately
a "best effort"; I'd like to make it more reliable if at all possible.
In the case described, with a writable / and no tmpfs, what is the downside
to my suggestion? /run would remain linked to /var/run forevermore[0] if
the boottime switcheroo does not happen, but that doesn't seem so terrible.
Both /run and /var/run will remain writable and effectively the same location,
which points to the other isn't terribly important in the short term.
[0] or until the admin prods it as specified in the release notes.
The assumption is that there won't be anything running having open files
in /var/(run|lock)
I think that's an assumption that will fail in some cases and since we can
avoid it we should do so. I have run things like databases and asterisk
in chroots and would vastly prefer running upgrades to not be broken.
An alternative could be to just copy the contents, but we really do need
the symlinks in place or else programs can't transition to the new paths
transparently as on normal systems.
Copying the contents is the main thing I'm objecting to. I'm proposing creating
symlinks which do allow a transparent transition and leaving it to the admin to
switch the links around at a convenient time if rc scripts are skipped.
I agree that unusual custom chroot environments can't always be handled fully
automatically. Where I disagree is whether we should make assumptions which
would break running systems rather than simply giving the admin the details
needed to adapt the custom environment at a time convenient to them.[1]
[1] I'm going to guess we'll assume they've taken care of such things
before upgrading to wheezy+1. That seems like a much looser and
safer assumption.
Thank you very much for your time and effort on moving to /run in Debian.
--
Edward Allcutt
--
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/alpine.deb.2.00.1104151503390.30...@pandora.retrosnub.co.uk
Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)
On Fri, 15 Apr 2011, Roger Leigh wrote: For new installs, where the default /etc/default/rcS files does set RAMTMP=yes by default, the fstab file will not yet contain any user-specific mounts. If they do want to manuall mount something on /tmp, then they simply set RAMTMP=no. Hopefully you don't set RAMTMP=yes on new installs where a /tmp partition has been configured (and thus will be in fstab)? -- Edward Allcutt -- 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/alpine.deb.2.00.1104151605100.30...@pandora.retrosnub.co.uk
Re: Only forbid use of old alternatives to /run in wheezy+1?
On Sat, 16 Apr 2011, rleigh wrote: We haven't made any plans to remove it yet. We'll look more closely at the best way to do that once all the users are moved over. Given the small number, it's quite likely this won't take very long. If it turns out that there are other users of /lib/init/rw, it's not a problem keeping it around for wheezy. But if there aren't, there's no need to retain it. If there is a cleaner method than using versioned Breaks, I'm sure we can look at that instead--nothing concrete is planned yet for the removal, so all suggestions are welcome. I suggest: - on upgrade, bind mount or symlink /run/init -> /lib/init/rw - on boot, after mounting /run, mkdir /run/init; ln -s /run/init /lib/init/rw Or in other words - exactly like we're handling /var/lock and /dev/shm except without a possible separate tmpfs. This keeps /lib/init/rw available at all times and doesn't require any particular upgrade order. The link could be dropped in wheezy+1 but there's no urgency to do so. I was under the impression that this was already part of the plan, did /run/init get dropped for some reason? -- Edward Allcutt -- 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/alpine.deb.2.00.1104161750130.30...@pandora.retrosnub.co.uk
Re: Only forbid use of old alternatives to /run in wheezy+1?
On Sat, 16 Apr 2011, Roger Leigh wrote: On Sat, Apr 16, 2011 at 05:58:19PM +0100, Edward Allcutt wrote: I suggest: - on upgrade, bind mount or symlink /run/init -> /lib/init/rw - on boot, after mounting /run, mkdir /run/init; ln -s /run/init /lib/init/rw Or in other words - exactly like we're handling /var/lock and /dev/shm except without a possible separate tmpfs. This keeps /lib/init/rw available at all times and doesn't require any particular upgrade order. The link could be dropped in wheezy+1 but there's no urgency to do so. I was under the impression that this was already part of the plan, did /run/init get dropped for some reason? It did. The general consensus was that if we did bind mount /run/init to /lib/init/rw on boot (and vice versa on initial install, as for the othe locations), we would still need to transition from /run/init to /run anyway, so we might as well transition directly from /lib/init/rw to /run in a single shot. This is unlike the other directories, where the files are linked directly to their final destinations. I see. I don't see how this can be done in a single shot though. Let's take the example of package P which currently keeps state in /lib/init/rw/P. It has version P1 in squeeze. For version P2 in wheezy it aims to move that state to /run/P. The plan is for packages that will use /run in wheezy to predepend on initscripts (>= X). To achieve this, P (version P2) has to Pre-Depend: initscripts (>= X). Because initscripts intends to forcibly move /lib/init/rw/* to /run/* you're proposing that initscripts will Breaks: P (<< P2). I'm hoping I've misunderstood somewhere because that sure looks like an unbreakable cycle to me... If /run/init has been inextricably vetoed then the safe option looks like leaving /lib/init/rw alone in wheezy and letting all relevant packages handle their own transition to /run. If we want to try hard to remove /lib/init/rw in wheezy+1 then we need RC bugs against packages using it which don't safely transition away for wheezy. -- Edward Allcutt -- 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/alpine.deb.2.00.1104161837100.30...@pandora.retrosnub.co.uk
Re: ifupdown 0.7~alpha4 in experimental
On Thu, 16 Jun 2011, Stephan Seitz wrote:
So how do you do the auto configuration? Do you have radvd running or a
DHCPv6 server? If I understand correctly, radvd won’t give you DNS servers.
radvd can be configured to provide dns servers, eg.
interface eth0 {
prefix ...
...
RDNSS x:y:z {};
};
The client also needs to accept these. Linux (the kernel) keeps track
of dns servers advertised in this way but does not update userspace resolvers
directly. I recommend installing rdnssd which gets these details from the
kernel via a netlink socket and updates /etc/resolv.conf
--
Edward Allcutt
Bug#638322: nfs-common: rpc.statd binds to udp port 631 preventing cups startup
On Thu, 18 Aug 2011, Ben Hutchings wrote: On Thu, Aug 18, 2011 at 05:39:16PM +0200, Jan Möbius wrote: sometimes rpc.statd binds to port 631 udp which is used by cups. Therefore cups is unable to bind to its port and no printers get discovered. Rebooting the system helps as rpc.statd uses another port afterwards. This is a fundamental problem of the bindresvport() function, and not specific to rpc.statd. Reassigning to general. Sure, bindresvport is archaic, but workarounds already exist. In particular, Debian already adds /etc/bindresvport.blacklist and the default already contains port 631. Does the submitter have this file in place with the default contents? The 'portreserve' package provides a kluge to avoid this, but it requires other packages to register the ports that must be reserved. It also won't work reliably, because insserv runs init scripts in parallel and there is thus a race condition in the way services claim their ports from the portreserve daemon. That seems like a much worse kluge than the existing blacklist. Allowing packages to register reserved ports however seems a useful feature. Reassign to eglibc as request for supporting /etc/bindresvport.blacklist.d ? A proper fix probably involves using systemd's socket-activation. Yes, I said systemd - which presumably means we'll have to wait another 5 years for this to be fixed. Irrelevant. Promoting systemd for its side-effect as an amelioration for an ureliable kluge is not a strong argument. ;) [0] [0] Not intended as an argument against systemd either. -- Edward Allcutt
