*** sambishop has quit IRC | 02:11 | |
*** zoli__ has joined #baserock | 03:26 | |
*** zoli__ has quit IRC | 05:28 | |
*** zoli__ has joined #baserock | 05:28 | |
*** zoli__ has quit IRC | 05:44 | |
*** zoli__ has joined #baserock | 06:21 | |
*** a1exhughe5 has joined #baserock | 07:21 | |
*** mariaderidder has joined #baserock | 07:23 | |
*** Albert_ has joined #baserock | 07:24 | |
*** Albert_ has joined #baserock | 07:25 | |
paulsherwood | fwiw ybd /win 24 | 07:46 |
---|---|---|
paulsherwood | bah!!!! | 07:46 |
paulsherwood | i started to say, fwiw ybd built all of the release x86_64 definitions in approx 3 hours | 07:47 |
*** sambishop has joined #baserock | 08:00 | |
straycat | distbuild-list-jobs, could we maybe change it to distbuild-list, or distbuild-ls, or something a little less long winded | 08:01 |
straycat | or… aliases, yes one day, one day… | 08:02 |
*** bashrc_ has joined #baserock | 08:03 | |
straycat | maybe even distls, and then we could have diststat | 08:03 |
paulsherwood | sorry if this is a dumb question, but why is this functionality needed, straycat? | 08:03 |
paulsherwood | (i am trying to answer your question, btw) | 08:04 |
straycat | because you can now detach from your running distbuilds, like screen but not screen | 08:04 |
*** edcragg has joined #baserock | 08:11 | |
*** Albert_ has quit IRC | 08:24 | |
pedroalvarez | radiofree: looks like finally they decided to do somthing - http://git.projects.genivi.org/?p=persistence/persistence-client-library.git;a=commitdiff;h=5fac47c728183c4dfee12524348240a07e5ef05c | 08:30 |
pedroalvarez | I was proud of my patch :/ | 08:31 |
Kinnison | heh | 08:33 |
pedroalvarez | did anyone integrate Mariadb in baserock? | 08:36 |
paulsherwood | i think i gave up | 08:37 |
paulsherwood | pedroalvarez: does that mean that Ingo Huerner re-implemented your solution? | 08:38 |
pedroalvarez | but I believe someone continued | 08:38 |
pedroalvarez | paulsherwood: worse, my solution was to add support to --disable-werror, he dropped my patch because "GENIVI requests to treat warnings as errors", and now he disabled -werror always | 08:40 |
pedroalvarez | well, IMO is worse | 08:40 |
paulsherwood | is he right? | 08:40 |
paulsherwood | this is a philosophical point. better to force the build to be clean? | 08:41 |
rjek | I prefer pedroalvarez's approach. | 08:42 |
Kinnison | It's better if the from-git variant always puts -Werror on by default | 08:42 |
Kinnison | traditionally you should have -Werror for developers and -Wno-error for integration/distribution | 08:42 |
*** ssam2 has joined #baserock | 08:42 | |
*** ChanServ sets mode: +v ssam2 | 08:42 | |
rjek | I like -Werror for development, but it's important to let people opt to disable it when building for production or end-user | 08:42 |
*** gary_perkins has joined #baserock | 08:43 | |
pedroalvarez | he contradicted himself with his patch, I think | 08:43 |
* paulsherwood wonders whether it's worth raising this on the genivi-projects list | 08:43 | |
pedroalvarez | I don't know.. I'm very merciful | 08:47 |
* paulsherwood is not | 08:50 | |
straycat | we know :) | 08:50 |
paulsherwood | :-) | 08:50 |
pedroalvarez | CTtpollard: was it you who was playing with mariadb? | 08:58 |
*** tiagogomes has joined #baserock | 09:00 | |
CTtpollard | pedroalvarez: our project was, ctgriffiths did the work with it | 09:00 |
pedroalvarez | yay, I found him! thanks CTtpollard | 09:01 |
* ctgriffiths was never any good at hide and seek | 09:02 | |
ctgriffiths | pedroalvarez: it's on my github but it's jumbled with the storyboard stuff, it will need cleaning up: https://github.com/ctgriffiths/baserock-definitions/commit/7e3f2a43269633c1eddab1a13cad69f6087e379d | 09:03 |
Kinnison | Why do we want mariadb? We already have pgsql | 09:04 |
pedroalvarez | Kinnison: just in case openstack stops working with pgsql | 09:04 |
Kinnison | Can we just murder whoever proposes that? | 09:05 |
Kinnison | I remember back when I tried OpenStack a few years ago and it used MySQL and it was awfully slow at the DB layer and massively inefficient and broken | 09:06 |
Kinnison | Because they had to layer proper transactionality on top | 09:06 |
rjek | ISTR that quite a few parts of the OpenStack project already don't work with PostgreSQL. StoryBoard IIRC, for example | 09:06 |
pedroalvarez | Kinnison: I think we are late to murder people | 09:07 |
Kinnison | OpenStack Infra. projects are very different from OpenStack itself | 09:08 |
Kinnison | their Infra. projects are often just "enough" to work | 09:08 |
CTtpollard | Stroyboard did drop pgsql support | 09:08 |
CTtpollard | *Storyboard | 09:08 |
*** Krin has joined #baserock | 09:10 | |
pedroalvarez | I can't find any info about this, but I believe that OpenStack is not going to drop patches if they break pgsql | 09:11 |
pedroalvarez | I think is good to bear that in mind if someday we plan to upgrade to kilo | 09:12 |
paulsherwood | Kinnison: on this i agree, pgsql is much simpler. trouble with software is other people's choices may not align with what's *best* | 09:14 |
Kinnison | paulsherwood: in a lot of ways, MySQL/MariaDB is simpler because people find pgsql's adherence to a properly ACID model hard to work with | 09:15 |
Kinnison | paulsherwood: also, less relevant these days, but libpq-dev was much harder to bind cleanly to | 09:15 |
paulsherwood | paulsherwood: i've just had better experiences with pgsql - it was trivial to add it to baserock, for example | 09:16 |
paulsherwood | s/paulsherwood/Kinnison/ obviously ;) | 09:16 |
straycat | mariadb would be better for working with ceilometer and apparently has a bette license | 09:16 |
straycat | *better | 09:16 |
straycat | slackware removed support for mysql in favour of mariadb in 2013 | 09:17 |
Kinnison | straycat: mariadb's licence is better than mysql's -- pgsql's is best | 09:17 |
rjek | Oracle screwed over MySQL so I think basically everybody went for MariaDB | 09:18 |
* bashrc_ uses MariaDB | 09:18 | |
pedroalvarez | baserock is currently using: redis, mariadb, pgsql, sqlite... | 09:20 |
* rjek has an extremely strong preference for predicability, reliability, and data integrity, so uses PostgreSQL | 09:20 | |
*** lachlanmackenzie has joined #baserock | 09:23 | |
paulsherwood | +1 | 09:24 |
*** CTtpollard has quit IRC | 10:03 | |
*** CTtpollard has joined #baserock | 10:14 | |
*** Albert_ has joined #baserock | 10:14 | |
edcragg | i'm getting this error building binutils on armv7lhf: http://paste.baserock.org/ipedugorel any ideas? | 10:38 |
straycat | the morph test suite seems to be failing its deploy scenarios, i can't look into this right now but just thought i'd say | 10:41 |
SotK | straycat: it seems ok to me, what error are you seing? | 10:42 |
SotK | s/seing/seeing/ | 10:42 |
rdale | why is gobject-introspection in the core stratum - it isn't a core build tool? | 10:43 |
pedroalvarez | edcragg: I think you are having problems with your filesystem | 10:48 |
pedroalvarez | a release is being done right now, and we are not hitting any problems when building | 10:48 |
ssam2 | rdale: https://gerrit.baserock.org/#/c/447/ | 10:48 |
ssam2 | that is when the change was made | 10:48 |
straycat | SotK, http://sprunge.us/TKIa | 10:48 |
ssam2 | straycat: oh, I guess that's my fault, thanks for pointing it out | 10:49 |
SotK | straycat: oh, its failing for me too... it must be a recent change | 10:49 |
edcragg | pedroalvarez: thanks... weirdly, it builds if i unmount /tmp before running morph | 11:02 |
pedroalvarez | :/ | 11:03 |
edcragg | probably because i also symlinked /tmp/morph_tmp to the external sdd | 11:04 |
edcragg | i'm guessing | 11:04 |
edcragg | s/sdd/ssd/ | 11:04 |
*** Albert_ has quit IRC | 11:36 | |
ssam2 | fix for sysroot.write issue: https://gerrit.baserock.org/#/c/612/ | 11:38 |
ssam2 | can anyone give it a quick review so I can merge it for the 15.19 release/ | 11:39 |
ssam2 | ? | 11:39 |
pedroalvarez | tiagogomes ^ ? | 11:42 |
tiagogomes | done | 11:43 |
ssam2 | thanks! | 11:45 |
edcragg | stage1 gcc seems to be failing as far as i can tell with 'Switch "--with-arch" may not be used with switch "--with-cpu"' on armv7 | 11:54 |
radiofree | i just compiled gcc on armv7 fine | 11:56 |
edcragg | good to know, dunno what i'm doing wrong then | 11:57 |
radiofree | pastebin the full build log | 11:59 |
radiofree | well, the log from gcc, though at state1 there's not much more | 11:59 |
radiofree | s/state/stage/ | 11:59 |
edcragg | radiofree: thanks, the whole thing is on fs1... fs1:/tmp/rb-out but the end is something like http://paste.baserock.org/yifeniwisi | 12:10 |
ssam2 | I realised that we need to mark baserock:baserock/definitions as using format version 3, before the 15.19 release | 12:12 |
ssam2 | as a way of noting that it requires the install-essential-files.configure extension | 12:13 |
paulsherwood | ssam2: this is too complex, isn't it? too easy to miss stuff, notice later | 12:14 |
ssam2 | I've sent https://gerrit.baserock.org/613 to update definitions.git | 12:14 |
ssam2 | paulsherwood: we didn't miss this. it caused build failures on the Masons, until the version of Morph was updated on them | 12:15 |
ssam2 | paulsherwood: I think in future we should only update the Masons immediately after a release | 12:15 |
ssam2 | so they will spot if someone commits something to master that doesn't build with the previous release | 12:15 |
pedroalvarez | and whenever they break, revert the cause? | 12:15 |
ssam2 | yes, until we make another release | 12:16 |
ssam2 | but I agree it's too complex! | 12:16 |
ssam2 | I also updated the description of V3 in http://wiki.baserock.org/definitions/historical/ to mention install-essential-files.configure | 12:16 |
paulsherwood | ssam2: have you thought any further about the ideas we discussed the other day? i tried them on persia, but i crashed and burned | 12:17 |
ssam2 | they're in my mind. I do think having a bootstrapping method for definitions that was committed to definitions would mean we could stop worring about whether one release could build the next one | 12:18 |
ssam2 | am going to lunch now, will respond to any other comments when i'm back! | 12:18 |
paulsherwood | :) | 12:18 |
*** zoli__ has quit IRC | 12:20 | |
*** zoli__ has joined #baserock | 12:22 | |
*** zoli__ has quit IRC | 12:26 | |
Zara | halp... http://paste.baserock.org/safaqefoqo What am I missing? | 12:32 |
*** fay__ has quit IRC | 12:32 | |
mwilliams_ct | Zara: are you using the isc-dhcp tarball or git repo? | 12:33 |
*** fay_ has joined #baserock | 12:34 | |
pedroalvarez | mwilliams_ct: looks like a git lorry in git.baserock.org | 12:36 |
pedroalvarez | (it has history) | 12:36 |
Zara | it's lorried upstream so I assume a git repo. (the download link is a tar.gz but I think it's been turned into a git repo) | 12:36 |
mwilliams_ct | Zara: pedroalvarez: ok, so the trouble is that the git repository doesn't include all the files the tarball does and those files are needed to compile | 12:36 |
mwilliams_ct | I think jjardon mentioned it might make sense to lorry the tarball as well/instead | 12:36 |
pedroalvarez | oh, indeed, there isn't a bind/ folder | 12:37 |
pedroalvarez | hep | 12:38 |
pedroalvarez | util/bind.sh seems to generate it | 12:38 |
pedroalvarez | hm.. you might be able to use part of that script to generate what you need, but yes, looks like a tarball import might be easier | 12:41 |
*** zoli__ has joined #baserock | 12:44 | |
Zara | I see. It's weird that their git is different from their tarball. | 12:47 |
Zara | how would I do a tarball import? | 12:47 |
Kinnison | Not uncommon for release tarballs to be materially different from tags in revision control | 12:47 |
persia | Even common: several projects have a tarball release procedure that sets up the code for builds in ways that would be annoying to commit to version control, but are essential to be confident of consistent support. | 12:50 |
Zara | I was just surprised that they were so different. | 12:52 |
Zara | the tarball is about 8 times the size, btw, if that matters | 12:52 |
persia | Sometimes upstream build tools encode the mechaism to generate the tarball: `make tarball` or similar. | 12:53 |
persia | IF your environment isn't carefully controlled, you won't end up with the same file content they get when they make a tarball, so upstream may not wish to support you using the results, but you can work around the odditieis. | 12:54 |
edcragg | radiofree: the branch i'm building from was 20 or so commits behind master, rebased and gcc seems to be building | 13:16 |
Zara | had a look around, am still in the dark about how to do a tarball import. sorry if this is documented and I've missed it! (alternatively, if running util/bind.sh will work equally well, how do I put that in the morph? I'm getting 'permission denied' so I assume I need more than just ./util/bind.sh on a line!) | 13:22 |
paulsherwood | sh ./util/bind.sh | 13:26 |
paulsherwood | or chmod a+x ./util/bind.sh | 13:26 |
paulsherwood | Zara: ^^ (maybe, or i may be wrong) | 13:27 |
mwilliams_ct | Zara: I think what pedroalvarez means is to lorry the tarball. if you have a look in the lorries repo, try grepping for "tarball" and you should find some examples | 13:28 |
*** Albert_ has joined #baserock | 13:29 | |
pedroalvarez | I always prefer to go with git whenever possible | 13:32 |
Zara | oh, found it in the trove reference manual. I'd searched 'tarball' and that hadn't come up, so I thought it might not be on there, but it is. | 13:35 |
Zara | paulsherwood: I tried the former and it didn't work. :( will try the latter now! otherwise, will lorry. | 13:36 |
SotK | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/lorry.git/tree/README may help with any other lorry questions | 13:37 |
ratmice__ | wish there was a standard dist-like target that didn't generate the tarball, but the sources that would go into the tarball... | 13:39 |
persia | ratmice__: Unfortunately of limited use to most folk. Even Debian, which frequently regenerates tarballs appreciates ending up with a tarball afterwards. | 13:41 |
paulsherwood | ratmice__: can you expand on that use-case, please? | 13:42 |
* paulsherwood doesn't fully understand, but knows that this needs work | 13:42 | |
ratmice__ | paulsherwood: in general something to make it simpler to create a branch which includes the files that normally go into the EXTRA_DIST automake variable | 13:43 |
persia | Zara: https://sources.debian.net/src/isc-dhcp/4.3.1-6/debian/README.source/ provides some validation that upstream doesn't provide an importable VCS: you are not alone in your frustration. | 13:44 |
ratmice__ | I should dig through automake :) | 13:44 |
paulsherwood | ratmice__: rather you than me :-) | 13:45 |
pedroalvarez | `mkdir bind; cp util/Makefile.bind.in bind/Makefile.in` as a preconfigure command seems to "fix" the configure failure, but other things might break | 13:51 |
pedroalvarez | indeed | 13:51 |
ratmice__ | seems like 'distdir' target may work | 13:51 |
pedroalvarez | it starts complaining for other things when running make | 13:51 |
persia | One of the reasons that tarball generation is separate is that sometimes the set of things required to build something from VCS are much larger than the set of things required to build from the tarball. | 13:52 |
pedroalvarez | Zara: tarball import | 13:53 |
Zara | hehe, was about to say that chmoda+x worked but apparently running that script wasn't enough to create the directory, something was weird, I didn't know what, and I was going to do a tarball import. glad that's the consensus :P | 13:54 |
Zara | new lorry coming soon. | 13:54 |
pedroalvarez | I believe that script tries to fetch repository | 13:56 |
pedroalvarez | I may be wrong | 13:56 |
ratmice__ | persia: indeed, binutils,gdb are a rather extreme case of this there (was/is) a lot of stuff in the repo, simulators, newlib, binutils, gdb, things for generating opcodes, some of which have no release tarball, and some of which have their own tarball thus, there's many tarballs coming from one repo, and a few only ever used by a small subset of developers | 13:57 |
persia | Eclipse belongs on that list :) | 13:58 |
Zara | what should I call this lorry, given that we already have isc-dhcp? I was going to go with isc-dhcp-tarball , but might as well check before I send it out into the world. | 14:05 |
persia | +1 for that nomenclature | 14:05 |
ssam2 | +1 | 14:06 |
*** fay_ has quit IRC | 14:06 | |
ratmice__ | fwiw distdir is even documented :) | 14:08 |
persia | Zara: Does `make distdir` work? | 14:08 |
* ratmice__ notes it doesn't seem to help in this case since the release process seems to go outside of the Makefiles | 14:08 | |
ratmice__ | persia: nope | 14:08 |
persia | :( | 14:09 |
persia | ratmice__: Thanks | 14:09 |
ratmice__ | SUBDIRS=bind ... (where bind.sh generates bind/) so it requires bind.sh to be run before you go through any of that.. | 14:10 |
*** fay_ has joined #baserock | 14:20 | |
Zara | persia: I don't know, didn't try it, made the lorry now instead. (https://gerrit.baserock.org/#/c/614/) | 14:28 |
persia | Zara: No worries: ratmice__ tried it, and it didn't help. | 14:28 |
ratmice__ | I actually didn't try it, but i'm confident it won't work | 14:30 |
ssam2 | radiofree: VT switching works in the x86_32 15.19 release image. (no vga=xx in the kernel commandline) | 14:42 |
ssam2 | also, it'd be really good if we could fix Baserock so VirtIO root disks work! we even have an initramfs now! | 14:43 |
ssam2 | ah, this is because the x86_32 systems don't have an initramfs still | 14:45 |
radiofree | ssam2: yes, it works without vga= | 15:10 |
radiofree | so devel images are fine, however weston/genivi images don't work | 15:10 |
radiofree | as a monstrous hack i was thinking about adding a getty@tty2.service | 15:10 |
radiofree | as long as noone does ctrl-alt-f3 (+) it should work | 15:11 |
* persia fears that level of monstrosity | 15:13 | |
Zara | (oops, didn't realise gerrit updates the patch set every time you edit the commit message. sorry if that just spammed anyone, in future I'll draft changes first!) | 15:14 |
*** mariaderidder has quit IRC | 15:27 | |
Albert_ | Question from an old git: I have a patch for AudioManager which is going into a branch from 6.2, so I have created branch baserock/6.2 as advised. How do I then push this to the right place? Or what do I do next? | 15:38 |
persia | Albert_: Upstream is not likely to take your patches in a timely manner? | 15:39 |
Albert_ | The last tag upstream was a while agao, it like like a bit hase changed sinse then. My patch probably isn't valid any more, but in the meantime... | 15:40 |
ssam2 | I've reworked the 15.19 release notes a bit, here is another darft: http://wiki.baserock.org/releases/baserock-15.19/ | 15:40 |
ssam2 | darft? draft. | 15:40 |
Albert_ | * it looks like a bit ... | 15:41 |
SotK | ssam2: s/cancel the running/cancel the running build/ in the ui changes section? | 15:42 |
radiofree | lots of changes, maybe mention there's now a new way to deploy a jetson? | 15:42 |
Albert_ | Meaning my patch would perhaps not be valid upstream because of changes, but in the meantime, it doesn't build | 15:42 |
ssam2 | radiofree: oh, is the baserock-flash script new for this release? I'll put it in then | 15:43 |
ssam2 | SotK: good spot | 15:43 |
Albert_ | So the question remains: how to get this patch in. I've not done it on BR before | 15:45 |
SotK | ssam2: looks fine other than that | 15:48 |
pedroalvarez | radiofree: regarding the flash script, I just fixed a couple of things on the wiki | 15:51 |
pedroalvarez | also, is taking ages to dd the image | 15:51 |
persia | Albert_: The best method is to land it upstream, and then submit a definitions patch to use it. | 15:53 |
tiagogomes | pedroalvarez did you set a block size? | 15:54 |
persia | Albert_: If that doesn't work, for one reason or another, the backup is to find a merger who is willing to add a local branch of the project on git.baserock.org | 15:54 |
persia | Then you can submit a change to definitions to use the local branch. | 15:54 |
pedroalvarez | tiagogomes: 8M | 15:54 |
pedroalvarez | ( I didn't, the script has that set) | 15:54 |
tiagogomes | pedroalvarez it is not much if is an SSD. You can use iotop to check the transfer rate | 15:55 |
Albert_ | The latter is the way that has been suggested to me. As for changing def'ns, that's my next job. | 15:55 |
Albert_ | Perhaps jonathanmaw or pedroalvarez who've been involved with AudioManager? | 15:56 |
ratmice__ | Albert_: from their blog post 'Release tag set', it seems like they definitely anticipate supporting 2 branches, one of them being stable, so I doubt they would discourage patches. | 15:57 |
radiofree | ssam2: maybe worth pointing out that mesa 10.5.4 is only used on a jetson, vm/x86 systems are still using the older one | 15:57 |
pedroalvarez | tiagogomes: thanks for the suggestion | 15:57 |
*** zoli__ has quit IRC | 15:58 | |
Albert_ | ratmice__, That's helpful. Where was this blog post? | 15:58 |
tiagogomes | iotop would fit nice in devtools | 15:58 |
*** CTtpollard has quit IRC | 15:58 | |
ratmice__ | Albert_: http://projects.genivi.org/audio-manager/blog/2014/07/release-tag-set | 15:59 |
pedroalvarez | tiagogomes: looks like my limit is the usb wire | 15:59 |
ratmice__ | hopefully thats the write AudioManager :) | 15:59 |
ratmice__ | s/write/right/ | 15:59 |
pedroalvarez | 3MB/s | 15:59 |
Albert_ | thanks ratmice__ | 15:59 |
persia | Albert_: Even if you can't land the patch, most Baserock mergers are more likely to approve a local branch if the patch is at least under review upstream. | 16:05 |
Albert_ | Noted. I'm also looking to see if I can get an existing commit from which to branch locally so that there's no need to make upstream changes | 16:06 |
* persia fails to parse that | 16:07 | |
*** a1exhughe5 has quit IRC | 16:10 | |
Albert_ | What I mean is, if there is a commit which I can rely on, and in which the build error I have experienced has been fixed, then I may be able to void having to patch. But which commit, when even tagged commits have broken the build? | 16:14 |
Albert_ | For it is only a build-time error. | 16:14 |
rdale | isn't it because you are using a newer cmake that the audiomanger maintainers? | 16:15 |
Albert_ | That is a factor, but there's more: there is an additional error | 16:16 |
persia | Albert_: Does the tip of the current development branch work? | 16:17 |
Albert_ | For the smake it's just involves a change to a morph file | 16:17 |
persia | If you can fix it in a morph file, you don't need to patch AudioManager, making your life easier. | 16:18 |
Albert_ | It builds but doesn't run, not on AudioManager | 16:18 |
persia | (although submitting things upsteam is always good anyway) | 16:18 |
Albert_ | persia, one fix can be done n a morph file, but not the other. | 16:19 |
Albert_ | It's REALLY simple - just a couple of spelling errors | 16:19 |
Albert_ | I don't know why it wasn't spotted. It kills the build. | 16:20 |
persia | simplicity isn't important, as annoying as that can be. | 16:20 |
*** CTtpollard has joined #baserock | 16:58 | |
*** zoli__ has joined #baserock | 16:58 | |
*** Albert_ has quit IRC | 17:01 | |
*** Albert_ has joined #baserock | 17:01 | |
*** zoli__ has quit IRC | 17:03 | |
*** bashrc_ has quit IRC | 17:06 | |
ssam2 | radiofree: good point on mesa. thanks | 17:06 |
*** Krin has quit IRC | 17:07 | |
*** sambishop has quit IRC | 17:10 | |
*** CTtpollard has quit IRC | 17:12 | |
ssam2 | jjardon, radiofree: what's the deal with mesa-common-vm ? | 17:13 |
ssam2 | it's something to do with 3D drivers in VMs but I don't understand it enough to write about it in the release notes | 17:13 |
radiofree | gallium-egl | 17:15 |
ssam2 | ok, so: | 17:16 |
ssam2 | Jetson systems now use Mesa 10.5.4. x86 systems still use a patched | 17:16 |
ssam2 | version of 10.3.7, so that gallium-egl is available: that driver is | 17:16 |
ssam2 | needed to use Weston in a VM, and it is removed in 10.4. | 17:16 |
pdar | I started to deploy a base-system-x86_64-generic.morph at 16:25 and its hanging at the "installing extlinux" stage. How could Igo about finding out whats wrong? | 17:17 |
radiofree | ssam2: looks good | 17:17 |
ssam2 | hmm, except the 10.4 release notes don't mention removal of gallium-egl | 17:17 |
ssam2 | i'll leave it at 'so that gallium-egl is available: that driver is needed to use Weston in a VM.' | 17:19 |
pedroalvarez | pdar: hard to say | 17:22 |
pedroalvarez | pdar: that should take few seconds | 17:22 |
pdar | Yep, I noticed the problem when testing something else so I thought I'd check a simpler system, then forgot about it.. | 17:24 |
*** sambishop has joined #baserock | 17:35 | |
*** gary_perkins has quit IRC | 17:35 | |
*** gary_perkins has joined #baserock | 17:35 | |
*** gary_perkins has quit IRC | 17:39 | |
pdar | oh, just rebooted my baserock and it done worked. Hoorah o/ | 17:39 |
*** tiagogomes has quit IRC | 17:48 | |
*** edcragg has quit IRC | 17:52 | |
ssam2 | Baserock 15.19 is released! | 18:15 |
ssam2 | The word 'baserock' appears 39 times in the release notes | 18:15 |
*** ssam2 has quit IRC | 18:23 | |
*** Albert_ has quit IRC | 18:29 | |
*** zoli__ has joined #baserock | 18:29 | |
*** zoli__ has quit IRC | 18:34 | |
*** lachlanmackenzie has quit IRC | 18:35 | |
*** rdale has quit IRC | 18:57 | |
*** zoli__ has joined #baserock | 19:30 | |
*** zoli__ has quit IRC | 19:35 | |
paulsherwood | w00t! :) | 19:43 |
*** zoli__ has joined #baserock | 21:01 | |
*** zoli__ has joined #baserock | 21:01 | |
*** zoli__ has joined #baserock | 21:02 | |
*** zoli__ has joined #baserock | 21:03 | |
*** zoli__ has joined #baserock | 21:04 | |
*** sambishop has quit IRC | 21:19 | |
*** zoli__ has joined #baserock | 22:20 | |
*** zoli__ has quit IRC | 22:24 | |
*** zoli__ has joined #baserock | 22:48 | |
*** zoli__ has quit IRC | 23:36 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!