<reatmon>
halstead: We've been seeing this behavior for the past couple of weeks. Sometimes it just clogs up and we don't get patches in Patchwork... most days it works just fine.
<vvn>
khem: I'm doing that for existing services already, but I struggle to package small scripts, such as a service running bmaptool for factory... Do I write a custom bmaptool-something package, do I append an existing package such as systemd-machine-units...
<vvn>
another example are first-boot one liners
<khem>
systemd-firstboot could be used for that kind of stuff
<khem>
what do you mean by systemd-machine-units
<khem>
I guess you mean Machine specific systemd units
<khem>
well some of them will be specific to your distro and some to machine
<khem>
so for simple services its perhaps fine to club them into systemd-machine-units or systemd-distro-units
<khem>
see systemd-compat-units.bb for example
bps has quit [Ping timeout: 248 seconds]
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
Tokamak has joined #yocto
jclsn has quit [Ping timeout: 240 seconds]
jclsn has joined #yocto
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
jclsn has quit [Ping timeout: 246 seconds]
RobertBerger has joined #yocto
sakoman has quit [Quit: Leaving.]
rber|res has quit [Ping timeout: 256 seconds]
Circuitsoft has joined #yocto
chep` has joined #yocto
chep has quit [Read error: Connection reset by peer]
chep` is now known as chep
amahnui has quit [Quit: Connection closed for inactivity]
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #yocto
prabhakarlad has quit [Quit: Client closed]
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
troth has quit [Ping timeout: 240 seconds]
troth has joined #yocto
<kp7299[m]>
<rburton> "when you find out what you..." <- Is there some specific process for sending patch for sanity check?
sakoman has joined #yocto
<zeddii>
khem: yah, it is doable to enable something like that. I can do a fragment in the kernel-cache and we can enable it via KERNEL_FEATURES, with some approriate name for the kernel feature like "allow_warnings"
amitk has joined #yocto
<khem>
yeah and its ppc specific since warnings will only be not treating as errors in arch/powerpc dir
<khem>
kp7299 same process where other oe-core patches go
<vvn>
even though it doesn't seem used that much, not sure
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
<vvn>
khem: there's no first-boot packages per-se, there's a systemd-specific service as part of systemd itself only. I thought about adding generic first-boot and factory-reset packages to my distro, so that my BSPs can append them as they like, but again, even add boot targets to pull-in these services on but. Now sure it's the good approach.
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<khem>
sure these are specific to products and distros
<vvn>
there's no systemd-distro-units thought
<vvn>
khem: I said that it doesn't seem used because contrary to many other recipes, the layer index lists no bbappend for systemd-machine-units
<khem>
there is in meta-selftest
<vvn>
ho I missed that one then, let me check
<vvn>
ho ok, I missed it because it is generated somehow
<vvn>
ok so a few pairs of small script + service files seems adequate instead of trying to create an individual myboard-copy-image-to-emmc weird package
<vvn>
khem: why does meta-selftest append systemd-machine-units if I may ask?
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
beneth has quit [Read error: Connection reset by peer]
sakoman has quit [Quit: Leaving.]
dtometzki has joined #yocto
vladest has quit [Quit: vladest]
vladest has joined #yocto
Wouter0100 has quit [Remote host closed the connection]
Wouter0100 has joined #yocto
troth has quit [Ping timeout: 240 seconds]
troth has joined #yocto
mvlad has joined #yocto
<T_UNIX[m]>
<khem> "T_UNIX do you intend it for..." <- I intend to source it as part of a initrd. But Imagine an application depends on it and I‘d like to use the host sysroot directory as rootfs via nfs
<michalkotyla>
Hello everyone! I have a problem with the QA issue [empty-dirs]. At this time I have no idea why do_package_qa says my directory is not empty, so I want to skip this temporary. It is possible? I tried with INSANE_SKIP but this do not work for me, and i do not see empty-dirs in QA variables list https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-insane
<kp7299[m]>
Just wanted to confirm while sending patch, is it required to add resultant build folder too tmp sstate-cache downloads ? As I have created these folder outside the repository analogous to .vs or .exe which is being created while we make projects while using VS on windows
<LetoThe2nd>
yo dudX
hcg has joined #yocto
kroon has joined #yocto
amahnui has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
Schlumpf has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
<RP>
Does anyone fancy fixing the fallout from the recent git security fix? Reproducible build issues :(
<kp7299[m]>
Ok, means I need to change the path of tmp, sstate-cache downloads to inside the poky as presently i have given them outside LetoThe2nd and need to add it for sending in patch
<LetoThe2nd>
kp7299[m]: hm? sorry i have no idea what you are talking about.
gsalazar has joined #yocto
<kp7299[m]>
ok, no issues LetoThe2nd
rfuentess has joined #yocto
<kp7299[m]>
I thought I got my answer
<kp7299[m]>
But i guess you were just greeting all
<RP>
igt-gpu-tools has a git call in lib/meson.build
kranzo has joined #yocto
mckoan|away is now known as mckoan
Wouter0100 has quit [Ping timeout: 256 seconds]
<amahnui[m]>
Hello everyone 👋
<amahnui[m]>
I wish to ask if I there is a way in which I can make a script in yocto-autobuilder-helper/scripts run last.
<kp7299[m]>
Hi RP Could you pls once confirm, that is we require to upload tmp downloads sstate-cache also in patch?
<kp7299[m]>
s/is/are/
<LetoThe2nd>
kp7299[m]: sorry, but why would you want to have those in a patch? the repos only keep metadata and code. tmp is even completely transient.
nemik has quit [Ping timeout: 246 seconds]
<kp7299[m]>
LetoThe2nd: Yeah, thats why I required confirmation, because I was also thinking the same as wrote above 😅
nemik has joined #yocto
<LetoThe2nd>
kp7299[m]: try to approach it from a logic point of view. if those things would make sense in a patch, then you could see them in the public repos, right? ;-)
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
<kp7299[m]>
LetoThe2nd: Yeah, got it, thats why required one confirmation, as i dont know all components of repo... But yeah, thanks for the same :)
troth has quit [Ping timeout: 256 seconds]
dev1990 has joined #yocto
florian_kc has joined #yocto
<qschulz>
amahnui[m]: hi, just call your python scripts inside scripts/run-docs-build
<qschulz>
amahnui[m]: (that does not answer your question, but knowing the context that's what you're after :) )
<amahnui[m]>
Yes this actually helps as I thnk that is the reason why my changes did not reflect in the extracted tarball.
<amahnui[m]>
Thank you
<qschulz>
amahnui[m]: you might want to update your local branch because we pushed quite a few patches last two days
<qschulz>
(and you can now run the script without commenting out stuff or modifying it, see environment variables in the comment at the top of the file)
troth has joined #yocto
ecdhe has quit [Ping timeout: 246 seconds]
beneth has joined #yocto
beneth has quit [Read error: Connection reset by peer]
<kp7299[m]>
Hi qschulz , How would I get to know that for sending email, whom all am I required to add in mailing list, presently I'm trying to solve with that curl issue only, just want to submit first patch
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
<qschulz>
kp7299[m]: curl recipe is in openembedded-core, so contribution rules for that project apply
<qschulz>
click on the Subscribe mail address I guess, or just create an account there and subscribe from there (that's what I did(
troth has joined #yocto
<qschulz>
(clicking on the big "Join this group" button)
<kp7299[m]>
Alright
<kp7299[m]>
And what about sending my patch for sanity check?
<qschulz>
kp7299[m]: figure out which git repo will need to have your patch applied, and read its README
<kp7299[m]>
qschulz: you mean to say i need to check oe repo?
<qschulz>
kp7299[m]: I don't know if your change applies to oe repo or not
<kp7299[m]>
qschulz: My changes were for curl ptest in yocto project's recipe's support, so there for curl recipe
<kp7299[m]>
So in that context I wanted to ask
<qschulz>
kp7299[m]: you were asking me about sanity check, that I have no idea which git repo holds your changes
<qschulz>
kp7299[m]: for curl, I told you the recipe is in openembedded-core, so you need to send the patch to the openembedded-core mailing list
<kp7299[m]>
ok, for sanity check I need to ask then rburton only to which repo i need to send , but for mailing then I'm sending to openembedded and cc to rburton , I guess that works fine
<qschulz>
kp7299[m]: no need to cc rburton, he'll receive the mail just fine, it's a public mailing list (except if that is an Outreachy requirement)
<qschulz>
kp7299[m]: what is the file you changed for the sanity check?
<qschulz>
in which git repo?
<ptsneves>
qschulz you are a cool person :) Everytime i come to this chat you help. I would buy you a beer
<kp7299[m]>
in master branch, meta/recipe-support/curl/curl/ added ptest-runner for checking first patch qschulz
<qschulz>
kp7299[m]: I'm sorry but I'm very confused now. You are talking about sanity checks but then give information about curl recipe changes
<qschulz>
ptsneves: maybe the day it's safe to have conferences in person again :)
<kp7299[m]>
ok, yesterday I was asked by rburton to submit my patch for sanity check, but above one is the file i added to master branch , so dont know
<RP>
kanavin_, rburton: git usage during do_install breaking with fakeroot with recent git upgrades on distros. Do we patch the recipes? Intercept the git calls with a wrapper and exit 1? Intercept the git calls and exit pseudo ?
* RP
is torn
<qschulz>
kp7299[m]: what rburton suggested is to add a sanity check on path sthat aren't absolute (I imagine)
<LetoThe2nd>
RP: cure Natalie Imbruglia?
<qschulz>
kp7299[m]: which i very much assume was in your conf/bblayers.conf file
<LetoThe2nd>
*ue, even.
<LetoThe2nd>
*cue
<kp7299[m]>
qschulz: when you find out what you missed, sending a patch to sanity check that would be really helpful
<kp7299[m]>
* "when you, * really helpful" , this was the thing, and it was abt sending for sanity check
<qschulz>
kp7299[m]: the few messages before were regarding your tasks failure and rburton saying your paths didn't start with a / (home/ something instead)
beneth has joined #yocto
<qschulz>
and if i remember correctly, he suggested to fix that and if that was the issue, to send a patch to "sanity check" that so it does not happen to other people
<qschulz>
sanity checks are usually performed in meta/classes/sanity.bbclass I think
<qschulz>
provided the sanity check needs to be done in sanity.bbclass
<qschulz>
and that your issue was about relative vs absolute paths in bblayers.conf
<qschulz>
but that you're the only to know
<kp7299[m]>
ok
manuel1985 has joined #yocto
Guest22 has joined #yocto
<kp7299[m]>
qschulz: From where I could get values for this set up for which I'm getting error: Unable to initialize SMTP properly. Check config and use --smtp-debug.
<qschulz>
kp7299[m]: have you set up git-send-email for your mail provider?
<kp7299[m]>
because i dont know which values i need to input for same
<kp7299[m]>
or better i could say preferable
<ptsneves>
hey guys what can cause kernel module version magics to mismatch on thud?
<qschulz>
ptsneves: kernel in devtool workspace?
<ptsneves>
no. that is the thing. Normal kernel recipe using vanila kernel.bbclass
<qschulz>
kp7299[m]: you need to get this information from your mail provider
<qschulz>
ptsneves: and compiling the kernel module with yocto too right?
<ptsneves>
yes. It seems like state cache issue
<Saur[m]>
michalkotyla: Using `INSANE_SKIP:${PN} = "empty-dirs"` should work (at least it does in our recipes).
<Saur[m]>
michalkotyla: But the best option is of course to not create any files in the directory in the first place. You should be able to tell what it is creating by looking in `tmp/work/<arch>/<recipe>/<version>/image/<non-empty directory>`.
Schlumpf has joined #yocto
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
xmn has quit [Ping timeout: 250 seconds]
leon-anavi has quit [Quit: Leaving]
<rburton>
kp7299[m]: i'm not sure what you meant to send, but that patch is the contents of your build directory and not any changes to curl. Before sending a patch it's always good to 'git show' or similar to check that the changes you're sending are what you expect.
<amahnui[m]>
qschulz: thank you I will download this ones
<kp7299[m]>
rburton: Yes, it was mistake by my end, sorry for that, I'll keep this thing in mind from next time before sending, i had just sent the wrong patch which consisted of whole build
<kp7299[m]>
qschulz: I had got three mails from them regarding addingto group, i dont know why i was not added
<qschulz>
did you use the same mail address for registering as the one you used to send your email with git-send-email?
<rburton>
the sender wasn't the same as the account which registered on the list
kranzo has joined #yocto
florian_kc has quit [Ping timeout: 260 seconds]
florian_kc has joined #yocto
<kp7299[m]>
yes, that was email id linked with my github account
<qschulz>
you need to use the same email otherwise you're not allowed to post to the list
<kp7299[m]>
Ok, I'll change email id in .gitconfig file
<amahnui>
Hello rburton: I would like to ask you if there are any community specific questions that I can add for my application as requested on the outreachy platform.
<amahnui>
`Please work with your mentor to provide a timeline of the work you plan to accomplish on the project and what tasks you will finish at each step.`
<amahnui>
This too
stkw0 has joined #yocto
goliath has joined #yocto
Guest22 has quit [Quit: Client closed]
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<rburton>
LetoThe2nd: ran memrey against bitbake building an image, and now i have a 2mb flamechart which my browser is struggling to load :)
prabhakarlad has joined #yocto
<rburton>
ah no it was just randomly timing out fetching d3js, because my vpn is terrible
<LetoThe2nd>
rburton: if your box chokes on 2mb, it might be time for a new one... something ppc, maybe? or MIPS? i hear its new new cool chit
<rburton>
i thought it might have been generating a huge diagram at runtime
<qschulz>
rburton: was wondering how long I'd have to wait for someone to run memray with bitbake :p
<rburton>
its quite boring, to be honest
<LetoThe2nd>
rburton: thinking is completely overrated. i'm speaking from experience.
<qschulz>
rburton: aren't we more CPU bound anyways?
<rburton>
god yes
<rburton>
this is demonstrating that we're not leaking anything badly during parse at least
<rburton>
i'll run it with a proper build to check there's nothing growing over time
<qschulz>
that's a good thing indeed
<rburton>
40mb resident in total, 4mb of which is allocated out of the parsers
<qschulz>
meh, who cares about 40mb
<rburton>
character encoding and mime type databases are bigger than the parsed metadata
<rburton>
hm memrey isn't following into the workers
<rburton>
ah i bet it can't follow an explicit subprocess.Popen
troth has quit [Ping timeout: 248 seconds]
florian_kc has quit [Ping timeout: 240 seconds]
<LetoThe2nd>
*sigh* gdk-pixbuf failing again.
troth has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
<michalkotyla>
Saur[m]: thanks, it works for me now after moving INSANE_SKIP to .bb from .inc file that i include by using `require file.inc`
<RP>
qschulz: I did merge the other docs patches btw, thanks
<qschulz>
RP: I saw, thx
<qschulz>
the default page still has an incorrect documentation_.js file though
<RP>
qschulz: I did mean to try and debug that but got ditracted :/
<qschulz>
what I thought could be the issue is the transition branch running last, but I would have been able to reproduce it locally then
sakoman has joined #yocto
TundraMan is now known as marka
<paulg>
RP, I'm not ignoring your e-mail ; I'm just trying to wrap my head around the install issue etc. If you want to just tweak things yourself - I'm fine with that - it surely will be faster...
<kp7299[m]>
<qschulz> "https://www.youtube.com/playlist..."; <- i dont know why these are so long videos and even without timestamps, thats why i dont like watching youtube videos
<RP>
paulg: np, I didn't think you were :) I have some local hacking of it in testing. Sadly the issue came up in overnight testing as reproducibility broke :/
<paulg>
that is why you don't want me hacking python. :-P
OutBackDingo has quit [Remote host closed the connection]
<RP>
paulg: in igt-gpu-tools it was from lib/meson.build
<RP>
paulg: I didn't check into the others, I'm going to assume the same issue
Schlumpf has joined #yocto
paulg has quit [Ping timeout: 240 seconds]
<kp7299[m]>
<qschulz> "https://www.youtube.com/playlist..."; <- Isnt there some doc for custom image creation, i really avoid videos as i need to replay them again and again if stuck somewhere, although i found few docs, but as they are not official then again i dont want to reply on them
<RP>
paulg: iputils similar. I put a log to a file in the git intercept just to check it was working and see what it was doing
<RP>
vmeson: I recently went over 900 and had to do something about things
<vmeson>
lol!
BobPungartnik has quit [Client Quit]
<paulg>
ok, I thought I was bad, but don't think I've ever had more than 50?
<paulg>
using an old turd with 4G as an "internet terminal" so to speak keeps me honest, I guess.
leon-anavi has quit [Quit: Leaving]
leon-anavi has joined #yocto
camus has quit [Quit: camus]
<kp7299[m]>
> >> IMAGE_INSTALL_append += "curl-dev" in conf/local.conf file and further just do bitbake core-image-minimal , for building up the final image as in official doc i can find package name being used, but dont know if curl is pacakge name or curl-dev is package name
<qschulz>
rburton: and I assume ptest-runner is required too (except if curl-ptest has a RDEPENDS on it?)
<rburton>
the runner gets pulled in via depends
<kp7299[m]>
So finally what my conf/local.conf should look like? IMAGE_INSTALL:append = " curl" DISTRO_FEATURES:append = " ptest" EXTRA_IMAGE_FEATURES += "ptest-pkgs"
<kp7299[m]>
or just
<kp7299[m]>
IMAGE_INSTALL:append = " curl-ptest"
<kp7299[m]>
because i was using first one...
<rburton>
either work
<kp7299[m]>
ok
ptsneves has joined #yocto
florian_kc has joined #yocto
<manuel1985>
kp7299[m], If I'm not mistaken EXTRA_IMAGE_FEATURES += "ptest-pkgs" will make EVERY package pull in its -ptest package. IMAGE_INSTALL:append = " curl-ptest" will only install curls ptest package.
<rburton>
either way you need the DISTRO_FEATURES line otherwise the ptest package won't be generated at all
<manuel1985>
So with EXTRA_IMAGE_FEATURES += "ptest-pkgs" you will also have bash-ptest etc. as well.
GLumen has joined #yocto
camus has joined #yocto
GLumen_ has joined #yocto
xmn has joined #yocto
GLumen has quit [Ping timeout: 256 seconds]
Circuitsoft has quit [Quit: Connection closed for inactivity]
<kp7299[m]>
Where i need to add these things for ptest as file was not mentioned in the doc, Be sure the recipe inherits the ptest class: Include the following line in each recipe:
<kp7299[m]>
inherit ptest
<kp7299[m]>
s///
<qschulz>
kp7299[m]: you are adding support for ptest to curl
<qschulz>
so the recipe to add inherit ptest to is curl
<kp7299[m]>
so I need to add this in meta/recipe-supports/curl=> .bb file
<qschulz>
kp7299[m]: you were sent an early version of what is requested for ptest support in curl yesterday
<qschulz>
so this should also help you trying to understand things
<kp7299[m]>
Got it, but in make doc we it is there that we are require to add do_compile_ptest() RDEPENDS_${PN}-ptest , but presently I'm trying to figure out on which basis in the patch they have written more of the content inside these function and even one new function do_install_ptest() is also added
<kp7299[m]>
* Got it, but in main doc we it is there that we are require to add do_compile_ptest() RDEPENDS_${PN}-ptest , but presently I'm trying to figure out on which basis in the patch they have written more of the content inside these function and even one new function do_install_ptest() is also added
hcg has joined #yocto
Tokamak has quit [Ping timeout: 246 seconds]
<khem>
T_UNIX: OK busybox should provide /bin/sh
BobPungartnik has joined #yocto
BobPungartnik has quit [Client Quit]
jqua[m] is now known as jquaresma[m]
florian_kc has quit [Ping timeout: 240 seconds]
florian has quit [Quit: Ex-Chat]
<kanavin_>
RP: can you summarize the git in distros situation in an email please? I am on holiday now, will be back tomorrow
<RP>
kanavin_: I have a patch on the list :)
<kanavin_>
RP: right, I'll get to it but not today most likely :)
<RP>
kanavin_: it is fine, I think we have a solution in hand
<RP>
kanavin_: thanks
nerdboy has quit [Ping timeout: 252 seconds]
<moto-timo>
I'm working on a somewhat generic approach to LUKS disk encryption... does it make sense to move cryptsetup from meta-oe to oe-core?
<moto-timo>
Probably better to wait for the dust to settle on kirkstone... I'll revisit later
<moto-timo>
(target is currently dunfell anyway)
<vvn>
How do you guys make DEPLOY_DIR_IPK privately available to the outside world? (because you have proprietary software, images and whatnot)
<vvn>
or DEPLOY_DIR in general so employees and customers can do bmaptool copy <company-url>... or opkg install foo
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
<kergoth>
I doubt most do that
<kergoth>
Binary based distributions are few and far between from what I've seen
<vvn>
but don't you guys make your DEPLOY_DIR directory available to developers at least?
<qschulz>
vvn: I archive artifacts with Jenkins and then you go to a build and you can download whatever was made available
<qschulz>
rburton: need to list the licenses used in there (e.g. glibc) and give the license. was wondering if I was missing on something or if I need to do everything by hand :)
<rburton>
qschulz: the tarball has a licenses file in iirc
<kergoth>
If it's only internal, it's easy, have your CI deploy the bits wherever you need them. rsync them to a server, whatever. Exposing that to your customers is a rather different question given access control
<kergoth>
at siemens disw for our sokol flex os product we have jenkins build and archive artifacts and deploy sstate and downloads to an internal server to act as a mirror for the devs, but that's about it
<kergoth>
should probably set up the error reporting service, pr server, and hashequiv servers one of these dyas
<amahnui[m]>
Hello qschulz RP rburton I sent a patch for auto-builder modifications for copy the scripts I wrote into the $outputdir and run them there, and it work on my local repository.
<amahnui[m]>
But rysinc was still giving me errors until I commented it.
<amahnui[m]>
It is at the yocto@lists.yoctoproject.org list
<RP>
amahnui[m]: I think you're a bit lost unfortunately. We're looking for a patch which changes that script to run your modification scripts against the tarball of docs
<amahnui[m]>
RP: ah, Please I wish to ask if the tarball of docs is that which you sent a download link of?
<amahnui[m]>
I'm saying so because I added some commands in run-docs-build which moves the modification scripts into the $outputdir and runs them there, making the modification to happen immediately after the tarball has been extracted in the $outputdir.
<RP>
amahnui[m]: yes, it is the one in the link we previously discussed
<RP>
amahnui[m]: our autobuilder doesn't have "/home/abongwa/Documents/auto-builder/stylescript.py" so your patch needs to first add these scripts to the repository, then use them from there
<RP>
amahnui[m]: also, since python3 is at the start of the files, you can just call "script.py", no need to "python3 script.py"
codavi has quit [Ping timeout: 276 seconds]
amitk has quit [Ping timeout: 260 seconds]
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
dmoseley has quit [Ping timeout: 240 seconds]
dmoseley has joined #yocto
<amahnui[m]>
RP: I actually sent a patch for the scripts to yocto@lists.yoctoproject.org, but I could send a different patch which contains the most recent file names I gave to it.
<amahnui[m]>
RP: That means the scripts have to be added to the repo in order before I can add its path to the run-docs-build
chep has joined #yocto
<amahnui[m]>
If I'm not mistaken
<RP>
amahnui[m]: we usually ask that submitters put together a patch series that incrementally builds up these changes, so the first patch in the series would add the scripts to the repository, the second patch would add entries to the build script much like your second one
<RP>
amahnui[m]: the fact that the file names don't match and there are incorrect path names as well as the calling convention for the scripts is incorrect means things need to be tweaked in that second one too
<amahnui[m]>
I sent a more recent for adding the scripts to the repository which contains filenames included in the second patch
<amahnui[m]>
For the second patch too, I will send a patch in which I think the only tweak to be done will be setting the path of the scripts to that when they are in the repository