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
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
> 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
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
> 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
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
> 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
> "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:
>>>>> Ivan Shmakov <[EMAIL PROTECTED]> writes:
>>>>> Russ Allbery <[EMAIL PROTECTED]> writes:
>>> or with the period escaped.
>> ... And this is the thing I haven't
> "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
>>>>> "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
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
> 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
>>>>> 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
> 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
> 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
> 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
> 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
>>>>> 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
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
> 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
> 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) an
> 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
> 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
> 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” lab
> 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
> 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 execp
> 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 s
> 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 entir
>>>>> 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
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 w
> 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
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.
> 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
> 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 sam
> 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
> 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
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) un
>>>>> 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 pat
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
a
>>>>> 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
> 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
>>>>> 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. T
> 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
>>> /"...
>> W
>>>>> 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). Th
> 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
>
> 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 du
> 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 sy
> 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 g
>>>>> 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.,
> 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
>
> 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 wa
>>>>> 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,
&
> 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 configure
>>>>> 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
> 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.
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-xo
>>>>> 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
>>
>>>>> 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, than
>>>>> 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_W
>>>>> 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
>
>>>>> 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 d
> 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
> 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
>> event
> 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
> 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
> 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
judici
>>>>> 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,
> 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
>>>>> 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'l
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 p
> 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 s
> 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
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
> 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 get
>>>>> 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
>&g
> 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 th
>>>>> 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
> 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.
> 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 co
> Игорь Пашев 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 th
> 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
> 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
> 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
> 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
> 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
>>>>> 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
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
>>>>> 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
>&
>>>>> 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,
>>>>> 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
> 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:
>> 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
> 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
> 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
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
>>>>> 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
1 - 100 of 144 matches
Mail list logo
