[oe] Problems building parts of python using openembedded
Hi. I'm using OE to build for OMAP4, when compiling python, OE reports success, however only the core python seems to be built successfully. Looking at the log files however, we see a lot of ld errors, when it tries to link to x86_64 libraries. As an example, the following is output with ncurses: Looking in ncursesw for ['/home/martin/Cisco/openembedded/oe/build/tmp-nimbus_2012_x-eglibc/sysroots/nimbus-panda/usr/lib'] Found /home/martin/Cisco/openembedded/oe/build/tmp-nimbus_2012_x-eglibc/sysroots/nimbus-panda/usr/lib/libncursesw.so ... ... /home/martin/Cisco/openembedded/oe/build/tmp-nimbus_2012_x-eglibc/sysroots/x86_64-linux/usr/lib/libncursesw.so.5: file not recognized: File format not recognized Any ideas why this happens, and what we can do to fix it? Best Regards Martin Ertsaas ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] Openembedded and ld-linux-armhf.so.3
Hi. I'm working on a pandaboard with OMAP4460. Were trying to use the newest PVR drivers, which conforms to the result that arose from https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012 We have applied the patch at the bottom of that page gcc, and also a patch for making eglibc make ld-linux-armhf, and load ld-linux-armhf instead of ld-linux. Problem is, this gives us a kernel panic when it tries to run init. Linking ld-linux.so.3 to ld-linux-armhf.so.3 does not work, and we're kind of in the dark as to what is missing. We tried fixing this by renaming the toolchain to be arm-none-linux-gnueabihf instead of arm-none-linux-gnueabi, as we heard this might be a problem with hardfloats, but this needed a lot of extra patches, and some patchwork on other packages like openssl and shadow. My question is, are there any ongoing plans to fix this, and make sure that if we have set hard float we make ld-linux-armhf in openembedded? For the record we are using eglibc2.15 and gcc4.6 from openembedded-core. Best regards Martin Ertsaas ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Openembedded and ld-linux-armhf.so.3
On 04/27/12 17:04, Mark Hatle wrote: On 4/27/12 7:38 AM, Martin Ertsås wrote: Hi. I'm working on a pandaboard with OMAP4460. Were trying to use the newest PVR drivers, which conforms to the result that arose from https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012 We have applied the patch at the bottom of that page gcc, and also a patch for making eglibc make ld-linux-armhf, and load ld-linux-armhf instead of ld-linux. Problem is, this gives us a kernel panic when it tries to run init. Linking ld-linux.so.3 to ld-linux-armhf.so.3 does not work, and we're kind of in the dark as to what is missing. We tried fixing this by renaming the toolchain to be arm-none-linux-gnueabihf instead of arm-none-linux-gnueabi, as we heard this might be a problem with hardfloats, but this needed a lot of extra patches, and some patchwork on other packages like openssl and shadow. My question is, are there any ongoing plans to fix this, and make sure that if we have set hard float we make ld-linux-armhf in openembedded? For the record we are using eglibc2.15 and gcc4.6 from openembedded-core. The ARM EABI + HF isn't well tested (to my knowledge) of oe-core. I was under the impressions a few people did use it, and it was working successfully for them. (Generally speaking people seem to agree that there is a place for ARM EABI + HF, but the performance increase to the couple of items where it helps is generally not worth the pain of incompatibility with the core ARM EABI. Thus it's not used very much in OE.) Could you verify that the stock configuration (without any of the changes you described above) is working and will boot w/o a kernel panic at init? If so then it'll be easier to help you track down the particulars of the ld.so name change and related items. --Mark It does work without the said changes, but did see an error in my patch, which resulted in gcc linking to /lib/lib/ld-linux-armhf.so.3. I'm currently compiling with the fixed patch, but at work so I won't be able to see if that was the issue before I get to work on monday. The problem with calling the toolchain arm-none-linux-gnueabihf will not be resolved by this though, but first thing for me now is to be able to use the ld-linux-armhf. -- Martin Best regards Martin Ertsaas ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Openembedded and ld-linux-armhf.so.3
On 04/29/12 04:40, Khem Raj wrote:
> On Fri, Apr 27, 2012 at 5:38 AM, Martin Ertsås wrote:
>> Hi.
>>
>> I'm working on a pandaboard with OMAP4460. Were trying to use the newest
>> PVR drivers, which conforms to the result that arose from
>> https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>>
>> We have applied the patch at the bottom of that page gcc, and also a
>> patch for making eglibc make ld-linux-armhf, and load ld-linux-armhf
>> instead of ld-linux. Problem is, this gives us a kernel panic when it
>> tries to run init. Linking ld-linux.so.3 to ld-linux-armhf.so.3 does not
>> work, and we're kind of in the dark as to what is missing.
>>
>> We tried fixing this by renaming the toolchain to be
>> arm-none-linux-gnueabihf instead of arm-none-linux-gnueabi, as we heard
>> this might be a problem with hardfloats, but this needed a lot of extra
>> patches, and some patchwork on other packages like openssl and shadow.
>>
>> My question is, are there any ongoing plans to fix this, and make sure
>> that if we have set hard float we make ld-linux-armhf in openembedded?
>>
>> For the record we are using eglibc2.15 and gcc4.6 from openembedded-core.
> would you show the patches so I can take a look what you did and whats going
> on
Sure, the patches are attached.
>> Best regards
>> Martin Ertsaas
>>
>> ___
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
--- a/ports/sysdeps/arm/shlib-versions 2011-05-10 09:49:03.0 -0600
+++ b/ports/sysdeps/arm/shlib-versions 2012-04-13 22:52:46.790815748 -0600
@@ -1,4 +1,4 @@
arm.*-.*-linux-gnueabi.* DEFAULT GLIBC_2.4
-arm.*-.*-linux-gnueabi.* ld=ld-linux.so.3
+arm.*-.*-linux-gnueabi.* ld=ld-linux-armhf.so.3
arm.*-.*-linux.* ld=ld-linux.so.2
--- a/elf/dl-load.c 2012-04-14 12:11:37.0 +
+++ b/elf/dl-load.c 2012-04-15 00:39:36.558765502 +
@@ -2086,10 +2086,13 @@
soname = ((const char *) D_PTR (l, l_info[DT_STRTAB])
+ l->l_info[DT_SONAME]->d_un.d_val);
if (strcmp (name, soname) != 0)
+#ifdef __arm__
+ if (strcmp(name, "ld-linux.so.3") || strcmp(soname, "ld-linux-armhf.so.3"))
+#endif
continue;
/* We have a match on a new name -- cache it. */
- add_name_to_object (l, soname);
+ add_name_to_object (l, name);
l->l_soname_added = 1;
}
# DP: For ARM hard float, set the dynamic linker to
# DP: /lib/ld-linux-armhf.so.3.
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 80bd825..8c9d2e7 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -62,7 +62,11 @@
/* Use ld-linux.so.3 so that it will be possible to run "classic"
GNU/Linux binaries on an EABI system. */
#undef GLIBC_DYNAMIC_LINKER
-#define GLIBC_DYNAMIC_LINKER SYSTEMLIBS_DIR "ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT "/lib/ld-linux-armhf.so.3"
+#define GLIBC_DYNAMIC_LINKER \
+ "%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
+%{!mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}"
/* At this point, bpabi.h will have clobbered LINK_SPEC. We want to
use the GNU/Linux version, not the generic BPABI version. */
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Openembedded and ld-linux-armhf.so.3
On 05/01/12 00:05, Khem Raj wrote: On Fri, Apr 27, 2012 at 5:38 AM, Martin Ertsås wrote: I'm working on a pandaboard with OMAP4460. Were trying to use the newest PVR drivers, which conforms to the result that arose from https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012 We have applied the patch at the bottom of that page gcc, and also a patch for making eglibc make ld-linux-armhf, and load ld-linux-armhf instead of ld-linux. Problem is, this gives us a kernel panic when it tries to run init. interesting bits are why kernel panics ? what error do you get from kernel ? is it some illegal instruction or something like that ? Do you have VFP enabled ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel Found out the problem why kernel panics. The patches I posted were the correct ones, but before this I used SYSLIB_PATH or something before "/lib/ld-linux-armhf.so.3", so the output actually was /lib/lib/ld-linux-armhf.so.3 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Openembedded and ld-linux-armhf.so.3
On 05/01/12 14:32, Khem Raj wrote: On Mon, Apr 30, 2012 at 11:44 PM, Martin Ertsås wrote: On 05/01/12 00:05, Khem Raj wrote: On Fri, Apr 27, 2012 at 5:38 AM, Martin Ertsåswrote: I'm working on a pandaboard with OMAP4460. Were trying to use the newest PVR drivers, which conforms to the result that arose from https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012 We have applied the patch at the bottom of that page gcc, and also a patch for making eglibc make ld-linux-armhf, and load ld-linux-armhf instead of ld-linux. Problem is, this gives us a kernel panic when it tries to run init. interesting bits are why kernel panics ? what error do you get from kernel ? is it some illegal instruction or something like that ? Do you have VFP enabled ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel Found out the problem why kernel panics. The patches I posted were the correct ones, but before this I used SYSLIB_PATH or something before "/lib/ld-linux-armhf.so.3", so the output actually was /lib/lib/ld-linux-armhf.so.3 ok good. I would be interested if you test the patchset i posted it will help a lot ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel I'll try them tomorrow and send a mail telling the findings. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Openembedded and ld-linux-armhf.so.3
On 05/01/12 14:32, Khem Raj wrote: > On Mon, Apr 30, 2012 at 11:44 PM, Martin Ertsås wrote: >> On 05/01/12 00:05, Khem Raj wrote: >>> On Fri, Apr 27, 2012 at 5:38 AM, Martin Ertsås wrote: >>>> I'm working on a pandaboard with OMAP4460. Were trying to use the newest >>>> PVR drivers, which conforms to the result that arose from >>>> https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012 >>>> >>>> We have applied the patch at the bottom of that page gcc, and also a >>>> patch for making eglibc make ld-linux-armhf, and load ld-linux-armhf >>>> instead of ld-linux. Problem is, this gives us a kernel panic when it >>>> tries to run init. >>> interesting bits are why kernel panics ? >>> what error do you get from kernel ? >>> is it some illegal instruction or something like that ? >>> Do you have VFP enabled >>> >>> ___ >>> Openembedded-devel mailing list >>> Openembedded-devel@lists.openembedded.org >>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel >> Found out the problem why kernel panics. The patches I posted were the >> correct ones, but before this I used >> >> SYSLIB_PATH or something before "/lib/ld-linux-armhf.so.3", so the output >> actually was /lib/lib/ld-linux-armhf.so.3 >> > ok good. I would be interested if you test the patchset i posted > it will help a lot > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel The patches posted seems to be working fine. I at least didn't have any problems with them. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Openembedded and ld-linux-armhf.so.3
On 05/02/12 23:06, Khem Raj wrote: > On 05/02/2012 02:35 AM, Martin Ertsås wrote: > > The patches posted seems to be working fine. I at least didn't have > > any problems with them. > > > thanks for trying them out. GCC patch is final but eglibc patch I > still got to improve that its not final version yet. No problem. Is there also plans for renaming the toolchains created to arm-none-linux-gnueabihf when using hardfloats? Tried doing that, but gcc failed first. Then, after patching up gcc like a madman as well as adding linux-gnueabihf to the package_qa_get_machine_dict dictionary in insane.bbclass, several other projects failed. Among them were openssl and shadow as far as I remember. Probably others as well, but that's where I gave up. Cool, so this will be put upstream with gcc 4.7 and eglibc 2.15? Btw, I was trying your patches with 4.6, not 4.7, as we have not attempted to migrate right now. Will do that soon though, but not right now. - Martin > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Openembedded and ld-linux-armhf.so.3
On 05/03/12 09:48, Koen Kooi wrote: > Op 03-05-12 08:48, Martin Ertsås schreef: > > On 05/02/12 23:06, Khem Raj wrote: > >> On 05/02/2012 02:35 AM, Martin Ertsås wrote: > >>> The patches posted seems to be working fine. I at least didn't have > >>> any problems with them. > >> > >> > >> thanks for trying them out. GCC patch is final but eglibc patch I still > >> got to improve that its not final version yet. > > > No problem. Is there also plans for renaming the toolchains created to > > arm-none-linux-gnueabihf when using hardfloats? > > What's the point in that? Renaming the toolchain won't grant it magical > powers and setting a targetvendor is perfectly valid. > > I've seen too many presentations this year at ELC and Collab where someone > says "renaming the toolchain fixed it" when they actually mean "using a > bare-metal toolchain for userspace doesn't really work". > Just look at the building the kernel with LLVM talk, a third of Marks > presentation was about challenges with calling the right toolchain > with the > right arguments. > > Fair point, I was just told that some packages might look at the name of the toolchain, and perhaps not give the optimal path for hard floats with the name of linux-gnueabi. Clearly some packages do actually look at the name of the toolchain, but for most cases at least, the only difference will be the hardfloat flag given to the compiler. Also seen quite a few toolchains using hardfloats which has the hf prefix, to show that this is actually a hardfloat toolchain. > > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] New kmod {libdir} breaks udev 182 build
On 05/15/12 10:39, Thilo Fromm wrote:
> Hello Khem,
>
>>> I've got an issue with
>>> openembedded-core/meta/recipes-kernel/kmod/kmod_git.bb, with the way
>>> {libdir} is set in line 19:
>>>
>>> libdir = "${base_libdir}"
>>>
>>> "git blame" claims this was added by Khem Raj on 2012-05-08. This line
>>> causes libkmod to put its pkgconfig ".pc" file in the staging area at
>>> "/lib/pkgconfig/libkmod.pc". This is sad because other recipes would
>>> only look at /usr/lib/pkgconfig/ and /usr/share/pkgconfig.
>>>
>>> Take meta-openembedded/meta-oe/recipes-core/udev/udev_182.bb, for
>>> example. The build predictably fails with
>>>
>>> checking for KMOD... no
>>> configure: error: Package requirements (libkmod >= 5) were not met:
>>>
>>> No package 'libkmod' found
>>>
>>>
>>> So what's the right thing do do here? Use a different package install
>>> path for libkmod, or point udev to /lib/pkgconfig by extending its
>>> PKG_CONFIG_PATH correspondingly?
>> One solution is to fix kmod to install pc files in /usr/lib with right paths
>> to access libkmod
>>
>> second solution is to look for pc files in ${base_libdir} while building udev
>> can you try this option.
> Yes, I was trying to state these two possible resolutions in my first
> mail. I already tried adding
>
> PKG_CONFIG_PATH =
> "${PKG_CONFIG_DIR}:${STAGING_DATADIR}/pkgconfig:${PKG_CONFIG_SYSROOT_DIR}/${base_libdir}/pkgconfig/"
>
> to udev-182 and systemd (which is also affected) recipes. It works
> around the bug. Still, I think kmod is publishing its .pc files in the
> wrong directory.
>
> Regards,
> Thilo
>
We are also having this issue, and have just added this hack in a
bbappend for udev and systemd. Not a pretty solution, but found it to be
a lot of work to make only the .pc files be put in /usr/lib/pkgconfig
instead of /lib/pkgconfig. I totally agree that kmod publishes it's .pc
files in the wrong directory, as every distro I have tried uses
/usr/lib/pkgconfig as the pkgconfig directory. Guess we will keep this
hack until kmod is fixed upstream though.
- Martin
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] gcc-crosssdk-initial can not compile. Get message: this target does not support --with-float
Hi. When trying to compile meta-toolchain, it crashes during gcc-cross-initial with the error: this target does not support --with-float Valied --with options are: arch arch_32 arch_64 cpu cpu_32 cpu_64 tune tune_32 tune_64 The reason for this is a commit that happened 2012-05-01 in openembedded core, called "gcc: Grok for callconvention-hard to enable hard float". Reverting this patches makes it compile, and still I get the --mfloat-abi=hard when compiling with the resulting toolchain. I'm compiling on a x64 Linux machine, with the target being a cortexa9 processor. I have the DEFAULTTUNE set to cortexa9hf-neon. What should the patch do, and what will happen if I disable it? Best regard Martin ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] gcc-crosssdk-initial can not compile. Get message: this target does not support --with-float
Sure. Will do it first thing in the morning. Think this actually happens in compile though, for some reason. Do you want me to paste it and give a link, or is it ok with an attachment? - Martin On 06/04/12 18:32, Khem Raj wrote: On Sun, Jun 3, 2012 at 11:49 PM, Martin Ertsås wrote: Hi. When trying to compile meta-toolchain, it crashes during gcc-cross-initial with the error: this target does not support --with-float Valied --with options are: arch arch_32 arch_64 cpu cpu_32 cpu_64 tune tune_32 tune_64 can you post log.do_configure of this package somewhere ? The reason for this is a commit that happened 2012-05-01 in openembedded core, called "gcc: Grok for callconvention-hard to enable hard float". Reverting this patches makes it compile, and still I get the --mfloat-abi=hard when compiling with the resulting toolchain. I'm compiling on a x64 Linux machine, with the target being a cortexa9 processor. I have the DEFAULTTUNE set to cortexa9hf-neon. What should the patch do, and what will happen if I disable it? Best regard Martin ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] gcc-crosssdk-initial can not compile. Get message: this target does not support --with-float
The configure log is at: http://pastebin.com/93h1rw7G while the compile log, which is what actually failes, is at: http://pastebin.com/2iXYrCDa Be warned that the compile log is quite big, a little over 1700 lines, and do seem to actually be a configure step, not a compilation step. This really puzzles me. Thanks for the help - Martin On 06/05/12 22:53, Khem Raj wrote: > On Tuesday, June 5, 2012, Martin Ertsås wrote: >> Sure. Will do it first thing in the morning. Think this actually happens > in compile though, for some reason. Do you want me to paste it and give a > link, or is it ok with an attachment? > > Paste in is ok >> - Martin >> >> On 06/04/12 18:32, Khem Raj wrote: >>> On Sun, Jun 3, 2012 at 11:49 PM, Martin Ertsås > wrote: >>>> Hi. >>>> >>>> When trying to compile meta-toolchain, it crashes during >>>> gcc-cross-initial with the error: >>>> >>>> this target does not support --with-float >>>> Valied --with options are: arch arch_32 arch_64 cpu cpu_32 cpu_64 tune >>>> tune_32 tune_64 >>> can you post log.do_configure of this package somewhere ? >>> >>>> The reason for this is a commit that happened 2012-05-01 in openembedded >>>> core, called "gcc: Grok for callconvention-hard to enable hard float". >>>> Reverting this patches makes it compile, and still I get the >>>> --mfloat-abi=hard when compiling with the resulting toolchain. >>>> >>>> I'm compiling on a x64 Linux machine, with the target being a cortexa9 >>>> processor. I have the DEFAULTTUNE set to cortexa9hf-neon. What should >>>> the patch do, and what will happen if I disable it? >>>> >>>> Best regard >>>> Martin >>>> >>>> ___ >>>> Openembedded-devel mailing list >>>> Openembedded-devel@lists.openembedded.org >>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel >>> ___ >>> Openembedded-devel mailing list >>> Openembedded-devel@lists.openembedded.org >>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel >> >> ___ >> Openembedded-devel mailing list >> Openembedded-devel@lists.openembedded.org >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel >> > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] gcc-crosssdk-initial can not compile. Get message: this target does not support --with-float
This fixed it. Thanks. - Martin On 06/10/12 00:25, Khem Raj wrote: > On 6/5/2012 11:20 PM, Martin Ertsås wrote: > > The configure log is at: http://pastebin.com/93h1rw7G while the > > compile log, which is what actually failes, is at: > > http://pastebin.com/2iXYrCDa > > > can you try this patch please > > http://patchwork.openembedded.org/patch/29589/ > > and report if it fixes the problem. > > -Khem > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] Moving pkg.m4 to the x86 sysroot instead of arm sysroot in toolchain
Hi. When building meta-toolchain, pkg.m4 is put in the arm sysroot of the toolchain, instead of the x86 sysroot where it belongs. pkg-config is in the x86 directory, and when it is in the arm directory, we need to hack the aclocal flags to point to it for stuff to compile. I have tried a few things, like adding pkgconfig-nativesdk to the task-sdk-host-nativesdk and pkgconfig to task-core-standalone-sdk. From my understanding, the former should populate the x86 directory, but obviously it didn't. Any ideas to what I can do to fix this? It would be greatly appreciated. Best regard Martin Ertsaas ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Moving pkg.m4 to the x86 sysroot instead of arm sysroot in toolchain
The issue was quite simple. My thoughts were correct, but should add pkgconfig-nativesdk-dev to task-sdk-host-nativesdk. - Martin On 07/23/12 10:46, Martin Ertsås wrote: > Hi. > > When building meta-toolchain, pkg.m4 is put in the arm sysroot of the > toolchain, instead of the x86 sysroot where it belongs. pkg-config is in > the x86 directory, and when it is in the arm directory, we need to hack > the aclocal flags to point to it for stuff to compile. > > I have tried a few things, like adding pkgconfig-nativesdk to the > task-sdk-host-nativesdk and pkgconfig to task-core-standalone-sdk. From > my understanding, the former should populate the x86 directory, but > obviously it didn't. Any ideas to what I can do to fix this? It would be > greatly appreciated. > > Best regard > Martin Ertsaas > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] meta-qt5 available
Hi. I have just made a new layer, for qt5 recipes. This contains work in progress recipes, but should be working. In the (not so) long run, qt5 recipes will hopefully be added to oe-core, but in the meantime these are available. The recipes are based on the qt4 recipes in oe-core from 4-5 months ago, and some of them might be a bit messy. If anyone feels the urge to help out with this layer, and make these recipes as good as humanly possible, feel free to do so. The project is located at git://github.com/martiert/meta-qt5.git Best Regards Martin Ertsaas ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Hello
Hi, and welcome. The way we started was by looking at the angstrom distribution. That is available as a oe-core layer, and you can easily start by compiling that one. After that, we started taking stuff from angstrom, into our own repository. Starting with configurations, and changing them as we wanted. And when we had our own, angstrom based, distro up and running, we started adding what we needed. But start looking at angstrom, and understand how oe works, at least that is my tip. - Martin On 08/24/12 11:14, Giuseppe Longo wrote: > Hello everyone, > i'm a new member of this list. > > Although i have no experience, i would like to learn howto create > linux distro for embedded systems. > > I would like to ask some basic questions: > - where do you start to create a linux distro? > - i need an embedded device without any os or firmware? > > Thanks, > Best regards. > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH] task-x11*: Rename to packagegroup to match oe-core.
Ok. Nice. Did not see your patches there.
- Martin
On 09/05/12 11:25, Martin Jansa wrote:
> On Wed, Sep 05, 2012 at 11:22:32AM +0200, Martin Ertsaas wrote:
>> ---
>> .../packagegroups/packagegroup-x11-server_1.0.bb | 23 +++
>> .../packagegroups/packagegroup-x11_1.0.bb | 30
>>
>> meta-oe/recipes-core/tasks/task-x11-server_1.0.bb | 23 ---
>> meta-oe/recipes-core/tasks/task-x11_1.0.bb | 30
>>
>> 4 files changed, 53 insertions(+), 53 deletions(-)
>> create mode 100644
>> meta-oe/recipes-core/packagegroups/packagegroup-x11-server_1.0.bb
>> create mode 100644
>> meta-oe/recipes-core/packagegroups/packagegroup-x11_1.0.bb
>> delete mode 100644 meta-oe/recipes-core/tasks/task-x11-server_1.0.bb
>> delete mode 100644 meta-oe/recipes-core/tasks/task-x11_1.0.bb
> NACK
>
> see my previous patches (and cover of last pull request).
>
> http://git.openembedded.org/meta-openembedded-contrib/log/?h=jansa/packagegroup
>
> after
> http://patchwork.openembedded.org/patch/35839/
> http://patchwork.openembedded.org/patch/35841/
> are applied in oe-core
>
> Cheers,
>
>> diff --git
>> a/meta-oe/recipes-core/packagegroups/packagegroup-x11-server_1.0.bb
>> b/meta-oe/recipes-core/packagegroups/packagegroup-x11-server_1.0.bb
>> new file mode 100644
>> index 000..7e43d55
>> --- /dev/null
>> +++ b/meta-oe/recipes-core/packagegroups/packagegroup-x11-server_1.0.bb
>> @@ -0,0 +1,23 @@
>> +DESCRIPTION = "Task for an image with Xserver"
>> +LICENSE = "MIT"
>> +LIC_FILES_CHKSUM =
>> "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58"
>> +PR = "r9"
>> +
>> +inherit task
>> +
>> +# for backwards compatibility
>> +RPROVIDES_${PN} += "task-xserver"
>> +
>> +XSERVER ?= "xserver-xorg \
>> + xf86-input-evdev \
>> + xf86-input-mouse \
>> + xf86-video-fbdev \
>> + xf86-input-keyboard \
>> +"
>> +
>> +
>> +RDEPENDS_${PN} = " \
>> + ${XSERVER} \
>> +"
>> +
>> +PACKAGE_ARCH = "${MACHINE_ARCH}"
>> diff --git a/meta-oe/recipes-core/packagegroups/packagegroup-x11_1.0.bb
>> b/meta-oe/recipes-core/packagegroups/packagegroup-x11_1.0.bb
>> new file mode 100644
>> index 000..326e09f
>> --- /dev/null
>> +++ b/meta-oe/recipes-core/packagegroups/packagegroup-x11_1.0.bb
>> @@ -0,0 +1,30 @@
>> +DESCRIPTION = "The X Window System -- install this task to get a
>> client/server based display multiplexer."
>> +SECTION = "x11/server"
>> +LICENSE = "MIT"
>> +LIC_FILES_CHKSUM =
>> "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
>> +PR = "r11"
>> +
>> +inherit task allarch
>> +
>> +PACKAGES += "${PN}-utils"
>> +
>> +RRECOMMENDS_${PN} = "\
>> + ${PN}-server \
>> + ${PN}-utils \
>> +"
>> +
>> +# xserver-common, x11-common
>> +VIRTUAL-RUNTIME_xserver_common ?= "xserver-common"
>> +
>> +# elsa or xserver-nodm-init(-systemd)
>> +VIRTUAL-RUNTIME_graphical_init_manager ?= "xserver-nodm-init"
>> +
>> +RDEPENDS_${PN}-utils = "\
>> + ${VIRTUAL-RUNTIME_xserver_common} \
>> + ${VIRTUAL-RUNTIME_graphical_init_manager} \
>> + xauth \
>> + xhost \
>> + xset \
>> + xrandr \
>> +"
>> +
>> diff --git a/meta-oe/recipes-core/tasks/task-x11-server_1.0.bb
>> b/meta-oe/recipes-core/tasks/task-x11-server_1.0.bb
>> deleted file mode 100644
>> index 7e43d55..000
>> --- a/meta-oe/recipes-core/tasks/task-x11-server_1.0.bb
>> +++ /dev/null
>> @@ -1,23 +0,0 @@
>> -DESCRIPTION = "Task for an image with Xserver"
>> -LICENSE = "MIT"
>> -LIC_FILES_CHKSUM =
>> "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58"
>> -PR = "r9"
>> -
>> -inherit task
>> -
>> -# for backwards compatibility
>> -RPROVIDES_${PN} += "task-xserver"
>> -
>> -XSERVER ?= "xserver-xorg \
>> - xf86-input-evdev \
>> - xf86-input-mouse \
>> - xf86-video-fbdev \
>> - xf86-input-keyboard \
>> -"
>> -
>> -
>> -RDEPENDS_${PN} = " \
>> - ${XSERVER} \
>> -"
>> -
>> -PACKAGE_ARCH = "${MACHINE_ARCH}"
>> diff --git a/meta-oe/recipes-core/tasks/task-x11_1.0.bb
>> b/meta-oe/recipes-core/tasks/task-x11_1.0.bb
>> deleted file mode 100644
>> index 326e09f..000
>> --- a/meta-oe/recipes-core/tasks/task-x11_1.0.bb
>> +++ /dev/null
>> @@ -1,30 +0,0 @@
>> -DESCRIPTION = "The X Window System -- install this task to get a
>> client/server based display multiplexer."
>> -SECTION = "x11/server"
>> -LICENSE = "MIT"
>> -LIC_FILES_CHKSUM =
>> "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
>> -PR = "r11"
>> -
>> -inherit task allarch
>> -
>> -PACKAGES += "${PN}-utils"
>> -
>> -RRECOMMENDS_${PN} = "\
>> - ${PN}-server \
>> - ${PN}-utils \
>> -"
>> -
>> -# xserver-common, x11-common
>> -VIRTUAL-RUNTIME_xserver_common ?= "xserver-common"
>> -
>> -# elsa or xserver-nodm-init(-systemd)
>> -VIRTUAL-RUNTIME_graphical_init_manager ?= "xserver-nodm-init"
>> -
>> -RDEPENDS_${PN}-utils = "\
>> - ${VIRTUAL-RUNTIME_xserver_common} \
>> - ${VIRTUAL-RUNTIME_graphical_init_manag
Re: [oe] jni.h included
As you are using icedtea6, I guess DEPENDS += "icedtea6" should do it.
- Martin
On 10/08/12 16:49, Jaap de Jong wrote:
>
> On 10/08/2012 04:05 PM, Khem Raj wrote:
>> On Mon, Oct 8, 2012 at 4:18 AM, Jaap de Jong
>> wrote:
>>> Hi All!
>>> probably a stupid question... my apologies!
>>> If a source I'm working on #include jni.h what do I need to add in a
>>> recipe
>>> to get it translated?
>> DEPENDS += "openjdk" or something like that which denotes jdk
>>
> Tried
> DEPENDS += "openjdk"
> unfortunately errors out with
> ERROR: Nothing PROVIDES 'openjdk'
>
> Tried with
> DEPENDS += "openjdk-6"
> but that errors out with
> fatal error: jni.h: No such file or directory
>
> So finally I ended up adding this:
> CFLAGS += "-I${STAGING_LIBDIR_NATIVE}/jvm/icedtea6-native/include
> -I${STAGING_LIBDIR_NATIVE}/jvm/icedtea6-native/include/linux"
> But that just looks so ugly...
>
>
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH] libftdi: Change to use GPLv2 intead of GPLv2-REL
On 10/09/12 19:27, Martin Jansa wrote: > On Tue, Oct 09, 2012 at 02:04:25PM +0200, Martin Ertsaas wrote: >> According to http://www.intra2net.com/en/developer/libftdi/, libftdi itself >> is licensed under LGPLv2, >> with some parts (eeprom programmer) is licensed under GPLv2. There doesn't >> seem to be any part licensed >> under a GPLv2-REL variation of GPLv2, and so we should use GPLv2 instead of >> GPLv2-REL. > Is it REL or RLE? Your subject and body says REL while LICENSE says RLE. > > Cheers, Damn, didn't see that typo. I'll push a new one asap. - Martin > >> Signed-off-by: Martin Ertsaas >> --- >> meta-oe/recipes-support/libftdi/libftdi_0.19.bb |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/meta-oe/recipes-support/libftdi/libftdi_0.19.bb >> b/meta-oe/recipes-support/libftdi/libftdi_0.19.bb >> index 2dba3f4..0842aaf 100644 >> --- a/meta-oe/recipes-support/libftdi/libftdi_0.19.bb >> +++ b/meta-oe/recipes-support/libftdi/libftdi_0.19.bb >> @@ -4,7 +4,7 @@ including the popular bitbang mode." >> HOMEPAGE = "http://www.intra2net.com/en/developer/libftdi/"; >> SECTION = "libs" >> >> -LICENSE = "LGPLv2.1 GPLv2-RLE" >> +LICENSE = "LGPLv2.1 GPLv2" >> LIC_FILES_CHKSUM= "file://COPYING.GPL;md5=751419260aa954499f7abaabaa882bbe \ >> file://COPYING.LIB;md5=db979804f025cf55aabec7129cb671ed \ >>" >> -- >> 1.7.8.6 >> >> >> ___ >> Openembedded-devel mailing list >> Openembedded-devel@lists.openembedded.org >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] jni.h included
Assuming you use meta-java, it seems like what you are looking for is:
DEPENDS += "openjdk-6-jdk"
as that at least contains the include, lib and bin directory.
- Martin
On 10/10/12 08:40, Jaap de Jong wrote:
>
> On 10/09/2012 07:51 AM, Martin Ertsås wrote:
>> As you are using icedtea6, I guess DEPENDS += "icedtea6" should do it.
>>
>> - Martin
> I thought that might do the trick, but...
> ERROR: Nothing PROVIDES 'icedtea6'
> So I tried
> DEPENDS += "icedtea6-native"
> and that ends with
> jni.h: No such file or directory
>
> Any other ideas?
>
>> On 10/08/12 16:49, Jaap de Jong wrote:
>>> On 10/08/2012 04:05 PM, Khem Raj wrote:
>>>> On Mon, Oct 8, 2012 at 4:18 AM, Jaap de Jong
>>>> wrote:
>>>>> Hi All!
>>>>> probably a stupid question... my apologies!
>>>>> If a source I'm working on #include jni.h what do I need to add in a
>>>>> recipe
>>>>> to get it translated?
>>>> DEPENDS += "openjdk" or something like that which denotes jdk
>>>>
>>> Tried
>>> DEPENDS += "openjdk"
>>> unfortunately errors out with
>>> ERROR: Nothing PROVIDES 'openjdk'
>>>
>>> Tried with
>>> DEPENDS += "openjdk-6"
>>> but that errors out with
>>> fatal error: jni.h: No such file or directory
>>>
>>> So finally I ended up adding this:
>>> CFLAGS += "-I${STAGING_LIBDIR_NATIVE}/jvm/icedtea6-native/include
>>> -I${STAGING_LIBDIR_NATIVE}/jvm/icedtea6-native/include/linux"
>>> But that just looks so ugly...
>>>
>>>
>>>
>>> ___
>>> Openembedded-devel mailing list
>>> Openembedded-devel@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>> ___
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>>
>
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-systemd][PATCH] meta-systemd: ntp: Change version to what is used in meta-networking.
On 10/26/12 09:14, Koen Kooi wrote: > Op 25-10-12 20:58, Martin Ertsaas schreef: > > Change version of ntp to match that in meta-networking. Also change > > ntpdate to ntp-date to match the names used in meta-networking. > > While you are there, can you also disable the autoactivating for the unit? > It's broken and I'm gettig tired of doing 'systemctl disable' on it for > every system. > To disable the autoactivating, were you thinking linking ntpd(ate).service to /dev/null, or something more sophisticated. - Martin > > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-systemd][PATCH] meta-systemd: ntp: Change version to what is used in meta-networking.
On 10/26/12 10:01, Martin Jansa wrote: > On Fri, Oct 26, 2012 at 09:14:43AM +0200, Koen Kooi wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Op 25-10-12 20:58, Martin Ertsaas schreef: >>> Change version of ntp to match that in meta-networking. Also change >>> ntpdate to ntp-date to match the names used in meta-networking. >> While you are there, can you also disable the autoactivating for the unit? >> It's broken and I'm gettig tired of doing 'systemctl disable' on it for >> every system. > Cannot we fix it? Last time I've noticed it was using wrong binary (not > installed by ntpdate package) from .service file. > > SHR root@qemux86-64 ~ $ opkg files ntpdate > Package ntpdate (4.2.6p3-r7) is installed on root and has the following > files: > /etc/network/if-up.d/ntpdate > /usr/bin/ntpdate > SHR root@qemux86-64 ~ $ grep Exec /lib/systemd/system/ntpdate.service > ExecStart=/usr/bin/ntpd -q -g -x > > Cheers, > > > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel So what is happening is that if you just install ntpdate, it still tries to use ntpd, which doesn't exist? Sorry for the questions now, but I don't have anywhere to test this right now. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-systemd][PATCH v2 2/2] meta-systemd: ntp: Fix starting of ntpdate.service
On 10/26/12 17:07, Burton, Ross wrote: On 26 October 2012 15:35, Enrico Scholz wrote: Martin Ertsaas writes: Type=oneshot -ExecStart=/usr/bin/ntpd -q -g -x +ExecStart=/usr/bin/ntpdate pool.ntp.org This should be made configurable. E.g. Environment=NTPHOSTS=pool.ntp.org EnvironmentFile=-/etc/sysconfig/ntp.conf ExecStart=/usr/bin/ntpdate $NTPHOSTS From http://www.pool.ntp.org/en/vendors.html: "To allow you to use the pool as the default time service in your application, we will set you up with special hostnames, for example 0.vendor.pool.ntp.org, 1.vendor.pool.ntp.org, 2.vendor.pool.ntp.org and 3.vendor.pool.ntp.org. You must absolutely not use the default pool.ntp.org zone names as the default configuration in your application or appliance." Someone -- probably someone on the TSC I suspect as a representative of the YP -- should register a vendor pool so we can default to 0.yocto.pool.ntp.org or something similar. Ross ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel That sounds like a good way to do it. Then we can simply use that as the default, and have the possibility to use an NTPHOST or something. Should we leave this until someone registers a pool, or what would be a good default pool until someone does it? - Martin ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH v2 1/3] meta-systemd: Move ntp recipes to 'meta-networking' sublayer
For this you should also have a look at the ntpdate.service and
ntp.service files. There was a discussion about this earlier:
http://patches.openembedded.org/patch/38575/
Also, what is not on that discussion, is that pool.ntp.org is not really
the way to do it. What we would like is to register something like
pool.yocto.ntp.org, but for
now I guess we can just use pool.ntp.org and then change it when someone
have registered it. Kind of feel someone officially related to the
project should register it.
- Martin
On 10/31/12 12:08, Otavio Salvador wrote:
> Signed-off-by: Otavio Salvador
> ---
> .../recipes-support/ntp/ntp/ntpd.service |0
> .../recipes-support/ntp/ntp/ntpdate.service|0
> .../recipes-support/ntp/ntp_4.2.6p3.bbappend |0
> 3 files changed, 0 insertions(+), 0 deletions(-)
> rename meta-systemd/{meta-oe =>
> meta-networking}/recipes-support/ntp/ntp/ntpd.service (100%)
> rename meta-systemd/{meta-oe =>
> meta-networking}/recipes-support/ntp/ntp/ntpdate.service (100%)
> rename meta-systemd/{meta-oe =>
> meta-networking}/recipes-support/ntp/ntp_4.2.6p3.bbappend (100%)
>
> diff --git a/meta-systemd/meta-oe/recipes-support/ntp/ntp/ntpd.service
> b/meta-systemd/meta-networking/recipes-support/ntp/ntp/ntpd.service
> similarity index 100%
> rename from meta-systemd/meta-oe/recipes-support/ntp/ntp/ntpd.service
> rename to meta-systemd/meta-networking/recipes-support/ntp/ntp/ntpd.service
> diff --git a/meta-systemd/meta-oe/recipes-support/ntp/ntp/ntpdate.service
> b/meta-systemd/meta-networking/recipes-support/ntp/ntp/ntpdate.service
> similarity index 100%
> rename from meta-systemd/meta-oe/recipes-support/ntp/ntp/ntpdate.service
> rename to meta-systemd/meta-networking/recipes-support/ntp/ntp/ntpdate.service
> diff --git a/meta-systemd/meta-oe/recipes-support/ntp/ntp_4.2.6p3.bbappend
> b/meta-systemd/meta-networking/recipes-support/ntp/ntp_4.2.6p3.bbappend
> similarity index 100%
> rename from meta-systemd/meta-oe/recipes-support/ntp/ntp_4.2.6p3.bbappend
> rename to
> meta-systemd/meta-networking/recipes-support/ntp/ntp_4.2.6p3.bbappend
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH v2 1/3] meta-systemd: Move ntp recipes to 'meta-networking' sublayer
On 10/31/12 13:11, Phil Blundell wrote: > On Wed, 2012-10-31 at 12:43 +0100, Martin Ertsås wrote: > >> for now I guess we can just use pool.ntp.org > > I'm not sure that this is a very good idea. The pool.ntp.org > documentation is fairly explicit that they don't want this: > > > You must absolutely not use the default pool.ntp.org zone names > as the default configuration in your application or appliance. > > > p. > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel Should we just leave the .service files broken then, until someone registers a pool? Or are we allowed to use someone else's pool? - Martin ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes
On 11/01/12 02:08, Paul Eggleton wrote:
On Tuesday 23 October 2012 12:20:20 Morgan Little wrote:
-PACKAGES += "ntpdate ${PN}-bin ${PN}-tickadj ${PN}-utils"
...
+PACKAGES += "${PN}-date ${PN}-bin ${PN}-tickadj ${PN}-utils"
I'm not particularly happy with this change. Apart from the fact that it
wasn't mentioned in the commit message, it breaks any recipe that depends upon
the previous ntpdate package. Could we go back to the old ntpdate name for the
package or at the very least provide an RPROVIDES for the old name? I'm happy
to submit a patch to do this once there is agreement either way.
Cheers,
Paul
I agree with you. Also find it kind of strange to change from ntpdate to
ntp-date, as the universally known name of that module is ntpdate. Don't
really see the rational of changing that to ntp-date in the recipe.
- Martin
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes
On 11/01/12 18:32, Joe MacDonald wrote: > [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On > 12.11.01 (Thu 17:19) Paul Eggleton wrote: > >> On Thursday 01 November 2012 17:09:59 Little, Morgan wrote: >>> My rational behind splitting like that is if it is just ntpdate and you try >>> to add ntp-ssl and ntpdate it will use ntp to provide ntpdate. It could be >>> change add RPROVIDES so ntp will provide ntpdate and ntp-ssl provides a >>> uniquely named version. >> The ssl version could be ntpdate-ssl if it needs to be unique. I think >> originally though these recipes weren't intended to be built side-by-side - >> rather they were mutually exclusive and the distro would make a choice as to >> which one was built. > Hmm, good point. > > Does it make sense to have both on a system? That is, if you build > ntp-ssl does that imply it will only use SSL for communications? If > that's not the case (which I suspect it isn't, but I haven't checked > myself) then there's not really a strong reason to install both on the > same system. Which then seems fine to provide ntpdate-ssl as the > alternative. > > Now that I think about it a bit more, maybe a RPROVIDES is appropriate > since ntp and ntpdate are overlapping in a lot of places. > > > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel Are you thinking of ntp providing ntpdate then? In my mind at least, this makes sense, as ntp seems able to do whatever ntpdate does, so I don't really see the rational of having both on the same system. - Martin ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes
On 11/02/12 14:01, Joe MacDonald wrote: > [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On > 12.11.02 (Fri 08:00) Martin Ertsås wrote: > >> On 11/01/12 18:32, Joe MacDonald wrote: >>> [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] >>> On 12.11.01 (Thu 17:19) Paul Eggleton wrote: >>> >>>> On Thursday 01 November 2012 17:09:59 Little, Morgan wrote: >>>>> My rational behind splitting like that is if it is just ntpdate and you >>>>> try >>>>> to add ntp-ssl and ntpdate it will use ntp to provide ntpdate. It could be >>>>> change add RPROVIDES so ntp will provide ntpdate and ntp-ssl provides a >>>>> uniquely named version. >>>> The ssl version could be ntpdate-ssl if it needs to be unique. I think >>>> originally though these recipes weren't intended to be built side-by-side >>>> - >>>> rather they were mutually exclusive and the distro would make a choice as >>>> to >>>> which one was built. >>> Hmm, good point. >>> >>> Does it make sense to have both on a system? That is, if you build >>> ntp-ssl does that imply it will only use SSL for communications? If >>> that's not the case (which I suspect it isn't, but I haven't checked >>> myself) then there's not really a strong reason to install both on the >>> same system. Which then seems fine to provide ntpdate-ssl as the >>> alternative. >>> >>> Now that I think about it a bit more, maybe a RPROVIDES is appropriate >>> since ntp and ntpdate are overlapping in a lot of places. >>> >>> >>> >>> ___ >>> Openembedded-devel mailing list >>> Openembedded-devel@lists.openembedded.org >>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel >> Are you thinking of ntp providing ntpdate then? In my mind at least, >> this makes sense, as ntp seems able to do whatever ntpdate does, so I >> don't really see the rational of having both on the same system. > Yeah, exactly. The only time I've ever wanted both ntp and ntpdate on > the same system at the same time was when I had a system with a clock > that was so badly damaged occasionally ntp couldn't recover it and I > needed to just do a reset on the time. But I could have even > accomplished that with ntp -q. In fact, a quick check of the ntp > manpage on my system says: > >-q Exit the ntpd just after the first time the clock is set. > This behavior mimics that of the ntpdate program, which > is to be retired. The -g and -x options can be used with > this option. Note: The kernel time discipline is disabled > with this option. > > So I'm thinking that ntpdate can be completely replaced with ntp if > you're putting that on your system. The obvious fallout would be in any > scripts specifically relying on something called 'ntpdate', but it looks > to me like the ntp package is already providing an ntpdate binary. > Seeing that, it seems to me that ntp/ntp-ssl and ntpdate actually > conflict with each other. > > > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel Then I agree, and think a nice solution to this would be that ntp provides ntpdate, as we don't want both. If you install ntp, you won't need ntpdate, and if you want ntpdate, you don't need all of ntp, and therefor just install ntpdate, and the same goes of course if what you want is ntp-ssl. If ntp is actually providing a ntpdate binary, I agree that it should actually conflict, and not only provide ntpdate. - Martin ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
