loosing dependencies
Currently, the `fortunes' package depends on either `fortune-mod' or `fortune-min': $ apt-cache show fortunes Package: fortunes ... Source: fortune-mod Version: 1:1.99.1-3 Provides: fortune-cookie-db Depends: fortune-mod (>= 9708-12), fortunes-min ... Does it make sense, provided that the fortune files may as well be read by M-x fortune in Emacs, or even by a plain `less'? And more generally, does it make sense for a pure-data package to have non-empty Depends:? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#461651: loosing dependencies
Package: fortunes Version: 1:1.99.1-3 Currently, the `fortunes' package depends on either `fortune-mod' or `fortune-min': $ apt-cache show fortunes Package: fortunes ... Source: fortune-mod Version: 1:1.99.1-3 Provides: fortune-cookie-db Depends: fortune-mod (>= 9708-12), fortunes-min ... $ It probably doesn't make sense, provided that the fortune files may as well be read by, e. g., M-x fortune in Emacs, or even by `less'. Could this dependency be relaxed, please? The following line may be added as well, if it's necessary: Conflicts: fortune-mod (<< 9708-12) [Cc: to debian-devel, since the discussion was started there.] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: loosing dependencies
> Ralf Treinen <[EMAIL PROTECTED]> writes: >> Currently, the `fortunes' package depends on either `fortune-mod' or >> `fortune-min': [...] >> Does it make sense, provided that the fortune files may as well be >> read by M-x fortune in Emacs, or even by a plain `less'? > Probably not, it seems to me that you are right, and that this > dependency should be relaxed. ACK. >> And more generally, does it make sense for a pure-data package to >> have non-empty Depends:? > I can imagine that there are cases in which data is really specific > to a particular application, but that doesn't seem to be the case > here. But, well, one may probably find some uses for that data even outside of that application? I hardly believe that there're data that's completely useless without a particular application or applications, be it icons, sounds, or LUTs for a particular scientific code. The only situation where I see it's appropriate for an `Architecture: all' package to contain an another package in it's `Depends:' is where the package also provides scripts which require that other package to be run. > Could you please file a bug report against the fortune package? Done [1]. [1] http://bugs.debian.org/461651 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
loosing dependencies: Depends: on logrotate
Since I've already started this thread, I'm going to ask for opinions on the one more issue with the current (Etch, at least) dependencies in Debian to bother me. Is `logrotate' really necessary for those 46 packages or so in Etch to include it in their `Depends:'? Debian Policy reads: --cut: www.debian.org/doc/debian-policy/ch-relationships.html-- The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality. The Depends field should also be used if the postinst, prerm or postrm scripts require the package to be present in order to run. Note, however, that the postrm cannot rely on any non-essential packages to be present during the purge phase. --cut: www.debian.org/doc/debian-policy/ch-relationships.html-- My opinion is that since `logrotate' is not required neither for the maintainer scripts in order to run, nor ``for the depending package to provide a significant amount of functionality'', this dependency should be either relaxed (to `Recommends:' or `Suggests:') or discarded completely. (And there're packages which provide a `logrotate.d/' file, but don't list `logrotate' as a dependency. Among these are `dpkg' and `apache2.2-common'.) I've already discussed on this matter [1]. The reasons for having such a dependency stated to me were, AIUT, as follows: * ``packages should not facilitate users to shoot themselves in the foot by filling up the logging partition''; yet there're a plenty of ways to do it whether `logrotate' is installed or not; I expect for the software to grant me freedom, not to revoke it in order to save me from but the very dumb mistakes; * since `logrotate' is `Priority: important', lightweight enough and it ``is the standard log rotation mechanism in Debian (including documentation in Debian policy)'', it would be there anyway, whether the dependency would be in place or not; but Debian Policy, AIUI, only mandates that the Debian packages must support `logrotate', not that the Debian users must actually use it! and isn't the absense of `logrotate' in the system a clear sign of that the user knows what he or she's doing? [1] http://bugs.debian.org/422968 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: loosing dependencies: Depends: on logrotate
> Don Armstrong <[EMAIL PROTECTED]> writes: >> Exactly. If any of the old, rather inflexible syslog implementations >> depended on logrotate, I would say that would be perfectly fine. But >> for applications (even if they write their logs themselves like >> apache or samba usually do), I would only expect a simple >> Recommends. On my servers, I'm forced to have logrotate installed >> due to applications like samba, even though I immediately disable >> logrotate after installation and use my own rotation scripts (for >> those applications not using syslog - syslog-ng in this case) >> instead. > You need to have some kind of log rotation in place, so a depends[0] > is perfectly appropriate, since the only type of log rotation that we > actually distribute is logrotate.[1] (I mean, without *some* kind of > log rotation, you're going to run out of disk space eventually, which > seems to me to be a pretty important bit of functionality.) To this end Priority: important seems to be enough. It's up to policy to specify which log rotation package (or rather interface) is to be supported by all of the packages (and thus by the system.) But it should be left to the user to decide which package to actually use. > Since samba even distributes an appropriate logrotate config file, it > obviously depends on it. In much the same way that debian-policy package depends on www-browser? To my mind, /etc/logrotate.d/ file is completely an option. Whether the user will use it or not is to be left to his or her own discretion. > Finally, it's not like you can't indicate that you're dealing with > logrotation by yourself by using an equivs package to work around the > dependency. Indeed. Though I don't think that such a workaround should be required. > Don Armstrong > 0: And actually, it's not clear to me why syslog-ng doens't depend > on logrotate. > 1: TTBOMK, of course; if there are others, then there possibly should > be a metapackage for them. This would require the /etc/logrotate.d/ files parsing to be implemented by the packages providing that metapackage. In much the same way that the `Provides: x-terminal-emulator' packages are expected to provide an `x-terminal-emulator' alternative. [...] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#450432: ... and even more bugs like this?
Last week I've reported a bug in ifconfig(8) (as of net-tools
1.60-17.) The problem is in that the ifconfig.8 contains the
following:
--cut--
.B ifconfig eth0:0 down
. Note: for every scope (i.e. same net with address/netmask combination) all
aliases are deleted, if you delete the first (primary).
--cut--
This is (I guess) intended to be rendered by Groff as:
``ifconfig ... in the bold face, then period (.), then Note:,
...'' However, it renders just as if there were no ``. Note:
...'' line at all. I guess, it happens because Groff interprets
``. Note:'' (or ``. Note''?) as a ``command'', and since it
knows no definition for it, it ignores the entire line.
The problem is that ifconfig.8 isn't the only file with such a
misfeature!
$ bash check-man-periods.sh /usr/share/man/man1/*.gz
/usr/share/man/man1/gpg.1.gz:. This is only used when \fB--use-agent\fR has
/usr/share/man/man1/ocamldoc.1.gz:. The file
/usr/share/man/man1/rpost.1.gz:. If this form is used, any port number
specified via the -N option
/usr/share/man/man1/sfxtest.1.gz:. Higher values of mode are more verbose.
...
/usr/share/man/man1/v.surf.rst.1grass.gz:. User can choose to output vector
files \fItreefile\fR and \fIoverfile\fR
...
$
(Look below for check-man-periods.sh.)
What I'm expected to do, then? (With respect to Debian BTS.) I
believe, start filing multiple bug reports would be a bad idea
(for me now.) May I suggest an explicit warning to be generated
by Groff on unknown ``command'', so that lintian(1) will issue a
warning on a malformed manual page, too? (Or a ``strict check''
mode for Groff, to be used especially by lintian and alike?)
And, out of curiosity, was the ``. Note:'' (and similar) ever
rendered by Groff, and if it is, when the behaviour was changed?
#!/bin/bash
### check-man-periods.sh --- Check man pages for ``period bugs'' -*- Sh -*-
examine_1 () {
local f="$1"
local s='\([[:blank:]].*\)\?$'
## a rough approximation...
## FIXME: nor commas, nor backslashes are allowed in $1
sed -e '/^[.][[:blank:]]/!d' \
-e '/^[.][[:blank:]]\+[.[:digit:][]/d' \
-e '/^[.][[:blank:]]\+\(B[IR]\?\|[IP]P\|SM\|\\["}]\)'"$s"'/d' \
-e '/^[.][[:blank:]]\+\(ad\|br\|de\|ds\|el\|fi\)'"$s"'/d' \
-e '/^[.][[:blank:]]\+\(ftr\?\|hy\|ie\|if\|in\|mso\|\)'"$s"'/d' \
-e '/^[.][[:blank:]]\+\(n[efhrs]\|nop\|r[mr]\|t[im]\)'"$s"'/d' \
-e '/^[.][[:blank:]]\+\(warn\|while\)'"$s"'/d' \
-e "s,^,$f:,"
}
for f in "$@"; do
case "$f" in
(*.gz) zcat "$f" | examine_1 "$f" ;;
(*) < "$f" examine_1 "$f" ;;
esac
done
### check-man-periods.sh ends here
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#450432: ... and even more bugs like this?
> Russ Allbery <[EMAIL PROTECTED]> writes: [...] >> --cut-- >> .B ifconfig eth0:0 down >> . Note: for every scope (i.e. same net with address/netmask combination) all >> aliases are deleted, if you delete the first (primary). >> --cut-- [...] > Yeah, this is a common roff coding problem. That text should be > written as: > .BR "ifconfig eth0:0 down" . > Note: Yes, I've guessed that when I was submitting a patch for Bug#450432. > or with the period escaped. ... And this is the thing I haven't found how to do. Could you please show me that spell? [...] >> What I'm expected to do, then? (With respect to Debian BTS.) I >> believe, start filing multiple bug reports would be a bad idea (for >> me now.) > Well, they certainly are bugs, and I think filing those bugs after > you verify that this is a problem and the period wasn't there for > some other purpose (such as to create a comment line) is perfectly > fine. Isn't .\" the better way to go then? Since this issue could be checked with lintian, I think that sending a wishlist report on it is a better way. IIUC, once the check is in lintian, the bugs like this would be filed automatically? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#450432: ... and even more bugs like this?
> "TV" == Thomas Viehmann <[EMAIL PROTECTED]> writes: [...] >> $ bash check-man-periods.sh /usr/share/man/man1/*.gz > Debian has lintian and linda to check for machine-detectable errors > like this one. Maybe you could wirte the same test in perl/python and > submit it as a whishlist item to the BTS for one of those packages. I still like the idea of implementing a check for unknown commands in Groff instead. A warning from Groff may be used to trigger a lintian warning, like how it's already done (check lintian/checks/manpages, Tag: manpage-has-errors-from-man.) I haven't written anything in Perl for the three years or so, but of course could give it a try. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#450432: ... and even more bugs like this?
>>>>> Russ Allbery <[EMAIL PROTECTED]> writes: >>>>> Ivan Shmakov <[EMAIL PROTECTED]> writes: >>>>> Russ Allbery <[EMAIL PROTECTED]> writes: >>> or with the period escaped. >> ... And this is the thing I haven't found how to do. Could you >> please show me that spell? > \&. Note: > \& is a null token that can be put at the beginning of a line to > ensure that it's not interpreted as a roff command. .BR is better, > in my opinion, since this introduces an extraneous space before the > period. ACK. Thanks for that. > Another approach that also works is to stop using .B entirely and > instead use font escapes: > \fBifconfig eth0:0 down\fP. > This is what Pod::Man does since constructing the .BR lines is > complex and can run into short arbitrary limits in some roff > implementations. Well, looks like so, but I see a problem with the legacy manpages that ``miss their parts.'' >> Isn't .\" the better way to go then? > Yes, but you never can tell what people do. A lintian check. To remind of a bad practice. >> Since this issue could be checked with lintian, I think that sending >> a wishlist report on it is a better way. IIUC, once the check is in >> lintian, the bugs like this would be filed automatically? > No, lintian doesn't file bugs. Someone still has to go file the > bugs, even if lintian is used to do the check. Lintian documentation reads: --cut: /usr/share/doc/lintian/lintian.html/ch1.html-- 3. Please DO NOT use Lintian to file bug reports (neither single ones nor mass bug reports). This is done by the authors of Lintian already and duplication of efforts and bug reports should be avoided! --cut: /usr/share/doc/lintian/lintian.html/ch1.html-- Is this bit out of date? > This is a minor bug, not a wishlist bug, IMO. Unless you meant the > bug on lintian. Yes, I've meant the latter. > (If you meant the bug against lintian, including a patch to do this > check would be lovely.) I'll start working on it soon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#450432: ... and even more bugs like this?
> "CW" == Colin Watson <[EMAIL PROTECTED]> writes: >> What I'm expected to do, then? (With respect to Debian BTS.) I >> believe, start filing multiple bug reports would be a bad idea (for >> me now.) May I suggest an explicit warning to be generated by Groff >> on unknown ``command'', so that lintian(1) will issue a warning on a >> malformed manual page, too? (Or a ``strict check'' mode for Groff, >> to be used especially by lintian and alike?) > The -wmac option to groff will emit a warning for this mistake. Today, I've found it, too. > See the "Warnings" node in 'info groff'. ... I've done it the hard way -- looked through the source. > It's not especially easy right now to make Lintian pass this, since > man doesn't expose an interface to add extra options to groff. And here goes another hack: $ cat man.local .warn 512 .mso /usr/share/groff/site-tmac/man.local $ cat mdoc.local .warn 512 .mso /usr/share/groff/site-tmac/mdoc.local $ LC_ALL=C GROFF_TMAC_PATH="$PWD" man ifconfig > /dev/null Reformatting ifconfig(8), please wait... /tmp/zman6d1c0O:63: warning: `Note:' not defined $ LC_ALL=C GROFF_TMAC_PATH="$PWD" \ man gpg ocamldoc rpost sfxtest v.surf.rst > /dev/null Reformatting gpg(1), please wait... /tmp/zmanqItyHp:153: warning: `-'' not defined /tmp/zmanqItyHp:1449: warning: `GPG_AGENT_INFO'' not defined /tmp/zmanqItyHp:1450: warning: `This' not defined Reformatting ocamldoc(1), please wait... /tmp/zmanGibSgq:109: warning: `The' not defined Reformatting rpost(1), please wait... /tmp/zmanq2L13v:96: warning: `If' not defined Reformatting sfxtest(1), please wait... /tmp/zman8dcg6e:87: warning: `Higher' not defined Reformatting v.surf.rst(1grass), please wait... /tmp/zmaneiehzB:130: warning: `User' not defined $ How about adding this one to lintian? > I'll file a bug for my own reference and see about adding one. Yes, please. [...] >> #!/bin/bash >> ### check-man-periods.sh --- Check man pages for ``period bugs'' -*- Sh -*- > I very much recommend against any attempt to parse *roff in shell, > FWIW. Even man-db's flex parser is ultimately doomed to failure and > should probably be replaced with something cunning involving custom > groff macros at some point. Agreed upon that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#450432: ... and even more bugs like this?
>>>>> "IS" == Ivan Shmakov <[EMAIL PROTECTED]> writes: >>>>> "CW" == Colin Watson <[EMAIL PROTECTED]> writes: [...] >> The -wmac option to groff will emit a warning for this mistake. [...] >> It's not especially easy right now to make Lintian pass this, since >> man doesn't expose an interface to add extra options to groff. IS> And here goes another hack: > $ cat man.local > .warn 512 > .mso /usr/share/groff/site-tmac/man.local > $ cat mdoc.local > .warn 512 > .mso /usr/share/groff/site-tmac/mdoc.local > $ LC_ALL=C GROFF_TMAC_PATH="$PWD" man ifconfig > /dev/null > Reformatting ifconfig(8), please wait... > /tmp/zman6d1c0O:63: warning: `Note:' not defined > $ [...] IS> How about adding this one to lintian? So, I've written a (yet another) crude hack and going to file a wishlist bug against lintian. A run on some of the `.deb's from Debian 4.0 *r0* (somewhat a random and, what's worse, somewhat outdated set): $ lintian --root="$PWD"/../lintian-root-2007-11-15 \ *.deb \ | grep -F has-errors W: libdirectfb-dev: manpage-has-errors-from-man usr/share/man/man1/directfb-config.1.gz 24: warning: `l' not defined W: dvidvi: manpage-has-errors-from-man usr/share/man/man1/a5booklet.1.gz 9: warning: `IX' not defined The lines like this seems to me somewhat bogus. I guess, `.IX' allows one to specify an index item, and since `man' doesn't provide any indices, this macro is left undefined, and thus ignored by `man' (and it's okay.) A simple-minded approach to suppress these warnings would be something like: .de IX .end but I believe that such a definition belongs to the macro package `man' uses. W: dvgrab: manpage-has-errors-from-man usr/share/man/de/man1/dvgrab.1.gz 308: warning: `..' not defined W: dput: manpage-has-errors-from-man usr/share/man/man1/dput.1.gz 92: warning: `P.SH' not defined W: dpkg-dev: manpage-has-errors-from-man usr/share/man/man1/dpkg-checkbuilddeps.1.gz 27: warning: `UR' not defined W: dpkg-dev: manpage-has-errors-from-man usr/share/man/man1/dpkg-architecture.1.gz 104: warning: `C`' not defined Something like the above with these two?.. W: dpkg-dev: manpage-has-errors-from-man usr/share/man/fr/man1/dpkg-checkbuilddeps.1.gz 34: warning: `UR' not defined W: dpkg-dev: manpage-has-errors-from-man usr/share/man/fr/man1/dpkg-architecture.1.gz 111: warning: `C`' not defined W: dpkg-dev: manpage-has-errors-from-man usr/share/man/ja/man1/dpkg-checkbuilddeps.1.gz 29: warning: `UR' not defined W: dpkg-dev: manpage-has-errors-from-man usr/share/man/de/man1/dpkg-checkbuilddeps.1.gz 33: warning: `UR' not defined W: dpkg-dev: manpage-has-errors-from-man usr/share/man/de/man1/dpkg-architecture.1.gz 110: warning: `C`' not defined W: dpkg-dev: manpage-has-errors-from-man usr/share/man/ru/man1/dpkg-checkbuilddeps.1.gz 33: warning: `UR' not defined W: dpkg: manpage-has-errors-from-man usr/share/man/man1/dpkg-query.1.gz 51: warning: `T' not defined ... And with this one, too? Below there're mentions of `DA', `DS', `E', `LO' and `TR' as well. W: dpkg: manpage-has-errors-from-man usr/share/man/fr/man1/dpkg-query.1.gz 42: warning: `T' not defined W: dpkg: manpage-has-errors-from-man usr/share/man/fr/man8/dpkg-statoverride.8.gz 91: warning: `UR' not defined W: dpkg: manpage-has-errors-from-man usr/share/man/ja/man1/dpkg-query.1.gz 39: warning: `T' not defined W: dpkg: manpage-has-errors-from-man usr/share/man/ja/man8/dpkg-statoverride.8.gz 75: warning: `UR' not defined W: dpkg: manpage-has-errors-from-man usr/share/man/de/man8/dpkg-statoverride.8.gz 92: warning: `UR' not defined W: dpkg: manpage-has-errors-from-man usr/share/man/man8/dpkg-statoverride.8.gz 90: warning: `UR' not defined W: dpkg: manpage-has-errors-from-man usr/share/man/sv/man1/dpkg-query.1.gz 41: warning: `T' not defined W: dpkg: manpage-has-errors-from-man usr/share/man/pl/man1/dpkg-query.1.gz 43: warning: `T' not defined W: dpkg: manpage-has-errors-from-man usr/share/man/pl/man8/dpkg-statoverride.8.gz 88: warning: `UR' not defined W: docbook-utils: manpage-has-errors-from-man usr/share/man/man7/frontend-spec.7.gz 37: warning: `..)' not defined W: docbook-to-man: manpage-has-errors-from-man usr/share/man/man1/instant.1.gz 81: warning: `E' not defined W: docbook-to-man: manpage-has-errors-from-man usr/share/man/man5/transpec.5.gz 467: warning: `DS' not defined W: docbook-to-man: manpage-has-errors-from-man usr/share/man/man3/regexp.3.gz 2: warning: `DA' not defined W: dirmngr: manpage-has-errors-from-man us
Bug#377392: Bug#450432: ... and even more bugs like this?
In a recent thread in debian-devel, it was suggested that
lintian could call man(1) in such a way that the groff(1),
called by `man', will emit warnings for every undefined macro,
which is useful in catching the bugs like this:
.B foo
. Note: ...
Below is the patch that implements the suggestion. Since `man'
doesn't allow the `-wmac' option to be passed to `groff' by any
other means, I've had to introduce two new files -- `mdoc.local'
and `man.local' (to override the files in groff/site-tmac/), and
the ${LINTIAN_ROOT}/groff-hack directory to hold them.
--- lintian-1.23.36/checks/manpages 2007-10-16 10:40:04.0 +0700
+++ lintian-1.23.36-groff-hack/checks/manpages 2007-11-16 00:16:11.0
+0600
@@ -253,10 +253,12 @@
# processed properly. (Yes, there are man pages that include other
# pages with .so but aren't simple links; rbash, for instance.)
my $cmd;
+ my $groff_dir = "$ENV{'LINTIAN_ROOT'}/groff-hack/";
+ my $man_cmd = "GROFF_TMAC_PATH='$groff_dir' man -l";
if ($file =~ m,^(.*)/(man\d/.*)$,) {
- $cmd = "cd unpacked/\Q$1\E && man -l \Q$2\E";
+ $cmd = ("cd unpacked/\Q$1\E && $man_cmd \Q$2\E");
} else {
- $cmd = "man -l unpacked/\Q$file\E";
+ $cmd = "$man_cmd unpacked/\Q$file\E";
}
my $pid = open MANERRS, '-|';
if (not defined $pid) {
diff -drHuN --exclude='*~' lintian-1.23.36/debian/rules
lintian-1.23.36-groff-hack/debian/rules
--- lintian-1.23.36/debian/rules2006-11-19 07:11:32.0 +0600
+++ lintian-1.23.36-groff-hack/debian/rules 2007-11-16 00:11:37.0
+0600
@@ -45,7 +45,7 @@
install -m 755 frontend/lintian-info $(tmp)/usr/bin/
# library files
@echo install library files
- for d in checks collection lib unpack; do \
+ for d in checks collection lib unpack groff-hacks; do \
install -d $(usl)/$$d; \
find $$d -type f ! -path '*/CVS/*' ! -path '*/.svn/*' \
| xargs -iFILE cp -p FILE $(usl)/$$d/; \
diff -drHuN --exclude='*~' lintian-1.23.36/groff-hacks/man.local
lintian-1.23.36-groff-hack/groff-hacks/man.local
--- lintian-1.23.36/groff-hacks/man.local 1970-01-01 07:00:00.0
+0700
+++ lintian-1.23.36-groff-hack/groff-hacks/man.local2007-11-14
23:09:47.0 +0600
@@ -0,0 +1,2 @@
+.warn 512
+.mso /usr/share/groff/site-tmac/man.local
diff -drHuN --exclude='*~' lintian-1.23.36/groff-hacks/mdoc.local
lintian-1.23.36-groff-hack/groff-hacks/mdoc.local
--- lintian-1.23.36/groff-hacks/mdoc.local 1970-01-01 07:00:00.0
+0700
+++ lintian-1.23.36-groff-hack/groff-hacks/mdoc.local 2007-11-14
23:09:48.0 +0600
@@ -0,0 +1,2 @@
+.warn 512
+.mso /usr/share/groff/site-tmac/mdoc.local
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Opinions sought: mlocate appropriate for Priority: standard?
> Adeodato Simó <[EMAIL PROTECTED]> writes: Imho this problem is not one that needs to be solved, if multiple locates are installed, multiple databases should be generated. >>> I think differently. Particularly given that findutil's locate can >>> be installed only as a dependency of other packages. (If this >>> wasn't the case, I'd agree your point of view is valid as well.) >>> Did you consider this? >> I did consider it, but afaik the pulled-in-by-dependency-szenario is >> going to be rare. > Well, dlocate has 2500 popcon installations, vs. slocate's 1500. So, > I'm still convinced findutil's locate's cron script should either > only run if it's the configured locate, *or* not run unless enabled > in /etc/default/locate. > But it's your package and I know how to disable one script for > cron, so I won't mention it further. :-) May I suggest a single `update-locate' script, with different implementations (`update-locate.findutils', etc.) belonging to the same alternatives group as `locate' and `updatedb'? This reduces the cron.daily script to a single line of code (though I don't know which package to put it in.) [...]
Re: Opinions sought: mlocate appropriate for Priority: standard?
>>>>> Ivan Shmakov <[EMAIL PROTECTED]> writes: >>>>> Adeodato Simó <[EMAIL PROTECTED]> writes: >>>>> Imho this problem is not one that needs to be solved, if multiple >>>>> locates are installed, multiple databases should be generated. >>>> I think differently. Particularly given that findutil's locate can >>>> be installed only as a dependency of other packages. (If this >>>> wasn't the case, I'd agree your point of view is valid as well.) >>>> Did you consider this? >>> I did consider it, but afaik the pulled-in-by-dependency-szenario >>> is going to be rare. >> Well, dlocate has 2500 popcon installations, vs. slocate's 1500. So, >> I'm still convinced findutil's locate's cron script should either >> only run if it's the configured locate, *or* not run unless enabled >> in /etc/default/locate. >> But it's your package and I know how to disable one script for cron, >> so I won't mention it further. :-) > May I suggest a single `update-locate' script, with different > implementations (`update-locate.findutils', etc.) belonging to the > same alternatives group as `locate' and `updatedb'? This reduces the > cron.daily script to a single line of code (though I don't know which > package to put it in.) ... A (to be introduced) locates-common package?
Re: Opinions sought: mlocate appropriate for Priority: standard?
> Andreas Metzler <[EMAIL PROTECTED]> writes:
>> May I suggest a single `update-locate' script, with different
>> implementations (`update-locate.findutils', etc.) belonging to the
>> same alternatives group as `locate' and `updatedb'? This reduces
>> the cron.daily script to a single line of code (though I don't know
>> which package to put it in.)
>> [...]
> I do not think that would work well, diffrent locates have different
> featuresets (and options).
It's the precise reason behind having per-locate
`update-locate.PACKAGE' scripts. Everything required to update
the database for any given locate (currently in
/etc/cron.daily/PACKAGE) is to be put into a /usr/sbin/-script
(/usr/sbin/update-locate.PACKAGE.) Like:
$ cat /usr/bin/update-locate.slocate
#! /bin/sh
if [ -x /usr/bin/slocate ]
then
if [ -f /etc/updatedb.conf ]
then
/usr/bin/updatedb
else
/usr/bin/updatedb -f proc
fi
chown root.slocate /var/lib/slocate/slocate.db
fi
$ cat /usr/bin/update-locate.findutils
#! /bin/sh
#
# former cron script to update the `locatedb' database.
#
# Written by Ian A. Murdock <[EMAIL PROTECTED]> and
#Kevin Dalley <[EMAIL PROTECTED]>
LOCALUSER="nobody"
export LOCALUSER
if [ -f /etc/updatedb.conf ]; then
. /etc/updatedb.conf
fi
if getent passwd $LOCALUSER > /dev/null ; then
cd / && nice -n ${NICE:-10} updatedb 2>/dev/null
else
echo "User $LOCALUSER does not exist."
exit 1
fi
$
The cron script, /etc/cron.daily/, then checks whether
/usr/sbin/update-locate (managed by the alternatives system)
exists, and, if it is, calls it:
$ cat /etc/cron.daily/update-locate
#!/bin/sh
if [ -x /usr/sbin/update-locate ]; then
/usr/sbin/update-locate
fi
Or am I missing something?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Opinions sought: mlocate appropriate for Priority: standard?
> Andreas Metzler <[EMAIL PROTECTED]> writes: >> $ cat /usr/bin/update-locate.findutils > [...] >> $ cat /etc/cron.daily/update-locate >> #!/bin/sh >> if [ -x /usr/sbin/update-locate ]; then >>/usr/sbin/update-locate >> fi >> Or am I missing something? > The fact that people might want to change with which options the > respective updatedb is invoked. Indeed. Though I'd prefer for code to stay in /usr. Combining both the configuration and the code in one /etc-script doesn't seem to me like a very bright idea. Having separate update-locate handle has an additional benefit of allowing one to start database update by hand ``in a clean way'' (compare, e. g., # /etc/init.d/foo start vs. # invoke-rc.d foo start.) Whoever does the work does the decision, though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#450432: ... and even more bugs like this?
> Colin Watson <[EMAIL PROTECTED]> writes:
[...]
>> W: libdirectfb-dev: manpage-has-errors-from-man
>> usr/share/man/man1/directfb-config.1.gz 24: warning: `l' not defined
>> W: dvidvi: manpage-has-errors-from-man usr/share/man/man1/a5booklet.1.gz 9:
>> warning: `IX' not defined
>> The lines like this seems to me somewhat bogus. I guess, `.IX'
>> allows one to specify an index item, and since `man' doesn't provide
>> any indices, this macro is left undefined, and thus ignored by `man'
>> (and it's okay.)
> Perhaps some of these should be explicitly ignored by lintian, as
> they're problems with popular generator tools and it really doesn't
> do anyone any good to report them in lintian; they should be filed as
> bugs against the generators instead.
ACK.
> (Unfortunately, you might have to parse groff's warning text in order
> to ignore particular cases.)
I'm not familiar with Groff at all... Does it allow later `.de'
to override the former?..
> .IX is probably from pod2man, which does:
[...]
> Russ, perhaps this should be something like this instead to suppress
> the warning?
[...]
>> A simple-minded approach to suppress these warnings would be
>> something like:
>> .de IX
>> .end
... And if it does, this definition just could be put into
lintian/groff-hack/{mdoc,man}.local, effectively suppressing the
Groff warnings.
>> but I believe that such a definition belongs to the macro package
>> `man' uses.
> man doesn't use any macro package of its own; it's all in groff. I'd
> like to keep it that way if possible. Anyhow, since this is a macro
> defined by a particular man page generator, it's not appropriate to
> handle it in either man or groff.
ACK.
>> W: dvgrab: manpage-has-errors-from-man usr/share/man/de/man1/dvgrab.1.gz
>> 308: warning: `..' not defined
> Looks like a botched attempt to define a macro. (.. is what you use
> to terminate a macro definition.)
Looks more like a comment from the generator:
305 Sections, no Front\-Cover Texts and no Back\-Cover Texts. A copy
306 of the license can be found under
307 \fB/usr/share/common\-licenses/FDL\fP.
308 ...\" created by instant / docbook\-to\-man, Wed 13 Dec 2000, 17:30
[...]
>> W: dpkg-dev: manpage-has-errors-from-man
>> usr/share/man/man1/dpkg-checkbuilddeps.1.gz 27: warning: `UR' not defined
> .UR used to be what you used to mark up URLs; man(7) recommended it
> until not that long ago.
What to use instead?
[...]
>> W: dirmngr: manpage-has-errors-from-man usr/share/man/man1/dirmngr.1.gz
>> 245: warning: `#'' not defined
244 Lines starting with a
245 '#'
246 are comments.
>> W: dirmngr: manpage-has-errors-from-man
>> usr/share/man/man1/dirmngr-client.1.gz 86: warning: `-vv'' not defined
85 verbose commands to \fBdirmngr\fR, such as
86 '-vv'
87 .
> I don't have this installed, but they look like typos.
Some misused quotes?
>> W: dialog: manpage-has-errors-from-man usr/share/man/man3/dialog.3.gz 1494:
>> warning: `..' not defined
> Maybe another botched attempt to define a macro?
1490 .TP 5
1491 .B const char * \fIfmt
1492 is the format of the \fBprintf\fP-like message to write.
1493 .TP 5
1494 ...
1495 are the variables to apply to the \fIfmt\fP format.
More like an Attempt to render ellipsis.
[...]
>> W: ddd: manpage-has-errors-from-man usr/share/man/man1/ddd.1.gz 34:
>> warning: `PSPIC' not defined
> This is sort of odd; that macro is defined in cases where the output
> device is capable of drawing pictures using pic. I think it would be
> best to ignore this one, although the warning could be suppressed
> like this:
> .if d PSPIC .PSPIC /tmp/buildd/ddd-3.3.11/./ddd/PICS/dddlogo.eps 10cm
ACK. Alternatively, an empty definition in
groff-hack/{mdoc,man}.local could be used (``if not defined
PSPIC, define empty PSPIC''.)
[...]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#377392: Bug#450432: ... and even more bugs like this?
> Colin Watson <[EMAIL PROTECTED]> writes:
>> In a recent thread in debian-devel, it was suggested that lintian
>> could call man(1) in such a way that the groff(1), called by `man',
>> will emit warnings for every undefined macro, which is useful in
>> catching the bugs like this:
>> .B foo
>> . Note: ...
>> Below is the patch that implements the suggestion. Since `man'
>> doesn't allow the `-wmac' option to be passed to `groff' by any
>> other means, I've had to introduce two new files -- `mdoc.local' and
>> `man.local' (to override the files in groff/site-tmac/), and the
>> ${LINTIAN_ROOT}/groff-hack directory to hold them.
> While I haven't reviewed the code in detail, the general approach
> seems largely reasonable to me. However, the error the developer sees
> will just be "manpage-has-errors-from-man", which in fact is no
> longer really true in this case; you're specifically enabling
> warnings that man doesn't show. Perhaps it would be best to turn
> these warnings from groff into a different lintian warning which can
> have a more informative description, and ideally a way for the
> developer to reproduce the problem.
A helper script, `lintian-man', could be introduced to hide all
the hackery, and to provide a way for the developer to reproduce
the problem. Then, Tag: may be changed to, e. g.,
`manpage-has-messages-from-lintian-man'. (Or should this script
be called `man-lintian'?)
I still hope that either `groff' or `man' will offer a way to
specify `-w'-options for `groff' in a more clean way. The
helper script could then be modified, or eliminated entirely.
The patch is as follows. (TODO: newly introduced lintian-man
script demands a man page on its own.) This new version of the
patch suppresses `.IX'-related warnings. (TODO: the generator
is to be fixed.)
--- lintian-1.23.36/checks/manpages 2007-10-16 10:40:04.0 +0700
+++ lintian-1.23.36-groff-hack/checks/manpages 2007-11-21 21:16:29.0
+0600
@@ -253,10 +253,11 @@
# processed properly. (Yes, there are man pages that include other
# pages with .so but aren't simple links; rbash, for instance.)
my $cmd;
+ my $man_cmd = "lintian-man -l";
if ($file =~ m,^(.*)/(man\d/.*)$,) {
- $cmd = "cd unpacked/\Q$1\E && man -l \Q$2\E";
+ $cmd = "cd unpacked/\Q$1\E && $man_cmd \Q$2\E";
} else {
- $cmd = "man -l unpacked/\Q$file\E";
+ $cmd = "$man_cmd unpacked/\Q$file\E";
}
my $pid = open MANERRS, '-|';
if (not defined $pid) {
@@ -282,7 +283,7 @@
}
chomp;
s/^[^:]+://o;
- tag "manpage-has-errors-from-man", "$file", "$_";
+ tag "manpage-has-messages-from-lintian-man", "$file", "$_";
last;
}
close(MANERRS);
--- lintian-1.23.36/checks/manpages.desc2007-06-21 15:48:26.0
+0700
+++ lintian-1.23.36-groff-hack/checks/manpages.desc 2007-11-21
21:16:26.0 +0600
@@ -120,9 +120,12 @@
Please double-check the manual page and replace the template language
with specific information about this program.
-Tag: manpage-has-errors-from-man
+Tag: manpage-has-messages-from-lintian-man
Type: warning
-Info: This man page provokes warnings or errors from man.
+Info: This man page provokes warnings or errors from lintian-man.
+ .
+ lintian-man is a helper script which behaves like man, but with Groff
+ warnings (-wman) explicitly enabled.
.
"cannot adjust" or "can't break" are trouble with paragraph filling,
usually related to long lines. Adjustment can be helped by left
--- lintian-1.23.36/debian/rules2006-11-19 07:11:32.0 +0600
+++ lintian-1.23.36-groff-hack/debian/rules 2007-11-21 21:18:13.0
+0600
@@ -43,9 +43,12 @@
install -m 755 frontend/lintian $(tmp)/usr/bin/
sed -i 's//$(VER)/' $(tmp)/usr/bin/lintian
install -m 755 frontend/lintian-info $(tmp)/usr/bin/
+# helper scripts
+ @echo install helper scripts
+ install -m 755 frontend/lintian-man $(tmp)/usr/bin/
# library files
@echo install library files
- for d in checks collection lib unpack; do \
+ for d in checks collection lib unpack groff-hacks; do \
install -d $(usl)/$$d; \
find $$d -type f ! -path '*/CVS/*' ! -path '*/.svn/*' \
| xargs -iFILE cp -p FILE $(usl)/$$d/; \
--- lintian-1.23.36/frontend/lintian-man1970-01-01 07:00:00.0
+0700
+++ lintian-1.23.36-groff-hack/frontend/lintian-man 2007-11-21
21:16:48.0 +0600
@@ -0,0 +1,5 @@
+#!/bin/sh
+: ${LINTIAN_ROOT:=/usr/share/lintian}
+export \
+GROFF_TMAC_PATH="${LINTIAN_ROOT}${GROFF_TMAC_PATH:+:}${GROFF_TMAC_PATH}"
+exec man "$@"
--- lintian-1.23.36/groff-hacks/man.local 1970-01-01 07:00:00.0
+0700
+++ lintian-1
Re: Bug#377392: Bug#450432: ... and even more bugs like this?
>>>>> Ivan Shmakov <[EMAIL PROTECTED]> writes: >>>>> David Weinehall <[EMAIL PROTECTED]> writes: >>> A helper script, `lintian-man', could be introduced to hide all the >>> hackery, and to provide a way for the developer to reproduce the >>> problem. Then, Tag: may be changed to, e. g., >>> `manpage-has-messages-from-lintian-man'. (Or should this script be >>> called `man-lintian'?) >> [snip] >> Sounds like a great idea in general. But: correct manual pages is >> not something that is specific to debian packages, so maybe manlint >> would be a better idea, also having it as a part of the man-db >> package instead might be an idea. Since the tool should behave like *man* with *w*arnings *e*nabled, I'd call it `manwe'... I've just submitted a patch for Bug#451187. > Well, one might then implement a generic method of passing Groff > options via `man', thus obviating the need to override the > `man.local' and `mdoc.local'. How about an environment variable > (say, `MANROFFOPT' or `MANGROFFOPT')? Done as well. >> lintian already depends on man-db, so the dependencies wouldn't >> change, and it would also mean that linda can use the same check >> without code duplication. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libFOO-BAR naming convention
> Loïc Minier <[EMAIL PROTECTED]> writes: >> I vaguely recall seeing a recommendation for library packages for a >> particular language to follow libFOO-BAR naming convention in >> Debian, where FOO is the name of a library, and BAR is an arbitrary >> common suffix (thus, liberror-perl, or libsqlite-ocaml.) > This depends on the language; chech the sub-policy for each > language -- unless you're preparing packages for a new language? Sort of. I'm planning to spend some time preparing Debian packages for Chicken extensions. > e.g. perl and java will use *-perl and *-java, but python notably > uses python-* obviously. Thanks!
libFOO-BAR naming convention
I vaguely recall seeing a recommendation for library packages for a particular language to follow libFOO-BAR naming convention in Debian, where FOO is the name of a library, and BAR is an arbitrary common suffix (thus, liberror-perl, or libsqlite-ocaml.) Could one point me to where this recommendation is given? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#377392: Bug#450432: ... and even more bugs like this?
> David Weinehall <[EMAIL PROTECTED]> writes: >> A helper script, `lintian-man', could be introduced to hide all >> the hackery, and to provide a way for the developer to reproduce >> the problem. Then, Tag: may be changed to, e. g., >> `manpage-has-messages-from-lintian-man'. (Or should this script >> be called `man-lintian'?) > [snip] > Sounds like a great idea in general. But: correct manual pages is > not something that is specific to debian packages, so maybe manlint > would be a better idea, also having it as a part of the man-db > package instead might be an idea. Well, one might then implement a generic method of passing Groff options via `man', thus obviating the need to override the `man.local' and `mdoc.local'. How about an environment variable (say, `MANROFFOPT' or `MANGROFFOPT')? > lintian already depends on man-db, so the dependencies wouldn't > change, and it would also mean that linda can use the same check > without code duplication. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Is Davide Puricelli MIA?
Does someone know if Davide Puricelli (evo at debian.org) is MIA? Apparently, the last upload by him was on 2007-06-10 [1]. I've tried to communicate him last year, but didn't succeed. I've mostly interested in the `chicken' package. The last version packaged for Debian is 2.5, and it seems that there're enough Chicken extensions [2] that aren't compatible with that version of Chicken anymore. [1] http://packages.qa.debian.org/x/xchat/news/20070610T154706Z.html [2] http://galinha.ucpel.tche.br:8080/Eggs%20Unlimited -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Davide Puricelli MIA?
> Davide Puricelli <[EMAIL PROTECTED]> writes: >> Does someone know if Davide Puricelli (evo at debian.org) is MIA? >> Apparently, the last upload by him was on 2007-06-10 [1]. I've >> tried to communicate him last year, but didn't succeed. >> I've mostly interested in the `chicken' package. The last version >> packaged for Debian is 2.5, and it seems that there're enough >> Chicken extensions [2] that aren't compatible with that version of >> Chicken anymore. > Hi Ivan, > I'm not MIA (I still read -devel and I follow the project life), Glad to hear it! > but you're right, I'm not really active in the packages field. > I'm planning to update chicken in upcoming days, luckily it's not a > huge work, Well, Chicken now contains the debian/ directory, currently used to facilitate the creation of unofficial `.deb's. Perhaps you shold review it. I've suggested to link Chicken against the host version of PCRE instead of the one supplied with Chicken itself [1]. Felix has recently committed a patch [2] which simplifies the change. Could this change be adopted for the official Debian package? There's a small thread starting at [3] which points a few problems with the current Debian packaging. Could you please review it? I hope to make some patches (namely, `srcdir' support and `CHICKEN_LIBRARY_PATH' support) soon, which may be of a particular interest to the Debian users. > while I just asked Bart Martens to help me to comaintain xchat. > About your private email: I didn't reply because I had never > received it! Strange enough. Hope you'll receive this one. [1] http://permalink.gmane.org/gmane.lisp.scheme.chicken.devel/516 [2] http://permalink.gmane.org/gmane.lisp.scheme.chicken.devel/526 [3] http://permalink.gmane.org/gmane.lisp.scheme.chicken.devel/474 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
/tmp on multi-FS set-ups, or: block users from using /tmp?
> Weldon Goree writes: > On Fri, 2012-05-25 at 10:02 -0400, Nikolaus Rath wrote: >> I think having / and /tmp share the same file system is a bad idea, >> because then writing lots of stuff to /tmp would potentially fill up >> the root file system (that typically also includes /var) and then >> cause a lot of breakage. >> However, if I put /tmp in a separate (on-disk) file system, I have >> to decide how much disk space to I want to permanently allocate for >> temporary data, in addition to the disk space permanently allocated >> for swapping. […] Somehow, I feel that some of the participants of this discussion are missing this very point: having /tmp on disk /doesn't/ mean that /all/ the free disk space will be available for it at any given time. In particular, as Ext2+ filesystems can only be expanded, and not reduced (without unmounting), I've got the habit of having most of the disk space unallocated, and only expanding the filesystems as they grow full. (Unless, of course, considerable amounts of cruft could be identified and removed at that time.) > If only ext*fs supported quotas... … But that makes me recall a solution to both the /tmp and quota issues I've seen somewhere: use ~/tmp/ instead of /tmp. This way, user's temporary files will be subject to exactly the same limits as all the other his or her files. (Still, we may need to identify the software that ignores TMPDIR and tries to write to /tmp unconditionally.) > (Snark aside, does tmpfs support quotas yet/will it ever?) -- FSF associate member #7257 -- 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/86r4u7koc5.fsf...@gray.siamics.net
Re: Packaging on GitHub ?
> Thorsten Glaser writes: > Charles Plessy dixit: >> upstream source moved to GitHub, and we would like to try to >> maintain the Debian package there as well. > This is not a good idea: http://mako.cc/writing/hill-free_tools.html That's why I tend to advocate for the use of Gitorious instead. --cut: http://en.wikipedia.org/wiki/Gitorious -- CAPTION: Gitorious Developer(s) Shortcut AS Written inRuby Operating system Cross-platform Available in English Type Project management software License GNU Affero General Public License Website https://gitorious.org/gitorious/ --cut: http://en.wikipedia.org/wiki/Gitorious -- PS. An RFP, perhaps? -- FSF associate member #7257 -- 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/861um2l4w9@gray.siamics.net
Re: Bug#675106: ITP: pgbulkload -- A high speed data loading utility for PostgreSQL
> Alexander Kuznetsov writes: […] (Some wording fixes and suggestions.) > Description : A high speed data loading utility for PostgreSQL > pg_bulkload is designed to load huge amount of data to a database. > You can choose whether database constraints are checked and how many errors > are If “You can…” here starts a new paragraph, there's ought to be an empty (“.”) line. And if not, the linebreak here came a bit too early than necessary. > ignored during the loading. For example, you can skip integrity checks for > performance when you copy data from another database to PostgreSQL. On the > other hand, you can enable constraint checks when loading unclean data. > . Are “constraint checks” different to “integrity checks” in the above? Unless they are, it should rather be, e. g.: … For example, you can skip integrity checks for performance when you copy data from another database to PostgreSQL, or have them in place when loading potentially unclean data. > The original goal of pg_bulkload was an faster alternative of COPY command in … was /a/ faster… Or, perhaps: … was to provide a faster… > PostgreSQL, but version 3.0 or later has some ETL features like input data > validation and data transformation with filter functions. > . … but as of version 3.0 some ETL features… were added. And what's ETL, BTW? > In version 3.1, pg_bulkload can convert the load data into the binary file > which can be used as an input file of pg_bulkload. If you check whether Perhaps: As of version 3.1, pg_bulkload can dump the preprocessed data into a binary file, allowing for… (Here, the purpose should be mentioned. Is this for improving the performance of later multiple “bulkloads”, for instance?) > the load data is valid when converting it into the binary file, you can skip > the check when loading it from the binary file to a table. Which would reduce > the load time itself. Also in version 3.1, parallel loading works > more effectively than before. s/effectively/efficiently/. But the whole sentence makes little sense, as the earlier versions weren't packaged for Debian. -- FSF associate member #7257 -- 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/86wr3ujphk@gray.siamics.net
Re: CD sizes again (and BoF reminder!)
> Ben Hutchings writes: [...] > - twm: no-one should have to suffer this And, exactly, why not? Before I've switched to Openbox, it was one of the two WM's I've used, along with FVWM. And they say [1] that it still can be handy at times. The “obscure” label may fit, though. [...] [1] news:1187451...@ddt.demos.su (in Russian; and is garbled beyond recognition on Google Groups.) -- FSF associate member #7257 -- 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/86sjd13tzn@gray.siamics.net
Re: Recommends for metapackages
> Jonas Smedegaard writes: […] > It is a feature (which each user is free to avoid by not using it!) > for Debian to include a meta-package that pulls in that vil n-m, > not a bug. … And what exactly this “feature” gives to the user? […] -- FSF associate member #7257 http://sf-day.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/86d3430zhm@gray.siamics.net
Re: Bug#637232: Multiarch breaks support for non-multiarch toolchain
> Jonathan Nieder writes: > Goswin von Brederlow wrote: >> What I don't understand is why compilers (which probably means ld >> from binutils in all cases) won't use ld.so.conf to find the libs. >> It only does so to find libs linked into libs you link against. So >> it is used execpt for the verry first level of recursion. > The ld library path and compiler library path represent different > things[*]. Somehow, I guess that “the ld.so(8) library path” and “the ld(1) library path” were actually meant here. […] -- FSF associate member #7257 http://sf-day.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/86pq7my9i5@gray.siamics.net
Re: Modified http://wiki.debian.org/DebianDeveloper to mention non-packagers
> The Fungi writes: > On 2012-07-26 14:29:14 +0100 (+0100), Ian Jackson wrote: >> We also need a general word for "someone involved with Debian in a >> positive way". "Participant" is clumsy; "member of the community" >> even more so. "Person" might do but word with a more positive spin >> would be nice. > As a long-time participant and non-DD, I've always liked the term > "contributor" in that context. As (hopefully) one of the affected, I'm fine with “contributor.” -- FSF associate member #7257 http://sf-day.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/86wr1puk4q.fsf...@gray.siamics.net
[OT] ifconfig(8)
> Marco d'Itri writes: > On Aug 08, Arno Töll wrote: >> ifconfig and route were around already when everyone insisted on the >> separation of /bin and /sbin. /bin/ip is slightly newer and >> supposed to replace ifconfig/route some day entirely. > Just for the records, iproute entirely replaced ifconfig/route long > ago. Curiously enough, ifconfig(8) shows RX/TX byte counts, and, somehow, I didn't manage to get a similar output from iproute. Any pointers? TIA. > The only reason for keeping around the old programs is compatibility > with other packages not yet updated and to not scare people who do > not know better. > (Does anybody want to try removing net-tools and see what breaks?) I guess that $ apt-cache rdepends may be a safer check, like: $ apt-cache rdepends --no-suggests net-tools However, it made me wonder, why ifupdown Suggests: net-tools? -- FSF associate member #7257 http://sf-day.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/86k3x9k5xn.fsf...@gray.siamics.net
Re: [OT] ifconfig(8)
>>>>> Timo Juhani Lindfors writes: >>>>> Ivan Shmakov writes: >> Curiously enough, ifconfig(8) shows RX/TX byte counts, and, somehow, >> I didn't manage to get a similar output from iproute. Any pointers? >> TIA. > $ ip -s link show lo > 1: lo: mtu 16436 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > RX: bytes packets errors dropped overrun mcast > 1686679058 6901861 0 0 0 0 > TX: bytes packets errors dropped carrier collsns > 1686679058 6901861 0 0 0 0 At last, I can forget about ifconfig(8). Thanks! -- FSF associate member #7257 http://sf-day.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/86fw7xk548@gray.siamics.net
Depends: hicolor-icon-theme: shouldn't it be Recommends: instead?
Abstract The non-data packages currently having an absolute dependency on hicolor-icon-theme should consider downgrading it to Recommends: at the least. The list, and the explanation, are below. Chapter I imagemagick Recently, Depends: hicolor-icon-theme was added to the imagemagick's control file, which triggered my curiosity: does it provide something that wasn't needed (or was missed) by the previous versions of the package, but is strictly necessary to run the newer ones? Indeed, it doesn't. To prove it, I've made a trivial control file for equivs-build(1): --cut: k1o7mjuxokuwghktzugfno8qib.ctl -- Package: k1o7mjuxokuwghktzugfno8qib Provides: hicolor-icon-theme Description: Pretend that hicolor-icon-theme is installed (dummy) A dummy package pretending to provide hicolor-icon-theme. --cut: k1o7mjuxokuwghktzugfno8qib.ctl -- Having hicolor-icon-theme removed and this one installed, I've proceeded to install imagemagick. Unsurprisingly, I've found /no/ issues with either installing or running it. (I've tried display(1), but I'm quite sure that there won't be any issues with convert(1), either.) Chapter II A few packages more Well, I've wondered, is this a singular issue with Depends: hicolor-icon-theme, somehow creeped into Debian Wheezy “just prior” to its scheduled release? Indeed, it isn't. I've examined the reverse dependencies of hicolor-icon-theme: $ apt-cache rdepends --no-suggests --no-recommends \ hicolor-icon-theme hicolor-icon-theme Reverse Depends: viridian tango-icon-theme synaptic rabbitvcs-core perlpanel oxygen-icon-theme openteacher kdelibs5-data imagemagick gnome-phone-manager gnome-icon-theme-symbolic gnome-icon-theme-extras gnome-icon-theme flush d-feet $ Well, it doesn't seem suspicious for anything *-icon-* and *-data to depend on an icon theme, but what about the rest? For a start, I've omitted rabbitvcs-core and viridian, and considered d-feet, flush, openteacher, perlpanel, and synaptic. Unsurprisingly, all of them were able to install and run, but while openteacher is seemingly unaffected by the absence of the data in question, the rest have had obvious issues: almost all of the icons were absent, resulting in blank space on the GUI, missing controls, and warnings to stderr (stdout?) Conclusion Since there're (as it seems) virtually no issues with running imagemagick without a “real” hicolor-icon-theme installed, my suggestion would be to downgrade the dependency to Suggests: (or Recommends:, if there's some point I've missed.) As for the other packages considered, my suggestion would be to downgrade the dependencies to Recommends: (or, for openteacher, to Suggests:, if it's indeed unaffected.) Unless there'd be any objections, I'll consider filing a bug against imagemagick, and perhaps the other aforementioned packages as well. Post Scriptum Curiously enough, the only “application” package having a Recommends: dependency on hicolor-icon-theme is cheese. -- FSF associate member #7257 http://sf-day.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/86ehn551jr@gray.siamics.net
Re: Depends: hicolor-icon-theme: shouldn't it be Recommends: instead?
> Simon McVittie writes: […] > hicolor-icon-theme is really the infrastructure for a theme, rather > than *being* a theme: it does not contain any icons of its own. It > represents the fallback icon theme for all desktops that use > freedesktop.org themes (GNOME, KDE, XFCE, etc.). The name "hicolor" > is for historical reasons - it was the default icon theme hard-coded > into old versions of one of the major desktop environments (KDE 2 or > 3, I think?) and it stuck. > Its purpose is to be the theme into which applications install their > "theme-neutral" icons: anything that displays a themeable icon should > search for it in the configured theme, and then fall back to hicolor. ACK, thanks for the explanation, and apologies for a “false alarm.” (But why the other “theme” packages depend on it, BTW?) Now, I wonder, could its Description: be amended so to explain its function in more detail? Stating that it's “the default fallback theme” doesn't tell quite much to me, for instance. Consider, e. g. (though the wording is flaky a bit): Description: FreeDesktop.org default fallback theme infrastructure This package contains the necessary infrastructure for the applications to install their theme-neutral icons for the implementations of the Freedesktop.org Icon Theme specification to use. It provides the respective directory layout, an index file, and a script to start gtk-update-icon-cache(1) as necessary. . This package is not an icon theme per se as it contains no icons of its own. The "hicolor" name was hardcoded into an older version of a major desktop environment and is retained for historical reasons. > Its only file outside /usr/share/doc is metadata describing the > directories it provides (index.theme, 24K), and its postinst and dpkg > trigger maintain a Gtk icon cache for icons added to it by > applications. Thus, its function also implies a couple of Shell scripts below /var/lib/dpkg/info/, too. (Which are simple enough to not worry about, though.) […] > I don't think "we could potentially save 24K on those rare systems > that have certain specific X apps, but no GUI menu" is a very > compelling reason to change packages' dependencies? At the very least, it now doesn't bother me much more than having libmysqlclient18 installed on my MX'es running exim4-daemon-heavy (given that I never had to use MySQL with it specifically.) Still, using Depends: to depend on a (otherwise optional) .postinst script doesn't seem quite right to me. (And I'm pretty sure that dependencies of such a kind are generally Recommends: ones in Debian.) -- FSF associate member #7257 http://sf-day.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/86ipcg1yzs@gray.siamics.net
versioned dependency on the libhdf5-7 virtual package
This issue was already discussed [1], and I've filed the
respective bug report [2] (to which there was no reply so far,
though), but now I see that there's a few more packages in
Wheezy with a dependency on libhdf5-7. Consider, e. g.:
$ bzcat \
< http.debian.net/debian/dists/wheezy/main/binary-amd64/Packages.bz2 \
| gawk '/^Package: / { pkg = $2; } /Version: / { vers = $2; }
/ libhdf5-7 \(/ { printf("%-23s %s\n", pkg, vers); }'
libhe5-hdfeos0 5.1.13.dfsg.1-3
libhdf5-7-dbg 1.8.8-9
libhdf5-dev 1.8.8-9
cgns-convert3.1.3.4-1
libnexus0 4.2.1-svn1614-1+b1
libnexus0-java 4.2.1-svn1614-1+b1
nexus-tools 4.2.1-svn1614-1+b1
r-cran-hdf5 1.6.10-1
tessa 0.3.1-6
tessa-mpi 0.3.1-6
udav0.7.1.2-3
$
Any chance this issue will be rectified? (Or should I file bug
reports against these packages?)
TIA.
[1] news:udlvci28as8@dr-wily.mit.edu
http://permalink.gmane.org/gmane.linux.debian.science/5353
[2] http://bugs.debian.org/680400
--
FSF associate member #7257 http://sfd.am-1.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/86a9wu9iky@gray.siamics.net
Re: status of eligibility of dug lists on lists.debian.org
> martin f krafft writes: […] > So the solution was to get one or two additional people, and > eventually I was even able to invest in more fail-proof hardware. > … and then you ask yourself what to do with all the spare cycles and > wouldn't other LUGs profit from your setup… And you keep going and > going and the dependence on you grows. Yes. […] > Now there are three ways forward: > 1. take back the mailing list, my infrastructure still exists and >could handle it, but am I willing to give a guarantee for the next >years to come? > 2. work with teams.debian.net to get it back up to speed. > 3. or use the official and professionally maintained infrastructure >on alioth.d.o or lists.d.o, which can probably handle a couple >dozens of additional lists. I can understand that we don't want a >new list for every formation or group in the Debian universe, To be honest, it's the very reason I dislike mailing lists. The groups come and go, while mailing lists have to stay forever, for their archive to be available for posterity. Usenet is better (though still not ideal) in this respect, as newsgroups aren't much more than just “tags”, which a single message may bear an arbitrary number of. Starting a “discussion group” should require no more skill and time than tuning a radio to an agreed frequency. And the archive should persist for as long as there's anyone to care. >but a list for large groups like the Debian users in and around of >Munich should arguably be doable. > My preference is clearly (3.). Maybe one of the sysadmins who could > host their own LUG list would be interested in helping the > listmasters. And should the hardware not be enough, then we can > probably find ways to upgrade it. I'd be fine going (2), either. What exactly needs to be done? -- FSF associate member #7257 -- 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/86mx0l3qrv@gray.siamics.net
conffiles
> Thomas Goirand writes: […] > BTW, "conffiles" is a pretty bad name. It's confusing, as you can > see once more. > I thought about calling it "dpkg-conffiles" which has the advantage > of underlying that we leave the handling of the file to the > responsibility of dpkg, keeps the same old "conffiles" name. But > people will continue to use the older short version of it, so... > Anyone with a better idea? umdekfiles, perhaps? (For “User modifies, dpkg keeps [the changes.]”) At the very least, I don't think anyone with half the sane mind will confuse them with “configuration files.” -- FSF associate member #7257 -- 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/86zk4j237k.fsf...@gray.siamics.net
Re: Packages removing alternatives on upgrade
> Jakub Wilk writes: [Cross-posting to packages@qa, for elvis is maintained by the QA group.] > Many packages remove alternatives on upgrade, only to re-add them > later, potentially discarding manual choices of the user. > See also bug #71621. […] > Debian QA Group >elvis >elvis-console >elvis-tools >ircii […] BTW, do I understand it correctly that it's just a matter of dropping the ‘upgrade’ case from .prerm? (Possible patch MIME'd.) TIA. -- FSF associate member #7257 --- debian/elvis-console.prerm.~1~ 2012-09-23 13:34:49.0 + +++ debian/elvis-console.prerm 2012-09-23 15:24:02.0 + @@ -3,7 +3,7 @@ set -e case "$1" in -upgrade|remove|deconfigure) +remove|deconfigure) for app in editor ex input vi view; do update-alternatives --quiet --remove "$app" /usr/bin/elvis done --- debian/elvis.prerm.~1~ 2012-09-23 13:34:49.0 + +++ debian/elvis.prerm 2012-09-23 15:24:02.0 + @@ -3,7 +3,7 @@ set -e case "$1" in -upgrade|remove|deconfigure) +remove|deconfigure) for app in editor ex input vi view; do update-alternatives --quiet --remove "$app" /usr/bin/elvisnox done --- debian/elvis-tools.prerm.~1~ 2012-09-23 13:34:49.0 + +++ debian/elvis-tools.prerm 2012-09-23 15:24:02.0 + @@ -3,7 +3,7 @@ set -e case "$1" in -upgrade|remove|deconfigure) +remove|deconfigure) update-alternatives --quiet --remove ctags /usr/bin/elvtags ;; failed-upgrade)
Re: Bug#688826: ITP: libarchive-rar-perl -- interface for the 'rar' command
> Joenio Costa writes: > Package: wnpp > Severity: wishlist > Owner: Joenio Costa > * Package name: libarchive-rar-perl > Version : 2.02 > Upstream Author : jean-marc boulade > * URL : http://search.cpan.org/dist/Archive-Rar/ > * License : Perl > Programming Lang: Perl > Description : interface for the 'rar' command > This is a module for the handling of rar archives. > .. > Locates the rar command AIUI, the Rar archiver is non-free. Do I understand it correctly that this package is thus intended for contrib? > (from PATH or from regedit for Win32) The W32 platform isn't worth mentioning, as Debian isn't available for one. > and encapsulate it to create, extract and list rar archives. -- FSF associate member #7257 -- 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/86y5jxwh64@gray.siamics.net
${HOME} vs. g_get_home_dir ()
I do remember filing a bug or two against packages that refer to the getent () data to find the user's “home” directory instead of using the HOME environment variable. The environment is the preferred place to check for this kind of things: it's (usually) under the full control of the user, and it's quite possible to run several instances of a single program using different environments (with different executable file search PATH's, locales, time zones, etc.), which occasionally turns to be an immense aid to debugging. (Want to use the all-defaults configuration for a program? Just start it like: $ HOME="$(mktemp -dt -- foo.)" foo) Now, Glib has g_get_home_dir (), whose description reads [1]: --cut-- Gets the current user's home directory as defined in the password database. Note that in contrast to traditional UNIX tools, this function prefers passwd entries over the HOME environment variable. --cut-- I believe that this behavior is buggy. There's even a (yet unresolved) bug report [2] against Gimp due to this behavior, and my guess is that there may be quite a few packages more affected by it. While I understand some of the concerns regarding the “Unix” behavior (also at [1]; quoted below), I'd like to note that the software which both relies on g_get_home_dir () /and/ stores its files under a subdirectory of the home directory returned (which is, arguably, a common practice), is also likely to run into issues should that /subdirectory/ be made non-writable (or non-readable), and the current g_get_home_dir () behavior is not a safeguard against it. Therefore, I'd like to propose for this behavior to be changed to match the usual Unix conventions. To address the only concern listed in [1] I deem valid, I'm also asking that the value of HOME be disregarded, unless it points to a directory, which is readable, writable, and owned, by the user. Unless there be objections (or Glib be quickly patched), I'd be filing a bug report against libglib2.0-0. TIA. --cut-- One of the reasons for this decision is that applications in many cases need special handling to deal with the case where HOME is Not owned by the user Not writeable Not even readable --cut-- [1] http://developer.gnome.org/glib/2.28/glib-Miscellaneous-Utility-Functions.html [2] http://bugs.debian.org/453711 -- FSF associate member #7257 -- 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/861uhowyp3@gray.siamics.net
Re: ${HOME} vs. g_get_home_dir ()
>>>>> Simon McVittie writes: >>>>> On 26/09/12 17:12, Ivan Shmakov wrote: >> (Want to use the all-defaults configuration for a program? Just >> start it like: $ HOME="$(mktemp -dt -- foo.)" foo) > Debian's GLib has been patched, and actually has this precedence: > G_HOME > getpwent > HOME. This was originally intended for running > things like regression tests on buildds, where the HOME specified in > /etc/passwd typically doesn't exist or can't be written; so G_HOME > gets set in debian/rules to force the issue. ACK, thanks for the hint! […] >> I believe that this behavior is buggy. There's even a (yet >> unresolved) bug report [2] against Gimp due to this behavior > To be more precise, that bug report is that the man page contradicts > what actually happens. The maintainer appears to think the correct > solution is to fix the man page. If he didn't change his mind over the past four years, that is. >> To address the only concern listed in [1] I deem valid, I'm also >> asking that the value of HOME be disregarded, unless it points to a >> directory, which is readable, writable, and owned, by the user. > That sounds like a good proposal... >> Unless there be objections (or Glib be quickly patched), I'd be >> filing a bug report against libglib2.0-0. > ... but I don't think this is the right way to make it happen. > Please research previous discussion to check that you're not missing > arguments that have happened in the past, Any particular pointers? A scan over the past 2.5 years of gtk-devel-list@ archives revealed nothing, and a brief Web search has only brought more users disappointed by this behavior (e. g., [3]) and more explicit work-arounds (e. g., [4].) [3] http://bugs.irssi.org/index.php?do=details&task_id=532 [4] http://zathura.pwmt.org/projects/girara/doxygen/utils_8c_source.html > then if you still think your proposal is the best option, take it > upstream. > I can see the value in having everything follow the same precedence, > $HOME > getpwent - predictability is good. However, having Debian's > GLib contradict behaviour that is specifically documented upstream > doesn't sound as though it promotes predictability. If your proposal > is good for Debian - which I think it is - then it's equally good for > upstream. Agreed. I guess I should raise this issue on gtk-devel-list@. -- FSF associate member #7257 -- 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/86r4povh7e@gray.siamics.net
Bug#688932: g_get_home_dir () should prefer ${HOME} over getpwuid ()->pw_dir
Package: libglib2.0-0
Version: 2.32.3-1
X-Debbugs-Cc: debian-devel@lists.debian.org
[Filing bug, as was suggested in the debian-devel@ discussion
[1]. I've also started a discussion in gtk-devel-list@ [2].]
Currently, it's not possible for the user to specify an
arbitrary home directory for most of the Glib-based packages
(such as, e. g., Gimp [3].)
I therefore suggest to change g_get_home_dir () to follow the
usual Unix convention of using ${HOME} as the user's home
directory, falling back to getpwuid ()->pw_dir should HOME be
non-existent or empty, or, additionally, should it point to a
directory not owned by the current user, or on which he or she
has no executable permission, unless the current user is ‘root’
(UID 0.)
An expanded rationale is at [4].
TIA.
[1] http://comments.gmane.org/gmane.linux.debian.devel.general/176973
[2] http://comments.gmane.org/gmane.comp.gnome.gtk+.devel.general/22721
[3] http://bugs.debian.org/453711
[4] http://permalink.gmane.org/gmane.comp.gnome.gtk+.devel.general/22721
--
FSF associate member #7257
--
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/868vbwuhuj.fsf...@gray.siamics.net
e2dis status update
>>>>> Ivan Shmakov writes: […] > The news is that both the disassembly (e2dis) and reassembly (imrt) > tools are now working (but read below for a caution) and available > from their public Git repository [1] at Gitorious! > [1] https://gitorious.org/e2dis/e2dis-devel […] > Unfortunately, the performance of the image reassembly tool (imrt) is > extremly poor for the filesystems of more than a few MiB's size. Long story short: the changes I've made over a month made imrt significantly faster. I didn't do much testing, but it seems like an order of magnitude jump! > (And it seems that there may be subtle bugs, too.) The bug I was referring to is that it seems that the version of libgcrypt I use apparently doesn't support as many as 30 or 40 digest objects existing at the same time. With the digest removal logic re-done properly (8f56056d), it doesn't seem like a big issue anymore. > As with jigdo-file(1), imrt doesn't rely on filenames, and instead > “guesses” the output chunks the files passed to it correspond by > comparing the hashes (SHA-1 and SHA256 as of a726267a.) However, > such a comparison is currently implemented in a straightforward yet > suboptimal (as in: totally dumb) way, leading to the problem. It was improved considerably in the commits from 2acc4706 to b5009c14 (roughly.) Then, I've switched to using prepared statements extensively (a51bf977, 5d2f278c), thus reducing the time to complete a simple 64 MiB test image reassembly by roughly 20%. Finally, I've implemented the “cue sheet” support (abd326b5, 64743751.) Now, e2dis recurses over the filesystem's directories and records the filenames for all the “chunks” whose digests are recorded. Conversely, imrt uses this table to narrow the comparison of the files being processed to only such digests. If that fails, it still falls back to doing full search. For the test image, this change reduces the time by some 75% more! As for the missing parts: there's still virtually no command line interface, and I hope to fix that within a month or so, making a proper release shortly after. Neither is there documentation, nor handy tools to maintain the databases created. In particular, while the format allows a single databased to hold indices for several images (say, it may be images for different platforms), there's no tools to either “split” such a database, or “join” a few together. […] -- FSF associate member #7257 -- 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/86botr5raz@gray.siamics.net
Re: Move all to /usr
> Marco d'Itri writes:
> On Oct 11, Sven Joachim wrote:
>> Rather complex, I'm afraid. Especially as not all architectures
>> even support an initramfs, AFAIK.
> I doubt this, since the initramfs can be embedded in the kernel image
> itself (and indeed it always contains one, it just is empty). But
> still, then these architectures would not support keeping /usr on a
> standalone file system, which may be an acceptable compromise.
I don't seem to understand. / is used to be self-contained; one
was still able run a “bare bones” system with just / (say, if
/usr was badly damaged somehow.) How an architecture could
/not/ support having /usr on a separate filesystem.
On the shore, I see no value in the whole idea of merging / and
/usr. Somehow, it reminds me a recent trend of moving graphical
mode support (for the architectures generally capable of a text
mode, as in: amd64, i386) from userspace (as in: X server) to
kernelspace (as in: fbcon, Wayland.)
Saving a dozen of bytes in ${PATH} doesn't seem like an
astonishing idea, anyway. What's the point, then?
[…]
--
FSF associate member #7257
--
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/868vor33yu@gray.siamics.net
Re: Move all to /usr
>>>>> Marco d'Itri writes:
>>>>> On Oct 11, Ivan Shmakov wrote:
>> Saving a dozen of bytes in ${PATH} doesn't seem like an
>> astonishing idea, anyway. What's the point, then?
> It is explained in the Red Hat wiki page. Try reading it again.
Indeed, I've just read it. To summarize: our / and /usr/ became
quite tangled over the years, so let's use initramfs instead of
/, and / instead of /usr.
Honestly, I believe that Debian hasn't messed up that that
badly. (In particular, I still think that it's possible to boot
without /usr being available.) However, should initramfs really
be considered “Debian's brand new /”, I demand that both
e2fsck(8) and bash(1) be included into one by default, so that
one would still be able to boot and repair a damaged /usr/^W /
from there.
To me, going this way means that initramfs becomes subject to
unconstrained growth. Somehow, I deem it less acceptable for
initramfs than for /.
--
FSF associate member #7257
--
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/864nzf32hn@gray.siamics.net
Re: Move all to /usr
> Marco d'Itri writes: > On Oct 11, Josselin Mouette wrote: > Le mardi 11 octobre 2011 à 16:32 +0200, Marco d'Itri a écrit : >>> I am still not 100% persuaded that this would be easy to do, but at >>> least I think that it has more merit than the old "move all to >>> /"... >> We already discussed the idea of dropping support for a separate >> /usr, and the outcome was a broad consensus for keeping things this >> way. > No, we discussed the idea of merging /usr in / (to which I was > opposed myself as well). This is a different concept. The only significant difference that I can see is that /etc could be put on a filesystem distinct to the one holding the binaries. An end which, on a second though, I cannot readily suggest on how to achieve any other way. Essentially, we leave / for /etc/ (and mount points) only, while /usr/ still serves roughly the same purpose as before. -- FSF associate member #7257 -- 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/86wrcb1jn1@gray.siamics.net
Re: Move all to /usr
>>>>> Mike Hommey writes: >>>>> On Wed, Oct 12, 2011 at 01:13:38AM +0700, Ivan Shmakov wrote: >>>>> Marco d'Itri writes: […] >>> No, we discussed the idea of merging /usr in / (to which I was >>> opposed myself as well). This is a different concept. >> The only significant difference that I can see is that /etc could be >> put on a filesystem distinct to the one holding the binaries. An >> end which, on a second though, I cannot readily suggest on how to >> achieve any other way. > And /dev. Which is on tmpfs most of the time, anyway. > And /boot. For the slightest chance that I may one day move away from GNU/Linux, I keep bootloader's files on a separate FS. (Presumably, even if I'd move to another system, I'll hardly part with GRUB.) To put it another way, I do not consider an installed bootloader to be part of a system (while its installer may be such a part.) And indeed, I've used to have a bootable floppy disk (CompactFlash, USB Flash) image with GRUB installed, but otherwise hardly related to GNU/Linux. (Say, it might contain Memtest86+, FreeDOS, and some random data.) -- FSF associate member #7257 -- 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/86obxn1him@gray.siamics.net
/ vs. /usr vs. fsck(8)
> Marco d'Itri writes: […] > So let's look at the reasons against merging /usr in / listed in my > final summary. All of them do not apply to merging / in /usr, and > actually become arguments in favour of doing it: > - NFS: sharing a read only system over NFS becomes much easier (I > would say that it actually becomes possible...) Agreed. Being one who actually have experimented with such a setup, I'd say that it makes an NFS boot environment much easier to maintain. […] However, please note that the current state of affairs (AIUI) is that we rely on / to check all the other filesystems before these are mounted. If the / filesystem is itself modified in the process, we're to reboot the system for safety. With /usr being mounted by initramfs, either we'd need to allow /usr to be checked /after/ it's mounted (by the filesystem checkers residing on it, which doesn't seems all that sane), /or/ we'd need to put all the filesystem checkers to initramfs. This implies that the latter would've to be updated each time a new filesystem check program is added to (and, perhaps, removed from) the system. […] -- FSF associate member #7257 -- 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/86k48a26n7.fsf...@gray.siamics.net
/ vs. /usr vs. udev(7)
> Marco d'Itri writes: […] > And then there is the big argument in favour of it: booting without > /usr is becoming more and more difficult. The two current solutions > for this adopted by udev and the related tools are both suboptimal: > waiting in a loop for /usr to appear can fail due to the timeout (and > I wonder when we will hit the first deadlock), and moving even more > stuff from /usr to / can work only up to a point. I don't seem to understand why is this supposed to change as we shuffle the things around. The problem is that we currently are starting udev from /, which is mounted from initramfs. Should we move, we'd have to mount /usr from initramfs instead. Now, if we're to keep udev starting /before/ /usr is mounted, we'd have to start udev from initramfs. OTOH, if this order isn't to be kept, why not just simply allow udev to be started after /usr is mounted, while retaining / vs. /usr distinction we currently use? -- FSF associate member #7257 -- 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/86fwiy26j2.fsf...@gray.siamics.net
Re: Move all to /usr
> unruh writes: > On 2011-10-12, Marco d'Itri wrote: […] >> So let's look at the reasons against merging /usr in / listed in my >> final summary. All of them do not apply to merging / in /usr, and >> actually become arguments in favour of doing it: >> - NFS: sharing a read only system over NFS becomes much easier (I >> would say that it actually becomes possible...) > And if NFS happens for whatever reason, be down when you try to mount > /usr, you have a useless system since you can do nothing with it. One still would have an initramfs instance. Also, this one is, AIUI, concerned primarily with system-on-NFS setups. Typically, these aren't of much use without /usr mounted anyway. The point is that currently, if there's a system which relies on /usr on NFS, the administrator has to somehow keep its / in sync with /usr. One can't just # chroot /nfs apt-get upgrade on the NFS server now, for that'd mean that (local) / is out of sync with (NFS mounted) /usr. With all the system residing below /usr, it suddenly becomes much a less hassle. >> - junk hardware: while moving /usr to / may not be possible due to >> the small size of the root partition, moving / to /usr will be easy >> - read only system: more parts would be read only > ? Surely you can make whatever you want read only now. With all the sort of software continuously writing to /etc/? Consider, e. g., /etc/blkid.tab, which is updated almost every time a removable media is connected to the system. Or /etc/mtab. Or /etc/lvm/cache/. […] > It is completely unclear what is pushing this proposal. The problem, AIUI, is that we start udev(7) before /usr is mounted. As udev is prone to spawn all the sorts of software in turn, we're either going to move more and more from /usr to /, /or/ to invent more kluges so that udev scripts would actually wait for /usr to be mounted. Both are indeed valid issues. I don't know for sure /why/ udev(7) should precede /usr in the boot order, though. Could someone clarify on that? > Also initrd or initfsrd both make things far more obscure--it seems > to me it becomes more difficult to figure out what your boot is > doing, and how to fix it when things break. And sometimes things > break. Yes. -- FSF associate member #7257 -- 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/86botm25xy@gray.siamics.net
Re: Move all to /usr
> Philipp Kern writes: > On 2011-10-11, Ognyan Kulev wrote: > На 11.10.2011 17:32, Marco d'Itri написа: […] >> /usr/src -> /usr/share/src > Probably depends if you want to support compile outputs there. I > guess some people compile their kernels there. Which isn't a good practice, anyway. For the kernel, it was my preference to have a single source hierarchy, and a separate hierarchy for each build, under, e. g., /var/tmp/, or /home/. (I haven't build a kernel for a while, though.) With /usr mounted read-only, it's still a suitable place for sources, but hardly so for builds. >> /usr/local -> /local > Don't know what you want to say with that, apart from getting rid of > FHS. I did it this way, and I did it the other. I feel no difference. As for the shared /usr, having local/ under /usr allows for site-specific software to be seen by the NFS clients, which is probably what one would want. -- FSF associate member #7257 -- 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/8639ey1uzq@gray.siamics.net
Re: / vs. /usr vs. fsck(8)
>>>>> Reinhard Tartler writes: >>>>> On Mi, Okt 12, 2011 at 06:09:00 (CEST), Ivan Shmakov wrote: […] > AFAIUI Harald (the fedora maintainer for their initramfs tool > dracut), he dislikes having a separate set of tools in /usr and the > initramfs, i.e., he strongly favors putting glibc, bash, iproute and > similar utilities directly in the initramfs. The main motivation > (again AFAIUI) seems to be behavioral consistency of tools between > early userspace and the booted system. Well, in the light of this, the original proposal now makes some sense. Indeed, they've made their initramfs their new /, and now wonder why would they need two /? Quite a sensible question, as it seems. Still, I don't think that it's applicable at all to Debian. > On the other hand, Debian has chosen against that and relies on > klibc, ipconfig, etc. for early userspace and thus, the initramfs. I > suspect the main motivations behind these decisions were portability > and size (please correct me and add references). If anything, I'd vote for the Debian way. And, I guess that makes Debian's initramfs and the system itself less interdependent, to the point that one could boot a system with a (kernel, initramfs) combination that's several revisions behind (or ahead) of the system proper. > I imagine it would be pretty challenging to improve the klibc based > tools to become feature-par and sufficiently behaviorally consistent > with their glibc based equivalents. In any case, I think having this > in mind is relevant for deciding whether the various fsck(8) > utilities can or should go into the initramfs or not. I believe that should fsck(8) be moved to initramfs, there would essentially be no reason to keep the rest of the «big stuff» off the latter. […] -- FSF associate member #7257 -- 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/86y5wqzk1i@gray.siamics.net
Re: Move all to /usr
> Daniel Baumann writes: > On 10/11/2011 04:32 PM, Marco d'Itri wrote: >> I am still not 100% persuaded that this would be easy to do, but at >> least I think that it has more merit than the old "move all to /"... > i'd rather see a /$foo and /usr/$foo merger to /system/$foo, so we > can have the trichotomy /system, /local and /home. My opinion would be for /system/distribution, /system/local, and /home. But, ouch, /system/distribution is essentially the present /usr! (While /system/local subsumes the current /usr/local, which isn't used that much, anyway, and /etc and /var.) The motivation is that it's much more important to backup /system/local (/etc, /var) than /system/distribution (/usr.) As for dpkg(8), we could have both /var/lib/dpkg/packages (with Package:, Version:, and everything modifiable) /and/ /usr/lib/dpkg/packages.d (with the full descriptions.) I'd argue that /boot is to be left in place, for I like to think of bootloader as /not/ belonging to any particular system installed on box. -- FSF associate member #7257 -- 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/86ty7ezjhq@gray.siamics.net
Re: Move all to /usr
> Tollef Fog Heen writes: >> The problem, AIUI, is that we start udev(7) before /usr is mounted. >> As udev is prone to spawn all the sorts of software in turn, we're >> either going to move more and more from /usr to /, /or/ to invent >> more kluges so that udev scripts would actually wait for /usr to be >> mounted. Both are indeed valid issues. >> I don't know for sure /why/ udev(7) should precede /usr in the boot >> order, though. Could someone clarify on that? > (With the assumption that /usr is on a separate fs from /): You might > very well need to load some drivers (be it network, FC, USB, SATA or > something else) and probe some bits (iSCSI auth?) to actually get to > the right block device. Yes. But should the system be moved to /usr, the above would still have to be done before it's mounted. The only difference is that instead of having all the software necessary to perform such initialization on /, we'd have to have them on initramfs — simply because no software is going to suddenly appear after mounting /, but before /usr is also available. (Assuming that /usr is still to be pointed to from an fstab(5) entry.) -- FSF associate member #7257 -- 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/86lisqzark@gray.siamics.net
Re: Move all to /usr
>>>>> Tollef Fog Heen writes: >>>>> ]] Ivan Shmakov >>>>> Tollef Fog Heen writes: >>> (With the assumption that /usr is on a separate fs from /): You >>> might very well need to load some drivers (be it network, FC, USB, >>> SATA or something else) and probe some bits (iSCSI auth?) to >>> actually get to the right block device. >> Yes. But should the system be moved to /usr, the above would still >> have to be done before it's mounted. The only difference is that >> instead of having all the software necessary to perform such >> initialization on /, we'd have to have them on initramfs — simply >> because no software is going to suddenly appear after mounting /, >> but before /usr is also available. (Assuming that /usr is still to >> be pointed to from an fstab(5) entry.) > Sure, and / might come from FC, USB, SATA, iSCSI or similar too. A > difference is that the initramfs isn't available once you start init > in your real /. The logical conclusion is then to start udev from > the initramfs, something we already do. Thanks, I wasn't aware of this. But it makes the whole idea of moving “everything” below /usr even less sensible. Consider, e. g.: --cut: news:20111012005824.gc11...@bongo.bofh.it -- And then there is the big argument in favour of it: booting without /usr is becoming more and more difficult. The two current solutions for this adopted by udev and the related tools are both suboptimal: waiting in a loop for /usr to appear can fail due to the timeout (and I wonder when we will hit the first deadlock), and moving even more stuff from /usr to / can work only up to a point. --cut: news:20111012005824.gc11...@bongo.bofh.it -- Now, if udev(7) starts to start its scripts while neither of / or /usr is mounted, how can moving anything to or from /usr help us avoid udev(7) scripts waiting for /some/ «real» FS is mounted? -- FSF associate member #7257 -- 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/864nzdzixm@gray.siamics.net
Re: RFC: Making mail-transport-agent Priority: optional
> Michelle Konzack writes: > Am 2011-10-13 12:13:56, hacktest Du folgendes herunter: >> The user will not be notified even if the daemons send a mail to >> them. I don't think any of the desktops GUIs that we ship know >> anything about the local mail queue unless explicitly configured in >> an MUA, nor do they notify the user when there is new mail. > I was using long time ago (8-10 years) a grafical MUA, which was > accessing ~/mail or /var/mail/. Since I use mutt, it is very > good, that mutt use by default ~/mail and the standard spool. > Maybe all MUAs in Debian should be configued by the Package > Maintainers, to support ~/mail by default or /var/mail/ by > default? I'd second on that. However, I should note that the Unix mbox format is quite obsolete by now, so I'd vote for the MUA's to support Maildir (~/Maildir/) at the least (and as the default), with Unix mbox (/var/mail/, ~/mail) possibly left as an option. -- FSF associate member #7257 -- 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/86zkh4xm5v@gray.siamics.net
Move mtab, etc. below /run
>>>>> Roger Leigh writes: >>>>> On Wed, Oct 12, 2011 at 11:24:09AM +0700, Ivan Shmakov wrote: >> With all the sort of software continuously writing to /etc/? >> Consider, e. g., /etc/blkid.tab, which is updated almost every time >> a removable media is connected to the system. Or /etc/mtab. Or >> /etc/lvm/cache/. > These should all be moved to /run. Indeed. > mtab will be moved shortly. The LVM and block ID caches should also > move there, with backups put under /var as required. Are there any Bug# one could subscribe to to watch the progress? -- FSF associate member #7257 -- 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/864nz8xolo.fsf...@gray.siamics.net
MUA's vs. local mail
> Henrique de Moraes Holschuh writes:
[…]
> I do know many of the GUI MUAs are incomplete jack-jobs that fail to
> add a handler for local system folders (i.e. were only partially
> ported to Linux). I am not sure which would be the better aproach to
> deal with this deficiency.
Recommends: dovecot-imapd, and let the MUA's use imap://[::1]/
by default?
Please also note that dovecot-imapd is perfectly runnable even
without special privileges, and even without a real network
socket (a pipe is just fine.) In particular, my Gnus/Emacs
setup has the following server's definition:
(nnimap "Maildir"
(nnimap-stream shell)
;; FIXME: use nnimap-shell-program here
(imap-shell-program
("MAIL=maildir:\"$HOME\"/Maildir /usr/lib/dovecot/imap")))
That way, Gnus is also unaware of my system's password.
Contrary to having a MUA access local mail directly, Dovecot
will cache certain headers, thus allowing the list of messages
to be prepared rather quickly. For the larger mailboxes, there
may be a really huge difference between using Maildir + Dovecot
vs. a MUA that accesses a Unix mbox file directly.
--
FSF associate member #7257
--
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/86zkh0vv1k.fsf...@gray.siamics.net
udev: what does it used for in Debian?
I've found that a few packages, contrary to my expectations, have Depends: on udev. I'm primarily concerned with alsa-base and initramfs-tools, but also wonder about libcomedi0, dkopp, python-expeyes, libnjb5, media-player-info, pulseaudio, ukopp, xserver-xorg-core, and midisport-firmware. The backstory is that I'm about to install Debian (either stable or testing) on a tiny Architecture: i386 system, and consider excluding udev from the installation, as the hardware in question has virtually no support for any pluggable devices whatsoever. -- FSF associate member #7257 -- 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/86lisaprgz@gray.siamics.net
Re: udev: what does it used for in Debian?
>>>>> Neil Williams writes: >>>>> On Mon, 24 Oct 2011 18:19:08 +0700 Ivan Shmakov wrote: >> I've found that a few packages, contrary to my expectations, have >> Depends: on udev. I'm primarily concerned with alsa-base and >> initramfs-tools, but also wonder about libcomedi0, dkopp, >> python-expeyes, libnjb5, media-player-info, pulseaudio, ukopp, >> xserver-xorg-core, and midisport-firmware. >> The backstory is that I'm about to install Debian (either stable or >> testing) on a tiny Architecture: i386 system, and consider excluding >> udev from the installation, as the hardware in question has >> virtually no support for any pluggable devices whatsoever. > udev isn't just for pluggable devices, packages can provide udev > rules to ensure that devices appear with a consistent name, It doesn't seem like a good reason for the aforementioned dependency, does it? And what the initramfs-tools package has to do with consistent devices' filenames? > e.g. /dev/input/event[0-9] does not include only pluggable or > external devices, it can contain several internal input devices as > HIDs but the actual number is not predictable. To make sure the > package reads from the correct device, it is wiser to provide a udev > rule which gives a particularly identified input device (by > classification / type / interface or even vendor) a known /dev > location as a name or symlink. Indeed, thanks. Somehow, I assume that given a relatively small number of devices per bus, this wasn't a problem, say, a decade or so ago. (Think of, say, 2 IDE or floppy drives per IDE or FDD controller, one keyboard, one PS/2 mouse, two RS-232 ports per UART, etc.) Or was it rather that there was much less variation between different instances Intel-based computers' hardware? However, I wonder, how often these numbers will change given that the system's hardware configuration will essentially be fixed for all the foreseeable future? I guess it won't be something like “every (other) kernel's release”, right? TIA. -- FSF associate member #7257 -- 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/86hb2ypj3i@gray.siamics.net
Re: udev: what does it used for in Debian?
>>>>> Marco d'Itri writes: >>>>> On Oct 24, Ivan Shmakov wrote: >> It doesn't seem like a good reason for the aforementioned >> dependency, does it? > There are many other reasons, you can find them in /lib/udev/. ACK, thanks. >> And what the initramfs-tools package has to do with consistent >> devices' filenames? > udev is needed to automatically load all the modules you need, for a > start. So, the kernel won't try to autoload a module when the corresponding device gets accessed? It was my understanding that, e. g., should a 10, 1 character device (/dev/psaux) be accessed, the kernel will spawn modprobe(8) against char-major-10-1, which is then resolved to ‘psmouse’ thanks to modprobe.conf(5). At the least, it was used to do just that something like a decade ago (IOW, as of 2.4.) $ /sbin/modprobe -c | grep -F -- 'char-major-10-1 ' alias char-major-10-1 psmouse $ >> However, I wonder, how often these numbers will change given that >> the system's hardware configuration will essentially be fixed for >> all the foreseeable future? I guess it won't be something like >> “every (other) kernel's release”, right? > Names could change even at every boot. Any reasons for that other than the order in which the modules get loaded? > Anyway, you have equiv. Try to use it and look what happens. I've never heard of that (and Googling for “linux equiv” doesn't seem to return anything relevant to the problem.) What's it? TIA. -- FSF associate member #7257 -- 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/86d3dmpgxr@gray.siamics.net
Re: udev: what does it used for in Debian?
>>>>> Timo Juhani Lindfors writes: >>>>> Ivan Shmakov writes: >> And what the initramfs-tools package has to do with consistent >> devices' filenames? > Initramfs runs udev. This allows you to use e.g. > root=/dev/disk/by-id/ata-WDC_WD3200AAJS-65B4A0_WD-WMAT13954017-part1 > instead of > root=/dev/sda1 > to specify where your root filesystem is. Indeed, it's a good option to have. But isn't it something that can be, in certain circumstances, however marginal, considered an extra? BTW, does the root=UUID= variant require udev as well? TIA. -- FSF associate member #7257 -- 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/868voapgol@gray.siamics.net
Re: udev: what does it used for in Debian?
>>>>> Marco d'Itri writes: >>>>> On Oct 24, Ivan Shmakov wrote: >> So, the kernel won't try to autoload a module when the corresponding >> device gets accessed? > Not for *hardware* drivers, since it cannot know which driver is > needed. Not even via modprobe.conf(5)? >> I've never heard of that (and Googling for “linux equiv” doesn't >> seem to return anything relevant to the problem.) What's it? > I meant equivs. Somehow, I've totally missed this one. Which, indeed, I've a plenty uses for. Thanks! > Anyway, I think that if you want to learn how udev works then you > should send your questions to an users support mailing > list/newsgroup/forum/etc. Well, seems like there're little specific to Debian in how udev works. Thanks. -- FSF associate member #7257 -- 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/8639eipe2m@gray.siamics.net
Re: udev: what does it used for in Debian?
>>>>> Ben Hutchings writes: >>>>> On Mon, 2011-10-24 at 22:12 +0700, Ivan Shmakov wrote: […] >> BTW, does the root=UUID= variant require udev as well? > Yes, currently the kernel filesystem code does not probe for filesystem > UUIDs. (However, it does support partition UUIDs as used in GPT. You > can use root=PARTUUID= to select from those. ACK, thanks! > But I doubt you're using a GPT.) Actually, I do. CHS addressing (as used in MBR, even if along with LBA) seems to me a bit obsolete (for at least a decade), thus I've moved to use GPT for all the new media almost as soon as I've discovered it. Sometimes, I have to use gptsync(8), though. -- FSF associate member #7257 -- 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/86ty6xoj76@gray.siamics.net
http://www.gnu.org/s/hello/manual/automake/ ?
> Adam Borowski writes: […] > GNU's and the inventor of AM_MAINTAINER_MODE's stance: > http://www.gnu.org/s/hello/manual/automake/maintainer_002dmode.html BTW, this URI seems to me like a thing to be reported to GNU webmasters (Cc:'ed.) The Automake manual should be (and it is) accessible via, e. g.: http://www.gnu.org/s/automake/manual/html_node/ http://www.gnu.org/software/automake/manual/html_node/ I was also surprised to find that the following URI's are also valid (but not, e. g., bash/ or tar/): http://www.gnu.org/s/hello/manual/autoconf/ http://www.gnu.org/s/hello/manual/gettext/ http://www.gnu.org/s/hello/manual/libc/ http://www.gnu.org/s/hello/manual/libtool/ If it was done on purpose, I'd suggest that the respective “parent” page (http://www.gnu.org/s/hello/manual/) should have them hyperlinked. TIA. […] -- FSF associate member #7257 -- 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/86r521mn20.fsf...@gray.siamics.net
Re: Advocating the use of RDF for Debian's published metadata
> Matthias Klumpp writes: […] > It would be very nice, if ftpmasters could tell if they would accept > a new format in the archive or if we should stay with RFC822 which is > used for nearly everything else already. >> Note that the same rationale stands for all metadata to be >> eventually published on the Web by Debian servers. >> Hope this helps. > Thank you for the information... I think RDF would be much more > "open" for other people and apps to use, as the data wouldn't be in a > Debian-specific format. (I can't imagine yet what others would do > with this data, but if more people would use RDF, e.g. other > distributors too, having it all in one standardized and extensible > format would be something valuable) Well, having this data aligned with the RDF model will help interoperability, I guess. One application I have in mind is that it becomes possible to query the Debian Packages and Sources databases using the powerful SPARQL language. In particular, one may quickly check if there're any packages that are transitively dependent on A, while also immediately dependent on B. (Yes, grep-dctrl(1) helps, but it's not quite as powerful a language as the recent edition of SPARQL, not to mention that it's yet another query language to learn.) However, I believe that it's infeasible to change the native format the aforementioned databases, as both it isn't going to be easy to implement, and it may bring considerable burden on both the Debian users and maintainers. Thus, my opinion is that there should be a tool performing conversion from the Debian's native database format to some RDF representation. In particular, rdfproc(1) could become such a tool, provided that Raptor will be extended to parse RFC 822. That being said, I don't see such a conversion as a simple and straight-forward process. In particular, should a package stanza be transformed into a named (as per Package:) or blank node (with Package: as an explicit relation)? The Depends: a, b and Depends: a | b may both have an RDF list in the object position, but how to distinguish between them? And how a line such as Depends: a (>> 0.1) should be expressed? Should the package names be encoded as string literals, or should they be transformed into URI's instead? There're quite a few choices to be made by the one volunteering for this. These questions were in my TODO list for some time (filed under Category: nifty hack, as I'm yet to see any serious practical uses for such a thing), but I'm short of spare time these days, and won't probably be able to do much, apart from participation in the discussions on this subject. -- FSF associate member #7257 -- 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/86hb2ng5bt.fsf...@gray.siamics.net
Re: Bug#645656: network-manager in Gnome
> Jon Dowland writes: > On Tue, Nov 01, 2011 at 02:56:53PM +, Ian Jackson wrote: >> We should do it when we judge that the benefits are worth the costs. >> In this particular case the costs seem to be minimal. There isn't >> even a direct patch-carrying cost, since the dependency is expressed >> in our own control files. > What should it be called: gnome-without-network-manager? > I really don't like evolution. Can I have a gnome-without-evolution? > (Only half-joking. I *really* don't like evolution). > Where do you draw the line? > (Of course, any Debian developer can freely create such a dependency > package, it doesn't have to be the GNOME maintainers.) > In case it isn't clear, I don't think it's a good idea. Well, I seem to jump into the discussion without thoroughly reading all the postings (and I've never tried to install the gnome package, BTW), but the issue with network-manager seems to me much easier to solve than the one with evolution, as the former is in Recommends:, while the latter is in Depends:. The difference is that there could be a «negapackage» (marked as manually installed with APT), with the sole purpose of having a Conflicts: network-manager line. (Why, such a package could simply be done with equivs!) Then, it was my understanding that APT will instantly remove network-manager (and its respective dependencies) should the negapackage be installed, and will never try to install the offending package until an explicit user request. Therefore, I'm curious if the Debian metapackages could be switched to primarily use Recommends:, and not Depends:? (So that the users could then have a conflicting package installed, or simply remove the offending package manually.) -- FSF associate member #7257 -- 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/86aa8fg3nn@gray.siamics.net
Re: Increasing minimum 'i386' processor
> Ben Hutchings writes: > On Sun, 2011-11-20 at 23:44 +0100, Cesare Leonardi wrote: […] >> While i might agree with the exclusion of 486 cpu classes (somewhere >> i have a Winchip C6 200 MHz but i consider it unusable except for >> very limited tasks), i think that excluding 586 could be too >> aggressive. AMD K6-2 processors doesn't have CMOV, because when i >> try to use various rescue CD on some of these machine, they don't >> boot with a messages informing of the missing instruction. These >> processors are about 15 years old but are still useful and usable >> today and maybe still for Wheezy+1. I think that would be a pity if >> Debian will not provide anymore a kernel for this old cpus. > Maybe you think it's a waste to replace old PCs, but in many cases > it's a waste of money to keep them running. Electricity isn't > getting any cheaper and modern systems are much better at > power-saving. I'm not sure about ARM, but one of my K6-based systems apparently has power consumption below or comparable to that of one of my Intel Atom ones. (Though the performance of the former is obviously lower.) One more observation is that the 80386-based systems and the like didn't require any coolers. That being said, I'm now considering moving to ARM-based hardware, such as the Raspberry Pi computer, for the tasks that don't require much CPU cycles. -- FSF associate member #7257 -- 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/86k46soboo@gray.siamics.net
Re: Processor microcode update packages
> Henrique de Moraes Holschuh writes: > On Fri, 28 Sep 2012, Eric Valette wrote: >> >> >> >> >> >> Reading the thread about microcode, I wonder why […] > 1. No html, please. And, especially, no /invalid/ HTML, please. […] -- Advocating the judicious use of XML applications at the Internet at large. Stop the use of proprietary formats on the Web and e-mail! -- 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/86vcexsdsv@gray.siamics.net
Re: ${HOME} vs. g_get_home_dir ()
>>>>> Simon McVittie writes: >>>>> On 26/09/12 18:15, Ivan Shmakov wrote: >>>>> Simon McVittie writes: >>> Please research previous discussion to check that you're not >>> missing arguments that have happened in the past, >> Any particular pointers? > Following the git history points to > <https://bugzilla.gnome.org/show_bug.cgi?id=2311>, which raises > interesting issues regarding running GUI applications from under > su/sudo (which is generally a bad idea, but back then there was > little alternative). There's also the analysis at [1]. Unfortunately, it seems that the possibility of the user /intentionally/ changing his or her own HOME was never considered (and neither such concerns are reflected in the documentation.) E. g.: --cut-- It turns out that most of this time, this is irrelevant. login sets $HOME and until you switch users, it will be left unchanged. The case where it becomes an issue is with some "execute a program as another user" commands. There is some difference in behavior here. --cut-- Should the target user be a non-privileged one, my suggestion (to only use HOME if it points to a directory which is both accessible and owned by the “now-current” user) should relieve the concerns listed. On the other hand, when the target user is ‘root’ (UID 0), either of these behaviors may be valid (depending on the exact circumstances, as was noted elsewhere in this thread), so this check shouldn't be done (should we follow the general principle of “root knows what it wants.”) [1] http://mail.gnome.org/archives/gtk-devel-list/2002-March/msg00066.html -- FSF associate member #7257 -- 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/86r4pls8w9@gray.siamics.net
[OT] kernel modules
> Eric Valette writes: […] > I do not want to compile microcode tool as a module because module > loading juts slows down the boot process and contrarilly to many > other package requiring firmware, this one does not enable to load > firmware when not compiled as a module. > So it does not work for people compiling their own kernel and not > using modules (when you tailor your kernel for a given machine, > modules are just slowing the boot process and do not bring anything). Unless under very specific circumstances, the use of a modular kernel brings one the ability to replace the particular hardware the system runs on at will. Say, it's possible to replace a just burned motherboard with an Intel CPU with a different one having an AMD CPU instead. Or one may take the HDD holding the system and put it into a wholly different box, while often retaining the ability to boot. For these reasons, in the majority of cases, compiling a non-modular kernel doesn't worth the effort, and may also be harmful to the system's operation. -- FSF associate member #7257 -- 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/86txuhqk91.fsf...@gray.siamics.net
Re: mass bug filing about versioned dependency on the libhdf5-7 virtual package
>>>>> Julien Cristau writes: >>>>> On Sun, Sep 30, 2012 at 00:28:15 +0700, Ivan Shmakov wrote: >> I tend to think that a re-build (via binNMU or otherwise) will be >> sufficient for most of the packages affected. >> Unless there'll be objections, I'm going to file the respective bug >> reports regarding the versioned dependency on libhdf5-7 against the >> following packages. (The affected versions and architectures >> [though only amd64 and i386 were tested] are shown, as well as the >> Depends: list items triggering the check.) > NAK. If a binNMU is all that's needed then please don't file bugs > against the packages. See http://wiki.debian.org/binNMU ACK, thanks for the pointer! The problem is that I'm yet unsure whether a binNMU will be sufficient or not. My analysis is below, and unless there'd be objections, I'd be filing a bug against release.debian.org, with the binNMU entries as follows. nmu libcgns_3.1.3.4-1 . ALL . -m 'Rebuilt against libhdf5-7 >= 1.8.8-7.1' nmu nexus_4.2.1-svn1614-1 . ALL . -m 'Rebuilt against libhdf5-7 >= 1.8.8-7.1' nmu r-cran-hdf5_1.6.10-1 . ALL . -m 'Rebuilt against libhdf5-7 >= 1.8.8-7.1' nmu tessa_0.3.1-6 . ALL . -m 'Rebuilt against libhdf5-7 >= 1.8.8-7.1' nmu udav_0.7.1.2-3 . ALL . -m 'Rebuilt against libhdf5-7 >= 1.8.8-7.1' AIUI, the packages affected are exactly those built against pre-1.8.8-7.1 versions of the Source: hdf5 libraries. That may explain the versioned dependency, and may be a good indication for that a binNMU will be sufficient to get the issue fixed. --cut: http://packages.debian.org/changelogs/pool/main/h/hdf5/hdf5_1.8.8-9/changelog -- hdf5 (1.8.8-7.1) unstable; urgency=low * Non-maintainer upload. * Stop building the c++ libraries, nothing uses them. And don't version the libhdf5-7 symbols file, so the dependency can also be satisfied by the mpi packages' Provides. * Use DEB_HOST_ARCH instead of DEB_BUILD_ARCH in debian/rules. * Don't require root for debian/rules clean. -- Julien Cristau Sat, 18 Feb 2012 12:25:35 + --cut: http://packages.debian.org/changelogs/pool/main/h/hdf5/hdf5_1.8.8-9/changelog -- As per http://packages.qa.debian.org/, all the packages I've listed before entered unstable prior to 2012-02-18 (except for Source: tessa, which was uploaded a couple of days after.) http://packages.qa.debian.org/libc/libcgns.html • [2012-01-24] Accepted 3.1.3.4-1 in unstable (low) (Sylvestre Ledru) http://packages.qa.debian.org/n/nexus.html • [2011-07-31] Accepted 4.2.1-svn1614-1 in unstable (low) (Tobias Stefan Richter) NB: apparently, nexus was re-built once as 4.2.1-svn1614-1+b1 on 2012-01-26 (before hdf5_1.8.8-7.1, and still bearing a possibly unwarranted versioned dependency on libhdf5-7.) http://packages.qa.debian.org/r/r-cran-hdf5.html • [2012-01-18] Accepted 1.6.10-1 in unstable (low) (Dirk Eddelbuettel) http://packages.qa.debian.org/t/tessa.html • [2012-02-20] Accepted 0.3.1-6 in unstable (low) (Josselin Mouette) http://packages.qa.debian.org/u/udav.html • [2012-01-25] Accepted 0.7.1.2-3 in unstable (low) (Salvatore Bonaccorso) TIA. -- FSF associate member #7257 -- 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/86fw5wp27b@gray.siamics.net
Bug#689572: nmu: packages linked against libhdf5-7 << 1.8.8-7.1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: debian-devel@lists.debian.org, debian-scie...@lists.debian.org There're several packages currently in Debian testing having a versioned dependency on the semi-virtual libhdf5-7 package (apparently as the result of being built prior to Source: hdf5 1.8.8-7.1 propagating to testing on 2012-02-23.) Consequently, these packages cannot be installed along with any of the other libraries providing libhdf5-7 (check, e. g., [1].) I'm therefore suggesting re-building these packages against the now-current libhdf5-7, with binNMU's as specified below. TIA. nmu libcgns_3.1.3.4-1 . ALL . -m 'Rebuilt against libhdf5-7 >= 1.8.8-7.1' nmu nexus_4.2.1-svn1614-1 . ALL . -m 'Rebuilt against libhdf5-7 >= 1.8.8-7.1' nmu r-cran-hdf5_1.6.10-1 . ALL . -m 'Rebuilt against libhdf5-7 >= 1.8.8-7.1' nmu tessa_0.3.1-6 . ALL . -m 'Rebuilt against libhdf5-7 >= 1.8.8-7.1' nmu udav_0.7.1.2-3 . ALL . -m 'Rebuilt against libhdf5-7 >= 1.8.8-7.1' The hdf-eos5_5.1.14+dfsg.1-1 currently in Debian unstable fixes the issue (as well as a few others), but unless it's unblocked (and enters Debian testing), it has to be re-built just as well: nmu hdf-eos5_5.1.13.dfsg.1-3 . ALL . -m 'Rebuilt against libhdf5-7 >= 1.8.8-7.1' [1] http://packages.debian.org/wheezy/libhdf5-7 JFTR, the respective Source: hdf5 Debian changelog [2] entry is: --cut: http://packages.debian.org/changelogs/pool/main/h/hdf5/hdf5_1.8.8-9/changelog -- hdf5 (1.8.8-7.1) unstable; urgency=low * Non-maintainer upload. * Stop building the c++ libraries, nothing uses them. And don't version the libhdf5-7 symbols file, so the dependency can also be satisfied by the mpi packages' Provides. * Use DEB_HOST_ARCH instead of DEB_BUILD_ARCH in debian/rules. * Don't require root for debian/rules clean. -- Julien Cristau Sat, 18 Feb 2012 12:25:35 + --cut: http://packages.debian.org/changelogs/pool/main/h/hdf5/hdf5_1.8.8-9/changelog -- The PTS entries for the packages affected are as follows. http://packages.qa.debian.org/h/hdf-eos5.html • [2012-02-24] hdf-eos5 5.1.13.dfsg.1-3 MIGRATED to testing (Britney) http://packages.qa.debian.org/libc/libcgns.html • [2012-01-24] Accepted 3.1.3.4-1 in unstable (low) (Sylvestre Ledru) http://packages.qa.debian.org/n/nexus.html • [2011-07-31] Accepted 4.2.1-svn1614-1 in unstable (low) (Tobias Stefan Richter) (Although nexus was re-built once as 4.2.1-svn1614-1+b1, it was on 2012-01-26, thus before hdf5_1.8.8-7.1, and still bearing a possibly unwarranted versioned dependency on libhdf5-7.) http://packages.qa.debian.org/r/r-cran-hdf5.html • [2012-01-18] Accepted 1.6.10-1 in unstable (low) (Dirk Eddelbuettel) http://packages.qa.debian.org/t/tessa.html • [2012-02-20] Accepted 0.3.1-6 in unstable (low) (Josselin Mouette) http://packages.qa.debian.org/u/udav.html • [2012-01-25] Accepted 0.7.1.2-3 in unstable (low) (Salvatore Bonaccorso) -- FSF associate member #7257 -- 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/86txuan2ki.fsf...@gray.siamics.net
Re: where is the DNSSEC root key?
> Philipp Kern writes: > On Thu, Oct 04, 2012 at 03:10:01PM -0400, Chris Knadle wrote: >> Last I looked into this [which has admittedly been a while], Bind 9 >> was the only DNS server that had actually implemented DNSSEC, and >> the others I looked at (PowerDNS, djbdns, tinydns) had stated (IIRC) >> that they were /not/ going to be implementing it. > Obviously there are also recursive resolver implementations, like > unbound. To the client they look like DNS servers, too. (And you > really want to use one of them on your local machine to do the DNSSEC > validation.) > Generally plain servers do not care about the key, it's just the > recursive resolvers that need it. To note is that dig(1) (of dnsutils) implements such a resolver (while not being a DNS server.) With +sigchase and +trusted-key=, it's perfectly capable of DNSSEC validation. >> The problem with this idea is that files installed by Debian >> packages must be unique in order to avoid file conflicts between >> packages. One way around this issue is via 'alternatives'. > Alternatives don't make sense. A dedicated packages might make some. Yes. Such a package should also include the ISC DNSSEC Look-aside Validation [1] trusted key, BTW. [1] https://dlv.isc.org/ -- FSF associate member #7257 -- 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/86pq4xldzz@gray.siamics.net
Re: Packages removing alternatives on upgrade
> Russ Allbery writes: […] > It's an improvement. Guillem makes a good argument that you should > drop deconfigure as well, which means that: > if [ "$1" = "remove" ] ; then > update-alternatives --remove > fi > is probably the best thing to use right now. […] > (Note that while common, I've never been fond of that case statement > construction, since it means that we can't introduce new maintainer > script actions without modifying lots of maintainer scripts that may > not need to be modified otherwise.) ? How is the ‘if’ statement above different to, say: case "$1" in (remove) update-alternatives --remove ;; esac -- FSF associate member #7257 -- 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/86wqz1k2nb@gray.siamics.net
non-developer packages depending on gettext?
I find somewhat unusual for the following packages to depend on gettext, given that the latter is a collection of utilities of interest primarily to software developers and maintainers (as stated in its own Description:.) Could someone please clarify on this? TIA. gnacaudio converter for GNOME gosaWeb Based LDAP Administration Program istanbulDesktop session recorder producing Ogg Theora video poker-web Web interface to a poker-network server (I've also filed Bug#690860 against Source: gnunet, which, AIUI, the maintainer intents to fix by dropping the dependency.) -- FSF associate member #7257 -- 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/861ugv9hef@gray.siamics.net
Re: non-developer packages depending on gettext?
> Neil Williams writes: […] > Check if the package contains a shell script which supports > translated output strings — such packages should Depend: gettext-base > rather than drop the dependency entirely. > I've had a quick look at gnas and it does seem that this is a case > where gettext-base is required, but not gettext. ACK, thanks for the information. To note is that Source: gnunet has contrib/report.sh, which calls gettext(1), but it doesn't seem to be propagated to any of the binaries currently depending on gettext. > gettext should only be necessary for packages or tasks which > *manipulate* PO files directly, rather than use the processed .mo > files to generate translated output. So, Build-Depends: yes, > Depends: probably a bug. gettext-base is only really needed when the > package provides shell scripts with translated output because those > evaluate the gettext process at runtime but that only requires > gettext-base, not gettext. > Could be worth filing a wishlist bug against lintian because it > should be quite easy to spot. ? I see no easy way to discern between these three cases (the dependency is valid, depend on gettext-base instead, drop the dependency altogether.) -- FSF associate member #7257 -- 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/86d30e8mco@gray.siamics.net
Re: non-developer packages depending on gettext?
>>>>> Neil Williams writes: >>>>> Ivan Shmakov wrote: >>>>> Neil Williams writes: […] >> To note is that Source: gnunet has contrib/report.sh, which calls >> gettext(1), but it doesn't seem to be propagated to any of the >> binaries currently depending on gettext. > You've misunderstood the gettext packaging. > $ dpkg -S `which gettext` > gettext-base: /usr/bin/gettext > So packages/scripts which call gettext should not depend on gettext > but on gettext-base instead — that's the point. The point is that I haven't checked for gettext(1) the first time I've examined the gnunet source package. So, even though I was sure that the dependency on gettext was unwarranted, I didn't actually rule out gettext-base. […] >>> Could be worth filing a wishlist bug against lintian because it >>> should be quite easy to spot. >> ? I see no easy way to discern between these three cases (the >> dependency is valid, depend on gettext-base instead, drop the >> dependency altogether.) > 0: Manipulating PO files directly should only happen during package > builds, so either the package is itself a build tool (like po4a) or > the dependency goes into Build-Depends. I understand the logic. What I can't understand is how to implement it as a lintian check. (There isn't really a “this package is a build tool” flag. There're Tags:, but they may be misleading; consider, e. g., gnuplot bearing suite::gnu.) > 1: Depend on gettext-base but not gettext when the package calls > /usr/bin/gettext, dgettext and/or ngettext directly (all from > gettext-base) rather than the other executables in the gettext binary > package which do stuff like manipulating or reporting on PO files. I don't see an easy way to check for calls to gettext(1), etc., either. Certainly, we can grep the source, but how reliably (and specific) would that be for a lintian check? > 2: Drop any dependency when no calls to gettext can be found in the > source and it isn't a build tool. Languages other than shell have > in-built ways of using the .mo file prepared through PO and gettext > to output translated text at runtime. This has nothing to do with > running gettext itself. Languages may also have their own packaging > support for this, e. g. liblocale-gettext-perl (which itself uses the > libc support, not gettext-base). So, at least we could safely warn about a dependency on gettext-base for a package containing no Shell scripts. Still, it doesn't seem to rule out a dependency on gettext. -- FSF associate member #7257 -- 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/86sj91z3vg@gray.siamics.net
[OT] XML
> Norbert Preining writes: [...] > Ever heard of grep, sed, awk, all these nice things that make > your life happy. Trash them when you are doing XML. JFTR: there's xmlstarlet(1), which is capable enough to replace awk(1), sed(1), and grep(1) (which is more often than not gets mixed with awk(1) and sed(1), even though its functions are effectively embedded within the former two) on most uses. And then, every other high-level language has libraries for XML processing. Of which Perl is close enough to Awk to hardly ever bother learning the latter at all. Seriously, XML takes a lot of concerns off an application programmer. It provides quoting, arbitrary hierarchical structure, support for different encodings, etc. Why, don't you think that $ grep '[[:lower:]]' FILE is ever supposed to work? For surely it isn't: grep has no way to know the encoding of the input file, and relies on the locale instead. On the contrary, XML allows for the encoding to be specified explicitly via a processing instruction. And then, there's XPath, which takes the input dataset structure into account. (Care to provide an example of grepping out the VALUE for KEY of [SECTION]?) … Oh how I'm glad that there're prominent TeX figures that are actively using XML nowadays! I take the point, however, that the XML toolset is not nearly as mature and complete as that for “plain text.” It /is/ an issue, and I hope it will be resolved. It /is/ reasonable to use the two-level hierarchial [SECTION] KEY = VALUE format for configuration files, for it has better readability (as long as the common tools are considered.) What is /not/ reasonable is to label and shun XML for what it's not. -- Advocating the judicious use of XML applications at the Internet at large. -- 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/86vccs4y6f.fsf...@gray.siamics.net
Re: [OT] XML
>>>>> Jakub Wilk writes:
>>>>> * Ivan Shmakov , 2012-11-26, 14:32:
>> Seriously, XML takes a lot of concerns off an application
>> programmer. It provides quoting, arbitrary hierarchical structure,
>> support for different encodings, etc. Why, don't you think that
>> $ grep [[:lower:]]' FILE is ever supposed to work? For surely it
>> isn't: grep has no way to know the encoding of the input file, and
>> relies on the locale instead. On the contrary, XML allows for the
>> encoding to be specified explicitly via a processing instruction.
>> And then, there's XPath, which takes the input dataset structure
>> into account.
> How do you search for a lowercase letter in XPath?
With fn:matches (WHERE, "\p{Ll}")?
Specifically, if you're interested in all ENTRY elements, whose
respective KEY's contain a lower-case letter, it may look
something like the following:
//x:entry[fn:matches (x:key/text (), "\p{Ll}")]
For instance, using xqilla(1) (xmlstarlet(1) doesn't seem to
support fn:matches ()):
$ cat < cf.xml
there be an all-lowercase key
all-lowercase key's value
THERE BE AN ALL-UPPERCASE KEY
all-uppercase key's value
There be a Mixed-case Key
mixed-case key's value
$ xqilla -i cf.xml \
<(printf %s\\n '\
declare namespace x="urn:uuid:95364fc4-e68d-492e-a122-7b3b37bdab10";' \
'//x:entry[fn:matches (x:key/text (), "\p{Ll}")]')
there be an all-lowercase key
all-lowercase key's value
There be a Mixed-case Key
mixed-case key's value
$
--
FSF associate member #7257
--
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/86mwy34ojh@gray.siamics.net
Maildir vs. mbox in Debian
> Adam Borowski writes: […] > Quoting from that page: > # With the advent and now widespread adoption of the superior Maildir > # format over the past several years, the entire "mbox" family of > # mailbox formats is gradually becoming irrelevant, and of only > # historical interest. > which is no news. And you can't really run a mail server in mbox if > you ever receive mail from business users: for them, sending the text > as an image wrapped in a Word document is the rule rather than an > exception[1]. Unfortunately, it's not just the business users. The so-called “office productivity suites” are seemingly widespread in academia and science, for instance. […] > So, what's the reason mbox is still the default in Debian? That's what I wonder about, too. […] > With current disk sizes, no one should care about a few gigs here, a > few gigs there. Unless you need to read a mbox linearly, that is. Seconded. JFTR: I've switched my mailservers to Maildir c. 2006, for much improved performance and manageability, and never had an issue with that. -- FSF associate member #7257 -- 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/86haoa18tg.fsf...@gray.siamics.net
Re: Maildir vs. mbox in Debian
> Christoph Anton Mitterer writes: […] > But it also has disadvantages to the mbox formats which may be > crucial for some people: > - wasting a lot of storage, which can be significant even if you use > small file systems block sizes... Only as long as static mbox files are considered. However, removing a message from an mbox requires an amount of free space equal to the size of the mbox in question, sans the message to be removed. OTOH, removing a message from Maildir requires no additional filesystem space. > - full text search will typically be slower, as one has to open/close > many files What are the estimates? And wouldn't it be better to use some kind of a specialized search engine if searching is deemed “crucial”? I guess that it may render the difference between the formats somewhat irrelevant. -- FSF associate member #7257 -- 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/86d2yxyqjj@gray.siamics.net
[OT] config file formats
> Игорь Пашев writes:
> 2012/12/2 Vincent Lefevre :
>> No, that's not sufficient. You may want relations between key-value
>> pair. For instance, if you have a line with a key "foo", then a line
>> with a key "bar" must also exist. Or a line with a key "number" must
>> have a value that is a number (more generally matching some regexp).
> For such configs general programming languages are good.
> E. g. perl:
> $foo = "wtf";
> if ($foo && !$bar) {
[…]
If and only if such “configuration files” will only /ever/ be
read by Perl-enabled tools. Which may pose a problem, e. g.,
should a port of the software in question to a resource-limited,
embedded system be considered at some point.
The problem with programming languages is that one can't merely
read a file in such a language, and extract some kind of result
warranted to be sensible. One has to /execute/ it instead.
(Some extra care is likely to be required for the “privileges'
gate” case as well.)
The same applies to *roff and TeX, BTW.
--
FSF associate member #7257
--
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/86hao4xod6.fsf...@gray.siamics.net
[OT] config file formats
> Vincent Lefevre writes: > On 2012-12-02 22:04:52 +0100, Wouter Verhelst wrote: > On Sun, Dec 02, 2012 at 12:31:00PM +0100, Vincent Lefevre wrote: […] >>> You may want relations between key-value pair. For instance, if >>> you have a line with a key "foo", then a line with a key "bar" must >>> also exist. Or a line with a key "number" must have a value that >>> is a number (more generally matching some regexp). >> That's not validation of the format, that's validation of the data. > That's validation of the config file. This is what XML validation > does: it checks whether the file is valid according to some schema. That being said, I believe that the reason XML became so widespread (and, conversely, it's ancestor SGML fell into disuse) is precisely because the former decoupled the format (representation, and its inherent semantics) itself from the validation. That way, we were able to forgo DTD and develop such (arguably, much better) XML schema representations such as XML Schema and RELAX NG. (The latter is the one used by Emacs.) I'm not aware of any “standard” schema representations for the (sectioned) key-value file formats, however. >> I've never seen any config file with nested config blocks that >> didn't make the file more complex and less easy to understand. > Wrong. Nested blocks make config files easier to understand. > Otherwise for the same feature (e. g. conditionals), one would need > things like horrible state variables. For instance, think about > redesigning a procmailrc with the ini format... On the second sight, the difference between, e. g.: d f i and, e. g.: [a.b] c = d e = f [a.g] h = i is mostly superficial. -- Advocating the judicious use of XML applications on the Internet at large. -- 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/868v9fy5rm.fsf...@gray.siamics.net
Re: Providing official virtualisation images of Debian
> Moritz Mühlenhoff writes: > Hi, I believe it's high time we start to providing Debian in form of > official virtualisation images. In contrast to the ISOs currently > provided it allows a quicker evaluation/testing of Debian (and can > also be very useful for testing (e. g. someone wrote on > debian-release that he doesn't have access to oldstable/stable > systems, with prepared virtualisation images that would no longer be > an issue). Most of the time, I'd prefer to use chroot'ed environments for getting access to other Linux-based systems (with comparable kernel versions.) > For many setups this could even replace the installer since software > selection and hostname can easily be tweaked post-install. While I can't readily advocate for one approach or the other, there certainly is an alternative. Namely, example preseed files for common in-VM installation scenarios may be provided (within a Debian package, in particular.) Also, it could be made easy and straightforward to select a preseed file external to the image itself from the bootloader's menu. Given a ready to use preseed file, installing Debian is a matter of minutes (operator's time.) Also, this way, the issue of authenticity checking is already solved, and there's no need to waste any disk space to host extra image files. With Qemu (KVM), the process may be further simplified by providing a tarball with the respective kernel and initramfs images, and an (example) script to start the installer, in addition to the preseed file. Since Qemu contains its own kernel bootloader, which can be configured from the command line, the process could be made almost fully-automated. The other virtualization solutions may demand a configuration file of a sort. The examples, templates, or generators of such files may also be provided. The only configuration option that I expect to often require operator's attention would be the HTTP proxy URI. […] -- FSF associate member #7257 -- 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/867h75q7gn@gray.siamics.net
Re: support for installing unconfigured systems (VM images, Debian Live images, preinstalled mobile/tablet images)
> Daniel Baumann writes: > On 07/26/2011 12:33 PM, Samuel Thibault wrote: >> Well, isn't it simply about not configuring a few packages? > no; see openssh-server.postinst, in the discussed use-case you want > to run everything in there except the creation of the host keys. > the only left problem to work out is to define a way so that upon > start, if enabled (which would be by default to yes upon boot), those > packages that have not configured their "private" stuff yet, to run > their postinsts again (to execute only those commands that create it, > see my other mail before). Given how a usual .postinst script is written, its repeated execution isn't expected to do any harm. AIUI, the .postinst scripts may be re-executed with dpkg-reconfigure(8). The --all option may be handy, as well as the --frontend=noninteractive and --unseen-only ones. -- FSF associate member #7257 -- 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/86y5zkpezw@gray.siamics.net
Re: Bug#637422: ITP: libaacs -- free-and-libre implementation of AACS
> Alessio Treglia writes: […] > Features: > * Portability: Currently supported platforms are GNU/Linux, Windows, > MacOS X. The main dependency is libgcrypt for all cryptographic > functions. > * Freedom: libaacs is released under a Free Software license, > ensuring it will stay free. > * Legal: libaacs does not include any key or certificate and respects > copyright. My English skills may be failing me, but to my eye, “legality” can be a feature, while “legal” can't. […] -- FSF associate member #7257 -- 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/86ei0qach5@gray.siamics.net
Re: mentors.debian.net runs the debexpo code now
> Paul Wise writes: > On Fri, Aug 12, 2011 at 5:02 PM, Ian Jackson wrote: […] > debexpo adds this to the above: > look for comments on the mentors.d.n website. > There never was any guarantee that subscribing to -mentors meant you > would know about other reviews. Indeed, it often happens that a > package gets uploaded to the archive and the maintainer/sponsor don't > even reply to the RFS saying that the package was uploaded. Or the > reviews moved to IRC or some team's mailing list. This doesn't > change with the new mentors, it just introduces yet another place to > look for reviews. Perhaps the comments on the site will become the > primary place for feedback, but I doubt it considering Debian's > mail-centric culture. I wonder, is it possible to add a bit more magic to debexpo, so that the comments made via the Web interface would be forwarded to the list, and vice versa? Perhaps Gmane's engine (which is, IIRC, free software) could be used as an inspiration? -- FSF associate member #7257 -- 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/86ipq280nu@gray.siamics.net
Re: mentors.debian.net runs the debexpo code now
>>>>> Paul Wise writes: >>>>> On Sat, Aug 13, 2011 at 5:12 AM, Ivan Shmakov wrote: >> I wonder, is it possible to add a bit more magic to debexpo, so that >> the comments made via the Web interface would be forwarded to the >> list, and vice versa? >> Perhaps Gmane's engine (which is, IIRC, free software) could be used >> as an inspiration? > Debexpo is software so it should be possible to add anything, as long > as there is a person who feels motivated enough to implement it. Are > you that person? > I imagine that it would be hard to extract mails and present them on > the web, This task is indeed in my queue, but I won't probably be able to get to it this year. > but you could at least give pointers to NEW/incoming, list archives > and the ITP bug replies on the comments page. I. e., the pointers to the related messages (or threads) within the archive? -- FSF associate member #7257 -- 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/86zkjd728o@gray.siamics.net
e2dis: a Jigdo-like tool for Ext2+ FS images
BTW, I've just announced [1] the availability of the code which (given some attention and care) may be turned into a Jigdo-like suite for Ext2+ FS images. (The casuality of fragmentation on such filesystems greatly reduces the applicability of the FS-agnostic Jigdo tool.) Perhaps, this may lessen the burden of the distribution of Debian virtualization images. (Should it become a part of the current practice.) Alternatively, this tool may allow for “smarter” virtualization images' backups. Or, it may be used to save the bandwidth when sending a whole virtualization image, e. g., to demonstrate a hard to reproduce bug. [1] http://thread.gmane.org/gmane.comp.file-systems.ext4/27269 -- FSF associate member #7257 -- 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/86ei0o76wz@gray.siamics.net
Re: e2dis: a Jigdo-like tool for Ext2+ FS images
>>>>> Adam Borowski writes: >>>>> On Sun, Aug 14, 2011 at 03:07:24PM +0700, Ivan Shmakov wrote: >> BTW, I've just announced [1] the availability of the code which >> (given some attention and care) may be turned into a Jigdo-like >> suite for Ext2+ FS images. >> (The casuality of fragmentation on such filesystems greatly reduces >> the applicability of the FS-agnostic Jigdo tool.) > It seems to me that if you instead physically reordered blocks, > actual data extents could be made contiguous, allowing use of > standard Jigdo. Thanks for the suggestion. Unfortunately, the Jigdo's assumption of the continuity of the blocks comprising a file covers the reassembly phase just as well. The blocks of an image may still be reordered to get the desired effect, but they'd have to be reordered back at the time of reassembly, thus requiring a separate relation (file) to do so. Perhaps, the ordering of the blocks on a filesystem can be altered (consistent with the service data of the filesystem itself) to remove fragmentation, but I'm not sure on that, and my limited knowledge of the Ext2FS library doesn't allow me to devise a way to do that. (But I'd ask about it in linux-ext4@.) … On the other hand, the “chunk mapping” model I've used in the current version of the e2dis code is a superset of the model implemented by Jigdo. Therefore, I don't think it'd be infeasible to implement Jigdo support in the image download and reassembly tool I'm planning to develop for e2dis. (BTW, I've posted a very basic image reassembly tool to alt.sources about three weeks ago [2]. It's not compatible with the format used by e2dis, though.) [2] news:86zkk8xhh4@gray.siamics.net > (Of course, that might be not worth the extra effort...) Jigdo has to “discover” octet sequences on an image with hashing, which is computationally expensive. IIRC, Debian's genisoimage(1) was altered to prepare a Jigdo's .template file as part of the image generation, which is much more efficient. I believe that a similar approach could be, and should be, used for the other filesystems as well. […] >> [1] http://thread.gmane.org/gmane.comp.file-systems.ext4/27269 -- FSF associate member #7257 -- 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/86aabc6sf5@gray.siamics.net
Re: mentors.debian.net runs the debexpo code now
>>>>> Arno Töll writes: >>>>> On 13.08.2011 17:36, Ivan Shmakov wrote: >>>> I wonder, is it possible to add a bit more magic to debexpo, so >>>> that the comments made via the Web interface would be forwarded to >>>> the list, and vice versa? >> This task is indeed in my queue, but I won't probably be able to get >> to it this year. > I am also interested to implement a mailing list <-> Expo bridge as > that's very important I think and necessary for future plans I have > with Expo. I was doing some contributions to Expo already in the > last few weeks, but I can't say when/if I find time to start such a > larger sub-task. > If you are interested to implement it, I would very welcome that, but > we should coordinate our plans here. Indeed. However, as I've already noted, I won't be able to get to that task until at (the very) least the next year. > I am not sure if we really need a such a big dependency as a Gmane > like service. I've referenced Gmane as an example of the successful engine used for turning the (news, but mail is quite similar) messages into Web pages and RSS feeds. I don't know their code base all that close, but, IIRC, it's free software, and my opinion is that it'd be pity if we won't be able to reuse it, at least in part. > Its probably enough to subscribe to debian-mentors (e.g. to a server > side mbox) (Just don't use the Unix mbox format for that.) > and track RFS threads by a non-standard header or magic subject / > pseudo tag similar to the BTS control server. Why not the standard Message-Id:, In-Reply-To:, and References: headers? -- FSF associate member #7257 -- 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/8662m06s1o@gray.siamics.net
Re: e2dis: a Jigdo-like tool for Ext2+ FS images
>>>>> Steve McIntyre writes: >>>>> Ivan Shmakov wrote: BTW, the primary Git repository for the project is now located at Gitorious: git://gitorious.org/e2dis/e2dis-devel.git http://gitorious.org/e2dis/e2dis-devel.git https://gitorious.org/e2dis/e2dis-devel The most notable improvement that I made recently is the message digest recording. […] >> IIRC, Debian's genisoimage(1) was altered to prepare a Jigdo's >> .template file as part of the image generation, which is much more >> efficient. I believe that a similar approach could be, and should >> be, used for the other filesystems as well. > That would be absolutely the best way to go, yes. I added the code > into mkisofs and genisoimage, but it has since been abstracted out > into libjte, part of the cdrkit package in Debian. I'm yet to take a look at the code, but do I understand it correctly that Jigdo's .template only allows for a file (as identified by the SHA-1 digest of its contents) to be associated with a contiguous part of the destination image? Such an approach is hardly applicable to Ext2+ FS images. Consider, e. g.: $ /sbin/debugfs +b21e37e0-c722-11e0-9094-001966aaa0b6.ext2 debugfs 1.41.12 (17-May-2010) debugfs: stat <12> Inode: 12 Type: regularMode: 0644 Flags: 0x0 Generation: 3178327445Version: 0x User: 0 Group: 0 Size: 16384 File ACL: 0Directory ACL: 0 Links: 1 Blockcount: 34 Fragment: Address: 0Number: 0Size: 0 ctime: 0x4e48e9c1 -- Mon Aug 15 09:41:21 2011 atime: 0x4e48e9c1 -- Mon Aug 15 09:41:21 2011 mtime: 0x4e48e9c1 -- Mon Aug 15 09:41:21 2011 BLOCKS: (0-11):21-32, (IND):33, (12-15):34-37 TOTAL: 17 debugfs: There, the file's contents in two parts: one occupies image's blocks 21 to 32, inclusive, and the other one 34 to 37, inclusive. It was my understanding that Jigdo's .template cannot associate one SHA-1 with such a non-contiguous chunk. -- FSF associate member #7257 -- 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/86wred1bac@gray.siamics.net
Re: apt repository checker?
> Paul Wise writes: > Within the context of the derivatives census I have been looking at > the apt repositories of our derivatives. I noted that some of them > are affected by #637563 due to directly importing Debian repository > data. I also found some repositories that are not GPG signed. So I > was wondering if we have a tool for checking apt repositories and > looking for common mistakes. Well, checking Sources (and Packages) for Bug#637563 could, as it seems, be implemented (in, say, Awk or Perl) quite easily. Signature checking, as well as the Release parsing & dist/ files download is a bit more tricky. Something like one or two rainy days of coding effort, I guess. -- FSF associate member #7257 Coming soon: Software Freedom Day http://mail.sf-day.org/lists/listinfo/ planning-ru (ru), sfd-discuss (en) -- 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/86ipprt5cz@gray.siamics.net
e2dis status update
>>>>> Steve McIntyre writes: >>>>> Ivan Shmakov wrote: >> It was my understanding that Jigdo's .template cannot associate one >> SHA-1 with such a non-contiguous chunk. > Correct. That could be added as a feature, maybe - we could add > extent-mapping. The format seemed to me a bit ad hoc, so I've used SQLite3 instead. The news is that both the disassembly (e2dis) and reassembly (imrt) tools are now working (but read below for a caution) and available from their public Git repository [1] at Gitorious! [1] https://gitorious.org/e2dis/e2dis-devel The performance of e2dis itself is apparently out of concern: $ tail -n7 -- \ +nohup.out-1314862288 \ +nohup.out-1314881076 ==> +nohup.out-1314862288 <== I: inode: ino=393214, blocks=0, size=0 I: inode: ino=393215, blocks=0, size=0 I: inode: ino=393216, blocks=0, size=0 I: filesystem: payload_blocks=286523 sqlite3_exec (db, `END;', 0, 0, => `(null)') => 0 108.10user 10.19system 2:34.25elapsed 76%CPU (0avgtext+0avgdata 0maxresident)k 8395040inputs+72outputs (7major+1229minor)pagefaults 0swaps ==> +nohup.out-1314881076 <== I: inode: ino=131071, blocks=0, size=0 I: inode: ino=131072, blocks=0, size=0 I: filesystem: payload_blocks=476432 Unknown code ext2 47 #0 for Payload blocks bitmap Unknown code ext2 47 #0 for block bitmap for /dev/stdin 24.90user 3.90system 0:36.49elapsed 78%CPU (0avgtext+0avgdata 0maxresident)k 1044670inputs+32outputs (3major+1203minor)pagefaults 0swaps $ The respecitve filesystems' sizes are as follows: Filesystem 1K-blocks Used Available Use% FILESYSTEM-1 3096336 1146168 1792884 39% FILESYSTEM-2507748477089 4445 100% And the sizes of the resulting indices are: 11054080 (3.5%) 0bca32a2-d46c-11e0-935b-001966aaa0b6.db 6078464 (1.2%) 105f858e-d498-11e0-935b-001966aaa0b6.db (No data in the indices beyond, roughly, the offsets, the hashes, and the inode numbers.) Unfortunately, the performance of the image reassembly tool (imrt) is extremly poor for the filesystems of more than a few MiB's size. (And it seems that there may be subtle bugs, too.) As with jigdo-file(1), imrt doesn't rely on filenames, and instead “guesses” the output chunks the files passed to it correspond by comparing the hashes (SHA-1 and SHA256 as of a726267a.) However, such a comparison is currently implemented in a straightforward yet suboptimal (as in: totally dumb) way, leading to the problem. I still hope to rewrite the respective part of the code and reach a better reassembly rate, and will report to the list. > I'm also thinking of adding code to say "this file from within this > .deb", so we could maybe support jigdo for live images too... That doesn't seem to be necessary: jigdo-file(1) relies on hashes, not filenames; and jigdo-lite(1) could be taught to recognize .deb's and unpack them into a temporary directory, for jigdo-file(1) to pick up the contents. -- FSF associate member #7257 Coming soon: Software Freedom Day http://mail.sf-day.org/lists/listinfo/ planning-ru (ru), sfd-discuss (en) -- 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/86k49r9f28.fsf...@gray.siamics.net
checking if .deb's match Packages
> Henrique de Moraes Holschuh writes:
[…]
> The Debian mirror in mirrors.kernel.org, on the other hand... While
> the apt signature will protect users downloading packages through the
> package manager, users that get binary packages directly are not
> protected.
FWIW, personally, I download both the binary packages /and/ the
signed lists.
[…]
> Do we have a automated way to signature-check every binary and source
> package in a repository against the hashes in the signed release
> files?
sha1sum(1) and sha256sum(1) will do. As for the input format
conversion, the following GNU Awk bit may help:
--cut: packages2sha256.awk --
! /./ {
if (fn != "" && sha256 != "") {
print sha256, "*" fn;
}
fn = ""; sha256 = "";
}
/^Filename: / { fn = $2; next; }
/^SHA256: / { sha256 = $2; next; }
--cut: packages2sha256.awk --
It may also be combined with grep-dctrl(1) to check a subset of
packages, like:
$ find dists/wheezy/ \
-type f -name Packages.bz2 -exec bzcat -- {} + \
| grep-dctrl -s Filename,SHA256 \
-F Priority --regex --pattern=required\\\|important \
| gawk packages2sha256.awk \
| sha256sum -c
--
FSF associate member #7257 Coming soon: Software Freedom Day
http://mail.sf-day.org/lists/listinfo/ planning-ru (ru), sfd-discuss (en)
--
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/86bov2amq8.fsf...@gray.siamics.net
Re: Dependencies of metapackages
> Wolodja Wentland writes: > is there a specific reason why metapackages depend rather then > recommend packages they are meant to pull in? > The rationale behind this question is [0] that we see a plethora of > users in #debian who ask questions like: "Why did apt remove all my > system??⸘one!one!eleven!" > and we have to explain to them that it is because they decided to > remove one of (typically) gnome's dependencies, which caused the > metapackage to be removed as well. The solution is then to either > mark all other dependencies as manually installed, install a smaller > metapackage or a combination of those. Since turning these dependencies into Recommends: is apparently infeasible, it may be useful to amend APT to automatically mark the metapackage's dependencies as manually installed if the metapackage itself is so marked. Or do I miss something obvious with this approach? (Sorry, I'm not familiar with the subject. Beyond knowing to avoid metapackages at all costs, i. e.) […] -- FSF associate member #7257 Coming soon: Software Freedom Day http://mail.sf-day.org/lists/listinfo/ planning-ru (ru), sfd-discuss (en) -- 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/867h5qamdt@gray.siamics.net
Re: Bug#641315: ITP: opendap -- Project for a Network Data Access Protocol
Already in Debian, as it seems. --cut: http://packages.debian.org/sid/libdap10 -- Open-source Project for a Network Data Access Protocol library OPeNDAP provides software that allows you to access data over the internet, from programs that weren't originally designed for that purpose, as well as some that were. While OPeNDAP is the original developer of the Data Access protocol which its software uses, many other groups have adopted DAP and provide compatible clients, servers and software development kits. --cut: http://packages.debian.org/sid/libdap10 -- -- FSF associate member #7257 Coming soon: Software Freedom Day http://mail.sf-day.org/lists/listinfo/ planning-ru (ru), sfd-discuss (en) -- 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/86boupycz0@gray.siamics.net
Depends: logrotate (forever and ever and ever)
>>>>> Andrei Popescu writes: >>>>> On Vi, 16 sep 11, 00:48:25, Ivan Shmakov wrote: [Cc: debian-devel@, for this discussion fits there better.] >> I wonder if there should be a separate mailing list to Cc: such bug >> reports. (debian-dependency-inquisitors@, perhaps?) > I don't think dependencies need any special handling compared to > other bug reports. In cases where you don't agree with the resolution > you can discuss the issue - together with the maintainer - on > debian-devel. Perhaps. >> I seem to remember that there was a longstanding issue with Depends: >> logrotate. Of course, no package should ever be “rendered unusable” >> (which, AIUI, is the very essense of Depends:) should logrotate not >> be installed! To quote the policy: --cut: http://www.debian.org/doc/debian-policy/ch-relationships.html -- The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality. --cut: http://www.debian.org/doc/debian-policy/ch-relationships.html -- Cf.: --cut: http://www.debian.org/doc/debian-policy/ch-relationships.html -- Recommends This declares a strong, but not absolute, dependency. The Recommends field should list packages that would be found together with this one in all but unusual installations. --cut: http://www.debian.org/doc/debian-policy/ch-relationships.html -- >> Yet, there seem to be something like 45 packages that Depends: on it >> as per Debian Wheezy. > Could you provide concrete examples? Sure. $ apt-cache show $(apt-cache rdepends logrotate | sed -e '/^ /!d; s///') \ | grep-dctrl -s Package -F Depends --regex --pattern=logrotate \ | LC_ALL=C sort -u \ | sed -e '/^Package: /!d; s///' | fmt -w72 aolserver4-daemon argus-server atop battery-stats boa cherokee clamav-base clamav-freshclam clamav-milter deejayd deejayd-webui interchange ippl knockd leafnode libvirt-bin lusca mailman mgetty muddleftpd net-acct ninja prayer privoxy pyca pygopherd quagga rabbitmq-server rsnapshot sipwitch sks slbackup snort snort-mysql snort-pgsql squid squid3 tinyproxy twatch uucp $ > I assume packages not logging to syslog do need some rotation of > their logs, otherwise they could render systems unusable by filling > up the drive. The use of logrotate doesn't prevent it; and the lack of such use doesn't force it, either. In particular, when the package is installed into a chroot (say, for testing), the Cron daemon is typically not run from there. Thus, chroot'ed logrotate won't ever be run, and won't have any effect on the free filesystem space. Also, certain server packages may be run both privileged (as a system service) and unprivileged (for just the invoking user.) (Think of, e. g., Rsync, but INN also can be configured in such a way.) There, logrotate is ineffective just as well, as the packaged configuration files certainly won't reference the filenames used by the particular user. Note that there's a reasonable amount of packages which either Recommends: or Suggest: logrotate instead: $ apt-cache show $(apt-cache rdepends logrotate | sed -e '/^ /!d; s///') \ | grep-dctrl -s Package --not -F Depends --regex --pattern=logrotate \ | LC_ALL=C sort -u \ | sed -e '/^Package: /!d; s///' | fmt -w72 atftpd bdii cacti cricket cron ctdb distributed-net dsyslog heartbeat heimdal-kdc horde3 kdm ldirectord liquidsoap masqmail mini-buildd-bld mini-buildd-rep pawserv rsyslog samba selinux-policy-default selinux-policy-mls sendmail-base sugarplum super sympa syslog-ng thttpd tor vsftpd wu-ftpd wwwoffle xinetd xtel xtide zabbix-agent zabbix-proxy-mysql zabbix-proxy-pgsql zabbix-proxy-sqlite3 zabbix-server-mysql zabbix-server-pgsql $ Moreover, there's at least the dpkg package which, while providing logrotate configuration files, doesn't mention logrotate among its dependencies at all. It's therefore my long-standing opinion that the dependency on logrotate should be downgraded to Recommends:, unless, of course, postinst or prerm do actually use anything provided by the logrotate package (which seems to me unlikely.) -- FSF associate member #7257 -- 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/867h55p0r3.fsf...@gray.siamics.net
