> The same applies to the GNOME/GTK stack, where Flatpak is the way to go
> for active development. libgtk-3-dev is really only for building Debian
> packages from their point of view, too.
Perhaps, but what matters is not upstream's point of view but Debian
user's point of view.
My perception i
On Wed, Feb 17, 2021 at 9:33 PM Johannes Schauer Marin Rodrigues
wrote:
[...]
> And then I run "cargo build". Every time I get a message like:
>
> error: no matching package named `foo` found
>
> I install librust-foo-dev until finally:
>
> Parent pid 535147, child pid 535148
> Child p
Quoting Andrej Shadura (2020-11-10 10:27:44)
> On Tue, 10 Nov 2020, at 08:28, Paul Wise wrote:
> > > The current proposal is to reduce the main Packages.xz files size by
> > > splitting[4] out all of the packages that are not intended for users,
> > > writing those into an own file. Those packages
The same applies to the GNOME/GTK stack, where Flatpak is the way to go
for active development. libgtk-3-dev is really only for building Debian
packages from their point of view, too.
But at least GNOME has scheduled releases which enable Debian stable to
maintain it, while npm, pip, gems, cargo e
Hello,
(I thought I had sent this mail already, but it looks I haven't)
One of the basic things we want is that users can get the source of
their packages, modify a little, and make a new package for their own
use. So in particular we want to be able to "apt source" and get all
the sources, in t
Matthias Klose writes:
> On 11/11/20 8:37 PM, Russ Allbery wrote:
>> Rust and Go both vendor dependencies during their build. Python isn't
>> really analogous; you *can* do something similar with virtualenvs, but
>> (a) Python doesn't really have a build the way that Rust and Go do
>> because on
On 11/11/20 8:37 PM, Russ Allbery wrote:
> Simon McVittie writes:
>> My understanding is that Rust and Go code literally doesn't have
>> analogous built-in system-wide search paths for third-party libraries,
>> and when building Debian packages that contain Rust and Go code, we have
>> to invent t
On Fri, Nov 13, 2020 at 19:28, Tomas Pospisek
wrote:
This solution seems to be too trivial that nobody would have though
of it, so what is it that I (and I guess many Debianers) are missing?
*t
Additionally these libraries change too fast and most of the time,
there is no long term suppo
On 13.11.20 20:51, Wolfgang Silbermayr wrote:
[...detailed explanation of why the buildlibs proposal for Rust is
necessary...]
Thanks a lot for the explanation Wolfgang!
*t
On 11/13/20 7:28 PM, Tomas Pospisek wrote:
> Hi Antonio (and anybody else that understands the technical problem involved
> here),
>
> I've been reading the whole thread and it seems to me that the reason, why
> Rust/Go build-time "libraries" need to be handled differently from all the
> other exi
Hi Antonio (and anybody else that understands the technical problem
involved here),
I've been reading the whole thread and it seems to me that the reason,
why Rust/Go build-time "libraries" need to be handled differently from
all the other existing stuff in the world and that "no user ever wan
On Ma, 10 nov 20, 10:06:24, Paul Wise wrote:
> On Tue, Nov 10, 2020 at 9:28 AM Andrej Shadura wrote:
>
> > Development packages for Rust and Go usually only ship source code.
>
> This reminds me of the proposal for installable source packages that
> one could (Build-)Depend on. Seems like that pr
Simon McVittie writes:
> I think perhaps the key thing here is that Python does *have* a
> reasonably well-defined system-wide search path for packages outside the
> Python core (/usr/lib/python3/dist-packages). Even if some projects
> prefer to use pip instead of dist-packages, they can't claim
On Wed, 11 Nov 2020 at 14:26:55 +0100, Matthias Klose wrote:
> If you ask some upstreams of Python based software, their recommendation would
> be to use pip, and probably conda (a cross OS distribution focusing on Python)
> to do upstream development. If you ask casual users, you probably will ge
On Wed, Nov 11, 2020 at 02:26:55PM +0100, Matthias Klose wrote:
> On 11/10/20 10:51 PM, Joerg Jaspert wrote:
> > On 15948 March 1977, Paul Wise wrote:
> >
> >> Does this include the -dev packages for C/etc libraries?
> >
> > No.
> >
> >> I guess it also applies to Haskell and other statically-li
On Tue, Nov 10, 2020 at 06:52:14PM -0500, Calum McConnell wrote:
> On Tue, 2020-11-10 at 10:07 +, Simon McVittie wrote:
> > On Tue, 10 Nov 2020 at 10:45:07 +0100, Johannes Schauer wrote:
> > > I'm confused. We are packaging libraries of language X but then those
> > > packages
> > > will not be
On 11/10/20 10:51 PM, Joerg Jaspert wrote:
> On 15948 March 1977, Paul Wise wrote:
>
>> Does this include the -dev packages for C/etc libraries?
>
> No.
>
>> I guess it also applies to Haskell and other statically-linked languages.
>> https://wiki.debian.org/StaticLinking
>
> StaticLinking itse
On 15949 March 1977, Thomas Goirand wrote:
I'm sorry but I don't understand everything here. If we aren't going
to
have new components like main/contrib/non-free, how will it work? We
main contain a new Packages.{gz,xz} file containing these? I'm
guessing
that it's not just a modification to
On 11/9/20 11:36 PM, Joerg Jaspert wrote:
> [4] We first thought about an entire new archive, but that is much more
> separate, creating a higher workload on maintaining it.
> Additionally, it would create problems following the licenses of
> packages. Then we thought about a new component
On 15949 March 1977, Calum McConnell wrote:
The Rust community's expectation seems to be that you would install
cargo,
and use that to download and build the clap package directly from
upstream,
without apt/dpkg being involved at all.
I don't know that that means we should abandon efforts to i
On Tue, 2020-11-10 at 10:07 +, Simon McVittie wrote:
> On Tue, 10 Nov 2020 at 10:45:07 +0100, Johannes Schauer wrote:
> > I'm confused. We are packaging libraries of language X but then those
> > packages
> > will not be used by people who write software for language X on
> > Debian?
> > Intuit
On 15948 March 1977, Paul Wise wrote:
Does this include the -dev packages for C/etc libraries?
No.
I guess it also applies to Haskell and other statically-linked
languages.
https://wiki.debian.org/StaticLinking
StaticLinking itself is not enough. This is about languages where the
actual
On Tue, 10 Nov 2020 at 10:45:07 +0100, Johannes Schauer wrote:
> I'm confused. We are packaging libraries of language X but then those packages
> will not be used by people who write software for language X on Debian?
> Intuitively, should I ever start with Rust, I would've thought that I had to
>
On Tue, Nov 10, 2020 at 9:28 AM Andrej Shadura wrote:
> Development packages for Rust and Go usually only ship source code.
This reminds me of the proposal for installable source packages that
one could (Build-)Depend on. Seems like that proposal would also solve
the issue with Go and Rust, as we
Hi,
Quoting Andrej Shadura (2020-11-10 10:27:44)
> On Tue, 10 Nov 2020, at 08:28, Paul Wise wrote:
> > > The current proposal is to reduce the main Packages.xz files size by
> > > splitting[4] out all of the packages that are not intended for users,
> > > writing those into an own file. Those pack
On Tue, 10 Nov 2020 at 20:29, Paul Wise wrote:
> On Mon, Nov 9, 2020 at 10:37 PM Joerg Jaspert wrote:
>
> > More and more packages are being uploaded into the Debian archive which
> > are only ever used for building packages. These are not only never
> > intended to be installed onto an end-user'
On Mon, Nov 9, 2020 at 10:37 PM Joerg Jaspert wrote:
> More and more packages are being uploaded into the Debian archive which
> are only ever used for building packages. These are not only never
> intended to be installed onto an end-user's system, they are even
> actively discouraged from being
his gets implemented, both in dak and also apt, is
still being discussed between the ftpteam and the apt maintainers. We
have ideas from writing out section based packages files to presenting
it as a subcomponent to main, and we think we will have something
finalized pretty soon. It possibly n
Theodore Ts'o:
> One other thought. Since someone might be trying to debug a core file
> for an executable belonging to a package which has since been
> superceded by a newer version in unstable or in testing, it would be
> useful if there was a Redis (or some other NoSQL) database where you
> can
One other thought. Since someone might be trying to debug a core file
for an executable belonging to a package which has since been
superceded by a newer version in unstable or in testing, it would be
useful if there was a Redis (or some other NoSQL) database where you
can look up a Build-ID and g
On Sat, May 21, 2016 at 04:34:19AM +, Niels Thykier wrote:
> > Also, does anyone know if someone is working on a FUSE client that
> > could be mounted on top of /usr/lib/debug/.build-id so that the
> > debuginfo files could be automatically made available as needed when
> > gdb tries to access
On Sat, May 21, 2016 at 12:12:11AM -0400, Theodore Ts'o wrote:
> Hi, is it intended that the Contents and Packages file in the dbgsyms
> archive are empty?
>
> I was hoping to be able to add http://debug.mirrors.debian.org/debian-debug/
> to my
> apt.sources list so I could easily download the db
Theodore Ts'o:
> Hi, is it intended that the Contents and Packages file in the dbgsyms
> archive are empty?
>
Hi,
http://debug.mirrors.debian.org/debian-debug/dists/unstable-debug/main/binary-amd64/Packages.xz
does not appear to be empty?
Mind you, the debug archive was created with less backw
Hi, is it intended that the Contents and Packages file in the dbgsyms
archive are empty?
I was hoping to be able to add http://debug.mirrors.debian.org/debian-debug/ to
my
apt.sources list so I could easily download the dbgsyms packages.
Also, does anyone know if someone is working on a FUSE cli
On Tue, 16 Mar 2010 01:10:10 +0100
Wouter Verhelst wrote:
> On Sun, Mar 14, 2010 at 10:02:22PM +, Neil Williams wrote:
> > and having Essential in the Packages file makes it harder than it
> > could be to avoid Essential if the list was in /etc.
>
> If the list is in /etc, an ignorant u
On Sun, Mar 14, 2010 at 10:02:22PM +, Neil Williams wrote:
> and having Essential in the Packages file makes it harder than it
> could be to avoid Essential if the list was in /etc.
If the list is in /etc, an ignorant user may modify the list (remember,
/etc is system-local!) and break th
in the Packages file - that could
just be a file in /etc used by apt. The mechanism doesn't warrant being
in the Packages file - I'm not seeking to drop the mechanism itself
in Debian, just in certain controlled environments like Emdebian and
the use of Packages files makes that unnecessari
Lucas Nussbaum writes:
> It is likely that other tools and scripts are affected. And there might
> also be some affected packages (debmirror? APT proxies?).
Certainly not debmirror. That alway had to cope with Arch:all packages
being listed in each archs Packages file and the same version in
sta
This
isn't a strict requirement, as the Packages file indicates the
architecture of packages which are listed within it.]
> At least for the packages files you should have a unique entry
> - per architecture (in the sense of a
> primary key in a database like UDD
>
>
ersions of one package end up in
different package files because they are for different architectures.
At least for the packages files you should have a unique entry
- per architecture (in the sense of a
primary key in a database like UDD
"packages_pkey" PRIIMARY KEY
(packag
On 11964 March 1977, Lucas Nussbaum wrote:
> The result of that change is that the structure of the Sources and
> Packages files have changed: before, there was only one version of each
> source or binary package in each suite (unstable, testing, stable). There
> can now be several
On Mon, 14 Dec 2009, Lucas Nussbaum wrote:
> The result of that change is that the structure of the Sources and
> Packages files have changed: before, there was only one version of
> each source or binary package in each suite (unstable, testing,
> stable). There can now be several ver
This one time, at band camp, Lucas Nussbaum said:
> So, where should we go from there? Our options are:
> - find & fix all the occurences of the problem ASAP. Please report it
> if you notice strange things about version numbers or other data
> that possibly comes from Sources/Packages.
> - ask
#x27;t find the email announcing that it was turned on, but that's
another issue, possibly with my mail handling ;)
The result of that change is that the structure of the Sources and
Packages files have changed: before, there was only one version of each
source or binary package in each suite
Hi,
On Samstag, 8. August 2009, Manoj Srivastava wrote:
> So am I correct in my assumption that only file conflicts with
> packages installed on the once-clean chroot would be detected by the
> test? Or am I missing something?
Yes. for the rest there is edos.debian.net :)
> > Yes, the
On Fri, Aug 07 2009, Holger Levsen wrote:
> On Freitag, 7. August 2009, Manoj Srivastava wrote:
>> While it is good to discover these bugs, is puiparts the correct
>> place to do this check? Won't puiparts only report on packages
>> installed on the machine on which the test is run, and
Hi Manoj,
On Freitag, 7. August 2009, Manoj Srivastava wrote:
> On Fri, Aug 07 2009, Holger Levsen wrote:
> > Today I picked another simple category: packages which failed the
> > piuparts test because the package tries to overwrite another packages
> > files without de
On Fri, Aug 07 2009, Holger Levsen wrote:
> Today I picked another simple category: packages which failed the piuparts
> test because the package tries to overwrite another packages files without
> declaring a conflict or replaces relation. See policy 7.4 and 7.6 at
> http://ww
to overwrite another packages files without
declaring a conflict or replaces relation. See policy 7.4 and 7.6 at
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts and
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
http://piuparts.debian.org/sid
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> On Thu, Sep 29, 2005 at 11:32:13PM -0500, Manoj Srivastava wrote:
>> reassign 142164 general
>> thanks
>>
>> Hi,
>>
>> Just because a topic has been discussed on the policy
>> discussion list is not reason enough to assign the bug to
>> policy.
On Thu, Sep 29, 2005 at 11:32:13PM -0500, Manoj Srivastava wrote:
> reassign 142164 general
> thanks
>
> Hi,
>
> Just because a topic has been discussed on the policy
> discussion list is not reason enough to assign the bug to
> policy.
Note that bug has been reassigned to the policy
Bill Allombert <[EMAIL PROTECTED]> writes:
> On Thu, May 19, 2005 at 07:34:46PM +0200, Jeroen van Wolffelaar wrote:
>> On Thu, May 19, 2005 at 12:18:55PM +0200, Goswin von Brederlow wrote:
>> > The detection of binary NMUs is currently, among others, using the
>> > debian version of a package and
On Thu, May 19, 2005 at 07:34:46PM +0200, Jeroen van Wolffelaar wrote:
> On Thu, May 19, 2005 at 12:18:55PM +0200, Goswin von Brederlow wrote:
> > The detection of binary NMUs is currently, among others, using the
> > debian version of a package and guessing from its form. What is a
> > binary NMU
name of
>> > the binary package being described. This is an inconsistency that makes
>> > it a bit harder to massage this data, e.g. with grep-dctrl.
>
>> Why not add a patch to grep-dctrl instead?
>
> grep-dctrl was only meant an example: every script
On Thu, May 19, 2005 at 12:18:55PM +0200, Goswin von Brederlow wrote:
> The detection of binary NMUs is currently, among others, using the
> debian version of a package and guessing from its form. What is a
> binary NMU and what not is not aparent from the Packages file. It has
> been suggested to
an inconsistency that makes
> > it a bit harder to massage this data, e.g. with grep-dctrl.
> Why not add a patch to grep-dctrl instead?
grep-dctrl was only meant an example: every script or whatever parsing
Packages files will have to deal with that inconsistency (in the case
of a Per
Anthony Towns writes:
> Goswin von Brederlow wrote:
>> The detection of binary NMUs is currently, among others, using the
>> debian version of a package and guessing from its form. What is a
>> binary NMU and what not is not aparent from the Packages file. It has
>> been suggested to insert Sourc
On 20050519T205101+1000, Anthony Towns wrote:
> Something equivalent to:
>
> cat /var/lib/dpkg/available |
> awk '/^Package:/ {P=$2;V=""}
> /^Version:/ {if (V=="") { V=$2; } }
> /^Source: .* (.*)/ {V=substr($3,2,length($3)-2)}
> /^Source:/ {P=$2}
> /^$/ {
Goswin von Brederlow wrote:
The detection of binary NMUs is currently, among others, using the
debian version of a package and guessing from its form. What is a
binary NMU and what not is not aparent from the Packages file. It has
been suggested to insert Source: entries pointing to the original
so
Antti-Juhani Kaijanaho wrote:
As you probably know, entries in the Packages file only have a Source
field if the name of the source package is different from the name of
the binary package being described.
Why not add a patch to grep-dctrl instead?
What patch would that be?
Something equivalent to:
t it greps but is ment to work on anything resembling
RFC822 headers. So while it would be possible to teach grep-dctrl
about Packages files and add Source: ... lines it is not desireable.
There is also another reason for more Source: ... entries in the
Packages file mentioned in an unrelated threa
On 20050519T153811+1000, Anthony Towns wrote:
> Adeodato Simó wrote:
> > As you probably know, entries in the Packages file only have a Source
> > field if the name of the source package is different from the name of
> > the binary package being described. This is an inconsistency that makes
> >
Adeodato Simó wrote:
As you probably know, entries in the Packages file only have a Source
field if the name of the source package is different from the name of
the binary package being described. This is an inconsistency that makes
it a bit harder to massage this data, e.g. with grep-dctrl
Hello all,
As you probably know, entries in the Packages file only have a Source
field if the name of the source package is different from the name of
the binary package being described. This is an inconsistency that makes
it a bit harder to massage this data, e.g. with grep-dctrl.
Befo
Dan Jacobson <[EMAIL PROTECTED]> schrieb:
> Does http://www.debian.org/mirror/ at least have the
> two-phase-mirroring script?
Why don't you go and look? And if you find the information too sparse,
submit a bug report with a patch?
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zür
Jeroen> Debian could promote this two-phase mirroring a bit more
Jeroen> maybe, and/or provide nice scripts, that's probably why #6786
Jeroen> is still open.
I suppose Debian is promoting one-phase mirroring and two phase
mirroring is "roll your own".
If you want me to tell my administrator to do
Hi Jeroen,
> How mirrors do their mirroring is up to the local mirror administrator,
> not to the general debian developer's community. Debian could promote
> this two-phase mirroring a bit more maybe, and/or provide nice scripts,
> that's probably why #6786 is still open.
>
> BUT DEBIAN CANNOT I
On Tue, Feb 15, 2005 at 11:51:10PM +0800, Dan Jacobson wrote:
> S> You've been told this before -- *debian-devel does not control the
> mirroring
> S> implementation used by arbitrary Debian mirrors*. Either talk to the
> mirror
> S> team and give them enough information to track this down, or -
S> You've been told this before -- *debian-devel does not control the mirroring
S> implementation used by arbitrary Debian mirrors*. Either talk to the mirror
S> team and give them enough information to track this down, or -- since you
S> know him well enough to be kept in the loop about his vacat
On Wed, Feb 09, 2005 at 09:51:44AM +0800, Dan Jacobson wrote:
> I know you Debian people think it's just hilarious when users try to
> apt-get upgrade during the period after when the Packages files
> arrive on the mirrors, but before the packages they describe have
> fully arr
Hi Dan,
On Wednesday, 09 Feb 2005, Dan Jacobson <[EMAIL PROTECTED]> wrote:
> I know you Debian people think it's just hilarious when users try to
> apt-get upgrade during the period after when the Packages files
> arrive on the mirrors, but before the packages they describe
I know you Debian people think it's just hilarious when users try to
apt-get upgrade during the period after when the Packages files
arrive on the mirrors, but before the packages they describe have
fully arrived.
"Haw haw haw, try again later", you say, never thinking that ma
On Wed, 9 Feb 2005, Per Bojsen wrote:
Package: zope-textindexng2
Version: 1:2.0.8-4
Severity: normal
When this package is built on the amd64 architecture, the files that
are to go in the /usr/lib/python2.2/site-packages/zope-textindexng2
directory fail to be installed. This is not obvious when the
On Sat, 11 Dec 2004, Goswin von Brederlow wrote:
> Adam Heath <[EMAIL PROTECTED]> writes:
> > On Fri, 10 Dec 2004, Santiago Vila wrote:
> >> On Sat, 11 Dec 2004, Dan Jacobson wrote:
> >> > Say, perhaps a "Date:" field could be added to Packages files
This one time, at band camp, Matthew Palmer said:
> On Sun, Dec 12, 2004 at 06:06:59PM -0500, Stephen Gran wrote:
> > This one time, at band camp, Dan Jacobson said:
> > > Off line with just the Packages file, you can't tell a dusty 1997
> > > package from an up to the minute state of the art packa
Stephen Gran writes:
> You have the changelogs. Use them.
The changelogs are in the Packages file?
--
John Hasler
On Sun, Dec 12, 2004 at 06:06:59PM -0500, Stephen Gran wrote:
> This one time, at band camp, Dan Jacobson said:
> > Off line with just the Packages file, you can't tell a dusty 1997
> > package from an up to the minute state of the art package.
>
> You have the changelogs. Use them.
You must hav
This one time, at band camp, Dan Jacobson said:
> Off line with just the Packages file, you can't tell a dusty 1997
> package from an up to the minute state of the art package.
You have the changelogs. Use them.
--
-
| ,''`.
I challenge you to tell me the dates of the packages using just the
Packages file. The best you can do is
$ grep-available -F version 200 -s Version|wc -l
1207
But that still leaves
$ grep-available -F version 200 -vs Version|wc -l
15127
packages that don't put the date into their version numbers.
Adam Heath <[EMAIL PROTECTED]> writes:
> On Fri, 10 Dec 2004, Santiago Vila wrote:
>
>> On Sat, 11 Dec 2004, Dan Jacobson wrote:
>>
>> > Say, perhaps a "Date:" field could be added to Packages files.
>> > I mean even dog food has the date stamp
On Fri, 10 Dec 2004, Santiago Vila wrote:
> On Sat, 11 Dec 2004, Dan Jacobson wrote:
>
> > Say, perhaps a "Date:" field could be added to Packages files.
> > I mean even dog food has the date stamped on it these days.
> > Even my crumby message has a Date: fiel
On Sat, 11 Dec 2004, Dan Jacobson wrote:
> Say, perhaps a "Date:" field could be added to Packages files.
> I mean even dog food has the date stamped on it these days.
> Even my crumby message has a Date: field.
> Sure, as your eyes scan the MD5sum: field, the package&#x
Say, perhaps a "Date:" field could be added to Packages files.
I mean even dog food has the date stamped on it these days.
Even my crumby message has a Date: field.
Sure, as your eyes scan the MD5sum: field, the package's DNA is
registered in your brain. But us old fashioned types w
Dan Jacobson <[EMAIL PROTECTED]> writes:
> Regarding a future Date: field for each package in Packages files,
> * Should the field be called Date: or Time:?
> * Should it be like "Mon, 18 Aug 2003 22:09:30 GMT" or "1061315862"?
> * Should it refer to the ti
On Wed, 20 Aug 2003, Dan Jacobson wrote:
> Regarding a future Date: field for each package in Packages files,
> * Should the field be called Date: or Time:?
> * Should it be like "Mon, 18 Aug 2003 22:09:30 GMT" or "1061315862"?
> * Should it refer to the time the
Regarding a future Date: field for each package in Packages files,
* Should the field be called Date: or Time:?
* Should it be like "Mon, 18 Aug 2003 22:09:30 GMT" or "1061315862"?
* Should it refer to the time the developer finished wrapping the
package, or the time it ente
With the introduction of the packages pool, I'm going to propose the
following change to the Packages files:
1. The filename tells what the Packages files contains:
Packages files should be independent of the their location, therefor the
name has to reflect their contents, i.e.
&quo
On Thu, Aug 31, 2000 at 08:44:16PM +1100, Herbert Xu wrote:
> > This was what I had to write to make a Packages file in a flat dir:
> > [EMAIL PROTECTED]:~/public_html/debian$ dpkg-scanpackages . override ./
> > >Packages
>
> You don't have to supply a third argument.
and /dev/null works fine f
Eray Ozkural <[EMAIL PROTECTED]> wrote:
> This was what I had to write to make a Packages file in a flat dir:
> [EMAIL PROTECTED]:~/public_html/debian$ dpkg-scanpackages . override ./
> >Packages
You don't have to supply a third argument.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org
I was running dpkg-scanpackages to construct a custom apt source.
This was the first time I really ran it, so I encountered the
peculiar style that I had to conform to.
This was what I had to write to make a Packages file in a flat dir:
[EMAIL PROTECTED]:~/public_html/debian$ dpkg-scanpackages .
On Tue, May 18, 1999 at 06:17:40PM +0200, Thomas Schoepf was heard to say:
>
> How are those Packages(.gz) files on ftp.debian.org created? Is there a
> .deb package available for download that provides that functionality?
>
I believe that dpkg-scanpackages, available in the dpkg-dev package,
Thomas Schoepf wrote:
>
> How are those Packages(.gz) files on ftp.debian.org created? Is there a
> .deb package available for download that provides that functionality?
dpkg-scanpackages from the dpkg-dev package creates the Packages file.
HTH,
-Remco
How are those Packages(.gz) files on ftp.debian.org created? Is there a
.deb package available for download that provides that functionality?
TIA!
Thomas
--
Debian GNU/Linux Developer PGP public key
http://www.debian.org/ KeyID 2EA7BBBD
It must have been a temporary glitch, the files are now available.
Bob
On Wed, 20 Jan 1999, Bob Nielsen wrote:
> It seems that all the hamm and slink packages files, as well as those for
> contrib and non-free (but not main) in potato are currently missing on
> three mirrors I hav
is helps.
> Paul
>
> On Wed, 20 Jan 1999, Bob Nielsen wrote:
>
> It seems that all the hamm and slink packages files, as well as those for
> contrib and non-free (but not main) in potato are currently missing on
> three mirrors I have checked today.
>
> Agggh!
>
/dh_builddeb.1.gz
php3-doc: /usr/doc/php3-doc/html/function.hw-getchilddoccoll.html
debhelper: /usr/bin/dh_builddeb
[paul:~]$
hope this helps.
Paul
On Wed, 20 Jan 1999, Bob Nielsen wrote:
It seems that all the hamm and slink packages files, as well as those for
contrib and non-free (but not main) in
It seems that all the hamm and slink packages files, as well as those for
contrib and non-free (but not main) in potato are currently missing on
three mirrors I have checked today.
Agggh!
Bob
On Wed, Jun 03, 1998 at 09:31:01AM -0500, Manoj Srivastava wrote:
> >>"Michael" == Michael Bramer <[EMAIL PROTECTED]> writes:
>
> Michael> If the the size information isn't in the debian-package,
> Michael> then i must download two files (NAME-VERSION.deb and
> Michael> NAME-VERSION.size.gz) or
Jules Bean <[EMAIL PROTECTED]> wrote:
> Is du -k not the answer?
du -S, but you need to know how many files are in each directory
to estimate block-size overhead -- assume that each file requires
two thirds of a block of unused space and you won't be too far off.
--
Raul
--
To UNSUBSCRIBE, ema
On Sat, 6 Jun 1998, Raul Miller wrote:
> Joey Hess <[EMAIL PROTECTED]> wrote:
> > How is it possible to check for block sizes with lintian? And what do you
> > expect a maintainer to do if they use a different block size and lintian
> > dislikes that? Reformat?
>
> To deal with block sizes we'll
1 - 100 of 128 matches
Mail list logo
