**** BEGIN LOGGING AT Mon Jul 15 02:59:58 2013 Jul 15 08:16:59 morning all Jul 15 08:27:24 morning all Jul 15 08:29:20 morning bluelightning Jul 15 08:29:27 hi eren Jul 15 08:29:29 morning all o/ Jul 15 08:49:44 good morning eren, bluelightning, c00kiemon5ter, all Jul 15 08:49:58 morning mckoan Jul 15 08:59:04 morning all Jul 15 09:02:14 hi silvio_l_ Jul 15 09:05:10 hi mckoan Jul 15 09:46:32 morning #oe Jul 15 09:54:55 bluelightning: about the PR bumps to superseed meta-oe-recipes and in general, why don't implement a strict policy about *dropping* PR when PV is updated? Jul 15 09:55:27 I know some Distro maintainer has concerns about PRSERVER, though Jul 15 09:55:33 ant_work: we have been doing that already Jul 15 09:55:51 and if PV increases there shouldn't be a problem dropping PR at the same time Jul 15 09:56:03 so it is de-facto policy Jul 15 09:56:19 right, as much as resetting it to r0 in the old days was Jul 15 09:57:39 and for old, stale recipes ? Probably there will be any natural PV bump... Jul 15 09:58:29 right, in which case PR is preserved Jul 15 09:59:10 wouldn't a PE change settle this issue too? Jul 15 09:59:53 i.e. on Yocto 1.5 release? Jul 15 10:09:47 Hey, does anyone here know if there's a BB variable for /etc/init.d/? Jul 15 10:10:03 Or should I simply use ${D}/etc/init.d/ when installing a service? Jul 15 10:10:05 ant_work: PE doesn't really help the situation though; it doesn't break any existing bbappends so their incremented PR values would still be used and we'd be in the same situation Jul 15 10:10:22 Stygia: ${sysconfdir}/init.d Jul 15 10:10:50 or ${D}${sysconfdir}/init.d within do_install, of course Jul 15 10:11:19 bluelightning, Ah right. Do you know how I can register the service in my recipe? Jul 15 10:11:56 bluelightning, I mean, simply copying it over isn't enough, is there some simple way to say 'this file in /etc/init.d/ should be installed as a service'? Jul 15 10:12:36 bluelightning, I suppose I could do it "Manually" in do_install_append() ? Jul 15 10:13:55 bluelightning, Uh obviously the equal of the command 'update-rc.d servicename defaults', or should it just be run manually? Jul 15 10:13:58 Stygia: you just need to install the initscript, inherit update-rc.d and then set INITSCRIPT_PACKAGES, INITSCRIPT_NAME and optionally #INITSCRIPT_PARAMS Jul 15 10:14:04 er s/#// Jul 15 10:14:26 that takes care of running update-rc.d automatically for you Jul 15 10:14:45 bluelightning, Hmm alright, thanks. ): Jul 15 10:14:46 :) Jul 15 10:15:00 bluelightning, And it's okay to do this is a recipe that does lots of stuff, yea? Jul 15 10:16:45 Stygia: sure, if the recipe packages something that requires an initscript, we'd always use this Jul 15 10:17:13 bluelightning, Alright, thanks. I will use this, then. Jul 15 10:25:52 hi all Jul 15 10:26:01 hi pb_ Jul 15 10:32:47 bluelightning: maybe the .bbappends touching PR should be listed and a warning given. It's painful but the layer maintainers will need to react Jul 15 10:41:40 I don't understand why everybody now hates PRINC so much, PR service is nice improvement, but PRINC works fine until PV is bumped Jul 15 11:04:04 JaMa: as you know th eissue is with package feeds. I.e. I could not upload my Angstrom feeds 'cause I'm running my untrusted prserver Jul 15 11:05:44 and how is this issue related to PRINC? Jul 15 11:08:25 http://patches.openembedded.org/patch/50691/ Jul 15 12:29:50 ant_work: that has nothing to do with "untrusted prserver" Jul 15 12:41:08 JaMa: ask Koen Jul 15 12:41:27 I'm not so in love with feeds maintainance ;) Jul 15 12:45:02 ant_work: I don't need to ask him, I'm not saying that these 2 are related Jul 15 12:45:21 those are the twofaces of the same medail Jul 15 12:45:59 a.k.a. how can you ensure package manager get it right Jul 15 12:48:43 JaMa: Jul 08 08:07:40 ant_work: uploading is disabled till the PRSERV mess gets sorted out :( Jul 15 12:49:33 JaMa: Jul 08 08:07:53 olnly a single autobuilder can upload now Jul 15 12:54:52 hi. when is AUTOINC added in the pkg rev? i was under the impression it was only when using AUTOREV. but i am building a recipe where I set SRCREV and AUTOINC is being used. Jul 15 12:55:17 ndec: any time you're using SRCPV I believe Jul 15 12:55:20 ndec: always when SRCPV is used Jul 15 12:55:56 so, how should i set PV when using SRCREV? i am doing this: PV = "1.4+gitr${SRCPV}" Jul 15 12:56:01 ant_work: it will work the same (only single PR server) even without any PRINC Jul 15 12:57:22 ndec: that is the correct way to set it Jul 15 12:57:42 then, i think i don't understand what AUTOINC means? Jul 15 12:57:51 ndec: AUTOINC is replaced when the package file is generated by a single integer Jul 15 12:58:11 a single integer? Jul 15 12:58:24 you mean recipe_.bb Jul 15 12:58:27 ndec: the idea is that the SRCREV can be changed and the PV always increments rather than being less or greater depending on how the value of SRCREV compares with the last value Jul 15 13:02:02 bluelightning: ah... i see. indeed the package name (.ipk) does not have AUTOINC, it's only in the 'log' during the build, i hadn't noticed that. Jul 15 13:02:41 so 2 persons build the same recipe, they might not get the same package version, is that correct? Jul 15 13:10:42 ndec: that's correct; if you use a shared PR server that issue goes away though Jul 15 13:11:59 bluelightning: hmm... i haven't looked into that yet... i will need to catch up on that. thx. Jul 15 13:19:23 If you have a package that includes non-target arch stuff, you get a "QA Issue: Architecture did not match ..." error. If this is done purposely, is there any appropriate way to squelch the error? Jul 15 13:20:19 chris__, Couldn't you set host, target, etc, as the architecture its supposed to be in? Jul 15 13:21:23 chris__: sure, I think INSANE_SKIP_packagename = "arch" should do it Jul 15 14:22:48 Hey guys, question. We discovered that two images flashed with our OE system have the same MAC address, and this obviously causes problems on our local network. However, we prefer not to manually change the mac addresses. Is there some canon way to ensure that mac addresses aren't duplicated in OE? Jul 15 14:24:58 Where do your store the MAC addresses on your device? Jul 15 14:26:49 Stygia: did you buy any mac addresses? Jul 15 14:27:13 mckoan, No, I don't think so. We bought a number of embedded devices. Jul 15 14:27:22 pb_, As far as I know, nowhere. We never specified the MAC's. Jul 15 14:27:30 Stygia: there's no standard mechanism in OE; usually this is handled in a device specific manner by the driver/firmware/bootloader Jul 15 14:27:56 Stygia: you *could* set this in a postinstall that runs on first boot if you have no other means of doing it Jul 15 14:28:15 Stygia: ah. if these are devices that you bought (rather than made) then I guess you should take it up with your vendor. Jul 15 14:28:28 bluelightning, Alright. We will look into that, then. Thank you. And as you indicated, it's presumably not OE's "fault" in this instance, it's presumably the vendor. Jul 15 14:28:31 pb_, Yes. Jul 15 14:29:14 Stygia: creating a recipe using a random MAC address generator would be challenging, but at the end you will face to the mac univocal issue if you don't buy them Jul 15 14:29:58 well, if he bought a device with an ethernet interface onboard, I think he'd be within his rights to expect it to come with an address. Jul 15 14:30:09 pb_: agree Jul 15 14:30:42 Stygia: on omap4/panda i remember someone was 'making up' the MAC address using a unique chip ID at boot time. Jul 15 14:30:43 pb_, That's how I felt. I was not aware that not having a MAC was an option. Jul 15 14:31:02 ndec, I would tend to use macchanger's algorithm, that has suited me just fine with regards to spoofing Jul 15 14:31:26 well, you get a unique MAC, and always the same on each device. Jul 15 14:32:30 ndec, I'm not sure we actually got a unique MAC with our devices this time. Jul 15 16:41:16 moin Jul 16 01:04:28 Stygia/bluelightning: thanks, INSANE_SKIP worked perfectly! **** ENDING LOGGING AT Tue Jul 16 02:59:58 2013