Re: Bug#678815: ITP: wmfs -- Window Manager From Scratch
On Mittwoch, 27. Juni 2012, Thomas Koch wrote: > Thus having said, I believe that the world (and Debians archive) does > have all the window managers it needs. :-) I beg to differ. To say it mildy :) -- 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/201206280058.11035.hol...@layer-acht.org
Re: Bug#678815: ITP: wmfs -- Window Manager From Scratch
2012/6/27 Thomas Koch : > Hi Mickaël, Hi, > I'm sorry that I did not include a warm welcoming statement in my last > mail. I'm happy about everybody who is interested in Debian and even > considers doing packaging work. I've found a community of great > professionals, friendly people and extraordinary personalities among > Debian's contributors. No problem :-) > I'm looking forward to hear more of you or meet you at a free software > event, e.g. next year's debconf in Switzerland? I don't think: it's a bit far, and anyway, i dont speak english well enough to go to conferences in english :-p Regards, Mickaël Raybaud-Roig -- 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/CADx5VdpvE3Mt9hAYC_rkhPNWiGi=3ZUXWDUFQC-QMxHx4+=a...@mail.gmail.com
Re: [Pkg-sysvinit-devel] Future of update-rc.d in wheezy+1
On Wed, 27 Jun 2012, Roger Leigh wrote: > On Wed, Jun 27, 2012 at 04:39:38PM +0200, Bernd Zeimetz wrote: > > On 06/27/2012 03:46 PM, Alexander Wirt wrote: > > > On Wed, 27 Jun 2012, Paul Wise wrote: > > > > > >> On Wed, Jun 27, 2012 at 6:27 PM, Petter Reinholdtsen wrote: > > >> > > >>> Yes. See http://bugs.debian.org/539591 >, > > >>> http://bugs.debian.org/573004 > and the source of insserv, where > > >>> a patch to do this was created and included by Kel. The patch has > > >>> been available for more than two years. > > >> > > >> Hmm, no upload in those two years either. Is file-rc still maintained at > > >> all? > > > It is. But more or less in "no-new-features" mode. > > > > > > Implementing the insserv stuff is wishlist for me. Even when I now get > > > forced into it. > > I don't think there's any question of "forcing", but encouraging > file-rc to retain compatibility with the init scripts being used by the > distribution. It looks like the patches are there, they just need > testing. If file-rc could have this in place for wheezy, that would > be highly desirable, so that we can work on deprecating runlevel > sequence numbers in wheezy+1. Nope, there is an experimental patch for insserv to print out sequence numbers, to get this working I first have to build my own insserv. And the whole file-rc part is - beside of some ideas in my mind - missing. So its unlikely to get this working unless insserv (for the patch) and file-rc get a freeze exception. Alex -- 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/20120628060233.gf6...@snow-crash.org
Re: Introducing http.debian.net, Debian's mirrors redirector
On Tuesday 26 June 2012 05:15:00 shirish शिरीष wrote: [...] > As can be seen pdiffs are generated if you use the same server. There are _no_ pdiffs for stable. For testing and sid, there are and they are used even if you use http.d.n. > > Unless the files really changed, the Last-Modified-Since headers should > > have prevented the download. Will have to check if they are correctly > > preserved, it might be that. I haven't looked at the code, but from a pcap, it seems APT isn't sending the I-M-S header, even to http.d.n. It does, however, correctly send it for files such as Release.gpg, even to the redirected host. APT guys: perhaps someone of you have an idea as to what is happening? Running apt-get update twice in a row, using http.d.n, and stable, will result in the Packages file being downloaded both times. Even if unchangeed. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- 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/201206280055.13756.geiss...@debian.org
Re: proposed sgml-base 1.16+nmu4 fixing #676717 and #678902
Helmut Grohne writes ("proposed sgml-base 1.16+nmu4 fixing #676717 and
#678902"):
> Here is my next attempt to fixing #676717 and #678902.
>
> I incorporated the parser Jakub Wilk proposed and tested it on a variety
> of catalog files. See the discussion on #676717 for why update-catalog
> is starting to parse catalog files.
>
> In addition I added a Pre-Dependency on dpkg >= 1.16.4 to close #678902.
> Which highlights that the fixed dpkg trigger bug #675613, #676061,
> #676062, #676107, #676118, #676122 still shows up. As per policy section
> 7.2 I raise this Pre-Depends on -devel.
>
> So the attached NMU is to fix all the known issues that have come up as
> a result of fixing #88010. Comments welcome.
I'm not convinced that a Pre-Depends is the best answer here. I think
a better answer would be for the new dpkg to activate all file
triggers when it first starts, and for sgml-base to simply use
Depends.
Ian.
--
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/20459.44532.500373.64...@chiark.greenend.org.uk
Re: yum 3.4.x failing: I need some help
Hi Thomas, On Wed, Jun 27, 2012 at 11:53 AM, Thomas Goirand wrote: > Hi, > > Since March the 1st, I had Yum 3.4.3-1 ready in my Git repository. But I > didn't upload the new version of yum because of an issue with the new > version. > > It seemed to be working, eg, I could bootstrap a CentOS 6 distro in a > chroot, just like you would with yum 3.2.x. And the resulting CentOS > distro seem to work. But at the end of the bootstraping process, yum > does a python stack dump: > > [...] > > FYI, what I'm doing is using this script (also available in dtc-xen in > Debian): > http://git.gplhost.com/gitweb/?p=dtc-xen.git;a=blob;f=src/dtc_install_centos;h=f06a05c89fb61c10cc883031afa515812db92c6c;hb=4a0a7801aa6dfa155e735dcb1045e2828066d8c9 > > I use the script like this: > mkdir /tmp/centos6 > ./dtc_install_centos /tmp/yumtemp /tmp/centos6 I ran this script and got back the same results. The difference seems to be that rpm has one definition of the path to the rpm database, this is defined by the %_dbpath configuration variable, and yum 3.4 hardcodes the path to be "/var/lib/rpm" in a few places (git grep rpmdbfname). On Debian the default value of %_dbpath is $HOME/.rpmdb, see #551669. However, for building a chrooted system in this manner you really *do* want %_dbpath to be /var/lib/rpm, because that's what the configuration will be when you chroot in. I don't know if there is a way to pass this variable into rpm via the yum command-line, but I was able to get this script working by temporarily creating /root/.rpmmacros with the line: %_dbpath /var/lib/rpm > If anyone has time to look into the issue and help me, that'd be really > great: I would then upload version 3.4.x in experimental (since I don't > want to introduce too much change just few days before the freeze, and > that v3.2 does the job too ...). The Git with v 3.4 is here: > Vcs-Browser: http://git.debian.org/?p=users/zigo/yum.git > Vcs-Git: http://git.debian.org/git/users/zigo/yum.git > > the branch to use is "debian-sid" even though I plan to upload that to > experimental. > > Last, I wouldn't be against having a co-maintainer. I'm not at all a > heavy yum user myself, I just use it for bootstrapping CentOS 6 in Xen > VMs when it's a customer's requirement. I took over maintainership only > because the package was left unmaintained and broken. I'd be interested in working with you, I've recently been doing a bit with rpm and yum on Debian. You can get back to me off-list if you want to talk about it. -- mike -- 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/cad6ldlkwasq-xnnpsnp2nt7gxbwow-bpzhmvs+5irctbqcw...@mail.gmail.com
Re: [RFC] Add upstream VCS info to control file
On Thu, Jun 28, 2012 at 7:47 AM, Andrew Shadura wrote: > I wonder why not use #-syntax, just like hg does: > > Vcs-Qux: quux://host.org/path/to/repo#debian/unstable git does not support that, seems it doesn't know about the # character: $ git clone 'git://anonscm.debian.org/anonscm.debian.org/openstack/nova.git#debian/unstable' Cloning into 'unstable'... fatal: The remote end hung up unexpectedly -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6H4=7fv8ql0f5px2muvnxspufugeq1oosf0cp2u2nc...@mail.gmail.com
ITP: qemplayer -- File-manager-like GUI front-end to MPlayer
Package: wnpp Severity: wishlist Owner: William Brana * Package name: qemplayer Version : 12.5 Upstream Author : William Brana * URL : http://sourceforge.net/projects/qemplayer/ * License : GPL Programming Lang: C++ Description : File-manager-like GUI front-end to MPlayer File-manager-like GUI front-end to MPlayer -- 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/CAJ7jCmmzHmeH6G+5j52quJzLk-Qt7EfzO9iqnk4OP+u=jmp...@mail.gmail.com
Re: Get a FREE 2-Way Motorola Pager.
I will like to get a free pager Samuel Reames IV p.o box 541 Darien,ga 31305
Re: [RFC] Add upstream VCS info to control file
Hello, On Thu, 14 Jun 2012 17:30:51 -0400 James McCoy wrote: > Since devscripts 2.11.7, you can do this: > Vcs-Git: git://anonscm.debian.org/anonscm.debian.org/openstack/nova.git -b > debian/unstable > I thought the patch that added that also updated the documentation, > but it looks like documentation still needs to be added. I wonder why not use #-syntax, just like hg does: Vcs-Qux: quux://host.org/path/to/repo#debian/unstable -- WBR, Andrew signature.asc Description: PGP signature
Re: [Pkg-sysvinit-devel] Future of update-rc.d in wheezy+1
On Wed, Jun 27, 2012 at 04:39:38PM +0200, Bernd Zeimetz wrote: > On 06/27/2012 03:46 PM, Alexander Wirt wrote: > > On Wed, 27 Jun 2012, Paul Wise wrote: > > > >> On Wed, Jun 27, 2012 at 6:27 PM, Petter Reinholdtsen wrote: > >> > >>> Yes. See http://bugs.debian.org/539591 >, > >>> http://bugs.debian.org/573004 > and the source of insserv, where > >>> a patch to do this was created and included by Kel. The patch has > >>> been available for more than two years. > >> > >> Hmm, no upload in those two years either. Is file-rc still maintained at > >> all? > > It is. But more or less in "no-new-features" mode. > > > > Implementing the insserv stuff is wishlist for me. Even when I now get > > forced into it. I don't think there's any question of "forcing", but encouraging file-rc to retain compatibility with the init scripts being used by the distribution. It looks like the patches are there, they just need testing. If file-rc could have this in place for wheezy, that would be highly desirable, so that we can work on deprecating runlevel sequence numbers in wheezy+1. > So might be this could avoided if we switch to something more modern > like openrc as discussed some weeks ago here - I think the main reason > file-rc edxists is because its much more easy to maintain than all the > other crap^Winit systems (including insserv) floating around. The openrc runscript format is certainly a bit nicer than the LSB header, but at the same time has some disadvantages. With the LSB header/insserv setup, we can read all the headers and have a dependency graph for all the scripts. But when you run a script by hand, or with invoke-rc.d, it can't satisfy dependencies at that point--it's only at the level of /etc/init.d/rc for runlevel changes. OpenRC OTOH has no global view but can resolve dependencies iteratively when running a script directly. Having both would be nice, which is what systemd/upstart give us. I'm still following OpenRC stuff, though I've not had time to get involved directly yet. The main point preventing us adopting it is lack of support for LSB dependencies, which would make upgrades rather painful. We could possibly address this by autogeneration of runscript wrappers for LSB scripts. Ideally, I'd like for OpenRC to gain a high level dependency graph view of the system, but it doesn't look like this is a design that would be particularly popular with OpenRC upstream. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120627215404.gn9...@codelibre.net
Apper instead of Synaptic for KDE (was Re: Mostly solved (was Re: Filed (Re: Preinstalled package manager(s) for PCs (wheezy))))
Hi Matthias, On 2012-06-27 14:54, Matthias Klumpp wrote: Hi! How odd that I didn't notice that bug... (I'm the GPK/PK maintainer) Well, I think pulling in Synaptic on KDE might be a bad idea, probably KDE desktop packages should pull in Apper instead, a KDE package manager based on PackageKit and fully integrated into the KDE desktop. It does not provide all functions of Synaptic, but for most users it will be good enough and KDE can avoid pulling in many GNOME packages. Synaptic is at best just a little GNOME-ish, beyond its GTK-ness. In reality, installing Synaptic would install just a little more than Apper - perhaps. Apper probably does integrate with KDE, but this is a small advantage compared to the difference in maturity. I wouldn't be strongly against installing Apper by default, but replacing Synaptic is a bigger challenge. [...] -- 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/4feb7e59.7030...@gmail.com
Re: Bug#679236: O: ckport -- portability analysis and security checking tool
Le mercredi 27 juin 2012 22:22:17, Ian Jackson a écrit :
> Philipp Schafft writes ("Bug#679236: O: ckport -- portability analysis and
security checking tool"):
> > The package as made hardy useful by Ron Lee's personal vendetta against
> > me.
>
> I searched a bit and AFAICT this is a reference to these threads:
> bugs.debian.org/674634
> http://lists.debian.org/debian-release/2012/06/msg00388.html
> http://lists.keep-cool.org/pipermail/announce/2012-May/86.html
>
> From
> http://packages.qa.debian.org/c/celt.html
> I see that Ron Lee is indeed the maintainer of celt.
>
> It seems to me from reading these conversations that Ron has no
> vendetta against you. That kind of accusation is totally
> inappropriate.
>
> Ron does indeed have something against the package celt, and his
> explanations make perfect sense to me. That is, he appears to be
> right. He is also doing, AFAICT, the right thing.
>
> I think NMUing the rdepends of celt is the right thing to do, if it is
> necessary. (That is, if they haven't already been updated to turn off
> celt.)
What is the link between celt and ckport? I mean, why does this orphaning
message refers (implicitely) to celt?
>
> Ian.
Anyway, I didn't know this package and it seems interesting. I'd be happy to
adopt this package but since I'm quite busy now it wouldn't make any sense to
adopt it now. I'll add a bookmark for it and will adopt it in september if
nobody does before.
Best regards,
Thomas Preud'homme
signature.asc
Description: This is a digitally signed message part.
Re: Bug#679236: O: ckport -- portability analysis and security checking tool
Philipp Schafft writes ("Bug#679236: O: ckport -- portability analysis and
security checking tool"):
> The package as made hardy useful by Ron Lee's personal vendetta against me.
I searched a bit and AFAICT this is a reference to these threads:
bugs.debian.org/674634
http://lists.debian.org/debian-release/2012/06/msg00388.html
http://lists.keep-cool.org/pipermail/announce/2012-May/86.html
From
http://packages.qa.debian.org/c/celt.html
I see that Ron Lee is indeed the maintainer of celt.
It seems to me from reading these conversations that Ron has no
vendetta against you. That kind of accusation is totally
inappropriate.
Ron does indeed have something against the package celt, and his
explanations make perfect sense to me. That is, he appears to be
right. He is also doing, AFAICT, the right thing.
I think NMUing the rdepends of celt is the right thing to do, if it is
necessary. (That is, if they haven't already been updated to turn off
celt.)
Ian.
--
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/20459.27513.16145.69...@chiark.greenend.org.uk
Re: cross-build-essential
On Wed, 27 Jun 2012 20:04:26 +0100 Wookey wrote: > A bit of background here for those who aren't following all the details: > > We are working towards having cross-compilers in the archive. The plan > is for those toolchains to use multiarch so that the existing > libc: linux-libc-dev: libgcc1: etc packages in the > archive are used by the cross-toolchains, rather than being rebuilt > and renamed as foo-cross packages (where practical). ... this is a pre-requisite for restarting work on Emdebian Crush after Wheezy which will extend Embedded Debian to offer a Debian system without coreutils, with a rebuilt busybox and likely without perl. The premise will be to only cross-build the packages which need functional changes and pull the rest from Emdebian Grip. (As a special-case, partial archive, packages for Emdebian Crush will stay on emdebian.org servers/mirrors.) So this is a very welcome development. Unlike the one-off release of Crush for the old ARM port based on Lenny, Multiarch should be capable of delivering support for multiple architectures - probably 4. Where packages are changed for Crush, we'll start using -crush suffixes to source package names. (e.g. busybox-crush, cairo-crush). http://www.emdebian.org/trac/browser/current/target (Those versions are old but the idea is the same.) I'm also hoping that the existing QtEmbedded build can be provided, somehow. http://lists.debian.org/debian-embedded/2011/10/msg00023.html Integrating these changes into the relevant Debian packages via build-options is a different question which can also be broached @DebConf. > This work, combined with sbuild's already-in-wheezy config to set up > multiarch and install crossbuild-essential-, and the forthcoming > -pkg-config packages, should make for painless cross-building > (modulo suitable multiarch metadata in packages and packages that are > actually capble of being cross-built). (Just one of the reasons to only cross-build for Crush what we actually need to modify - bootstrapping will need wider coverage.) > I'll give a more complete summary of current state at debconf. Anyone wanting to talk about the details of creating a very small Debian distribution for specific targets can also talk to myself or Wookey at DebConf. This can be part of the proposed Emdebian BoF. A new version of Crush using Multiarch cross-compilers should get us back to a sub 32Mb install of a Debian system, maybe sub 20Mb. (Sub 16Mb means using uClibc which is a harder problem.) Anyone with ideas on how to prune the iconv files normally provided with eglibc:libc6? Find me/Wookey @/during DebConf. http://www.emdebian.org/emdebian/flavours.html -- Neil Williams = http://www.linux.codehelp.co.uk/ pgptQRJ15nfIR.pgp Description: PGP signature
proposed sgml-base 1.16+nmu4 fixing #676717 and #678902
Here is my next attempt to fixing #676717 and #678902.
I incorporated the parser Jakub Wilk proposed and tested it on a variety
of catalog files. See the discussion on #676717 for why update-catalog
is starting to parse catalog files.
In addition I added a Pre-Dependency on dpkg >= 1.16.4 to close #678902.
Which highlights that the fixed dpkg trigger bug #675613, #676061,
#676062, #676107, #676118, #676122 still shows up. As per policy section
7.2 I raise this Pre-Depends on -devel.
So the attached NMU is to fix all the known issues that have come up as
a result of fixing #88010. Comments welcome.
Please CC my in replies as I am not subscribed to -devel.
Helmut
diff -Nru sgml-base-1.26+nmu3/debian/changelog
sgml-base-1.26+nmu4/debian/changelog
--- sgml-base-1.26+nmu3/debian/changelog2012-05-28 21:11:52.0
+0200
+++ sgml-base-1.26+nmu4/debian/changelog2012-06-27 21:04:29.0
+0200
@@ -1,3 +1,16 @@
+sgml-base (1.26+nmu4) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * update-catalog --update-super ignores catalogs referencing non-existent
+files. (Closes: #676717) Thanks to Jakub Wilk for contributing the parser.
+ * Remove warning about rebuilding packages as it may confuse users.
+ * Quieten update-catalog during trigger and postinst, to avoid warnings for
+packages in "rc" state.
+ * Pre-Depend on dpkg >= 1.16.4 (Closes: #678902). Removed dependency on
+dpkg >= 1.14.18. sgml-base highlights a bug in dpkg's trigger processing.
+
+ -- Helmut Grohne Thu, 21 Jun 2012 16:09:07 +0200
+
sgml-base (1.26+nmu3) unstable; urgency=low
* Non-maintainer upload.
diff -Nru sgml-base-1.26+nmu3/debian/control sgml-base-1.26+nmu4/debian/control
--- sgml-base-1.26+nmu3/debian/control 2012-05-28 13:58:23.0 +0200
+++ sgml-base-1.26+nmu4/debian/control 2012-06-27 20:38:49.0 +0200
@@ -11,7 +11,8 @@
Priority: optional
Architecture: all
Conflicts: sgml-data (<= 0.02), sgmltools-2 (<= 2.0.2-4)
-Depends: ${perl:Depends}, dpkg (>= 1.14.18)
+Depends: ${perl:Depends}
+Pre-Depends: dpkg (>= 1.16.4)
Suggests: sgml-base-doc
Description: SGML infrastructure and SGML catalog file support
This package creates the SGML infrastructure directories and provides
diff -Nru sgml-base-1.26+nmu3/debian/sgml-base.postinst
sgml-base-1.26+nmu4/debian/sgml-base.postinst
--- sgml-base-1.26+nmu3/debian/sgml-base.postinst 2012-05-28
13:58:23.0 +0200
+++ sgml-base-1.26+nmu4/debian/sgml-base.postinst 2012-06-22
17:22:31.0 +0200
@@ -61,12 +61,12 @@
fi
## --
-update-catalog --update-super
+update-catalog --quiet --update-super
ln -sf /var/lib/sgml-base/supercatalog /etc/sgml/catalog
fi
if [ "$1" = "triggered" ]
then
-update-catalog --update-super
+update-catalog --quiet --update-super
fi
## --
diff -Nru sgml-base-1.26+nmu3/tools/update-catalog
sgml-base-1.26+nmu4/tools/update-catalog
--- sgml-base-1.26+nmu3/tools/update-catalog2012-05-28 21:11:52.0
+0200
+++ sgml-base-1.26+nmu4/tools/update-catalog2012-06-27 21:04:45.0
+0200
@@ -4,6 +4,7 @@
## --
## Copyright (c) 2001-2004 Ardo van Rangelrooij
## Copyright (c) 2012 Helmut Grohne
+## Copyright (c) 2012 Jakub Wilk
##
## This is free software; see the GNU General Public Licence version 2
## or later for copying conditions. There is NO warranty.
@@ -138,8 +139,6 @@
print "Invocation of dpkg-trigger failed with status $?.\n";
print "Forcing update of the super catalog...\n";
&update_super;
-} else {
-print "update-catalog: Please rebuild the package being set up with a
version of debhelper fixing #477751.\n";
}
}
elsif ( $add )
@@ -240,17 +239,71 @@
}
## --
+# Reference: https://www.oasis-open.org/specs/a401.htm
+sub check_catalog($)
+{
+my($catalog)=shift;
+my $base = $catalog;
+$base =~ s,/[^/]+$,,;
+my $catalog_tokens = qr{
+( (?: \s+ | -- .*? --)+ # whitespace and comments
+| ' .*? ' | " .*? " # literal
+| \S+ # other tokens
+)
+}sx;
+unless(open(PKGCAT, "<", $catalog)) {
+print "Warning: Ignoring unreadable catalog file `$catalog'.\n"
+unless $quiet;
+return 0;
+};
+local $/;
+my $contents = ;
+close PKGCAT;
+my $prevtoken = 0;
+while ($contents =~ m/$catalog_tokens/g) {
+my $token = $1;
+if ($prevtoken) {
+next if $token =~ m/^\s|^--/;
+$token =~ s/^(['"])(.*)\1$/$2/;
+if($prevtoken eq 'base') {
+$base = $token;
+} elsif($prevtoken eq 'catalog') {
+my $path;
+if($token =~ m,^/,)
Re: cross-build-essential
+++ Wookey [2012-01-19 14:32 +]: > +++ Neil Williams [2012-01-19 13:02 +]: > > On Thu, 19 Jan 2012 12:10:28 + > > Wookey wrote: > > > > > I've thought for a long time that a package like build-essential for > > > cross-building would be a really good idea. > > > > +1 > > > > It should probably depend on build-essential itself as a starting point. > > I suppose so. You won't get far without that. OK, there has been progress in this area. Thanks to Patrick McDermmot (GSOC student) we have a patch to add support to build-essential for a crossbuild-essential- packages. http://odin1.pehjota.net/~pj/debian-bootstrap/build-essential/ The initial patches there add crossbuild-essential packages to the build-essential source, which is easy to do but leads to some questions. 1) Some of the packages that cross-build-essential depends on (cross-compiler packages) are not yet in the archive, and won't be in wheezy. That means that these packages will not be installable and thus will not migrate from unstable until the cross-compiler packages do arrive. That seems like a very good reason to keep cross-build-essential as a separate source package for now, available from emdebian.org, along with the toolchains. Anyone disagree? 2) Is the build-essential maintainer happy to include this code once the resulting packages _are_ installable? Or in the same way that he (doko) likes to keep the cross-toolchains separate should we keep them separate for the forseeable future? Does that change once everything is built in the archive? Is the maintainer happy with the implementation above? It uses the existing machinery of build-essential to be compatible but is still somewhat intrusive. A bit of background here for those who aren't following all the details: We are working towards having cross-compilers in the archive. The plan is for those toolchains to use multiarch so that the existing libc: linux-libc-dev: libgcc1: etc packages in the archive are used by the cross-toolchains, rather than being rebuilt and renamed as foo-cross packages (where practical). Prototypes of those packages for i386 and amd64 are now available at: http://emdebian.org/~thibg/repo/ You can't install them without having the modified dpkg (also in that repo) which allows depends: (i.e a specific arch) syntax. We are hopeful that that dpkg change will just scrape into wheezy so that these toolchains will be easily usable without having to have a nobbled dpkg to hand. This work, combined with sbuild's already-in-wheezy config to set up multiarch and install crossbuild-essential-, and the forthcoming -pkg-config packages, should make for painless cross-building (modulo suitable multiarch metadata in packages and packages that are actually capble of being cross-built). I'll give a more complete summary of current state at debconf. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- 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/20120627190426.gg26...@dream.aleph1.co.uk
Re: Bug#679235: RFA: animals -- Traditional AI animal guessing engine using a binary tree DB
On Wed, Jun 27, 2012 at 07:47:43PM +0100, Ben Hutchings wrote: > > That said, there was this bug report saying "We'll RM celt anytime soon, > > so don't use it anymore" and that's it. > Surely you were aware that CELT was experimental and this was due > to happen? Yep. And upstream code is cluttered with #if CELT_0_5 #elif CELT_0_7 #else #endif so I appreciate the arrival of opus. > CELT never had a stable bitstream format, so this sort of codec > compatibility issue could occur even if all parties had some version > of it. > > It's now dead upstream, and support for any version of CELT would have > become less and less useful during the lifetime of wheezy. Nothing to argue with that, that's why I dropped CELT support immediately. Cheers -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver -- 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/20120627185729.gw6...@ltw.loris.tv
Re: Mostly solved (was Re: Filed (Re: Preinstalled package manager(s) for PCs (wheezy)))
Hi! How odd that I didn't notice that bug... (I'm the GPK/PK maintainer) Well, I think pulling in Synaptic on KDE might be a bad idea, probably KDE desktop packages should pull in Apper instead, a KDE package manager based on PackageKit and fully integrated into the KDE desktop. It does not provide all functions of Synaptic, but for most users it will be good enough and KDE can avoid pulling in many GNOME packages. About the GNOME side: I already splitted up the GNOME-PackageKit package, but I didn't upload the changes to unstable. Splitting the package means that you will be able to install some components of GPK (the update manager, software manager and helper tools) independently from each other. This might be useful in the current situation. (so only the parts of GPK which are needed are present and people can use Synaptic for other things. E.g. the update-manager can bes used with Synaptic, and people don't have two package managers installed) Don't think uploading the splitted version at time would be a good idea, so I think the current solution is okay, if the GNOME team wants it. (which seems to be the case) Thanks for the attention :-) Cheers, Matthias 2012/6/27 Filipus Klutiero : > On 2012-04-05 20:20, Filipus Klutiero wrote: >> >> This didn't generate as much feedback as I hoped, but I filed a ticket >> asking task-desktop to install synaptic: >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667703 > > > Joey Hess changed tasks to bring Synaptic in KDE, LXDE and Xfce. Only the > GNOME situation is unchanged (Josselin Mouette alleged that gnome already > pulls in Synaptic). > tasksel 3.10 should migrate to testing shortly. > > > -- > 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/4feb27ee.7060...@gmail.com > -- 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/CAKNHny8vr06Ug7yX-3HfVxTSKdNzDxiDBUe67rfgGmF0=5t...@mail.gmail.com
Re: Bug#679235: RFA: animals -- Traditional AI animal guessing engine using a binary tree DB
On Wed, Jun 27, 2012 at 08:05:13PM +0200, Adrian Knoth wrote: > On Wed, Jun 27, 2012 at 05:33:41PM +, The Fungi wrote: > > > > what??? -v please. > > Presumably a reference to http://bugs.debian.org/674634 . > > Speaking of which, I also had to disable CELT support in jackd1 and > jackd2, since none of the upstreams has opus code ready. > > That said, there was this bug report saying "We'll RM celt anytime soon, > so don't use it anymore" and that's it. Surely you were aware that CELT was experimental and this was due to happen? > We can live without it in jackd1 and jackd2, and maybe some day, > somebody will port it to opus to regain the missing functionality. > > I wasn't involved in the mumble discussion, but got some complaints from > users saying they can no longer join conference calls. CELT never had a stable bitstream format, so this sort of codec compatibility issue could occur even if all parties had some version of it. > Long story short: this was no transition, it was "EOL in 3, 2, 1, now". > > I wasn't exactly happy about it, but at least it wasn't crucial for > jackd1/2. If there is consensus that CELT *will* be in wheezy, I'd use > the remaining time and re-enable it in jackd1/jackd2 again. It's now dead upstream, and support for any version of CELT would have become less and less useful during the lifetime of wheezy. Also, as I recall, there was an important security issue with no fix available. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20120627184743.gx2...@decadent.org.uk
Re: yum 3.4.x failing: I need some help
hi, > Since March the 1st, I had Yum 3.4.3-1 ready in my Git repository. But I > didn't upload the new version of yum because of an issue with the new > version. > > It seemed to be working, eg, I could bootstrap a CentOS 6 distro in a > chroot, just like you would with yum 3.2.x. And the resulting CentOS > distro seem to work. But at the end of the bootstraping process, yum > does a python stack dump: > > Traceback (most recent call last): [...] > OSError: [Errno 2] No such file or directory: > '/tmp/centos6/var/lib/rpm/Packages' that shows your issue in two lines - did you look if that file actually exists or resides somewhere else? Cheers, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4feb5321.60...@bzed.de
Re: scim and assorted packages
On Wed, 27 Jun 2012 19:30:11 +0200 Toni Mueller wrote: > today I received an email from the FTP masters that a pacakge that is > highly relevant to me, has been pulled from Debian. Which package? scim doesn't seem to have been removed. > I understand that > most folks are now looking at that ibus stuff (which is imho not ready > for prime time, yet), but would like to understand better how a package > with only 1 normal and 2 minor bugs can be pulled, and... how I can stay > at the front of this. Was it due to a dependency which needed to be removed for other reasons. Was this one of the Qt3 related removals? Packages are removed for more reasons than just to close their bugs, RC or not. Abandonware is a common reason for removal. Also, packages are often removed to *avoid* RC bugs when a dependency needs to be removed. There's always a bug report, there's always a delay to try and find someone with the time to update the package before the dependency is removed. > /me tries to carve out some time to aid in scim packaging, which still > has a *much*, *much* wider range of supported languages and scripts than > ibus (saying ibus is a replacement for scim is an euphemism, at best). It's a bit late now to offer help, this close to the freeze. The package can come back into experimental via NEW, if the reasons for the removal are fixed. Then someone would need to do the work of creating a backport after the Wheezy release, after getting the package back into testing (wheezy+1). The notice from the ftp-master will link to the bug report detailing why the package was removed. It would help if you could mention the specific packages and the specific bug reports. http://ftp-master.debian.org/removals.txt Is this the one? [Date: Wed, 27 Jun 2012 16:40:08 +] [ftpmaster: Alexander Reichle-Schmehl] Removed the following packages from unstable: scim-modules-table |0.5.9-1 | amd64, armel, armhf, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc scim-modules-table | 0.5.9-1+b2 | hurd-i386 scim-tables | 0.5.9-1 | source scim-tables-additional |0.5.9-1 | all scim-tables-ja |0.5.9-1 | all scim-tables-ko |0.5.9-1 | all scim-tables-zh |0.5.9-1 | all Closed bugs: 659309 --- Reason --- RoQA; orphand, no upstream, out dated -- Also closing bug(s): 378158 558636 618314 649881 676016 From the #659309 bug report: > scim-tables is SCIM's table engine with quite a few table data files > along with it, which serves some CJK users. It has been several months > after orphaning the package and nobody stands up to continue to > maintain it. Users should move to other input method framework > including ibus and fcitx. There is a so-called new upstream which is > actually gathering random patches from ordinary users, and they aren't > actually "maintain" or do actual improvements. I hereby request for > its removal. That seems a perfectly good reason to remove a package. To stay up to date with such things, watch the WNPP messages on this list. This package was orphaned Fri, 10 Feb 2012 09:17:05 - so it's been over 4 months and nobody came up with the time to maintain it. There's also wnpp-alert in the devscripts package. The orphaning bug was reassigned to ftp for removal on Sun, 6 May 2012. If this isn't the package you're thinking about, then the same methods will show the detail of the package itself. Finally, removals only affect those wanting to install the package for the first time - if you already have it installed, your installation isn't affected. The packages and dependencies may, of course, change but as the package is orphaned, it's unlikely that this would be fixed if the package was retained - indeed it just makes it likely that the package would be removed at that point as uninstallable and likely FTBFS which are RC bugs. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpN07vw7o9xx.pgp Description: PGP signature
Re: Bug#679235: RFA: animals -- Traditional AI animal guessing engine using a binary tree DB
On Wed, Jun 27, 2012 at 05:33:41PM +, The Fungi wrote: > > what??? -v please. > Presumably a reference to http://bugs.debian.org/674634 . Speaking of which, I also had to disable CELT support in jackd1 and jackd2, since none of the upstreams has opus code ready. That said, there was this bug report saying "We'll RM celt anytime soon, so don't use it anymore" and that's it. We can live without it in jackd1 and jackd2, and maybe some day, somebody will port it to opus to regain the missing functionality. I wasn't involved in the mumble discussion, but got some complaints from users saying they can no longer join conference calls. Long story short: this was no transition, it was "EOL in 3, 2, 1, now". I wasn't exactly happy about it, but at least it wasn't crucial for jackd1/2. If there is consensus that CELT *will* be in wheezy, I'd use the remaining time and re-enable it in jackd1/jackd2 again. Adr"no strong feelings either way"ian -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver -- 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/20120627180513.gt6...@ltw.loris.tv
Re: Bug#679235: RFA: animals -- Traditional AI animal guessing engine using a binary tree DB
Hi, On Mittwoch, 27. Juni 2012, The Fungi wrote: > Presumably a reference to http://bugs.debian.org/674634 . reminds me indeed on the hostility in the "43 window managers"-thread recently here :/ agressive QA is wrong, IMO. Strong QA totally cool OTOH. But those are not the same... cheers, Holger -- 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/201206271209.30817.hol...@layer-acht.org
Re: scim and assorted packages
On Wed, Jun 27, 2012 at 07:30:11PM +0200, Toni Mueller wrote: > today I received an email from the FTP masters that a pacakge that is > highly relevant to me, has been pulled from Debian. Why not name the package in question? It does not appear to be scim, which is what you wrote in your subject line. Looking at the removal log, I see scim-tables was removed today. I assume you are referring to it. > how I can stay at the front of this. The package was orphaned in February and removal was requested in May[1]. Thus there was plenty of time to "stay at the front of this" if you had wished to. I'm pretty sure the PTS[2] shows such actions prominently, and it's a good idea to visit the PTS page of any package you really care about every once in a while. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659309 [2] http://packages.qa.debian.org/s/scim-tables.html I believe it's possible to reintroduce the package if there's a willing and able maintainer, but it'd need to go through NEW again -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ -- 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/20120627175338.ga5...@kukkaseppele.kaijanaho.fi
Re: Bug#679235: RFA: animals -- Traditional AI animal guessing engine using a binary tree DB
On 2012-06-27 11:11:12 -0600 (-0600), Holger Levsen wrote:
> what??? -v please.
[...]
Presumably a reference to http://bugs.debian.org/674634 .
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }
--
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/20120627173340.gj1...@yuggoth.org
scim and assorted packages
Hi, today I received an email from the FTP masters that a pacakge that is highly relevant to me, has been pulled from Debian. I understand that most folks are now looking at that ibus stuff (which is imho not ready for prime time, yet), but would like to understand better how a package with only 1 normal and 2 minor bugs can be pulled, and... how I can stay at the front of this. /me tries to carve out some time to aid in scim packaging, which still has a *much*, *much* wider range of supported languages and scripts than ibus (saying ibus is a replacement for scim is an euphemism, at best). Kind regards, --Toni++ -- 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/20120627173010.ga12...@spruce.wiehl.oeko.net
Re: Bug#679235: RFA: animals -- Traditional AI animal guessing engine using a binary tree DB
Hi, On Mittwoch, 27. Juni 2012, Philipp Schafft wrote: > I request an adopter for the animals package. After the personal vendetta > by Ron Lee against me what??? -v please. > I'm no longer interested in wasting my time for the > Debian project. eeks. not cheering, Holger -- 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/20120627.13226.hol...@layer-acht.org
yum 3.4.x failing: I need some help
Hi, Since March the 1st, I had Yum 3.4.3-1 ready in my Git repository. But I didn't upload the new version of yum because of an issue with the new version. It seemed to be working, eg, I could bootstrap a CentOS 6 distro in a chroot, just like you would with yum 3.2.x. And the resulting CentOS distro seem to work. But at the end of the bootstraping process, yum does a python stack dump: Traceback (most recent call last): File "/usr/bin/yum", line 29, in yummain.user_main(sys.argv[1:], exit_code=True) File "/usr/share/yum-cli/yummain.py", line 288, in user_main errcode = main(args) File "/usr/share/yum-cli/yummain.py", line 140, in main result, resultmsgs = base.doCommands() File "/usr/share/yum-cli/cli.py", line 440, in doCommands return self.yum_cli_commands[self.basecmd].doCommand(self, self.basecmd, self.extcmds) File "/usr/share/yum-cli/yumcommands.py", line 214, in doCommand return base.installPkgs(extcmds) File "/usr/share/yum-cli/cli.py", line 717, in installPkgs self.install(pattern=arg) File "/usr/lib/python2.7/dist-packages/yum/__init__.py", line 3580, in install if (self.rpmdb.searchNames([po.name]) and File "/usr/lib/python2.7/dist-packages/yum/rpmsack.py", line 1180, in searchNames returnList.extend(self._search(name=name)) File "/usr/lib/python2.7/dist-packages/yum/rpmsack.py", line 1246, in _search po = self._makePackageObject(hdr, idx) File "/usr/lib/python2.7/dist-packages/yum/rpmsack.py", line 1272, in _makePackageObject self._cached_rpmdb_mtime = os.path.getmtime(rpmdbfname) File "/usr/lib/python2.7/genericpath.py", line 54, in getmtime return os.stat(filename).st_mtime OSError: [Errno 2] No such file or directory: '/tmp/centos6/var/lib/rpm/Packages' FYI, what I'm doing is using this script (also available in dtc-xen in Debian): http://git.gplhost.com/gitweb/?p=dtc-xen.git;a=blob;f=src/dtc_install_centos;h=f06a05c89fb61c10cc883031afa515812db92c6c;hb=4a0a7801aa6dfa155e735dcb1045e2828066d8c9 I use the script like this: mkdir /tmp/centos6 ./dtc_install_centos /tmp/yumtemp /tmp/centos6 then the error above appears. I asked upstream author, and they couldn't reply to me strait away with a way to fix: http://old.nabble.com/Error-bootstraping-CentOS-with-Yum-from-Debian-SID-td33421825.html If anyone has time to look into the issue and help me, that'd be really great: I would then upload version 3.4.x in experimental (since I don't want to introduce too much change just few days before the freeze, and that v3.2 does the job too ...). The Git with v 3.4 is here: Vcs-Browser: http://git.debian.org/?p=users/zigo/yum.git Vcs-Git: http://git.debian.org/git/users/zigo/yum.git the branch to use is "debian-sid" even though I plan to upload that to experimental. Last, I wouldn't be against having a co-maintainer. I'm not at all a heavy yum user myself, I just use it for bootstrapping CentOS 6 in Xen VMs when it's a customer's requirement. I took over maintainership only because the package was left unmaintained and broken. Cheers, Thomas -- 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/4feb2c8e.6050...@debian.org
Mostly solved (was Re: Filed (Re: Preinstalled package manager(s) for PCs (wheezy)))
On 2012-04-05 20:20, Filipus Klutiero wrote: This didn't generate as much feedback as I hoped, but I filed a ticket asking task-desktop to install synaptic: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667703 Joey Hess changed tasks to bring Synaptic in KDE, LXDE and Xfce. Only the GNOME situation is unchanged (Josselin Mouette alleged that gnome already pulls in Synaptic). tasksel 3.10 should migrate to testing shortly. -- 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/4feb27ee.7060...@gmail.com
Re: Lintian warning: hardening-no-fortify-functions & version numbering
On Sun, Jun 24, 2012 at 11:29:56AM +0100, Lars Wirzenius wrote: > On Sat, Jun 23, 2012 at 03:27:07PM -0700, Russ Allbery wrote: > > CFLAGS is an old, long-standing make thing. CPPFLAGS is newer and I > > believe was introduced by Autoconf > > I don't know the history of CPPFLAGS. It's possible it was introduced by > Autoconf. However, it is now embedded into the implicit rules of GNU Make, > so every Makefile that doesn't override the rule for compiling a .c file > to a .o file uses CPPFLAGS. I peeked around the Internet a bit, in the hope that adding some more fact into this pointless discussion will make it stop. CPPFLAGS was used by the GNU coding standards at least since January 11, 1993, which is when the document was imported into CVS. I failed to find an older copy, but I'm fairly sure the coding standards are older than that. GNU Make documents CPPINFO in Sep 18, 1991. That's about when Autoconf started (and also approximately when the first release of Linux happened; heady times). I think Autoconf is a red herring, whether CPPFLAGS originated there or not. GNU Make supports it, and has done so for _decades_. -- I wrote a book: http://gtdfh.branchable.com/ signature.asc Description: Digital signature
Re: [Pkg-sysvinit-devel] Future of update-rc.d in wheezy+1
On 06/27/2012 03:46 PM, Alexander Wirt wrote: > On Wed, 27 Jun 2012, Paul Wise wrote: > >> On Wed, Jun 27, 2012 at 6:27 PM, Petter Reinholdtsen wrote: >> >>> Yes. See http://bugs.debian.org/539591 >, >>> http://bugs.debian.org/573004 > and the source of insserv, where >>> a patch to do this was created and included by Kel. The patch has >>> been available for more than two years. >> >> Hmm, no upload in those two years either. Is file-rc still maintained at all? > It is. But more or less in "no-new-features" mode. > > Implementing the insserv stuff is wishlist for me. Even when I now get forced > into it. So might be this could avoided if we switch to something more modern like openrc as discussed some weeks ago here - I think the main reason file-rc edxists is because its much more easy to maintain than all the other crap^Winit systems (including insserv) floating around. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4feb1b2a.3080...@bzed.de
Re: [Pkg-sysvinit-devel] Future of update-rc.d in wheezy+1
On Wed, 27 Jun 2012, Paul Wise wrote: > On Wed, Jun 27, 2012 at 6:27 PM, Petter Reinholdtsen wrote: > > > Yes. See http://bugs.debian.org/539591 >, > > http://bugs.debian.org/573004 > and the source of insserv, where > > a patch to do this was created and included by Kel. The patch has > > been available for more than two years. > > Hmm, no upload in those two years either. Is file-rc still maintained at all? It is. But more or less in "no-new-features" mode. Implementing the insserv stuff is wishlist for me. Even when I now get forced into it. Alex -- 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/20120627134633.gc6...@snow-crash.org
Re: [Pkg-sysvinit-devel] Future of update-rc.d in wheezy+1
On Wed, Jun 27, 2012 at 6:27 PM, Petter Reinholdtsen wrote: > Yes. See http://bugs.debian.org/539591 >, > http://bugs.debian.org/573004 > and the source of insserv, where > a patch to do this was created and included by Kel. The patch has > been available for more than two years. Hmm, no upload in those two years either. Is file-rc still maintained at all? -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6foqhovi6zae6yx-cbol81zlxvkujzxcgghvpmntga...@mail.gmail.com
Re: Lintian warning: hardening-no-fortify-functions & version numbering
On 27/06/12 14:20, Ben Hutchings wrote: > On Wed, 2012-06-27 at 14:09 +0300, Serge wrote: >> 2012/6/25 Ben Hutchings wrote: >> BTW, it's interesting that Fedora/CentOS use -Wp,-D_FORTIFY_SOURCE=2 and they use it in CFLAGS/CXXFLAGS. >>> >>> Presumably as a workaround for build systems that do not respect >>> CPPFLAGS. >> >> I actually noticed that because it's "-Wp,-D...", not "-D...". But I guess >> you're right, it's in CFLAGS because many build systems support CFLAGS, >> but only autotools support CPPFLAGS. >> >>> GNU make's implicit rules use CPPFLAGS. If other build systems or >>> overriden rules don't use it, it's a bug. This can of course be >>> worked around in debian/rules. >> >> Well, such argument can be applied to any build system. For example: Cmake >> uses CMAKE_C_FLAGS, but GNU's make does not use it. It's a bug. > > GNU make is the standard build sequencing tool for the GNU system (i.e. > for Debian). CMake and the others probably ought to follow the platform > conventions. > > [...] Actually CMake *does* honour CFLAGS and copies them into CMAKE_C_FLAGS, it doesn't do this for CPPFLAGS though. Look at the other cmake packages how hardening flags are handled there. Something like copying the set CPPFLAGS into CXXFlags or something. >> Talking just about autotools: >> * CPPFLAGS without CFLAGS are used only by ./configure script >> * CPPFLAGS without CFLAGS are used only for some conftests >> * -D_FORTIFY_SOURCE=2 means nothing for those tests >> * -D_FORTIFY_SOURCE=2 does nothing at all without -O2 >> So even for autotools there's no reason to keep -D_FORTIFY_SOURCE=2 in >> a CPPFLAGS variable. It can be easily dropped. > [...] > > I do take the point that it's not obviously useful to separate out > CPPFLAGS. > > Ben. > -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Re: Lintian warning: hardening-no-fortify-functions & version numbering
On Wed, 2012-06-27 at 14:09 +0300, Serge wrote: > 2012/6/25 Ben Hutchings wrote: > > >> BTW, it's interesting that Fedora/CentOS use -Wp,-D_FORTIFY_SOURCE=2 > >> and they use it in CFLAGS/CXXFLAGS. > > > > Presumably as a workaround for build systems that do not respect > > CPPFLAGS. > > I actually noticed that because it's "-Wp,-D...", not "-D...". But I guess > you're right, it's in CFLAGS because many build systems support CFLAGS, > but only autotools support CPPFLAGS. > > > GNU make's implicit rules use CPPFLAGS. If other build systems or > > overriden rules don't use it, it's a bug. This can of course be > > worked around in debian/rules. > > Well, such argument can be applied to any build system. For example: Cmake > uses CMAKE_C_FLAGS, but GNU's make does not use it. It's a bug. GNU make is the standard build sequencing tool for the GNU system (i.e. for Debian). CMake and the others probably ought to follow the platform conventions. [...] > Talking just about autotools: > * CPPFLAGS without CFLAGS are used only by ./configure script > * CPPFLAGS without CFLAGS are used only for some conftests > * -D_FORTIFY_SOURCE=2 means nothing for those tests > * -D_FORTIFY_SOURCE=2 does nothing at all without -O2 > So even for autotools there's no reason to keep -D_FORTIFY_SOURCE=2 in > a CPPFLAGS variable. It can be easily dropped. [...] I do take the point that it's not obviously useful to separate out CPPFLAGS. Ben. -- Ben Hutchings Lowery's Law: If it jams, force it. If it breaks, it needed replacing anyway. signature.asc Description: This is a digitally signed message part
Bug#679265: RFH: libisoburn -- command line ISO-9660 and Rock Ridge manipulation tool
Package: wnpp Severity: normal I request assistance with maintaining the libisoburn package. I currently lack the time to maintain this package alone. This includes a high-level library along with a versatile app called xorriso for burning and image production. It has grown a tremendous amount of options, to the point of being "language" interpreter on its own right, also featuring other program option personalities (like these of mkisofs, cdrecord). This is the hardest part to thoroughly test. Debian-cd image production is in the hands of xorriso, except for the PowerPC images due to lack of ISO9660/HFS(+) support which is currently emerging. Upstream conversations and following upstream VCS are almost a must. Upstream is responsive. The alioth project could be reached at: pkg-libburnia-de...@lists.alioth.debian.org Co-maintainers welcome. The package description is: xorriso is a command line and dialog application, which creates, loads, manipulates, and writes ISO-9660 file system images with Rock Ridge extensions. . It maps file objects from POSIX compliant file systems into Rock Ridge enhanced ISO-9660 file systems and features session-wise manipulation of such file systems. It can load the management information of existing ISO images and write the resulting session to optical medium or as file system objects. . Supported optical media types: - CD-R, CD-RW - DVD-R, DVD-R DL, DVD-RW, DVD+R, DVD+R DL, DVD+RW, DVD-RAM - BD-R, BD-RE . Some interesting features: - Emulation of the mkisofs and cdrecord programs. - Data backup and restore capabilities - compression, ACLs, and filters. - Isohybrid MBR with partition offset - features booting ISOLINUX from USB sticks, or from other devices that appear to PC-BIOS as hard disks. The images carry a conventional partition table for a USB stick; the first partition reports the size of the ISO image, but starts at a non-zero address. It is nevertheless still mountable. - Jigdo Template Export - jigdo representation of the resulting ISO-9660 image, generated on the fly. . Test suite: xorriso source code comes with a release engineering test-suite called `releng', which aims to cover most of the functionality of the xorriso and the underlying libraries of libburn, libisofs, and libisoburn. -- 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/20120627131407.18171.20759.reportbug@sid
Bug#679254: RFH: libisofs -- library to create ISO9660 images
Package: wnpp Severity: normal I request assistance with maintaining the libisofs package. I currently lack the time to maintain this package alone. The major drain of time is following various image specs, following the upstream VCS, and further discussions. One interesting aspect is that libisofs links with libjte in order to produce jigdo representation at the same time while producing the iso image itself (state stable). Further developments are ongoing to produce ISO9660/HFS(+) hybrids, see #630351 for some details, which is also of interest of debian-cd task (currently performed by genisoimage for Debian PowerPC images offered) This would take quite some effort in testing and proving it correct. Upstream is responsive. The alioth project could be reached at: pkg-libburnia-de...@lists.alioth.debian.org Co-maintainers welcome. The package description is: libisofs creates ISO images which can then be burnt with cdrskin or other software. -- 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/20120627130139.17765.29666.reportbug@sid
Bug#679249: RFH: libburn -- library to provide CD/DVD writing functions
Package: wnpp Severity: normal I request assistance with maintaining the libburn package. I currently lack the sufficient time, and burning devices to provide adequate testing of its optical burning capabilities, although the software is in quite mature state. In this case the burning applicaiton is cdrskin. Upstream is responsive. There is an alioth project could be reached at: pkg-libburnia-de...@lists.alioth.debian.org Co-maintainers welcome. The package description is: libburn is a library for reading, mastering and writing optical discs. Supported media are: CD-R, CD-RW, DVD-RAM, DVD+RW, DVD+R, DVD+R/DL, DVD-RW, DVD-R, DVD-R/DL, BD-R, BD-RE. -- 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/20120627124802.17218.26501.reportbug@sid
Re: Bug#679078: ITP: acpi-support-minimal -- minimal acpi scripts
On Jun 27, "Bernhard R. Link" wrote: > I'd prefer to get this fixed in acpi-support-base, but I think you > have made your point very clear that the only purpose of that package is > to not do anything if some power manager is running and that to detect this > perfectly you are totally willing to force anyone to install consolekit > (and thus dbus) who justs wants his system shutting down cleanly when the > power button is pressed. That this is not issue for you at all and that > you do not see any problem in introducing this change 2012-06-21 i.e. > shortly before the freeze. Agreed. The consolekit dependencies are unacceptable for headless servers where you just want the ACPI power button event to work. If fixing acpi-support-base is hard then acpi-support-minimal or acpi-support-server would be just as good. -- ciao, Marco signature.asc Description: Digital signature
Bug#679237: ITP: ecflow -- Work flow controller for running programs based on time or dependencies
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: ecflow Version : 2.0.30 Upstream Author servic...@ecmwf.int * URL : http://software.ecmwf.int/wiki/display/ECFLOW/Home * License : Apache Programming Lang: python, C++ Description : Work flow controller for running programs based on time or dependencies ecFlow is a work flow package that enables users to run a large number of programs ( with dependencies on each other and on time) in a controlled environment. It provides reasonable tolerance for hardware and software failures, combined with good restart capabilities. ecFlow submits tasks(jobs) and receives acknowledgements from tasks when they change status and when they send events, using child commands embedded in the scripts. ecflow stores the relationship between tasks, and is able to submit tasks dependent on triggers. -- 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/20120627111609.21401.26379.report...@ailm.sceal.ie
Re: Lintian warning: hardening-no-fortify-functions & version numbering
2012/6/25 Ben Hutchings wrote: >> BTW, it's interesting that Fedora/CentOS use -Wp,-D_FORTIFY_SOURCE=2 >> and they use it in CFLAGS/CXXFLAGS. > > Presumably as a workaround for build systems that do not respect > CPPFLAGS. I actually noticed that because it's "-Wp,-D...", not "-D...". But I guess you're right, it's in CFLAGS because many build systems support CFLAGS, but only autotools support CPPFLAGS. > GNU make's implicit rules use CPPFLAGS. If other build systems or > overriden rules don't use it, it's a bug. This can of course be > worked around in debian/rules. Well, such argument can be applied to any build system. For example: Cmake uses CMAKE_C_FLAGS, but GNU's make does not use it. It's a bug. GNU make must use CMAKE_C_FLAGS. And dpkg must set it too. Even more, dpkg should set only CMAKE_C_FLAGS, CMAKE_CXX_FLAGS and CMAKE_SHARED_LINKER_FLAGS. Yes, this may create some problems for people packaging autotools, but this can of course be worked around in debian/rules. Come on. :) How many build systems except autotools are using CPPFLAGS? cmake, qmake, imake, nmake? It looks completely autotools-specific to me. And forcing it is no better than forcing qmake DEFINES or CMAKE_C_FLAGS. It just adds more work to packagers, but makes nothing better. Talking just about autotools: * CPPFLAGS without CFLAGS are used only by ./configure script * CPPFLAGS without CFLAGS are used only for some conftests * -D_FORTIFY_SOURCE=2 means nothing for those tests * -D_FORTIFY_SOURCE=2 does nothing at all without -O2 So even for autotools there's no reason to keep -D_FORTIFY_SOURCE=2 in a CPPFLAGS variable. It can be easily dropped. Also dropping CPPFLAGS would also allow: 1. Use same rules for cmake and autotools packages. 2. Make every rules file a few lines shorter, thus a bit faster to build 3. Make "Hardening" wiki page shorter 4. Reduce the number of workarounds by one 5. Reduce the number of things people need to think about when packaging, making packaging a little bit easier. And no disadvantages on the other hand. :) If it's not fixed in dpkg, as you said, it can be worked around in debian/rules. I'm just trying to avoid adding unnecessary workarounds to debian packages. -- Serge -- 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/CAOVenEqf8dXxr5-W7Rd==QoJq6n_gwaFqxFt0=bpoqf1yr5...@mail.gmail.com
Bug#679236: O: ckport -- portability analysis and security checking tool
Package: wnpp
Severity: normal
Hereby I orphan the package ckport.
The package as made hardy useful by Ron Lee's personal vendetta against me.
While not directly related most packages provided data for this package
("ckport database") will be removed or orphaned.
As it is not fully useless I only orphan it not asking for RM.
The package itself is in good shape. Upstream development is not affected by
this.
I hope the package will find a new home. I will gladly help a new maintainer
as needed.
The package description is:
ckport is a tool to check already compiled binaries and libraries for porting
and security problems.
.
It uses objdump to read the binaries and analyses calls and jumps to functions.
.
This package is architecture independent and can be used on non-host
architecture binaries if an objdump tool for the target architecture
is installed.
--
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/20120627104934.31992.97663.report...@ph7.ph.sft.vpn
Bug#679235: RFA: animals -- Traditional AI animal guessing engine using a binary tree DB
Package: wnpp Severity: normal I request an adopter for the animals package. After the personal vendetta by Ron Lee against me I'm no longer interested in wasting my time for the Debian project. The package itself is in good shape and easy to maintain. I still will do the upstream and will happly help a new maintainer to take this, including answering questions and be cooperative with futur problems. Hope all those little animals find a nice new home! The package description is: You think of an animal, and this package tries to guess it... when it's wrong, you teach it about your animal. . To be more flexible and help educational aspect this game does not contain an initial database. This also allows it to be used for non animals like guessing of tools or locations. -- 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/20120627103317.31804.35203.report...@ph7.ph.sft.vpn
Bug#679223: ITP: tonicdns -- RESTful API for PowerDNS
Package: wnpp Severity: wishlist Owner: Kouhei Maeda * Package name: tonicdns Version : 1.1.0 Upstream Author : Cyso Managed Hosting * URL : https://github.com/Cysource/TonicDNS * License : GPL Programming Lang: PHP Description : RESTful API for PowerDNS It uses the MIT licensed Tonic RESTful library as its base. Feature is below: * Token based communication. * Option to store tokens in the PowerDNS database, or in a separate SQLite database. * Should work with any PowerDNS backend database, tested with MySQL. * Supports adding of zones, records and zone and record templates. * Atomic commits, all modifications are validated on input and executed in a single transaction. -- 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/20120627094519.12281.21839.report...@vmdeb.cyberagent.co.jp
Re: Bug#679078: ITP: acpi-support-minimal -- minimal acpi scripts
* Michael Meskes [120626 14:48]: [ Guillem Jover [120626 12:05]:] > > I'll be reopening 665987, but if that gets closed again I'd be very > > happy to switch to acpi-support-minimal from my now locally built > > acpi-support packages w/ the consolekit dependency removed. > [...] I'm absolutely willing > to listen to ideas of solving this, which imo would be a much better solution > than creating an additional package that will only partly work. [...] I'd prefer to get this fixed in acpi-support-base, but I think you have made your point very clear that the only purpose of that package is to not do anything if some power manager is running and that to detect this perfectly you are totally willing to force anyone to install consolekit (and thus dbus) who justs wants his system shutting down cleanly when the power button is pressed. That this is not issue for you at all and that you do not see any problem in introducing this change 2012-06-21 i.e. shortly before the freeze. > "If that gets closed again" sounds like I was closing the bug without > a reason, which I didn't. That sentence was much more neutral than anything I think I could have written. After you were closing two bug reports by just dismissing the issue, a "if that gets closed again" is a totally objective way to describe expectations. Bernhard R. Link -- 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/20120627093253.ga3...@client.brlink.eu
Re: [Pkg-sysvinit-devel] Future of update-rc.d in wheezy+1
[Roger Leigh] > Could [file-rc] use insserv to do the dependency graph and then just > consume the makefile-style dependency list? Yes. See http://bugs.debian.org/539591 >, http://bugs.debian.org/573004 > and the source of insserv, where a patch to do this was created and included by Kel. The patch has been available for more than two years. -- Happy hacking Petter Reinholdtsen -- 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/20120627092719.gb20...@login2.uio.no
Future of update-rc.d in wheezy+1
Hi folks, I'd just like to briefly discuss potential plans for update-rc.d in wheezy+1, and how this might impact on file-rc and sysv-rc. sysv-rc has defaulted to using LSB header dependencies and insserv for a few years now. The last few releases require you to enable insserv to upgrade, and the pending upload just does this automatically. The result is that all wheezy users of sysv-rc will be using dependency-based boot. This means that the runlevels and sequence numbers passed as arguments to update-rc.d will never be used; they will just get silently discarded. The main problem as I see it is that these numbers are going to bitrot badly--they aren't being tested, while the dependency information in the header is being used by everyone. I'd like to suggest that we do the following in sysv-rc update-rc.d: - wheezy: silently drop start|stop sequence numbers and runlevels (this is already the case when using insserv, and we can remove the non-insserv codepaths) - wheezy+1: warn if these options are used - wheezy+2: remove support for the options and error out if used And additionally, to add lintian warnings for use of these options, including when using dh_installinit. The main problem that I can see is file-rc is currently still dependent upon the sequence numbers and runlevel information. Would it be possible for file-rc to also add support for dependencies? Given that the static boot ordering is quite dead at this point, it would be very helpful to know what's possible here. Could it use insserv to do the dependency graph and then just consume the makefile-style dependency list? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120627091329.gj9...@codelibre.net
Re: File naming of scripts in /etc/init.d
Dear all, Thank you for your answers. Le 25-06-2012, à 15:21:02 +0100, Roger Leigh (rle...@codelibre.net) a écrit : > On Mon, Jun 25, 2012 at 03:59:30PM +0200, Steve R. Petruzzello wrote: > > Le 25-06-2012, à 14:47:58 +0100, Roger Leigh (rle...@codelibre.net) a écrit > > : > > > > > On Mon, Jun 25, 2012 at 01:51:36PM +0200, Steve R. Petruzzello wrote: > > > > I noticed that some scripts in /etc/init.d/ are suffixed by .sh and > > > > some are > > > > not. [...] All except console-screen.sh, hwclock.sh and keymap.sh are > > > > from > > > > the initscripts package. > > > > > > > > So 1) nowhere is .sh suffixing mentioned and 2) some scripts are not > > > > named by > > > > their package's name (hwclock.sh is part of the util-linux package). Is > > > > there > > > > a reason for this? > > > > > > Nowadays, it's essentially the case that > > > - scripts with a .sh suffix are run from rcS > > > > But not all scripts in /etc/rcS.d/ have a .sh suffix (for instance > > S09mdadm-raid). > > No, it's not a strict rule, just historic practice. If we were to > do it over today, it's unlikely we would use the suffixed names. So my question was not too stupid :) Best regards, Steve -- 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/20120627084604.GA8811@localhost
Bug#679212: ITP: python-whois -- Python module/library for retrieving WHOIS information of domains
Package: wnpp Severity: wishlist Owner: Francois Marier * Package name: python-whois Version : 0.6.3 Upstream Author : DDarko * URL : https://code.google.com/p/python-whois/ * License : MIT Programming Lang: Python Description : Python module/library for retrieving WHOIS information of domains This Python wrapper for the "whois" command has a simple interface to access parsed WHOIS data for a given domain. . It is able to extract data for many of the popular TLDs (com, org, net, biz, info, pl, jp, uk, nz, ...) and queries WHOIS servers directly instead of going through an intermediate web service. -- 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/20120627083130.24669.27456.report...@isafjordur.dyndns.org
Re: duplicates in the archive
On Mon, Jun 25, 2012 at 12:38:42PM +0200, Svante Signell wrote: > > Which wm does that? I know it isn't gnome-shell at least, as I've been > > using it quite successfully without nm installed. > Have you tried to use evolution without NM? I didn't try but it only suggests network-manager. However some applications do behave weird if you just deinstalled n-m (pidgin for instance), because they assume that you're not connected. After a reboot (maybe dbus restart is enough) they certainly connect again, though. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Dependency-based boot ordering and sysvinit in unstable
severity 678231 serious severity 676473 serious forgemerge 676463 678231 676473 tags 676463 + pending thanks On Thu, Jun 07, 2012 at 09:31:47PM +0100, Roger Leigh wrote: > Hi, > > If you're using unstable and you're using static boot ordering with > sysv-rc, you might have run into #676463/#676520. > > We've been using dynamic dependency-based boot ordering by default for > quite some time now. However, if you had a lenny (or earlier) system, > prior to sysv-rc 2.88dsf-23, users had a choice between opting to > remain using the old static legacy boot ordering, or to enable dynamic > dependency-based boot ordering. In 2.88dsf-23, the question is > removed, and dynamic boot ordering will be enabled on all systems. > > For the majority of users, this won't cause any problems at all. > However, if you have any lingering scripts without any LSB headers, > you'll need to fix them up or remove them to allow dynamic boot > ordering to be enabled. This is obviously not too desirable, since > it requires fixing things up by hand. But it doesn't break anything > either (other than requiring you to fix things to continue--the boot > ordering will be unaffected until the migration can proceed). > > Ideally, we would be able to skip the sanity checks and just enable it > anyway, with the non-LSB scripts getting ordered after all the LSB > scripts. This should satisfy the (absent) dependencies in all but the > most insane of cases. But this does require testing carefully, which > is why it's not done at the present time. The packages at http://people.debian.org/~rleigh/sysvinit/ remove all the old sanity checks and permit insserv to run when scripts without LSB headers are present. The scripts get ordered at the end of $all. i.e. they are run after all scripts with LSB headers, but before rc.local and other scripts that require $all to be run before them. This should be safe to do in all cases, with the exception being any custom scripts which are ordered in a specific place in the runlevel. These will now most likely get run later than previously. However, running after all system-provided services are started will usually be the correct thing to do. This will only cause problems if the script must start strictly before a particular service starts. In this situation, you'll need to add an LSB header describing the specific dependencies. I'd be grateful for any testing and feedback of the above prerelease packages before they get uploaded to unstable. Unless there are any major objections to this change, I'd like to upload this later in the week. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120627073852.gh9...@codelibre.net
