| 00:40.22 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 02:16.49 | *** join/#oe koen (~koen@ip4da2a5ae.direct-adsl.nl) |
| 02:31.48 | *** join/#oe coolmouse (~coolmouse@113.201.248.17) |
| 02:33.15 | *** join/#oe coolmouse_ (~coolmouse@113.201.248.17) |
| 03:11.33 | *** join/#oe evanmeagher (~MongooseW@c-73-71-33-109.hsd1.ca.comcast.net) |
| 03:38.28 | *** join/#oe evanmeagher (~MongooseW@c-73-71-33-109.hsd1.ca.comcast.net) |
| 04:08.06 | *** join/#oe AndersD (~anders@h83-209-191-235.dynamic.se.alltele.net) |
| 04:32.00 | *** join/#oe AndersD (~anders@h83-209-191-235.dynamic.se.alltele.net) |
| 04:40.03 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 05:39.19 | *** join/#oe ndec (~ndec@linaro/ndec) |
| 05:47.01 | *** join/#oe suihkulokki (~voipio@jessie.kos.to) |
| 06:03.29 | *** join/#oe tasslehoff (~Tasslehof@77.40.182.102) |
| 06:11.48 | *** join/#oe phdeswer_ (~phdeswer@91-159-55-220.elisa-laajakaista.fi) |
| 06:19.46 | *** join/#oe morphis_ (~morphis@p5480DDEA.dip0.t-ipconnect.de) |
| 06:19.48 | *** join/#oe josep (~jhunt@c-c012e455.010-118-73746f7.cust.bredbandsbolaget.se) |
| 06:20.17 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 06:34.06 | *** join/#oe jku (jku@nat/intel/x-gjplygcmseulxthw) |
| 06:34.50 | *** join/#oe dv_ (~quassel@chello062178118086.5.14.vie.surfer.at) |
| 06:39.47 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 06:45.47 | *** join/#oe vdehors (~vdehors@LAubervilliers-656-1-228-141.w80-14.abo.wanadoo.fr) |
| 06:46.34 | *** join/#oe coolmouse (~coolmouse@113.201.248.17) |
| 06:54.30 | *** join/#oe jbrianceau_away (uid10952@gateway/web/irccloud.com/x-vuxchwbohbvifpru) |
| 06:54.59 | *** join/#oe coolmouse_ (~coolmouse@113.201.248.17) |
| 07:23.47 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 07:24.41 | *** join/#oe joshuagl (~joshuagl@192.198.151.43) |
| 07:37.24 | *** join/#oe t0mmy (~tprrt@217.114.201.133) |
| 07:38.04 | *** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net) |
| 07:45.26 | *** join/#oe ftonello (~felipe@81.145.202.106) |
| 07:52.55 | *** join/#oe JaMa (~martin@ip-86-49-34-37.net.upcbroadband.cz) |
| 08:08.59 | *** join/#oe edbart (~ebartosh@192.198.151.45) |
| 08:18.02 | *** join/#oe jonathanmaw (~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk) |
| 08:22.49 | *** join/#oe rburton (~Adium@home.burtonini.com) |
| 08:54.24 | *** join/#oe rburton1 (~Adium@home.burtonini.com) |
| 09:05.59 | *** join/#oe NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey) |
| 09:06.11 | *** join/#oe lerela (~lerela___@50-200-149-212-static.hfc.comcastbusiness.net) |
| 09:11.25 | *** join/#oe belen (Adium@nat/intel/x-bozknwxtfxsrjeaj) |
| 09:15.47 | *** join/#oe belen (~Adium@134.134.137.71) |
| 10:05.10 | Jin^eLD | I have a very strange behaviour in relation to prserv |
| 10:05.15 | Jin^eLD | imho its a bug, but I am not sure |
| 10:05.25 | Jin^eLD | I summarized it here |
| 10:05.29 | Jin^eLD | https://pastebin.mozilla.org/8867448 |
| 10:06.12 | Jin^eLD | I thought prserv is supposed to always increment the revision in order to have an updatable system |
| 10:06.41 | Jin^eLD | but I have a situation where the revision goes back.. like it would remember some state and return to it |
| 10:06.45 | Jin^eLD | is this a bug? |
| 10:24.06 | *** join/#oe belen (Adium@nat/intel/x-giotuzfricyfjnjh) |
| 10:56.24 | koen | Jin^eLD: mixing sstate archives? |
| 10:58.35 | Jin^eLD | it is a multimachine build... |
| 10:58.50 | Jin^eLD | and hmm, when testing I was building only one machine |
| 10:59.02 | Jin^eLD | I guess that was the problem? |
| 10:59.54 | koen | well, pr info gets encoded into the sstate |
| 11:00.03 | koen | that's the only time I've seen prserv going backwards |
| 11:00.14 | koen | when using sstate from a 'different' build |
| 11:01.16 | Jin^eLD | let me retest by building all of the machines.. |
| 11:08.14 | Jin^eLD | that did not help |
| 11:08.20 | Jin^eLD | its a machine arch package |
| 11:08.43 | Jin^eLD | I change conf for machine A, it gets bumped, machine B stays t 2.0 |
| 11:09.03 | Jin^eLD | but i build both configs including package-index in the end |
| 11:09.13 | Jin^eLD | then i change config of machine A back to how it was |
| 11:09.20 | Jin^eLD | and PR will jump back to 2.0 |
| 11:18.46 | dv_ | question regarding devtool |
| 11:19.10 | dv_ | is it possible to define what exact bbappend is affected if I use modify-recipe? right now I can only specify the layer |
| 11:19.32 | dv_ | but a bbappend already exists, so it would be great if devtool modified that one. instead, it creates a new one, because it deduces a different file path |
| 11:19.49 | dv_ | err, update-recipe, not modify-recipe |
| 11:47.03 | *** join/#oe ldnunes (~ldnunes_@187.23.154.250) |
| 11:49.33 | *** join/#oe berton (~fabio@187.23.154.250) |
| 12:14.28 | *** join/#oe mattsm (uid128834@gateway/web/irccloud.com/x-jarmhzfdjjqxzzod) |
| 12:14.53 | *** join/#oe stefan_schmidt (~stefan@pD9F783B5.dip0.t-ipconnect.de) |
| 12:26.36 | *** join/#oe vmeson (~rmacleod@128.224.252.2) |
| 12:58.04 | *** join/#oe davis (~davis@rrcs-96-10-245-18.midsouth.biz.rr.com) |
| 12:58.39 | davis | hello |
| 13:03.05 | Crofton|work | ~ugt |
| 13:03.05 | infobot | it has been said that ugt is Universal Greeting Time. Created in #mipslinux, it is a rule that states that whenever somebody enters an IRC channel it is always morning, and it is always late when the person leaves. The local time of any other people in the channel, including the greeter, is irrelevant. http://www.total-knowledge.com/~ilya/mips/ugt.html |
| 13:04.59 | *** join/#oe kristoffer (~kristoffe@ua-83-227-162-207.cust.bredbandsbolaget.se) |
| 13:20.38 | *** join/#oe paulg (~paulg@128.224.252.2) |
| 13:52.15 | *** join/#oe Aethenelle (~Aethenell@107.138.98.226) |
| 14:37.39 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
| 15:10.21 | *** join/#oe t0mmy (~tprrt@217.114.201.133) |
| 15:15.59 | *** join/#oe jchonig (~quassel@firewall.honig.net) |
| 15:39.52 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 15:41.36 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 15:47.36 | *** join/#oe jku (~jku@dyj170ycrv18---3wlh9y-3.rev.dnainternet.fi) |
| 15:51.29 | *** join/#oe yann|work (~yann@85-171-21-92.rev.numericable.fr) |
| 16:10.29 | *** join/#oe aehs29 (~aehernan@134.134.139.78) |
| 16:12.22 | *** join/#oe evanmeagher (~MongooseW@50.1.57.30) |
| 16:15.43 | *** join/#oe likewise (~likewise@145.132.74.106) |
| 16:16.31 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 16:24.32 | *** join/#oe like2wise (~likewise@145.132.74.106) |
| 16:27.31 | *** join/#oe likewise_ (~likewise@46.166.190.131) |
| 16:28.12 | *** join/#oe challinan (~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
| 17:05.02 | *** join/#oe berton (~fabio@187.23.154.250) |
| 17:23.37 | *** join/#oe evanmeag_ (~MongooseW@50.1.57.30) |
| 17:25.33 | *** join/#oe evanmeagher (~MongooseW@50.1.57.30) |
| 17:27.39 | *** join/#oe evanmeag_ (~MongooseW@50.1.57.30) |
| 17:28.21 | *** join/#oe stefan_schmidt (~stefan@pD9F7843C.dip0.t-ipconnect.de) |
| 17:34.06 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 17:36.26 | *** join/#oe yann|work (~yann@85-171-21-92.rev.numericable.fr) |
| 17:58.42 | *** join/#oe t0mmy (~tprrt@ram31-2-82-228-88-46.fbx.proxad.net) |
| 18:15.36 | moto-timo | JaMa: python-matplotlib built for me on qemux86_64... maybe recent changes fixed the do_compile glitch? |
| 18:17.21 | *** join/#oe paulg (~paulg@209.29.74.150) |
| 18:42.30 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 18:44.49 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 18:52.53 | *** join/#oe evanmeag_ (~MongooseW@50.1.57.30) |
| 18:53.14 | *** join/#oe edbart (ebartosh@nat/intel/x-gtzqiyjzrpxwsupw) |
| 18:57.17 | *** join/#oe jackmitch|home (~Thunderbi@cpc2-slam8-2-0-cust880.2-4.cable.virginm.net) |
| 19:04.19 | *** join/#oe evanmeagher (~MongooseW@50.1.57.30) |
| 19:08.32 | *** join/#oe likewise (~likewise@46.166.188.213) |
| 19:17.16 | *** join/#oe armpit (~akuster@64.2.3.194) |
| 19:20.27 | *** join/#oe josep (~jhunt@c-291ee455.010-118-73746f7.cust.bredbandsbolaget.se) |
| 19:38.34 | khem | kergoth: should git fetch be using git repo tarball from premirrors if configured ? |
| 19:38.47 | khem | kergoth: or will it always go to upstream git repo for getting it |
| 19:38.53 | khem | even first time |
| 19:39.02 | kergoth | premirrors works fine with mirror tarballs |
| 19:39.08 | khem | hmmm |
| 19:39.15 | khem | kergoth: somehow its not going there |
| 19:39.24 | khem | its finding it |
| 19:39.29 | khem | but not deciding to use it |
| 19:39.38 | khem | how can that be |
| 19:41.13 | kergoth | that shouldn't even be possible. if it successfully downloads the mirror tarball, and it's in DL_DIR, then it'll unpack it and use that as the git repo. it might still need to contact the remote git repository to update it, if the tarball is out of date, though |
| 19:42.09 | khem | its not getting to DL_DIR |
| 19:42.21 | khem | but fetch logs show that its able to access it |
| 19:42.29 | khem | and wget outside bb works ok too |
| 19:42.31 | khem | on same box |
| 19:42.43 | fischerm | Crofton|work: did you get around to look at devtools vs oe issue? |
| 19:43.06 | *** join/#oe yann|work (~yann@nan92-1-81-57-214-146.fbx.proxad.net) |
| 19:43.47 | dl9pf | denix: which revision of meta-ti works with jethro ? master/head ? |
| 19:44.17 | kergoth | khem: might try a test case of putting the premirror url to the git tarball as SRC_URI in a recipe, see what it does fetching it directly, maybe it'll give more useufl info? |
| 19:44.26 | kergoth | then it'd error rather than just falling back to a real fetch |
| 19:45.07 | dl9pf | khem: did you do theBB_GENERATE_MIRROR_TARBALLS = "1" ? |
| 19:45.19 | dl9pf | my site.conf looks like: |
| 19:45.24 | dl9pf | BB_GENERATE_MIRROR_TARBALLS = "1" |
| 19:45.24 | dl9pf | DL_DIR = "/home/dl9pf/.yocto/shared_downloads" |
| 19:45.42 | dl9pf | then I move that over to webhost and set the premirror up like: |
| 19:46.00 | dl9pf | PREMIRRORS = "\ |
| 19:46.00 | dl9pf | git://.*/.* http://192.168.2.100/downloads/ \n \ |
| 19:46.00 | dl9pf | ftp://.*/.* http://192.168.2.100/downloads/ \n \ |
| 19:46.00 | dl9pf | http://.*/.* http://192.168.2.100/downloads/ \n \ |
| 19:46.00 | dl9pf | https://.*/.* http://192.168.2.100/downloads/ \n\ |
| 19:46.01 | dl9pf | " |
| 19:48.37 | *** join/#oe debris` (debris@gateway/shell/fnordserver.eu/x-qjrcebyziqkeztoz) |
| 19:49.53 | Crofton|work | fischerm, one built |
| 19:49.59 | Crofton|work | name wasn't annoying |
| 19:53.12 | *** join/#oe bluelightning (~paul@2406:e007:5ad0:1:5e51:4fff:febb:401d) |
| 19:53.13 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 19:55.58 | khem | dl9pf: do we need BB_GENERATE_MIRROR_TARBALLS = '11 |
| 19:56.02 | khem | BB_GENERATE_MIRROR_TARBALLS = "1" |
| 19:56.31 | dl9pf | khem: yes. premirror only works on 'tarballs' . it does not recognize git *trees* |
| 19:56.45 | dl9pf | so those mirror tarballs will be tarred git trees |
| 19:57.09 | dl9pf | otherwise you will only premirror the tarballs but not the gits |
| 19:58.04 | dl9pf | so you need to do a fresh build with BB_GENERATE_MIRROR_TARBALLS = "1" to generate the necessary git2.foo.bar.*.tar.bz2's |
| 19:58.16 | khem | isnt that just for generating the tars |
| 19:58.23 | khem | is it required for using it too ? |
| 19:58.24 | *** join/#oe t0mmy (~tprrt@ram31-2-82-228-88-46.fbx.proxad.net) |
| 19:58.37 | dl9pf | not required for using it iirc |
| 19:58.46 | Crofton|work | bluelightning, awake? |
| 19:59.00 | dl9pf | i just tend to keep it on and sync my dl_dir with the premirror once in a while |
| 20:00.06 | bluelightning | Crofton|work: I am yes |
| 20:00.08 | bluelightning | morning all |
| 20:00.28 | khem | dl9pf: so I am just using it |
| 20:00.31 | khem | its being generated |
| 20:00.39 | khem | already by a server |
| 20:01.05 | dl9pf | yep |
| 20:01.35 | dl9pf | iirc there is one glitch ... recipes using autorev won't be happy with the tarballs. |
| 20:01.40 | Crofton|work | installed an extensible sdk and failed, had to ook in log for perl module fail, restarting install fixes it? |
| 20:02.04 | dl9pf | khem: what you could do is to do a PREMIRRORONLY fetch ... what was the name again ... |
| 20:02.25 | dl9pf | BB_FETCH_PREMIRROR_ONLY |
| 20:02.40 | Crofton|work | hmm |
| 20:06.56 | Crofton|work | bluelightning, Required perl module(s) not found: Text::ParseWords Thread::Queue Data::Dump |
| 20:06.56 | Crofton|work | er |
| 20:07.01 | Crofton|work | while installing sdk-ext |
| 20:07.21 | Crofton|work | they are installed on machine I am installing sdk |
| 20:07.45 | bluelightning | Crofton|work: that's odd... which distro? |
| 20:07.54 | Crofton|work | Fedora |
| 20:08.00 | bluelightning | version? |
| 20:08.06 | Crofton|work | 23 |
| 20:08.20 | bluelightning | ok... I guess I will try to reproduce that here then |
| 20:08.30 | Crofton|work | regualr sdks are fine |
| 20:11.18 | Crofton|work | stagger off to fool with a nwer repo |
| 20:12.30 | bluelightning | regular SDKs don't have that check ;) |
| 20:15.15 | Crofton|work | ah |
| 20:15.21 | Crofton|work | yum says they are installed |
| 20:15.24 | Crofton|work | er dnf |
| 20:15.28 | Crofton|work | need to be modern |
| 20:15.58 | Crofton|work | I do not have /usr/lib/perl |
| 20:16.14 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 20:22.06 | *** join/#oe like2wise (~likewise@46.166.188.213) |
| 20:22.12 | bluelightning | Crofton|work: erm... how do you have those modules installed and not have perl? |
| 20:22.23 | Crofton|work | I have perl |
| 20:22.41 | bluelightning | Crofton|work: those are all of the modules we check for, so I would suspect the problem is it's unable to run perl for some reason |
| 20:23.15 | Crofton|work | [balister@thuvia ~]$ which perl |
| 20:23.15 | Crofton|work | /usr/bin/perl |
| 20:24.02 | Crofton|work | I have /usr/share/perl5 |
| 20:24.24 | *** join/#oe ant_home (~ant__@host183-191-dynamic.56-82-r.retail.telecomitalia.it) |
| 20:24.24 | Crofton|work | sdk install says: Can't locate Text/ParseWords.pm in @INC (you may need to install the Text::ParseWords module) (@INC contains: //usr/lib/perl/site_perl/5.22.1 //usr/lib/perl/vendor_perl/5.22.1 //usr/lib/perl/5.22.1 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/perl/site_perl/5.22.1/ /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/perl/site_perl/5.22.1 /usr/local/oecore-x86_64/sysroots/x86_64-oesd |
| 20:24.24 | Crofton|work | k-linux/usr/lib/perl/vendor_perl/5.22.1/ /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/perl/vendor_perl/5.22.1 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/perl/5.22.1/ /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/perl/5.22.1 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/perl/5.22.1 .) at -e line 1. |
| 20:31.06 | *** join/#oe eFfeM (~frans@c73189.upc-c.chello.nl) |
| 20:36.01 | Crofton|work | bluelightning, I suspect they work on my machine, but something screws up the test in the sdk |
| 20:38.36 | armpit | hmm SRCREV does not like spaces |
| 20:38.57 | Crofton|work | how can you get spaces in a rev? |
| 20:39.32 | armpit | after the hash via cut&past |
| 20:40.07 | armpit | and before the last " |
| 20:45.22 | fischerm | Crofton|work: they always build ... they just don't work |
| 20:45.34 | Crofton|work | define not work |
| 20:46.05 | fischerm | Crofton|work: some paths are not replaced so you get runtime link errors |
| 20:46.11 | fischerm | Crofton|work: on dev machine |
| 20:46.22 | fischerm | Crofton|work: just try if you can run devtool |
| 20:46.27 | Crofton|work | well, mine will not install |
| 20:46.37 | fischerm | ok, that looks similar |
| 20:46.44 | fischerm | mine installed and then didn't work |
| 20:47.04 | Crofton|work | I'll need to go to New Zealand and work with bluelightning in person |
| 20:47.41 | bluelightning | Crofton|work: your cat may not approve that expense ;) |
| 20:48.03 | Crofton|work | true |
| 20:48.39 | bluelightning | is this master or jethro btw? |
| 20:49.02 | bluelightning | jethro's eSDK does have quite a number of bugs that I haven't got around to backporting fixes for |
| 20:49.58 | fischerm | bluelightning: master |
| 20:50.37 | Crofton|work | master here |
| 20:51.00 | bluelightning | ok, that's a good start at least |
| 20:54.52 | bluelightning | was the eSDK built on the same machine or another? |
| 20:56.56 | Crofton|work | mine was built on smae |
| 21:00.20 | dl9pf | hey, is there a way to mask a .bbappend (e.g. if there is no .bb) ? |
| 21:00.53 | dl9pf | basically tell bitbake to ignore a foo%.bbappend through entry in, lets say local.conf |
| 21:03.02 | dl9pf | is that BBMASK ? |
| 21:03.17 | bluelightning | that would be one way |
| 21:03.26 | bluelightning | alternatively you could set BB_DANGLINGAPPENDS_WARNONLY = "1" |
| 21:03.57 | dl9pf | bluelightning: ah, cool |
| 21:04.04 | dl9pf | will try that |
| 21:19.55 | *** join/#oe boz_v1 (~juukorho@projects.sse.fi) |
| 21:20.42 | *** join/#oe radhus (~radhus@sevh.radhuset.org) |
| 21:27.03 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 21:35.54 | fischerm | Crofton|work: same here |
| 21:35.57 | fischerm | bluelightning: ^^^ |
| 21:36.39 | Crofton|work | fuck, finally brute force disabled Qt5 check on thrift and have recipe that should survive jama |
| 21:42.23 | *** join/#oe evanmeagher (~MongooseW@50.1.57.30) |
| 22:08.22 | Crofton|work | bluelightning, any chance you can point me at the perl checks so I can look them over? about done for the day here |
| 22:08.44 | bluelightning | Crofton|work: they're in sanity.bbclass - search for the modules it reports |
| 22:09.10 | bluelightning | thinking about it it could possibly be related to the environment within the installer being cleaned |
| 22:10.42 | *** join/#oe Aethenelle (~Aethenell@199.15.128.78) |
| 22:12.26 | Crofton|work | this is when the sdk is installed |
| 22:12.34 | *** join/#oe Aethenelle (~Aethenell@199.15.128.78) |
| 22:21.28 | bluelightning | Crofton|work: yes... SDK installation consists of the normal extraction plus running bitbake to install the sstate artifacts |
| 22:21.44 | bluelightning | and the first part of that run is the normal build sanity checks in sanity.bbclass |
| 22:22.38 | bluelightning | one difference with a normal run of bitbake though is that the install script cleans the environment before running anything, possibly something is excluded that affects perl |
| 22:35.05 | *** join/#oe likewise (~likewise@46.166.190.195) |
| 22:37.10 | Crofton|work | anyone played with myrepo for managing a colelction of layers? |
| 22:51.48 | kergoth | Crofton|work: i've used it locally quite a bit |
| 22:54.59 | Crofton|work | I'm lookig to see if I can replace repo with it |
| 22:56.08 | kergoth | it'd be a fair bit less flexible, no way to lock down a repository, etc, since it basically just wraps running git commands over multiple repositories, in my experience |
| 22:56.34 | kergoth | but depending on your requirements, it'd work fine |
| 22:57.11 | kergoth | i use it for my upstream yocto builds as an alternative to mucking with submodules, since i want to do my testing with branch heads to make sure our layers are working well with them |
| 22:57.36 | kergoth | or use it in concert with submodules, just as a quicker easier way to update them and operate against them.. |
| 23:02.00 | Crofton|work | hmm, I want to lock revs |
| 23:02.05 | Crofton|work | may not help |