<kp7299[m]>
<RP> "kp7299: they give us a way of..." <- But as per issue which is there, in which we are required to write ptest for curl, and I have checked for some other ptest which were implemented for perl, python and so on... but still unable to get flow of these ptest and what need to be kept in mind for writing these, basically in what direction I should work for writing these ptest in context of curl and ptest
<jclsn>
Gruetzi mitanand
<jclsn>
Oh wrong language
<jclsn>
Good morning
<qschulz>
Oida
<RP>
kp7299[m]: I don't understand what you're asking. curl presumably has some tests in it and the idea would be to enable those tests within our automated test framework, ptest being the mechanism by which we'd do that?
<kp7299[m]>
Alright, rburton RP Specifically my first step should be to search for those curl tests which are already there, then I should check for this never merged patch, As RP has given context and LetoThe2nd thanks for youtube video for getting more into end user context
<rburton>
essentially ptests are a way to run the package's tests on the target. curl has a test suite, so that patch installs it into the ptest package.
td95 has joined #yocto
<td95>
Hi,
<td95>
do you have any interesting job interview (regular and advanced) questions about Yocto that you could share? :)
troth has quit [Ping timeout: 276 seconds]
Vonter has quit [Ping timeout: 240 seconds]
Vonter has joined #yocto
troth has joined #yocto
bps has joined #yocto
alejandrohs has quit [Ping timeout: 260 seconds]
alejandrohs has joined #yocto
kranzo has joined #yocto
Net147 has quit [Quit: Quit]
mrpelotazo has quit [Quit: Hasta la vista!]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
mrpelotazo has joined #yocto
GNUmoon has quit [Remote host closed the connection]
<jclsn>
I am still wondering if this PREMIRRORS issue I have is acttually a bug or if I am not just doing things wrong. I have pushed my sources to Artifactory by pushing the complete downloads directory. This path I set as SOURCE_MIRROR_URL and then put BB_FETCH_PREMIRRORONLY = "1", which doesn't work. It still tries to fetch from the normal repos.
<jclsn>
When I put BB_NO_NETWORK = "1", it doesn fetch from Artifactory, but then complains that it can't because there is no network.
<jclsn>
RP: Is this the right way to do it?
<jclsn>
Probably not...
<amahnui[m]>
<rburton> "essentially ptests are a way..." <- Can this be used to test for the effect of changes on any script and be sure that the changes never broke the script where the changes took place?
<jclsn>
Are PREMIRRORS only used for local mirrors?
<barometz>
PREMIRRORS by default point to downloads.yoctoproject.org, so no.
<barometz>
I set up exactly the same thing about a month ago (with Artifactory, too) and what you're describing sounds right, so this devil is probably in a detail
<barometz>
it does, yeah, I just meant to distinguish between "local shared folder" and anything you might consider more remote
<barometz>
`SOURCE_MIRROR_URL = "https://<artifactory host>:443/artifactory/<repo>/mirror/sources/"; INHERIT += "own-mirrors"` (the mirror/sources/ path is entirely optional, I just thought I'd stick with downloads.yoctoprojects.org's organization in case we ever want to mirror other stuff)
<barometz>
That snippet is in our base distro file
<barometz>
You can check your do_fetch logs to see what's actually happening during fetch, if you haven't yet
<jclsn>
I always see that anyway
<jclsn>
ERROR: at-spi2-core-native-2.36.1-r0 do_fetch: Network access disabled through BB_NO_NETWORK (or set indirectly due to use of BB_FETCH_PREMIRRORONLY) but access requested with command /usr/bin/env wget -t 2 -T 30 --passive-ftp --no-check-certificate -P /home/user/Workspace/Yocto/vti1/../downloads
<barometz>
Nowhere in the documentation does it suggest that PREMIRRORONLY implies NO_NETWORK
<jclsn>
I also don't see how that makes sense
<barometz>
Have you tried it without the PREMIRRORONLY option? We're not using that (in part because some recipes download stuff we don't want in our premirror) and everything is fine
<jclsn>
Plus: When I set NO_NETWORK = "0" and keep it on
<jclsn>
ERROR: libedit-native-20191231-3.1-r0 do_fetch: Network access disabled through BB_NO_NETWORK (or set indirectly due to use of BB_FETCH_PREMIRRORONLY) but access requested with command /usr/bin/env wget -t 2 -T 30 --passive-ftp --no-check-certificate -P /home/user/Workspace/Yocto/my-machine/../downloads
<jclsn>
ERROR: Logfile of failure stored in: /home/user/Workspace/Yocto/my-machine/build/tmp/work/x86_64-linux/libedit-native/20191231-3.1-r0/temp/log.do_fetch.678:
<jclsn>
Now it doesn't try to fetch from Artifactory and still complains that there is no network
<barometz>
ah, I think the error message may just be wrong
<RP>
jclsn: BB_NO_NETWORK would stop it using PREMIRRORS too. You want the PREMIRRORONLY option alone I think
<jclsn>
If NO_NETWORK is set by FETCH_PREMIRRORONLY this shouldn't make a difference
* RP
is just going from memory though
<barometz>
The manual does say "any network accesses to anything other than the PREMIRRORS would fail.", which suggests to me that PREMIRRORONLY maybe works as a sort partial NO_NETWORK? But that's entirely speculative on my part
<jclsn>
So if this is really a bug in bitbake, I would try to convince our Product Owner to make some time for fixing it
<RP>
jclsn: It will make a difference as premirroronly sets it for anything != premirror whereas setting BB_NO_NETWORK sets it everywhere
<jclsn>
Okay
<RP>
Perhaps it should error if both are set just to be clear?
<jclsn>
RP: Why does bitbake only try to fetch from Artifactory when I set BB_NO_NETWORK then?
<qschulz>
jclsn: because I assume you don't have a local copy of this and the fetcher needs to get the sources somewhere?
<qschulz>
thus it tries to fetch it but cannot because you disabled the network?
<RP>
jclsn: which fetcher does artifactory use?
<jclsn>
qschulz: That is the whole point of Artifactory! I want Bitbake to fetch from there instead from external sources, so I can build without internet access
<jclsn>
RP: What do you mean by which fetcher?
<RP>
jclsn: do we have an artifactory fetcher?
<jclsn>
RP: I was hoping you did
<barometz>
It's just https, nothing fancy.
<jclsn>
Oh that you mean
<jclsn>
Yeah https
<RP>
right, plain https is ok. I was getting confused for a minute
<RP>
jclsn: when you set BB_NO_NETWORK it shouldn't trying https
<jclsn>
RP: Exactly and it should still try it when setting FETCH_PREMIRORONLY
<jclsn>
I don't get it
<jclsn>
barometz: Still waiting for you config btw dum di dum
<barometz>
I posted up higher up, bu tI see now
<barometz>
you can't generate mirror tarballs from the mirror, I think
<barometz>
the generate tarballs option is used separately, not during the regular build
<RP>
jclsn: I suspect BB_NO_NETWORK = "0" doesn't work, you need to not set it
<jclsn>
RP: Works for my colleagues with their ftp server
<jclsn>
It also doesn't make a difference. I just explicitly set it
<jclsn>
barometz: I can only see that you posted a broken linked to the yoctoproject's website
<RP>
the bitbake code is using bb.utils.to_boolean(d.getVar("BB_NO_NETWORK")) so that should work I guess
<RP>
a lot of the code doesn't do that FWIW so I'm caution against "0" values
<barometz>
jclsn: ' SOURCE_MIRROR_URL = "https://<artifactory host>:443/artifactory/<repo>/mirror/sources/"; INHERIT += "own-mirrors" ' (the mirror/sources/ path is entirely optional, I just thought I'd stick with downloads.yoctoprojects.org's organization in case we ever want to mirror other stuff)
<barometz>
is literally the only thing we have in our distro file for this
<jclsn>
barrometz: Okay sorry then
<jclsn>
It is exactly like mine twb
<jclsn>
btw
<jclsn>
When I set all PREMIRROS one by one like this
<jclsn>
it does work but I am getting checksum errors
<jclsn>
When I use the same wget command manually thought and compare the files, the checksum is correct
<jclsn>
Do I need to push the .done file as well?
tlwoerner_ has quit [Quit: Leaving]
tlwoerner_ has joined #yocto
tlwoerner_ has quit [Remote host closed the connection]
tlwoerner has joined #yocto
<jclsn>
**sigh**
<sotaoverride>
good morning
<jclsn>
Good afternoon
<sotaoverride>
Greetings to all. Back to figuring out overlayfs today. Didint really get to it yesterday.
ardo has quit [Read error: Connection reset by peer]
ardo has joined #yocto
<qschulz>
RP: sigh.. I broke the obsolete message on the docs website.. (it hasn't been regenerated for some reason right now but it's broken locally when building with the yocto-autobuilder-helper script)
akiCA has joined #yocto
<RP>
qschulz: I don't know why it didn't regenerate but I won't force anything until there are patches I guess?
<rburton>
hpsy[m]: first step is can you replicate after you removed your custom layers
<amahnui[m]>
rburton: I just sent it again
<rburton>
amahnui[m]: still nothing
florian has quit [Quit: Ex-Chat]
<amahnui[m]>
As I read on the outreachy portal, it says we need to discuss with our mentors to come up with the time commitments for the final application
Minvera has joined #yocto
<hpsy[m]>
rburton: Till now I haven't been able to, so I thought I would try to understand what differences are detected, it could at least point me in the right direction.
leon-anavi has quit [Quit: Leaving]
<amahnui[m]>
s/As/rburton:/
kranzo has quit [Quit: Client closed]
<rburton>
amahnui[m]: the expectation is fairly fulltime, unless you can't do that
<khem>
rburton: its still using clang++ from host and failing ../git/inc/hf/panic.h:13:1: error: '_Noreturn' is a C11 extension [-Werror,-Wc11-extensions]
<rburton>
i hate hafnium
goliath has joined #yocto
<amahnui[m]>
<rburton> "amahnui: the expectation is..." <- Full time is 8 hours a day right?
<rburton>
amahnui[m]: the outreachy page says 30, so 6
<rburton>
khem: it should be using the prebuilt clang, i wonder why it isn't
<rburton>
khem: so you have a new clang on the host?
<amahnui[m]>
rburton: I can
<amahnui[m]>
Can I use the task from the outreachy portal to fill the time commitments?
<rburton>
yes
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
beneth has quit [Read error: Connection reset by peer]
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
kevinrowland has joined #yocto
<khem>
rburton: I have clang 13.x on host
<khem>
rburton: why are you canning compiler for an app, its so wrong
florian has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
pabigot has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
pabigot has joined #yocto
<rburton>
khem: blame google
<rburton>
we've someone who has been spending serious time un-googling the build system
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
bps has joined #yocto
bps has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
<vmeson>
rburton: they missed the boat when naming that project, it should have been called: halfnivm or halfniu-vm
<kp7299[m]>
I was unable to see these patches in master branch , but these were in honister branch, is there some specific reason for the same?
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
dev1990 has joined #yocto
olani has joined #yocto
<Saur[m]>
kp7299: The version of curl in master is newer and already have those patches as part of the upstream code.
<kevinrowland>
Hey all. What does "support" mean in the context of the YP Releases page: https://wiki.yoctoproject.org/wiki/Releases ? If Hardknott has support until this month, what happens next month? :)
<Saur[m]>
kp7299: See commit b4f08791 in openembedded-core (or commit a901b318 in poky).
<Saur[m]>
kevinrowland: After the next Hardknott release, there will typically not be any more.
florian has quit [Ping timeout: 276 seconds]
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
<paulg>
two identical builds, 2nd links in sstate-cache from the 1st, and also adds systemd to conf/local.conf
<paulg>
mostly everything gets recycled, but wait for it... glibc-2.35 gets recompiled.
<paulg>
oh, well and the kernel, but I expected that, given the systemd.scc that exists.
<paulg>
I didn't expect glibc to need rebuilding.
<paulg>
qemu arm 64 and core-image-full-cmdline ; not that it should matter.
<kevinrowland>
Saur[m]: thanks very much!
prabhakarlad has quit [Quit: Client closed]
tomzy_0 has quit [Quit: Client closed]
<paulg>
glibc rebuild eventually triggers some other rebuilding once you march down the dependency chain... not surprising.
<yudjinn[m]>
Is arch a bad idea for yocto dev?
<kp7299[m]>
Saur: Are all the patches being accepted through master branch only or is it origin/master ? basically the latest one which you are saying, which exact branch is ir?
hcg has quit [Quit: Client closed]
mvlad has quit [Remote host closed the connection]
olani has quit [Ping timeout: 256 seconds]
olani has joined #yocto
<Saur[m]>
kp7299: `origin/master` is your local reference to the upstream `master` branch (assuming your upstream is called `origin`, which it is by default). When you checkout a local `master` branch, it then tracks the `origin/master` branch by default.
<rburton>
yudjinn[m]: it mostly works but you'll quite possible hit problems caused by newer host packages before most other people
<yudjinn[m]>
Gotcha. I'm having issues just getting minimal to work
<Saur[m]>
kp7299: The `master` branch of `openembedded-core` is the development branch where everything new is expected to happen.
<rburton>
paulg: that's because glibc inherits systemd, because it ships a unit
<rburton>
yudjinn[m]: using a tested distribution means we don't just tell you to use a tested distribution :). but say what the error is, might not be arch related
ardo has quit [Ping timeout: 248 seconds]
<paulg>
eeech - systemd engulfs something ; why am I not surprised.
goliath has joined #yocto
<yudjinn[m]>
rburton: yeah I'm planning on going to fedora if arch gives too much issue. I'm hoping it was just an issue of missing rpm-tools, attempting the build again now
* paulg
sheds a tear and waves bye to PS/2 and i8042
<Saur[m]>
yudjinn: You should not need to have RPM tools installed on the host. bitbake should build them as part of the build if needed...
<yudjinn[m]>
The openssl do_package_write faile
<Saur[m]>
yudjinn: Do you have the `log.do_package_write` log file from that build? If so, please provide it (via pastebin or similar).
<yudjinn[m]>
Saur @Saur:libera.chat: I'm trying to follow the getting started docs, where do I find the log file?
<yudjinn[m]>
Oh, wait. After installing rpm-tools on my host, the build succeeded
<Saur[m]>
Hmm, interesting...
<yudjinn[m]>
For future reference, where can I find the log files, though?
<Saur[m]>
yudjinn: Something like `tmp/work/<architecture>/openssl/<version>/temp/log.do_package_write_rpm` where `<architecture>` and `<version>` depends on what target you are building for, and which version of OE you are using.
<sotaoverride>
how can I get overlayfs bbclass to work wuth dunfell?
<sotaoverride>
is it something doable, the backporting etc, or should I not be considering it even?
<RP>
paulg: I wondered if anyone would miss them! :)
Minvera has quit [Remote host closed the connection]
<Saur[m]>
yudjinn: Unfortunately `package_write_rpm` is a Python task so there is not much to go on in the log. The `exit 137 from 'rpmbuild ...'` indicates that `rpmbuild` was terminated by a `kill -9`, but there is nothing to tell why...
<yudjinn[m]>
I'm on kirkstone, if that matters Saur
<paulg>
RP, I would have complained if they were removed from generic x86-64 and not just qemu...
<RP>
paulg: totally, it is qemu where we they're being a pain
<paulg>
yet another pre-y2k peripheral/infrastructure that finds its way going up the wrong side of the bathtub curve
<paulg>
8250 might have been closer to death if there weren't those usb-2-serial dongles everywhere
<RP>
paulg: it is weird how some things survive
ardo has joined #yocto
VigneshSekar[m] has joined #yocto
gsalazar has quit [Ping timeout: 272 seconds]
chep` has joined #yocto
chep has quit [Ping timeout: 246 seconds]
chep` is now known as chep
chep` has joined #yocto
chep has quit [Read error: Connection reset by peer]
chep` is now known as chep
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #yocto
BCMM has quit [Quit: Konversation terminated!]
GLumen has quit [Read error: Connection reset by peer]