Hi,
Quoting Jonathan Dowland (2025-05-06 10:51:45)
> On Thu May 1, 2025 at 8:37 PM BST, Chris Hofstaedtler wrote:
> > Does anything actually _use_ the Build-Essential: yes line?
>
> I honestly don't know.
I've never seen it being used.
> I expect so, or the ftp-mast
On Thu May 1, 2025 at 8:37 PM BST, Chris Hofstaedtler wrote:
Does anything actually _use_ the Build-Essential: yes line?
I honestly don't know. I expect so, or the ftp-masters wouldn't be
adding it to packages. Having it in the control metadata makes it
visible to users (apt show
* Jonathan Dowland [250428 18:02]:
On Mon Apr 28, 2025 at 4:46 PM BST, Sven Joachim wrote:
On 2025-04-28 15:57 +0100, Jonathan Dowland wrote:
Thanks! For reasons I cannot explain, installing build-essential (in a
Salsa CI environment) did not pull in perl.
The tag is coming from an FTP
On Mon Apr 28, 2025 at 4:46 PM BST, Sven Joachim wrote:
On 2025-04-28 15:57 +0100, Jonathan Dowland wrote:
"apt-cache show perl" lists it as "Build-Essential: yes". But why? It's
not in the transitive dependencies of build-essential,
It is, dpkg-dev depends on perl:a
On 2025-04-28 15:57 +0100, Jonathan Dowland wrote:
> "apt-cache show perl" lists it as "Build-Essential: yes". But why? It's
> not in the transitive dependencies of build-essential,
It is, dpkg-dev depends on perl:any.
> nor /usr/share/doc/build-essential/
"apt-cache show perl" lists it as "Build-Essential: yes". But why? It's
not in the transitive dependencies of build-essential, nor
/usr/share/doc/build-essential/list, and I can't find that header
verbatim in Perl's debian/control in the source, nor in the bin
debian.org/debian-policy/2022/12/msg00023.html
> Your argument cuts both ways. Right now, Policy says that
> the bugs are RC, and if you believe that should be different, why
> don't you propose such a change and seek consensus yourself?
I don't think it does. Policy doesn't spe
On Sat, Sep 17, 2016 at 11:26:05AM +0200, Michael Biebl wrote:
> Hi,
>
> I wonder if nowadays pkg-config would qualify as Build-Essential.
No, I don't think so.
> We have 2400 source packages listing it as explicit Build-Depends and
> countless -dev packages pulling in pkg
2016-09-17 14:06 Guillem Jover:
On Sat, 2016-09-17 at 11:26:05 +0200, Michael Biebl wrote:
At which point do we consider a package Build-Essential?
It's not like every package actually uses gcc or make during build either.
If you had picked g++ that would have been a better example. :
Hi!
On Sat, 2016-09-17 at 11:26:05 +0200, Michael Biebl wrote:
> I wonder if nowadays pkg-config would qualify as Build-Essential.
I don't think so.
> We have 2400 source packages listing it as explicit Build-Depends and
> countless -dev packages pulling in pkg-config. So the li
Am 17.09.2016 um 12:24 schrieb Josh Triplett:
> I can't think of anything this would buy us, other than a few bytes in
> the Packages file.
It's a valid question. I guess I need to explain what triggered this
email. A couple of days ago I uploaded a new version of gtk-doc-tools
(to experimental) w
Michael Biebl wrote:
> I wonder if nowadays pkg-config would qualify as Build-Essential.
>
> We have 2400 source packages listing it as explicit Build-Depends and
> countless -dev packages pulling in pkg-config. So the list of packages
> requiring pkg-config during build is p
Hi,
I wonder if nowadays pkg-config would qualify as Build-Essential.
We have 2400 source packages listing it as explicit Build-Depends and
countless -dev packages pulling in pkg-config. So the list of packages
requiring pkg-config during build is potentially much longer.
At which point do we
Control: reassign -1 ftp.debian.org
Control: retitle -1 make-guile should be priority: extra, not standard
Control: tags -1 - moreinfo wontfix
On Sat, Oct 25, 2014 at 11:42:32AM +0300, Martin-Éric Racine wrote:
> > I believe this is the correct consensus that DDs have reached when
> > make-guile p
2014-10-25 5:04 GMT+03:00 Dimitri John Ledkov :
> On 24 October 2014 15:23, Matthias Klose wrote:
>> Control: tags -1 + wontfix moreinfo
>>
>> Am 21.09.2014 um 16:27 schrieb Martin-Éric Racine:
>>> Package: build-essential
>>> Version: 11.7
>>&g
On 24 October 2014 15:23, Matthias Klose wrote:
> Control: tags -1 + wontfix moreinfo
>
> Am 21.09.2014 um 16:27 schrieb Martin-Éric Racine:
>> Package: build-essential
>> Version: 11.7
>> Severity: normal
>>
>> Given how 'make' has priority O
Control: tags -1 + wontfix moreinfo
Am 21.09.2014 um 16:27 schrieb Martin-Éric Racine:
> Package: build-essential
> Version: 11.7
> Severity: normal
>
> Given how 'make' has priority Optional, while 'make-guile' is Standard,
> build-essential's Depe
+++ Wookey [2012-06-27 20:04 +0100]:
> +++ Wookey [2012-01-19 14:32 +]:
> > +++ Neil Williams [2012-01-19 13:02 +]:
> > > On Thu, 19 Jan 2012 12:10:28 +
> > > Wookey wrote:
> > >
> > > > I've thought for a long time that a package
plans to support such combinations with
> > cross-build-essential?
>
> Multiarch should support this and dpkg-architecture already does. So
> if someone wants to maintain toolchains to do this then adding an
> entry to cross-build-essential is easy. (We didn't put everything
> possi
Simon McVittie writes:
> On 28/06/12 10:17, Goswin von Brederlow wrote:
>> Say I want to have the build-essential for i386 installed on amd64.
>> I could install build-essential:i386, replacing gcc/g++:amd64 with
>> gcc/g++:i386. Wouldn't that give me everything need
plans to support such combinations with
> > cross-build-essential?
>
> It shouldn't differ from compiling for different CPUs: the key problem
> in cross-compilation is "your build system can't run your host system's
> binaries", which you can arrive at e
On Thu, Jun 28, 2012 at 10:29:20AM +0100, Simon McVittie wrote:
> On 28/06/12 10:17, Goswin von Brederlow wrote:
> > Say I want to have the build-essential for i386 installed on amd64.
> > I could install build-essential:i386, replacing gcc/g++:amd64 with
> > gcc/g++:i386.
+++ Svante Signell [2012-06-28 11:43 +0200]:
>
> The situation is even more complicated if compiling for different OSes:
> Like as host (build) Linux:i386 and guest (target) kFreeBSD:amd64 or
> Hurd:i386. Any plans to support such combinations with
> cross-build-essential?
M
On 28/06/12 10:43, Svante Signell wrote:
> The situation is even more complicated if compiling for different OSes:
> Like as host (build) Linux:i386 and guest (target) kFreeBSD:amd64 or
> Hurd:i386. Any plans to support such combinations with
> cross-build-essential?
It shouldn&#
On Thu, 2012-06-28 at 10:29 +0100, Simon McVittie wrote:
> On 28/06/12 10:17, Goswin von Brederlow wrote:
> > Say I want to have the build-essential for i386 installed on amd64.
> > I could install build-essential:i386, replacing gcc/g++:amd64 with
> > gcc/g++:i386.
On 28/06/12 10:17, Goswin von Brederlow wrote:
> Say I want to have the build-essential for i386 installed on amd64.
> I could install build-essential:i386, replacing gcc/g++:amd64 with
> gcc/g++:i386. Wouldn't that give me everything needed to cross-compile
> for i386?
For evolu
Wookey writes:
> +++ Wookey [2012-01-19 14:32 +]:
>> +++ Neil Williams [2012-01-19 13:02 +]:
>> > On Thu, 19 Jan 2012 12:10:28 +
>> > Wookey wrote:
>> >
>> > > I've thought for a long time that a package like build-essential
On Wed, 27 Jun 2012 20:04:26 +0100
Wookey wrote:
> A bit of background here for those who aren't following all the details:
>
> We are working towards having cross-compilers in the archive. The plan
> is for those toolchains to use multiarch so that the existing
> libc: linux-libc-dev: libgcc1:
+++ Wookey [2012-01-19 14:32 +]:
> +++ Neil Williams [2012-01-19 13:02 +]:
> > On Thu, 19 Jan 2012 12:10:28 +
> > Wookey wrote:
> >
> > > I've thought for a long time that a package like build-essential for
> > > cross-building would be
Hi all,
I have not so time available too, but :
- I need a good cross toolchain solution for armel/armhf.
- I use debian on my sheevas and desktops
- I have allready made a port of DoudouLinux Debian based system on
Genesi SmartBook
- I have a lot of others projects still in progress or in standby
+++ Paul Wise [2012-01-21 20:37 +0800]:
> On Thu, Jan 19, 2012 at 8:10 PM, Wookey wrote:
>
> > Currently on Debian you'll need to have made the emdebian repositories
> > available because otherwise you won't find any cross-compilers, but
> > hopefully we'll have them in the main archive in the not
On Sat, 21 Jan 2012 22:03:11 +0100
Vincent Danjean wrote:
> Le 21/01/2012 16:29, Neil Williams a écrit :
> > The cross-dependency resolution is yet another feature of Debian which
> > is waiting for MultiArch...
>
> While waiting on proper MultiArch in Debian (when will dpkg with
> multiarch p
Le 21/01/2012 16:29, Neil Williams a écrit :
> On Sat, 21 Jan 2012 20:37:58 +0800
> Paul Wise wrote:
>
>> On Thu, Jan 19, 2012 at 8:10 PM, Wookey wrote:
>>
>>> Currently on Debian you'll need to have made the emdebian repositories
>>> available because otherwise you won't find any cross-compilers
On Sat, 21 Jan 2012 20:37:58 +0800
Paul Wise wrote:
> On Thu, Jan 19, 2012 at 8:10 PM, Wookey wrote:
>
> > Currently on Debian you'll need to have made the emdebian repositories
> > available because otherwise you won't find any cross-compilers, but
> > hopefully we'll have them in the main arch
On Thu, Jan 19, 2012 at 8:10 PM, Wookey wrote:
> Currently on Debian you'll need to have made the emdebian repositories
> available because otherwise you won't find any cross-compilers, but
> hopefully we'll have them in the main archive in the not-too distant.
Whats the status/blockers for getti
On Thu, 19 Jan 2012 12:10:28 +
Wookey wrote:
> I've thought for a long time that a package like build-essential for
> cross-building would be a really good idea.
>
> Currently to get the right tools and libs installed for cross-building
> you need to do slightly
+++ Neil Williams [2012-01-19 13:02 +]:
> On Thu, 19 Jan 2012 12:10:28 +
> Wookey wrote:
>
> > I've thought for a long time that a package like build-essential for
> > cross-building would be a really good idea.
>
> +1
>
> It should probably
On Thu, 19 Jan 2012 12:10:28 +
Wookey wrote:
> I've thought for a long time that a package like build-essential for
> cross-building would be a really good idea.
+1
> Currently to get the right tools and libs installed for cross-building
> you need to do slightly di
es much more robust. Not having
to hard code per-arch package lists and being able to handle it
just like we currently handle build-essential would, IMO, be a
Good Thing.
If it were to use the same file format that build-essential uses,
we would be able to reuse that.
Regards,
Roger
--
.&#x
I've thought for a long time that a package like build-essential for
cross-building would be a really good idea.
Currently to get the right tools and libs installed for cross-building
you need to do slightly different things on different distros
Having just been looking at sbuild cross-su
On Sat, 26 Mar 2011 10:53:07 +0100
Joerg Jaspert wrote:
> there are currently two ways to indicate what Debian considers
> "Build-Essential". There is the package build-essential and there is
> also a flag in the packages files.
Wherever I do use build-essential in Emdebian
Joerg Jaspert wrote:
> there are currently two ways to indicate what Debian considers
> "Build-Essential". There is the package build-essential and there is
> also a flag in the packages files.
> We think it was used to be able to calculate the B-E packages by "jus
Hi,
there are currently two ways to indicate what Debian considers
"Build-Essential". There is the package build-essential and there is
also a flag in the packages files.
We think it was used to be able to calculate the B-E packages by "just
looking at the packages files",
On Wed, 2008-07-16 at 22:29 +0200, Mike Hommey wrote:
> I'm wondering... do we have binary packages for all kernel modules we have
> (free) -source packages for so that such kernel modules don't need to be
> built by users ?
No, but *most* of them are built by linux-modules-extra-2.6 or
linux-mo
It looks like the search you tried is just broken.
The search tool works but it is rather dumb and the instructions are misleading.
_i386 will only find packages with _i386 in the filename. So it will NOT find
arch all packages like module-assistant. There does not seem
to be a way to search fo
Zitat von "brian m. carlson" <[EMAIL PROTECTED]>:
On Wed, Jul 16, 2008 at 09:53:24PM +0200, richs wrote:
I think that including headers, m-a and build essential would be a
good move for the developers. Other distros have out-of-the-box
non-free and proprietary apps/d
er.net/jigdo/jigdo-search.php?q=build-essential&l=http%3A%2F%2Fcdimage.debian.org%2Fcdimage%2Frelease%2F4.0_r3%2Fi386%2Fjigdo-cd%2Fdebian-40r3-i386-CD-1.jigdo
17 Feb 2008;Debian GNU/Linux 4.0 r3 "Etch" - Official i386 CD Binary-1
20080217-11:50 (20080217)
pool/main/m/mod
Le Wed, Jul 16, 2008 at 08:21:14PM +, brian m. carlson a écrit :
>
> Non-free (and contrib) packages are not part of Debian and are therefore
> not shipped on Debian CDs or DVDs. I understand your frustration with
> not being able to use your wireless card out of the box; I have the same
> pr
Hi Fjp:
I am surprised that the dependencies are on the image, as I have always
been met with problems trying to install build-essential from the first iso.
I will post the output from the terminal on my next fresh install of
Lenny and Etch.
I can assure you that on an http download i386
richs wrote:
> Hi, basically I am requesting module-assistant, build-essential and the
> kernel headers for the default kernel on the first iso.
I really don't have a clue what you're going on about then.
If you check these pages, you'll see that all three package you name _
On Wed, Jul 16, 2008 at 08:21:14PM +, brian m. carlson wrote:
> On Wed, Jul 16, 2008 at 09:53:24PM +0200, richs wrote:
>> I think that including headers, m-a and build essential would be a good
>> move for the developers. Other distros have out-of-the-box non-free
>>
On Wed, Jul 16, 2008 at 09:53:24PM +0200, richs wrote:
I think that including headers, m-a and build essential would be a good
move for the developers. Other distros have out-of-the-box non-free and
proprietary apps/drivers/codecs, I would just like to see Debian offer a
complete base on
Hi, basically I am requesting module-assistant, build-essential and the
kernel headers for the default kernel on the first iso. These are basic
tools that are necessary to be able to install non-free, proprietary
packages such as madwifi, nvidia-drivers etc.
My main point is the wireless
Hi,
[EMAIL PROTECTED] wrote:
> They are free, do not take up space, but
> without them (on a wireless only computer) you hit a vicious circle;
> Needing internet to be able to get internet.
Avoiding the free vs. non-free firmware issue, most of these packages
are available on Debian CDs/DVDs, jus
I would like to ask why essential packages are not included on the first Debian
download cd/iso. I use Nvidia and Atheros wireless, but the packages
module-assistant, build essential, kernel headers, wireless-tools etc, are
needed for most other graphic, network driver and firmware
Lars Wirzenius wrote:
> to, 2005-01-13 kello 13:35 +0200, Lars Wirzenius kirjoitti:
> > I don't think debhelper fits into this category. On the other hand,
> > build-essential (version 10.1) already depends on file, html2text,
> > debconf-utils, and po-debconf, which I th
Peter Samuelson wrote:
[Ken Bloom]
I'm confused. One making backports from sid to woody should backport
a package in such a way that it is buildable with woody's
build-essential.
AFAICS, that's no more true for build-essential than for anything else.
That is, you can either ba
[Ken Bloom]
> I'm confused. One making backports from sid to woody should backport
> a package in such a way that it is buildable with woody's
> build-essential.
Yes. Same will be true backporting to sarge. But if sarge
build-essential were to be updated to contain debhelper
On Fri, 14 Jan 2005 17:21:38 +0100, Tollef Fog Heen wrote:
> * Frank KÃster
>
> | That's correct from the point of view of a buildd, or of a developer
> | running a sid machine. But it is not correct for backporters: Imagine
> | that packages are added to build-ess
Goswin von Brederlow wrote:
Anthony Towns writes:
http://lintian.debian.org/reports/Tpackage-lacks-versioned-build-depends-on-debhelper.html
Having the current debhelper be build-essential would fix the ~237
bugs lintian finds for build-deps on debhelper that should be
versioned, but aren&#
Oh, also:
>
> http://lintian.debian.org/reports/Tpackage-lacks-versioned-build-depends-on-debhelper.html
>
> Having the current debhelper be build-essential would fix the ~237
> bugs lintian finds for build-deps on debhelper that should be
> versioned, but aren't.
Aren't t
the point of view of a buildd, or of a developer
> > > | running a sid machine. But it is not correct for backporters: Imagine
> > > | that packages are added to build-essential, or versioned dependencies in
> > > | it are bumped to a higher version number. Then a package withou
On Fri, 2005-01-14 at 18:44 +0100, Frank KÃster wrote:
> Scott James Remnant <[EMAIL PROTECTED]> wrote:
>
> > In effect, if you're building unstable packages on stable, the first
> > thing you should build is unstable's build-essential.
>
> Are you kidd
Frank Küster wrote:
Scott James Remnant <[EMAIL PROTECTED]> wrote:
In effect, if you're building unstable packages on stable, the first
thing you should build is unstable's build-essential.
Are you kidding? Well, this is okay if we're talking only about added
packages or hig
Scott James Remnant <[EMAIL PROTECTED]> wrote:
> In effect, if you're building unstable packages on stable, the first
> thing you should build is unstable's build-essential.
Are you kidding? Well, this is okay if we're talking only about added
packages or higher versi
ot correct for backporters: Imagine
> > | that packages are added to build-essential, or versioned dependencies in
> > | it are bumped to a higher version number. Then a package without
> > | Build-Dependencies, or with Build-Dependencies that can be fulfilled in
> > | sta
On Fri, 2005-01-14 at 17:21 +0100, Tollef Fog Heen wrote:
> * Frank KÃster
>
> | That's correct from the point of view of a buildd, or of a developer
> | running a sid machine. But it is not correct for backporters: Imagine
> | that packages are added to build-ess
* Frank Küster
| That's correct from the point of view of a buildd, or of a developer
| running a sid machine. But it is not correct for backporters: Imagine
| that packages are added to build-essential, or versioned dependencies in
| it are bumped to a higher version number. Then a pa
Anthony Towns wrote:
Scott James Remnant wrote:
The stats:
8,920 source packages in Debian unstable main.
8,254 declare a build-dependency on debhelper
= 92% of packages build-depend on debhelper.
Is that sufficient to declare it build-essential?
Also of interest is that some 1300 packages
Anthony Towns wrote:
> Andreas Barth wrote:
>> * Hamish Moffatt ([EMAIL PROTECTED]) [050114 00:45]:
>>>Not if build-essential included a suitable versioned depends, like
>>>debhelper (>= 4). It already does that for gcc.
>> That would still mean a ver
-Depends: at all with those changes, and another 1200
wouldn't need to declare a Build-Depends-Indep:.
Not even versioned depends?
Not if build-essential included a suitable versioned depends, like
debhelper (>= 4). It already does that for gcc.
That would still mean a versioned dependency
gt; declare a Build-Depends: at all with those changes, and another 1200
> > > wouldn't need to declare a Build-Depends-Indep:.
> > Not even versioned depends?
> Not if build-essential included a suitable versioned depends, like
> debhelper (>= 4). It already does tha
0
> > wouldn't need to declare a Build-Depends-Indep:.
>
> Not even versioned depends?
Not if build-essential included a suitable versioned depends, like
debhelper (>= 4). It already does that for gcc.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTE
Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote:
> On 20050113T040729+, Scott James Remnant wrote:
>> Is that sufficient to declare it build-essential?
>
> This issue belongs to debian-policy.
Remember that policy tends to be shaped by current practice. If there&#
On Thu, Jan 13, 2005 at 11:19:03PM +1000, Anthony Towns wrote:
> Also of interest is that some 1300 packages would no longer need to
> declare a Build-Depends: at all with those changes, and another 1200
> wouldn't need to declare a Build-Depends-Indep:.
Not even versioned depends?
/* Steinar *
* Anthony Towns (aj@azure.humbug.org.au) [050113 14:20]:
> Scott James Remnant wrote:
> >What say you?
> Rename it to "standard-debian-build-environment". :)
It's more a "default-debian-build-environment" :)
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85
Scott James Remnant wrote:
The stats:
8,920 source packages in Debian unstable main.
8,254 declare a build-dependency on debhelper
= 92% of packages build-depend on debhelper.
Is that sufficient to declare it build-essential?
Also of interest is that some 1300 packages would no longer need
to, 2005-01-13 kello 13:35 +0200, Lars Wirzenius kirjoitti:
> I don't think debhelper fits into this category. On the other hand,
> build-essential (version 10.1) already depends on file, html2text,
> debconf-utils, and po-debconf, which I think are also not necessary for
>
On 20050113T040729+, Scott James Remnant wrote:
> The stats:
>
> 8,920 source packages in Debian unstable main.
> 8,254 declare a build-dependency on debhelper
>
> = 92% of packages build-depend on debhelper.
>
> Is that sufficient to declare it build-essent
% of packages build-depend on debhelper.
> >
> > Is that sufficient to declare it build-essential?
>
> No, it's not by definition, as you don't *need* it for a simple
> "hello, world" package written in C. The fact that there are policy
> compliant package
92% of packages build-depend on debhelper.
> >
> > Is that sufficient to declare it build-essential?
>
> No, it's not by definition, as you don't *need* it for a simple
> "hello, world" package written in C. The fact that there are policy
> complian
On Thu, 13 Jan 2005, Scott James Remnant wrote:
> The stats:
>
> 8,920 source packages in Debian unstable main.
> 8,254 declare a build-dependency on debhelper
>
> = 92% of packages build-depend on debhelper.
>
> Is that sufficient to declare it build-ess
to, 2005-01-13 kello 04:07 +, Scott James Remnant kirjoitti:
> The stats:
>
> 8,920 source packages in Debian unstable main.
> 8,254 declare a build-dependency on debhelper
>
> = 92% of packages build-depend on debhelper.
>
> Is that sufficient to declare it
On Thu, Jan 13, 2005 at 04:07:29AM +, Scott James Remnant wrote:
> The stats:
>
> 8,920 source packages in Debian unstable main.
> 8,254 declare a build-dependency on debhelper
>
> = 92% of packages build-depend on debhelper.
>
> Is that sufficient to de
that all packages are really updated for that before sarge, but
> lets get b-e with such a thing in sarge IMO).
ACK, debhelper should be in b-e for Sarge if we wish to handle it like
other packages in build-essential nowadays.
For regular Sid environment it would change nothing/not much,
On 10168 March 1977, Scott James Remnant wrote:
> = 92% of packages build-depend on debhelper.
> It can be argued that these are already effectively build-essential due
> to the high number of packages build-depending on them anyway.
I think it should be b-e, but with a versioned
On Thu, Jan 13, 2005 at 04:07:29AM +, Scott James Remnant wrote:
> The stats:
>
> 8,920 source packages in Debian unstable main.
> 8,254 declare a build-dependency on debhelper
>
> = 92% of packages build-depend on debhelper.
>
> Is that sufficient to de
The stats:
8,920 source packages in Debian unstable main.
8,254 declare a build-dependency on debhelper
= 92% of packages build-depend on debhelper.
Is that sufficient to declare it build-essential?
The downside:
Package: debhelper
Depends: perl (>= 5.6.0-16), coreut
Corner part of the website.
Well, since Developer's Corner is not Policy, we can make that happen.
Webmasters, can we get some arrangement such that the informational
list of build-essential packages (see the package build-essential) is
available in the Developer's Corner, preferably a
89 matches
Mail list logo
