Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] Kernel download problem.
@ 2013-06-14 10:02 Sagaert Johan
  2013-06-14 17:41 ` Thomas Petazzoni
  0 siblings, 1 reply; 4+ messages in thread
From: Sagaert Johan @ 2013-06-14 10:02 UTC (permalink / raw)
  To: buildroot

 
 Hi

There seems to be a problem with the downloading of a kernel when a longterm release is selected.

Buildroot tries 

http://www.kernel.org/pub//linux/kernel/v2.6/linux-2.6.34.14.tar.xz 

While the real kernel is at 
https://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.34/linux-2.6.34.14.tar.xz

So maybe it should be copied to the buildroot sources mirror.

 
Regards Sagaert Johan

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Buildroot] Kernel download problem.
  2013-06-14 10:02 [Buildroot] Kernel download problem Sagaert Johan
@ 2013-06-14 17:41 ` Thomas Petazzoni
  2013-08-27 21:21   ` James Potts
  0 siblings, 1 reply; 4+ messages in thread
From: Thomas Petazzoni @ 2013-06-14 17:41 UTC (permalink / raw)
  To: buildroot

Dear Sagaert Johan,

On Fri, 14 Jun 2013 12:02:44 +0200, Sagaert Johan wrote:

> There seems to be a problem with the downloading of a kernel when a longterm release is selected.
> 
> Buildroot tries 
> 
> http://www.kernel.org/pub//linux/kernel/v2.6/linux-2.6.34.14.tar.xz 
> 
> While the real kernel is at 
> https://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.34/linux-2.6.34.14.tar.xz
> 
> So maybe it should be copied to the buildroot sources mirror.

Could you show which Buildroot configuration exhibits the problem? From
a quick look, the only way for Buildroot to be told to use 2.6.34.14 is
by specifying a custom kernel version. And in this case, it's the user
responsibility to make sure the URL is correct. Why would we keep
2.6.34.14 in our mirror specifically and not the myriad of other kernel
versions that the user may select?

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Buildroot] Kernel download problem.
  2013-06-14 17:41 ` Thomas Petazzoni
@ 2013-08-27 21:21   ` James Potts
  2013-08-27 21:53     ` Thomas Petazzoni
  0 siblings, 1 reply; 4+ messages in thread
From: James Potts @ 2013-08-27 21:21 UTC (permalink / raw)
  To: buildroot

Thomas Petazzoni <thomas.petazzoni@...> writes:

> On Fri, 14 Jun 2013 12:02:44 +0200, Sagaert Johan wrote:
> 
> > There seems to be a problem with the downloading of a kernel when a 
longterm release is selected.
> > 
> > Buildroot tries 
> > 
> > http://www.kernel.org/pub//linux/kernel/v2.6/linux-2.6.34.14.tar.xz 
> > 
> > While the real kernel is at 
> > https://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.34/linux-
2.6.34.14.tar.xz
> > 
> > So maybe it should be copied to the buildroot sources mirror.
> 
> Could you show which Buildroot configuration exhibits the problem? From
> a quick look, the only way for Buildroot to be told to use 2.6.34.14 is
> by specifying a custom kernel version. And in this case, it's the user
> responsibility to make sure the URL is correct. Why would we keep
> 2.6.34.14 in our mirror specifically and not the myriad of other kernel
> versions that the user may select?

Sorry to respond to an older post, but I just ran into the same problem.  
The issue here is how you specify the kernel.  When not using the default 
version, we have the option of "Custom version" or "Custom tarball."  When 
you choose "Custom version" it asks you to fill in the version number, and 
it builds the URL for downloading from kernel.org.  But this only works for 
non-longterm kernels.

I.e, if I choose "Custom version" and specify "2.6.34.6" as the version, 
everything works as expected.  But if I choose "2.6.34.12" as the version, 
buildroot breaks, because it doesn't build the correct URL.

Mind you, this is due to silliness on the part of the kernel.org maintainers 
IMO, for splitting different kernel sub-versions into different directories.

Regardless, buildroot currently doesn't do what's expected, since you can't 
just type in a kernel version and expect it to work.  It would be nice if it 
either (a) knew where to find the various "longterm" kernels, or (b) gave a 
warning that you might need to locate the kernel, and specify the URL under 
the "Custom tarball" option.

-Jim

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Buildroot] Kernel download problem.
  2013-08-27 21:21   ` James Potts
@ 2013-08-27 21:53     ` Thomas Petazzoni
  0 siblings, 0 replies; 4+ messages in thread
From: Thomas Petazzoni @ 2013-08-27 21:53 UTC (permalink / raw)
  To: buildroot

Dear James Potts,

On Tue, 27 Aug 2013 21:21:53 +0000 (UTC), James Potts wrote:

> > Could you show which Buildroot configuration exhibits the problem? From
> > a quick look, the only way for Buildroot to be told to use 2.6.34.14 is
> > by specifying a custom kernel version. And in this case, it's the user
> > responsibility to make sure the URL is correct. Why would we keep
> > 2.6.34.14 in our mirror specifically and not the myriad of other kernel
> > versions that the user may select?
> 
> Sorry to respond to an older post, but I just ran into the same problem.  
> The issue here is how you specify the kernel.  When not using the default 
> version, we have the option of "Custom version" or "Custom tarball."  When 
> you choose "Custom version" it asks you to fill in the version number, and 
> it builds the URL for downloading from kernel.org.  But this only works for 
> non-longterm kernels.
> 
> I.e, if I choose "Custom version" and specify "2.6.34.6" as the version, 
> everything works as expected.  But if I choose "2.6.34.12" as the version, 
> buildroot breaks, because it doesn't build the correct URL.

Aah, ok.

> Mind you, this is due to silliness on the part of the kernel.org maintainers 
> IMO, for splitting different kernel sub-versions into different directories.

Right, but since 3.x, they have apparently changed their mind, and
longterm versions are stored in the same place as the normal kernel
releases. Therefore, I'm not sure there's really a good incentive to
fix this in Buildroot, besides saying "use the Custom tarball" solution
in this case.

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2013-08-27 21:53 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-06-14 10:02 [Buildroot] Kernel download problem Sagaert Johan
2013-06-14 17:41 ` Thomas Petazzoni
2013-08-27 21:21   ` James Potts
2013-08-27 21:53     ` Thomas Petazzoni

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox