*** jamiehowarth [43a10722@gateway/web/freenode/ip.67.161.7.34] has joined #baserock | 03:20 | |
*** straycat [~straycat@vortis.xen.tardis.ed.ac.uk] has quit [Ping timeout: 240 seconds] | 06:20 | |
*** straycat [~straycat@vortis.xen.tardis.ed.ac.uk] has joined #baserock | 06:22 | |
*** mSher [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 06:44 | |
*** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:40 | |
*** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 07:44 | |
*** mSher [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 07:59 | |
*** mSher [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:00 | |
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:01 | |
*** mSher [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Client Quit] | 08:02 | |
*** mSher [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:02 | |
*** mSher [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Client Quit] | 08:05 | |
*** mSher [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:05 | |
*** mSher [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Client Quit] | 08:06 | |
*** mSher [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:06 | |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:40 | |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:48 | |
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:58 | |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 09:07 | |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:16 | |
* ssam2 notices http://operatingsystems.io/ | 09:33 | |
ssam2 | an event about operating systems in London on a tuesday in November | 09:33 |
---|---|---|
jmacs | Oh yes, I saw that | 09:34 |
ssam2 | I think I shall see about going, if work will allow it. Sounds interesting | 09:35 |
jmacs | I'd be up for going | 09:36 |
Krin | hey all, and morning (ish). Beginning to think this is a lost cause but does anyone know of a way to install a .deb file onto baserock? more precisely a way to port it to something that baserock will understand? I have tried doing it manually with ar -x to unpack the file, I got it to attempt to run, but not joy in the actual continuing to run... | 10:01 |
rjek | BR people might be interested in the ostree talk | 10:02 |
franred | richard_maw, I was talking yesterday with Kinnison about if it is possible to use one repo to build another repo at building time without installing the first repo in the system, and Kinninson told me that could be a possibility using some "devel directory" wich will be not installed... | 10:02 |
Kinnison | Krin: It's not massively likely you'll get that to work | 10:03 |
Kinnison | Krin: I'd start by using dpkg-deb on a debian system to unpack the archive and then transfer the contents over, but if you need libraries which are not present in Baserock you won't get it up trivially | 10:03 |
ssam2 | Krin: persia wrote a tool to install a .deb in Baserock, I seem to recall | 10:04 |
Kinnison | Krin: I take it you don't have source to this deb? | 10:04 |
Krin | yeah, i was working on that assumption Kinnison, my last ditch effort is to see if anyone knows a way to port it | 10:04 |
ssam2 | https://github.com/persia/debinject | 10:04 |
Kinnison | ssam2: he wrote something, yes | 10:04 |
Krin | no source avaialiable Kinnison | 10:04 |
rjek | Oh, Justin Cormack is organising that OS conference. He's a good guy. | 10:04 |
Kinnison | rjek: ? | 10:04 |
Krin | no source makes Krin a sad codething | 10:05 |
jmacs | Kinnison: http://operatingsystems.io/ | 10:05 |
rjek | Kinnison: http://operatingsystems.io/ mentioned by ssam2 at 1034. | 10:05 |
Kinnison | Krin: oh dear. Erm, what platform is this for? | 10:05 |
Kinnison | that conf sounds interesting | 10:05 |
Krin | Ubuntu, mac OS, windows. all individual downloads, but nothing that i think is likely to work with baserock | 10:06 |
Kinnison | the Ubuntu stuff, what platform is it for? | 10:06 |
Krin | R13 if i recall, but let me go check | 10:06 |
Kinnison | intel? arm? | 10:07 |
Kinnison | 32bit? | 10:07 |
Kinnison | 64bit? | 10:07 |
Krin | rel19.2 arm | 10:07 |
Krin | 64 bit | 10:07 |
Kinnison | so aarch64 ? | 10:07 |
Kinnison | Baserock isn't on aarch64 yet | 10:08 |
Krin | ah. this could explain some things XD | 10:08 |
Kinnison | What are you trying to do with aarch64? Do you have kit? If so, we could try and bootstrap a port at some point. | 10:09 |
Krin | still trying to get CUDA working on baserock, using a jetson board, baserock installed and updated to the latest for the jetsons | 10:10 |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 10:14 | |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:15 | |
Kinnison | jetson isn't aarch64 it's armv7lhf | 10:15 |
Krin | well, i assume it's that architecture then, as it's the CUDA software specificaly designed for the Jetson *blushes* | 10:16 |
Kinnison | Is it meant to run *on* the jetson? | 10:20 |
Krin | yes it is a pacakage specificaly designed to run on the jetson Kinnison, however it's designed to run on the jetson default software which is a variation of Ubuntu | 10:23 |
richard_maw | I think the point was asking how you were offered aarch64 binaries for Jetson | 10:24 |
Krin | richard_maw, i dont know how to tell what the binarys are for, i'm still not very experianced in linux or embedded really, i made an assumption, knowing that the Tegra is a 64 bit proccessor, i assumed that the software for it would also be 64bit. | 10:32 |
Krin | it also has little to no documentation without installing the software, as it's a seperate thing from te standardly obtainable CUDA toolkits | 10:34 |
Kinnison | Krin: dpkg-deb -I foofile.deb | 10:34 |
Kinnison | can you put the output of that into a pastebin for me? | 10:34 |
richard_maw | Krin: http://en.wikipedia.org/wiki/Tegra#Tegra_K1 suggests that are working on an experimental 64-bit core, but the A15 versions are 32-bit | 10:35 |
Krin | Kinnison, https://admin.codethink.co.uk/pnopaste/?1926 | 10:36 |
* Kinnison appreciates this is all a little confusing | 10:36 | |
Kinnison | Krin: Hmm, that's not a public pastebin :-( | 10:36 |
Kinnison | Architecture: armhf | 10:37 |
Kinnison | Okay, that's a plausible start | 10:37 |
Krin | http://pastebin.com/fXSdCbNh | 10:37 |
Kinnison | Okay, so let's start by extracting it | 10:39 |
Kinnison | one sec | 10:39 |
Kinnison | dpkg-deb --fsys-tarfile foo.deb > foo.tar | 10:39 |
Kinnison | then copy foo.tar to your jetson and unpack it | 10:40 |
Kinnison | then try running one of the binaries | 10:40 |
Kinnison | if it fails, pastebin the result | 10:40 |
jmacs | Is /tmp meant to be tmpfs on baserock? | 10:43 |
richard_maw | that's the default config for systemd | 10:43 |
jmacs | That doesn't really answer my question | 10:46 |
richard_maw | we never explicitly decided we wanted /tmp as a tmpfs, it's just that's what systemd does by default | 10:48 |
richard_maw | so we've gone with it | 10:48 |
jmacs | Let me rephrase that: /tmp is tmpfs on my baserock system. Is that what you would expect? | 10:49 |
richard_maw | yes | 10:49 |
jmacs | So morph build is failing because it wants 4GB of free space on /tmp/morph_tmp | 10:51 |
richard_maw | we usually put --tempdir=/src/tmp and attach a larger disk on /src, or if we've got a large enough rootfs you could put --tempdir=/var/tmp | 10:52 |
Krin | Kinnison, should i do the same with all the .deb files contained in the original .deb file? | 10:53 |
Kinnison | Krin: i'm sorry, you mean they put a bunch of .debs into a .deb? | 10:54 |
Krin | yes, they have | 10:54 |
Kinnison | oh dear | 10:54 |
Krin | or at least the unpackaged version has more .debs inside it | 10:54 |
jmacs | richard_maw: What is --tempdir an arugment to? | 10:55 |
richard_maw | morph | 10:55 |
jmacs | Aha | 10:56 |
*** tiagogomes [~tiagogome@213.15.255.100] has quit [Quit: Leaving] | 10:56 | |
richard_maw | you can put "tempdir = /src/tmp" into /etc/morph.conf so you don't need to pass it every time | 10:56 |
Krin | and if i recall corectly from my earlyer experiments with ar -x Kinnison, some of THOSE .deb files also contain .debs | 10:56 |
*** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 10:56 | |
jmacs | Yes, that's the step I was missing | 10:56 |
Kinnison | Krin: that sounds horrendous | 10:57 |
Krin | i spent most of last afternoon digging down into the depths of the package to extract the actual meat of the package, and trying to put the results in the right place, got it to run in the end, but it just had the same error as when i got the previous attempt to install but not work | 10:58 |
Kinnison | I'm afraid that I'm at a loss | 10:59 |
Kinnison | if they've made debs which are that horrendous then I'm not sure what to suggest | 10:59 |
Krin | Kinnison, fly to America, buy a flame-thrower and walk up to the Nvidia office with intent for "polite discussion on correct packaging"? | 11:01 |
Krin | hell as i say, i'm not that experienced at linux and even i looked at this stuff and went "surely that's not... right?.. whatever..." | 11:02 |
Kinnison | As a DD I'm horrified they might do that | 11:03 |
Krin | DD? debian developer? | 11:16 |
Krin | Kinnison, ^ | 11:17 |
Kinnison | yes | 11:18 |
Krin | kay, i'm thinking it's time to throw in the towel on getting CUDA to work on baserock | 11:18 |
Kinnison | I may be able to assist with the pickapart tomorrow | 11:19 |
* Krin goes home to get a towel to throw at the jetson board | 11:19 | |
Krin | that would be appreciated Kinnison, i'm a long way out of my depth here :) | 11:19 |
*** jamiehowarth [43a10722@gateway/web/freenode/ip.67.161.7.34] has quit [Ping timeout: 246 seconds] | 11:51 | |
jmacs | Gah, just had another failed self-deployment and it seems to have taken out the root filing system by itself this time :/ | 12:01 |
SotK | I thought Baserock upgrades either worked or didn't do anything? :/ | 12:02 |
jmacs | I'm going to try and mount it outside the VM and investigate | 12:03 |
jjardon | Hi! Can I have some feedback from the patches I sent last week/beginning of this before move to another stuff? ("We are too busy to review them!" Is a perfect valid answer ;)) | 12:42 |
richard_maw | jjardon: are those the llvm and libdrm moving ones? | 12:43 |
richard_maw | I'd like to review and +1 your changes, but I'm afraid I don't know enough about the graphics stack | 12:44 |
* richard_maw is annoyed by how many kernel morphologies we have, and the duplicated information between them | 12:45 | |
Kinnison | If radiofree were comfortable reviewing jjardon's patches I'd feel okay with merging on his +1 | 12:45 |
richard_maw | it makes it more difficult to add generic options to all kernels | 12:45 |
jjardon | Yep, these moves trying to avoid duplication and also avoid unnecessary rebuilds | 12:46 |
jjardon | Kinnison: thanks, I will try to ping him | 12:47 |
jmacs | I think my previous deploy failed because I ran two deployments with the same VERSION_LABEL | 12:48 |
pedroalvarez | jmacs: where you deploying as rawdisk? | 12:49 |
jmacs | Would it be worth me putting in a check to see if you're deploying to your current btrfs volume name (or whatever the term is)? | 12:49 |
pedroalvarez | s/where/were/ | 12:49 |
jmacs | No, ssh-rsync | 12:50 |
jmacs | I don't mean deploy, I mean upgrade | 12:50 |
pedroalvarez | which is the same as depl;oy using ssh-rsync :) | 12:51 |
richard_maw | it sounds worthwhile, you ought to be able to get the list of systems from `system-version-manager list` | 12:51 |
richard_maw | though I think paul added junk to the ends of the lines, making it harder to use the output in a machine parsable way | 12:52 |
pedroalvarez | true, but the version label is going to be always in the first column | 12:52 |
jmacs | Currently it says "14.40b (running) (default)" which is useful junk | 12:52 |
richard_maw | perhaps, but it means we can't add a version with those strings in its name | 12:53 |
jmacs | True. | 12:53 |
richard_maw | pedroalvarez: assuming it's only in the first column means you couldn't have a nice human friendly version name with spaces in | 12:53 |
* jjardon just realize his libdrm patches doesn't apply anymore. Will rework it | 12:54 | |
* richard_maw is a little annoyed that we couldn't have versions with \n in by parsing the output of `system-version-manager list` | 12:54 | |
jjardon | pedroalvarez: do you remember what was the reason for disabling dri3 in mesa? | 12:55 |
pedroalvarez | jjardon: nope, I just did what James told me to do | 12:56 |
pedroalvarez | richard_maw: then we have to change the list command to support an option to show/hide the default and the running bits | 12:57 |
pedroalvarez | or add another command | 12:57 |
wikicat | Wiki change: http://wiki.baserock.org/recentchanges/#change-9b64888ca807db163750f7560546e97b6ea7cd3c | 12:59 |
richard_maw | either another command, which NUL terminates the names, or uses a structured format; or just fix the write extension to fail gracefully if the version already exists | 12:59 |
richard_maw | ah, the isue is that it assumes that if it couldn't make the snapshot, it needs to clean it up | 13:04 |
richard_maw | currently, ssh-rsync can be used to delete a baserock version | 13:06 |
pedroalvarez | seriously? :S | 13:07 |
wikicat | Wiki change: Adding resolution for insufficient /tmp space error http://wiki.baserock.org/recentchanges/#change-6fec29d0eb9fb03d26efbc9bfb90f98aa57e67e2 | 13:07 |
richard_maw | pedroalvarez: yeah, because it tries to mkdir the version root directory, fails, and cleans up the subvolumes and version root directory | 13:08 |
richard_maw | though it won't update the extlinux.conf | 13:08 |
pedroalvarez | then, checking before that the version doesn't exist, would be great | 13:10 |
richard_maw | just fixing it to clean up its resources properly would work | 13:10 |
ssam2 | jjardon: i'll try to look at your patches tomorrow | 13:16 |
ssam2 | jmacs, richard_maw: good spot, I didn't realise that about deploying to an existing VERSION_LABEL | 13:17 |
ssam2 | any volunteers to fix it? | 13:17 |
richard_maw | I'll do it | 13:17 |
jmacs | I thought I'd already volunteered, but be my guest :) | 13:20 |
paulsherwood | jjardon: yes, sorry i've been offline. +1 | 13:39 |
jjardon | paulsherwood: \o/ | 13:42 |
* jjardon goes to merge :) | 13:42 | |
*** genii [~quassel@ubuntu/member/genii] has joined #baserock | 14:14 | |
franred | hi, we were lorrying a repository "python-packages/decorator" from "https://bitbucket.org/pypa/pypi", when we want to use "https://code.google.com/p/micheles/" | 14:29 |
pedroalvarez | oops | 14:30 |
franred | changing the URL in the lorry file will remove the old repo and add the new one without any consecuences? | 14:30 |
pedroalvarez | I think lorry controller will fail to push some parts of the new lorry | 14:31 |
pedroalvarez | due conflicts | 14:31 |
franred | do we want to lorry pypi at all? (it is only used for the strata that Im actually working in) | 14:31 |
ssam2 | what's pypi ? | 14:31 |
pedroalvarez | franred: if I understood it correctly, it's used in your stratum, but you didn't want to use it | 14:31 |
ssam2 | surely we don't want to import http://pypi.python.org/ ? | 14:32 |
franred | ssam2, it is the same, does it? | 14:33 |
pedroalvarez | we can force the lorry controller to force push the new lorry, but I don't know the consequiences in downstream troves | 14:33 |
franred | but I think it is not a decorator... | 14:34 |
franred | ssam2, I want a decorator which is in https://code.google.com/p/micheles/ | 14:34 |
pedroalvarez | but that repo not only contains the decorator source | 14:35 |
franred | https://pypi.python.org/pypi/decorator/3.4.0 | 14:35 |
franred | yep... should I use the tarball instead? | 14:35 |
franred | the mercurial repository contains more than the decorator | 14:36 |
pedroalvarez | franred: couldn't you use this? https://pypi.python.org/pypi/decorator | 14:36 |
pedroalvarez | baserock-14.40.1 has been finally released | 14:42 |
pedroalvarez | there is a new jetson devel system ready to flash in download.baserock.org | 14:42 |
ssam2 | \o/ | 14:42 |
franred | I need a fast review about this lorry file: http://fpaste.org/140650/66470141/ | 14:54 |
richard_maw | franred: it sucks that we have to have a tarball import, but +1 | 14:55 |
SotK | franred: +1 | 14:56 |
richard_maw | I'm not sure where the micheles name is from though | 14:56 |
franred | richard_maw, the other posibility is lorry a whole mercurial repository with other projects on it :S | 14:56 |
richard_maw | we've done chunks like that before | 14:56 |
richard_maw | it's a depressingly popular way of running a project | 14:57 |
franred | richard_maw, do you think that is better the mercurial repo than the tarball? | 14:57 |
franred | note: this will add also extra work in the chunk morphology | 14:58 |
richard_maw | yeah, but we're not afraid of that | 14:58 |
jmacs | ssam2: Have you tried running "knife" yet? I just get errors connecting to https://supermarket.getchef.com | 14:58 |
franred | richard_maw, then I will change the lorry patch | 14:59 |
pedroalvarez | then, makes sense to call it "decorator" when it is going to add more things? | 15:00 |
franred | pedro, I will called micheles-repository | 15:00 |
pedroalvarez | but micheles is a person! | 15:01 |
pedroalvarez | isn't? | 15:01 |
Kinnison | presumably | 15:01 |
franred | it is | 15:01 |
pedroalvarez | I'm going to create a repository with multiple proyects, and then lorry it. so I can have a repo with my name in g.b.o! | 15:01 |
richard_maw | hm, hold on for a minute | 15:02 |
richard_maw | eww, this repository isn't just decorator, it's a dumping ground for things that are unrelated | 15:03 |
pedroalvarez | they are maybe related | 15:03 |
Kinnison | fran did say | 15:03 |
pedroalvarez | same author | 15:03 |
richard_maw | it's got things that aren't code or documentation about code in it | 15:03 |
pedroalvarez | another point is: what do we do with upstrem:decorator? | 15:05 |
ssam2 | jmacs: I didn't try all 'knife' commands | 15:05 |
ssam2 | might be SSL related | 15:05 |
*** pwerner9 [~pwerner9@c-68-61-186-102.hsd1.mi.comcast.net] has joined #baserock | 15:06 | |
jmacs | Yes, looks like it | 15:06 |
ssam2 | in fact, you may need an account to contact supermarket.getchef.com and have your private certificate for that account available to Knife somewhere | 15:06 |
jmacs | I've no idea what the chef server should be either | 15:06 |
ssam2 | no, Chef seem to provide a public instance | 15:08 |
franred | pedroalvarez, I will change the name from decorator-micheles to python-decorator - and.... lorry the tarball! :S | 15:08 |
ssam2 | jmacs: or, you can install it in a Fedora or Debian machine from their 'megapackage', although I guess it requires some setting up | 15:08 |
ssam2 | you can also run Chef without a server | 15:08 |
ssam2 | there's a tool called `chef-solo` which helps with that | 15:09 |
pedroalvarez | franred: I'm not sure about that | 15:09 |
pedroalvarez | I can't +2 that decission | 15:09 |
franred | it is just a name - I will sign-off that | 15:10 |
pedroalvarez | is not just a name | 15:11 |
jmacs | I'm trying to set up my machine as a chef server now | 15:11 |
ssam2 | cool, let me know how it goes! | 15:11 |
franred | richard_maw, SotK, any problem to lorry the tarball and called pytho-decorator rather than decorator-micheles? pedroalvarez think that I should replace the actual decorator by this but I don't know the consequences of that | 15:12 |
SotK | I don't have an issue with the name, but am interested to know why we need to lorry this if decorator is already lorried? | 15:16 |
richard_maw | wrong decorator I think | 15:16 |
SotK | fair enough then I guess | 15:16 |
franred | yeah, it is the wrong decorator | 15:20 |
wikicat | Wiki change: Update instructions to use latest tag http://wiki.baserock.org/recentchanges/#change-449879c58163562020894bb26e349174194a2412 | 15:21 |
wikicat | Wiki change: Update baserock-jetson instructions to work with latest release http://wiki.baserock.org/recentchanges/#change-6d0ca92e65cef0b0da658654c938be66b11b19ea | 15:25 |
richard_maw | oh wikicat is a bot! | 15:26 |
* richard_maw thought straycat was playing games | 15:26 | |
franred | sorry to bother you today with this but I need a new review: http://fpaste.org/140662/28685091/ - this has the name changed and an additional repo that we need | 15:28 |
ssam2 | franred: what name has changed? looks like 2 additional repos and no other changes | 15:30 |
franred | ssam2, the second one is the same that I've posted before but with different naem | 15:31 |
franred | name even | 15:31 |
ssam2 | right, ok | 15:31 |
ssam2 | +1 | 15:31 |
straycat | yeah wikicat should point to something more useful though | 15:48 |
*** tiagogomes [~tiagogome@213.15.255.100] has quit [Quit: Leaving] | 15:48 | |
* richard_maw ended up rewriting ssh-rsync to be mostly context managers | 15:50 | |
rjek | win 8 | 15:50 |
franred | anyone could have a look the the fast review I've posted before or should I take the +1 from ssam2 as a +2? :P | 15:50 |
rjek | bah | 15:50 |
richard_maw | franred: go ahead | 15:50 |
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 15:53 | |
wikicat | Wiki change: http://source.baserock.branchable.com/?p=source.git;a=commitdiff;h=6ef520b | 16:05 |
*** jamiehowarth [~jamiehowa@2607:fb90:1d0e:a276:dd60:e171:b550:85b4] has joined #baserock | 16:18 | |
*** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 16:33 | |
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:35 | |
richard_maw | ssam2: added raises and re-tested, worked | 16:37 |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:37 | |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 16:37 | |
jjardon | So Im trying to upgrade to latest systemd the update will be blocked because I need coreutils (GPLv3) to compile it. Any hint where I have to look at to try to fix this in the correct way? | 17:07 |
*** mSher [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:11 | |
radiofree | jjardon: it'll only be blocked for genivi? | 17:25 |
jjardon | radiofree: yes | 17:25 |
radiofree | for now that shouldn't be a concern really? | 17:30 |
jjardon | My understanding is that no-GPLv3 code can go in genivi images. So we can't put coreutils in core to build systemd with them | 17:35 |
pedroalvarez | our current approach with gplv3 chunks in genivi system is: remove everything installed by them when everything is built | 17:36 |
radiofree | as far as i'm aware the gpl3 stuff is removed *after* building | 17:36 |
pedroalvarez | if we do the same with coreutils we will end up with a system unusable | 17:36 |
radiofree | if you build gpl2 stuff with gpl3 things, would you have to remove the gpl2 stuff? | 17:37 |
pedroalvarez | afact, we are not removing anything else than gplv3 things | 17:37 |
Kinnison | So long as no gplv3 code is *linked* into the system you're safe | 17:40 |
Kinnison | gpl doesn't infect through compilation or you'd never be able to build anything but gpl code with gcc | 17:40 |
paulsherwood | richard_maw: if i may be so bold, what on earth is a 'context manager'? | 17:44 |
jjardon | maybe this can be solved putting coreutils in a separate stratum, make foundation depend on it, but do not use that stratum in the genivi systems? | 18:28 |
pedroalvarez | jjardon: that would work, yeah. not the ideal solution though | 18:29 |
jjardon | mmm, morph is stuck in "Resolving artifacts", this is the latest log: http://fpaste.org/140717/87946014/ Any idea what is happening/where should I look? | 18:31 |
pedroalvarez | some people have reported slow starting times some days ago | 18:32 |
radiofree | jjardon: it's probably not stuck | 18:32 |
radiofree | it just takes absolutely ages | 18:32 |
paulsherwood | yes, i blame recent changes :/ | 18:32 |
pedroalvarez | jjardon: please, leave it running and report the log later | 18:32 |
jjardon | sure! | 18:33 |
jjardon | its alive!! :) | 18:33 |
pedroalvarez | jjardon: any useful in the log? | 18:33 |
* paulsherwood wonders why 85.199.252.101 has been yellow since Tuesday? | 18:35 | |
pedroalvarez | I only see one yellow | 18:35 |
jjardon | pedroalvarez: I do not think so: it continues running normally after 11 min: http://fpaste.org/140722/41287973/ | 18:35 |
radiofree | that's definitely a regression | 18:37 |
paulsherwood | jjardon: are you using latest morph? | 18:38 |
jjardon | paulsherwood: latest master, yes | 18:38 |
paulsherwood | hmmm. | 18:38 |
jjardon | note this is after adding the GNOME stratum | 18:39 |
jjardon | but it was no so slow before | 18:39 |
paulsherwood | http://fpaste.org/140724/ | 18:39 |
paulsherwood | seems blazingly fast to me, suddenly | 18:40 |
paulsherwood | erm, has someone been fiddling with deploy? | 18:42 |
paulsherwood | http://fpaste.org/140727/ | 18:43 |
pedroalvarez | paulsherwood: I've changed the http://85.199.252.101/ address to point to new mason, which builds also the genivi systems | 18:43 |
paulsherwood | pedroalvarez: but it's not working? | 18:43 |
paulsherwood | anything i can check before i reboot my busted devel system and pray? | 18:43 |
pedroalvarez | system-version-manager list | 18:44 |
paulsherwood | i don't even have ls, never mind system-version-manager | 18:45 |
pedroalvarez | oh, I missed that | 18:46 |
pedroalvarez | Richard Maw has sent a patch to fix that | 18:46 |
paulsherwood | i'm on latest master morph, definitions | 18:46 |
pedroalvarez | I think you were running the TEST version when doing the upgrade with version label TEST | 18:46 |
paulsherwood | ok | 18:46 |
pedroalvarez | can be that true? | 18:47 |
paulsherwood | yes, it can. well spotted :) | 18:47 |
paulsherwood | but now i haven't even got 'reboot' | 18:47 |
pedroalvarez | hahaha | 18:47 |
pedroalvarez | is an openstack instance? | 18:48 |
paulsherwood | i'm laughing here too, but crying inside ;) | 18:48 |
paulsherwood | nope, my local vm | 18:48 |
pedroalvarez | hmm | 18:48 |
paulsherwood | not to worry | 18:48 |
pedroalvarez | then you should have a button to reboot it | 18:48 |
paulsherwood | yes, that fixed it (rebooting into factory) | 18:49 |
paulsherwood | so maybe i wasn't actually in fact running latest morph ... | 18:49 |
pedroalvarez | the patch is not merged anyway | 18:50 |
pedroalvarez | (I think) | 18:50 |
pedroalvarez | currently if you deploy an upgrade with a version label that already exsist, the previous version will be removed and the deployment fail | 18:50 |
pedroalvarez | we spotted that today | 18:51 |
paulsherwood | interesting conundrum... if i'm (accidentally) in TEST, do git pull for morph, that won't be the morph i actually get, becasue TEST /usr/bin doesn't have the script to run latest morph in it | 18:51 |
* paulsherwood decides to fix this hole in cycle.sh | 18:58 | |
*** pwerner9 [~pwerner9@c-68-61-186-102.hsd1.mi.comcast.net] has quit [Quit: pwerner9] | 19:09 | |
*** jamiehowarth [~jamiehowa@2607:fb90:1d0e:a276:dd60:e171:b550:85b4] has quit [Ping timeout: 272 seconds] | 20:57 | |
radiofree | Kinnison: just saw your comment, will take a look at them tomorrow | 22:31 |
*** pwerner9 [~pwerner9@d14-69-32-220.try.wideopenwest.com] has joined #baserock | 23:02 | |
*** pwerner9 [~pwerner9@d14-69-32-220.try.wideopenwest.com] has quit [Client Quit] | 23:07 | |
*** genii [~quassel@ubuntu/member/genii] has quit [Remote host closed the connection] | 23:13 | |
* paulsherwood discovers celery, and marvels | 23:31 | |
*** pwerner9 [~pwerner9@d14-69-32-220.try.wideopenwest.com] has joined #baserock | 23:40 | |
*** pwerner9 [~pwerner9@d14-69-32-220.try.wideopenwest.com] has quit [Quit: pwerner9] | 23:54 | |
*** pwerner9 [~pwerner9@d14-69-32-220.try.wideopenwest.com] has joined #baserock | 23:59 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!