> 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 ju
>>>>> 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://gito
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[Sorry for multi-posting.]
I'm curious if there're any GnuPG users interested in public key
data exchange in either Krasnoyarsk, Krasnoyarsk Krai, Russia,
or Novosibirsk, Novosibirsk Oblast, Russia?
I expect to
I wonder, is there a kind of reference of the common command
line interface conventions that the CLI's of the software
included in Debian should adhere to?
E. g., I see that tree (as of 1.5.3-1) doesn't support the --
POSIX options' terminator:
$ tree -- .
>>>>> Russ Allbery writes:
>>>>> Ivan Shmakov writes:
>> 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 pro
>>>>> 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-depe
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
> 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
> syste
> 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, personal
>>>>> 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
> e
> 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 si
>>>>> 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
>>>>> 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,
>>>>> 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
>&
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-agnosti
>>>>> 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 ve
> 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
> 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
> 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 onl
> 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 wro
> 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 w
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 `Dep
> 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, i
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
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, p
> 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' pac
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
vers
>>>>> 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 t
> 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
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.)
> 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
> 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
> 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
>> Th
> 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 m
> 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 lin
>>>>> 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
> 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 depende
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
>>>>> "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 espec
> "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'', s
>>>>> 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
> "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 ite
> 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 probl
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 de
101 - 144 of 144 matches
Mail list logo
