| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 01:00 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 01:00 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 01:00 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 01:00 | |
| *** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 08:00 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer] | 08:00 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:14 | |
| *** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Remote host closed the connection] | 08:22 | |
| *** zoli_ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has joined #baserock | 08:42 | |
| *** zoli_ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has quit [Changing host] | 08:42 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 08:42 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 08:43 | |
| *** zoli_ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has joined #baserock | 08:43 | |
| *** zoli_ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has quit [Changing host] | 08:43 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 08:43 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:43 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:01 | |
| perryl | pedroalvarez: i'm having trouble connecting to my firehose machine on DC, is there an issue with VMs or has it lost its floating IP? | 09:04 |
|---|---|---|
| persia | I believe floating IPs changed, but I may be misinterpreting. Did it have a logical name? | 09:05 |
| perryl | IIRC, it was just firehose | 09:07 |
| perryl | ssam2 was the one who set it up | 09:08 |
| persia | firehose.baserock.org? | 09:10 |
| * perryl isn't sure | 09:11 | |
| perryl | it may be worth waiting for ssam2 to arrive and double checking with him | 09:11 |
| persia | Heh, possibly. Unless you want to spend time querying DNS to see if you can figure it out first (dig can be fun). | 09:12 |
| pedroalvarez | perryl: sorry about that, I'll give you now the new IP | 09:16 |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:16 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:18 | |
| perryl | sorted, thanks pedroalvarez! | 09:18 |
| * pedroalvarez checks other .baserock.org urls | 09:19 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:25 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:35 | |
| Mode #baserock +v ssam2 by ChanServ | 09:35 | |
| pedroalvarez | just discovered that lorry controller is failing to lorry because it cannot resolve (e.g.) github.com | 09:45 |
| pedroalvarez | I see that the nameserver specified in its resolv.conf differs from other machines pluged in the same network | 09:46 |
| pedroalvarez | I don't know why this is happening | 09:51 |
| persia | I'd suggest fixing for now, and then troubleshooting in a test environment. | 09:51 |
| pedroalvarez | but, won't the resolv.conf be regenerated? | 09:52 |
| persia | Given the recent migration, I presume there to be data available to allow easy generation of the test environment, although I may be mistaken. | 09:52 |
| persia | Depends on the system configuration. What environment? How is resolv.conf being populated now? | 09:52 |
| pedroalvarez | persia: you are right, easy to prepare a test environment | 09:52 |
| persia | Ah, good. So we can have our cake and eat it too :) | 09:53 |
| * persia hugs virtualisation | 09:53 | |
| pedroalvarez | systemd-resolved is what creates resolv.conf | 09:55 |
| persia | And how is that configured? How does this configuration differ from instances that don't have the issue? | 09:56 |
| tiagogomes | hey ssam2, do you remember vaguely when you disabled the C++ stuff for binutils? | 09:58 |
| pedroalvarez | ok, differences between a sane system and git.baserock.org: In the sane one /etc/resolv.conf is a symlinkt to /etc/run/systemd/resolve/resolv.conf. And in g.b.o this is a static file. | 09:58 |
| ssam2 | when? will have been about 2 years ago | 09:58 |
| ssam2 | if I didn't leave a comment in the morphology or the commit message, shoot me | 09:59 |
| ssam2 | looking at the morphology, I don't see any C++ stuff being disabled, what do you mean? | 10:00 |
| pedroalvarez | persia: looks like if you modify /etc/resolv.conf with a static file, systemd-resolved won't try to replace it with the symlink to the autogenerated resolv.conf | 10:00 |
| persia | pedroalvarez: Aha, in that case, make it a symlink, and it ought be good. | 10:00 |
| pedroalvarez | yes. I've also double checked that the file to be symlinked is sane | 10:01 |
| persia | That's best behaviour for systemd-resolved: it lets people with specialised needs statically configure the file in the traditional way. | 10:01 |
| pedroalvarez | indeed | 10:01 |
| ssam2 | i'm wondering what the best version of Morph would be to build baserock-14.46 | 10:02 |
| persia | How about the version used in 14.46? | 10:02 |
| ssam2 | would make sense, but it's not tagged | 10:02 |
| * persia queries | 10:02 | |
| ssam2 | I can dig and find the sha1, but the fact that it's not tagged suggests that it's not so simple | 10:03 |
| persia | Why? | 10:03 |
| tiagogomes | ssam2, you disabled it in configure.in and configure e72775a. I was just wondering if you hacked configure manually or auto-generated it from configure.in | 10:03 |
| tiagogomes | ssam2, the reason that I am asking is that I tried to regenerate it but I got: configure.ac:34: error: Please use exactly Autoconf 2.64 instead of 2.69. (no retro-compatibility ¬ ¬) | 10:04 |
| ssam2 | tiagogomes: I will have generated it using autoconf | 10:04 |
| ssam2 | we have updated autoconf since then, probably | 10:04 |
| ssam2 | persia: definitions is tagged, so I can use the version of Morph listed in the baserock-14.46 tag of definitions | 10:05 |
| tiagogomes | so or either I downgrade autoconf or I try to manually edit configure | 10:05 |
| ssam2 | just seems strange not to be tagging releases of Morph | 10:05 |
| ssam2 | tiagogomes: I'd advise against trying to edit configure | 10:05 |
| ssam2 | at least if you generated it with autoconf you can blame problems that you have on autoconf, not yourself | 10:05 |
| Kinnison | ssam2: we haven't tagged morph for some time (at least not as baserock releases) | 10:06 |
| persia | ssam2: As I've said before, I think morph ought have a release model, even though I think definitions should not. Getting there is confusing. | 10:06 |
| persia | Anyway, 384dc8d2eb9222746085f0274c625eb163eda88a should work | 10:06 |
| franred | ssam2, I though we aim to use latest version of morph always... but this means that we need backward compatibility, though | 10:07 |
| ssam2 | tiagogomes: I see what you mean now | 10:07 |
| ssam2 | tiagogomes: does latest binutils still use autoconf 2.64? that's pretty unfortunate if so | 10:08 |
| tiagogomes | ssam2, it seems easier to change configure, than downgrade autoconf. This will would be temporary because when we have a bootstrap c++ compiler, I won't need to disable the c++ stuff in bintutils | 10:09 |
| ssam2 | your funeral :) | 10:09 |
| persia | Can the autoconf stuff be upgraded to 2.69? | 10:10 |
| persia | Or does upstream have another target version they might like? | 10:10 |
| tiagogomes | :'( | 10:10 |
| persia | Do any of the distros have patches that build with alternate autoconf? | 10:11 |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:12 | |
| ssam2 | tiagogomes: remember you don't have to downgrade autoconf in Baserock | 10:13 |
| ssam2 | just install autoconf 2.64 from a release tarball, run it, and commit the result | 10:13 |
| ssam2 | the whole point of using a tarball is that you don't need autoconf (or any other autotool) at build time, because 'configure' exists and is committed to git | 10:14 |
| tiagogomes | on configure.ac: AC_PREREQ(2.64) | 10:14 |
| tiagogomes | Maybe I could try to change AC_PREREQ(2.69), but that could break thinks in other ways | 10:14 |
| ssam2 | I believe you can parellel-install different versions of autoconf on a machine, by setting a configure option when you configure autoconf | 10:15 |
| tiagogomes | that's a good idea ssam2 | 10:15 |
| Kinnison | I think that'd imply updating devel systems to have both first | 10:15 |
| Kinnison | since early stages are built using the enclosing devel system | 10:16 |
| ssam2 | Kinnison: not at all, because everything is built from tarballs at that point | 10:16 |
| ratmice__ | haven't found the patch (e72775a) but, i believe you should be able to just --disable-dirname for any directory that uses c++ in the binutils root? | 10:16 |
| persia | ssam2: Yes, but unless you actively dirty the cache, you can't cause cache.baserock.org to do that sort of hack. | 10:16 |
| Kinnison | ssam2: Oh cool | 10:17 |
| franred | tiagogomes, why don't try to update the autoconf prereq to 2.69 and fix errors and submit the change to upstream? (talking always if you have time) | 10:17 |
| ssam2 | persia: i don't understand how cache.baserock.org has anything to do with this | 10:17 |
| ssam2 | ratmice__: that's interesting! | 10:17 |
| persia | ssam2: Ah, right, you're just changing source so that you don't need the tools to be present. I was thinking about the case where the tools were being used as part of a live build. | 10:18 |
| tiagogomes | ratmice__, e72775acb5326e948d2542622afb9bed4fd67c15 in git://git.baserock.org/delta/binutils-redhat.git | 10:18 |
| ratmice__ | in general gcc/binutils use a specific version of autoconf because if everyone used whatever version of autoconf there would be endless churn/large diffs whenever someone changes it, and it keeps everyone running the same version, just be glad it uses a release version :D at one time it did not :) | 10:19 |
| ssam2 | ratmice__: is --disable-dirname a binutils ./configure flag? I don't see it (but I have an old clone of binutils) | 10:19 |
| tiagogomes | I was wondering the same, I couldn't find it either | 10:20 |
| tiagogomes | Not even in the newest repo | 10:21 |
| ratmice__ | s/dirname/gdb/ or s/dirname/ld/, (or in this case likely --disable-gold) i forget where it is, I didn't know about it either until they switched to git | 10:23 |
| * ratmice__ hopes he is remembering correctly :) | 10:23 | |
| ssam2 | oh, so e.g. if only 'gold' uses C++ we can just --disable-gold ? | 10:23 |
| ssam2 | that's worth investigating | 10:23 |
| ratmice__ | yeah | 10:23 |
| ssam2 | as long as we don't end up with no linker or something :) | 10:24 |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 10:24 | |
| tiagogomes | ssam2 that wouldn't be good | 10:24 |
| tiagogomes | ah, they use cc for c++ files. I was looking for cpp, c++, hpp | 10:25 |
| ratmice__ | ahh, so i see this is actually in ld/configure disabling the c++ test cases, so it may not in fact help at all | 10:28 |
| * Kinnison says rude words about nested autoconf | 10:29 | |
| * richard_maw dislikes it because the result is usually that the nested ./configure scripts are run when you use `make`, rather than when you run the top-level ./configure | 10:30 | |
| * ratmice__ dislikes it because --help=recursive outputs a bunch of junk over and over | 10:34 | |
| Kinnison | in general, 'recursive $BUILD_FOO' is a bad plan IMO | 10:36 |
| persia | Most of the reasons people do it is because they don't understand the loop instructions in their build tool. | 10:37 |
| persia | Then again, most of the reasons there are so many build tools is because people don't understand their build tool. | 10:37 |
| paulsherwood | that certainly explains why i started doing that foyr ybd :) | 10:37 |
| ratmice__ | I'll admit i like the concept behind binutils build tree specifically, where you have a top-level directory it just builds everything underneath it, so you can add and remove modular components | 10:37 |
| ratmice__ | but ideally the top-level directory should be stupid of the components underneath it, and etc, etc... | 10:38 |
| persia | For make, I'd prefer to have a text file named "components" containing a list of the components I wanted to enable. | 10:38 |
| persia | I'm not as familiar with other build tools, but I presume they can support a similar construct. | 10:38 |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:39 | |
| franred | I need a repo to compile another repo, what is the neatest way to add it without having to copy the repo into the system and them copy it to the build directory for the second repository to compile this latest one? | 10:41 |
| franred | s/to compile/for compiling/ | 10:42 |
| ssam2 | not sure there is a neat way ... how big is it? | 10:50 |
| franred | ssam2, I need the apache portable runtime to build apache httpd | 10:51 |
| franred | not sure how big it is :S | 10:51 |
| persia | Is there a set of artifacts from the apr that can be considered a "chunk" to be a build-dependency of apache? | 10:52 |
| persia | That's the most semantically compatible way to do it, but it may be messier than that. | 10:52 |
| franred | persia, Im afraid apache-httpd needs apr source code | 10:55 |
| persia | All of it? | 10:56 |
| persia | You could make a chunk that contains a snapshot of a repo content, but I'd be surprised if that was the best way. | 10:56 |
| persia | How do the distros do it? | 10:57 |
| persia | At least Debian seems to build apr separately, and then build apache against it | 10:59 |
| persia | https://sources.debian.net/src/apr-util/1.5.4-1/debian/ | 10:59 |
| persia | http://sources.debian.net/src/apache2/2.4.10-9/debian | 10:59 |
| franred | persia, thanks, I will give a go :) | 11:00 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 11:00 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:01 | |
| persia | If anyone knows how to get similar information for how Fedora builds things, it would be useful to look at both techniques (I've forgotten most of the right Fedora URLs) | 11:01 |
| ssam2 | http://pkgs.fedoraproject.org/ | 11:09 |
| persia | So http://pkgs.fedoraproject.org/cgit/apr-util.git/tree/apr-util.spec | 11:13 |
| persia | But I can't find apache2 there: it may just be me. | 11:13 |
| ssam2 | I think it's called 'httpd' in Fedora | 11:13 |
| persia | Also not found in that cgit search interface | 11:14 |
| ssam2 | ah, not sure then | 11:14 |
| radiofree | http://pkgs.fedoraproject.org/cgit/httpd.git/tree/?h=f21 ? | 11:15 |
| persia | radiofree: Thanks! | 11:16 |
| persia | franred: ^^ | 11:16 |
| jjardon | Hi, current NetworkManager requires readline6 but baserock only have readline5 for (I think) license reasons. What would be the best way to proceed here? | 11:16 |
| persia | Do we have any information about which systems have license restrictions? | 11:17 |
| jjardon | (readline is in core because is a dependency of cpython) | 11:17 |
| radiofree | genivi system, no gpl3 | 11:17 |
| persia | I suspect the best way is to fork the strata, so some systems get one, and others get the other. | 11:17 |
| persia | Then we split core into core-gpl2 and core-gp3? | 11:17 |
| persia | s/gp3/gpl3/ | 11:18 |
| radiofree | there's no network manager in genivi systems right? | 11:18 |
| jjardon | persia: that would mean fork everything on top of core ... | 11:18 |
| radiofree | couldn't you just put a newever version of readline in the network manager strata? | 11:18 |
| jjardon | radiofree: no, they use conman | 11:18 |
| radiofree | s/newever/newer | 11:18 |
| radiofree | can you --disable-cli or something? | 11:18 |
| radiofree | (in NM) | 11:18 |
| persia | jjardon: How much commonality is there between the gpl2-only and gpl3-ok systems? I suspect that after a short time, we don't need to fork anymore. | 11:18 |
| jjardon | radiofree: no, seems its a hard dependency. | 11:21 |
| pedroalvarez | radiofree's suggestion of adding readline in network manager strata sounds good to me | 11:22 |
| jjardon | persia: all the current systems in definitions master are gpl2-only, I think | 11:22 |
| persia | I don't like the idea of having two different readlines on network-manager enabled systems. | 11:22 |
| persia | I'd rather see python done with the same readline. | 11:22 |
| persia | jjardon: But are they all required to be so? | 11:22 |
| jjardon | yeah, me neither, but if its the only solution Id use it | 11:22 |
| radiofree | it's better than doubling the number of strata | 11:22 |
| jjardon | persia: no, only genivi AFAIK | 11:23 |
| persia | I think that only the GENIVI systems are required to be gpl2-only, and suspect that we only have to fork a few strata to achieve that. | 11:23 |
| pedroalvarez | persia: I also liked your suggestion of a core-gpl3, but then all the artifacts above core will differ | 11:23 |
| persia | pedroalvarez: Yes, but how many artifacts do we need in both GENIVI and non-GENIVI systems? | 11:23 |
| jjardon | thats why I have to put coreutils is in a differect stratum, dor example | 11:23 |
| radiofree | multimedia, wayland, graphics, input, mesa, weston (audio? connectivity?) | 11:24 |
| pedroalvarez | should the genivi definitions be a fork of definitions? | 11:25 |
| persia | That might be easier, and helps ensure the tooling can usefully support multiple definitions repos. | 11:26 |
| persia | Since we anticipate every user having a separate definitions repo, this is a key feature. | 11:26 |
| radiofree | pedroalvarez: that sounds like a good idea | 11:26 |
| ssam2 | pedroalvarez: that's a really good idea ! | 11:26 |
| persia | The only detriment is that if work is done that can benefit both definitions, it may need to be duplicated. | 11:27 |
| ssam2 | merging improvements from baserock/definitions.git into downstream forks of definitions.git is a problem we need to solve | 11:28 |
| jjardon | Id like that, because I personally do not care about genivi systems, but that would mean a lot of duplicated strata everywhere | 11:28 |
| persia | The other direction as well, to ease sharing updates upstream. | 11:28 |
| ssam2 | I'm on a project currently where one of the things we need to do is solve the former problem (at least, make things easier). The latter would be nice too. | 11:29 |
| ssam2 | currently `git merge baserock/master` presents a comically unsolvable merge conflict :) | 11:29 |
| ssam2 | (assuming `baserock` is a remote that points to git://git.baserock.org/baserock/baserock/definitions) | 11:30 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 11:30 | |
| paulsherwood | ssam2: if i may ask, how many commits are in the fork branch? | 11:31 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:32 | |
| ssam2 | paulsherwood: I've no idea, but 9+ months of work | 11:32 |
| ssam2 | so probably lots | 11:32 |
| paulsherwood | ok, that's enough of an answer :) | 11:32 |
| jjardon | ok, I will go for the "readline6 in NetworkManager stratum" Thanks for the feedback! | 11:34 |
| perryl | ls | 11:35 |
| persia | radiofree: pedroalvarez: Do you feel comfortable forking defintions from before that patch lands to maintain GENIVI? | 11:37 |
| pedroalvarez | well, maintaining a fork, will be a bit more effort, but I think is something that we need to face | 11:39 |
| persia | One of the areas of complication is CI: how do we want to handle CI for this? | 11:41 |
| persia | I know of another project that is considering using Baserock for musl-based systems that wants to be upstream: do we think they should have yet another fork, or does that present different problems to definitions? | 11:41 |
| persia | (the same applies for folk who might want to use ulibc, but I don't have any special knowledge there) | 11:42 |
| ssam2 | persia: different question, I think (although it might have the same answer, for now) | 11:43 |
| pedroalvarez | I'm now thinking that if the genivi systems were in a fork, then I wouldn't be able to use the current infra to build them | 11:43 |
| ssam2 | pedroalvarez: why? | 11:44 |
| ssam2 | morph checkout baserock:baserock/genivi master | 11:44 |
| pedroalvarez | ssam2: yeah, but my current infra has distbuild networks | 11:44 |
| persia | So? | 11:44 |
| pedroalvarez | so I have to reconfigure them to build from genivi, and then switch them back to continue doing CI? | 11:45 |
| persia | ssam2: Yes, changing readline vs. the C library is different, but both are very deep changes, so have the same class of issues. | 11:45 |
| persia | pedroalvarez: Why? | 11:45 |
| ssam2 | pedroalvarez: baserock:baserock/definitions isn't hardcoded anywhere :) | 11:45 |
| pedroalvarez | yeah, that's true and good news to me | 11:46 |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 11:51 | |
| tiagogomes | I am having build failures when compiling binutils 2.25. A comment found in the web says that binutils needs flex to compile. But flex is not on build essential. Linux From Scratch seems to not need flex to compile binutils. Anyone has any insight about this? | 11:54 |
| persia | How does LFS compile binutils? | 11:55 |
| persia | The current LFS book says to use binutils 2.17, and that "versions greater than 2.24 are not recommended"), so it may not be useful to rely on LFS as a source for binutils 2.25 integration. | 11:58 |
| tiagogomes | persia the online documentation has intructios for 2.25 | 11:59 |
| tiagogomes | but flex on LFS is built after the final build of binutils | 12:00 |
| tiagogomes | in Baserock happens the same | 12:00 |
| persia | You're better at finding LFS docs than I :) | 12:00 |
| persia | Maybe there is an alternate target of some sort that doesn't need flex? | 12:01 |
| tiagogomes | I am getting this error: http://paste.baserock.org/fanaditoye | 12:01 |
| persia | Maybe it is special configure arguments, or similar? | 12:01 |
| persia | How are sysinfo.c and syslex_wrap.c being generated? | 12:02 |
| tiagogomes | Neither baserock or LFS seems to use a configure option to disable flex requirement | 12:03 |
| bwh | I don't see how you could avoid a dependency on flex | 12:03 |
| bwh | binutils does kind of need to parse stuff | 12:03 |
| ssam2 | tiagogomes: probably the generated flex files are present in the tarball | 12:04 |
| persia | That seems the easiest bootstrap workaround. | 12:04 |
| ssam2 | but the makefile will try to rebuild them if the timestamps of the generated files are older than the timestamps of the flex input files | 12:04 |
| tiagogomes | yep | 12:04 |
| ssam2 | I've no idea why you get "multiple definition of `main'" though! | 12:05 |
| persia | And git doesn't preserve timestamps, so lorried tarballs are annoying. | 12:05 |
| ssam2 | persia: morph resets all timestamps when checking out a source tree, to work around that problem | 12:05 |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 12:06 | |
| persia | ssam2: How does morph resetting everything work around git resetting everything? | 12:06 |
| ssam2 | it does so after running `git checkout` | 12:06 |
| ssam2 | I assume the code was added because git resetting everything wasn't working right. I've never checked this assumption. | 12:06 |
| persia | Yes, but 1) how is that useful, and 2) why does this work around the issue? | 12:07 |
| persia | Unless morph has instructions to only update timestamps for generated files, it causes all the same problems. | 12:07 |
| ssam2 | no, if the timestamps are all the same then nothing is newer than anything else | 12:07 |
| ssam2 | it's always worked fine for me, so I've never dug into it to work out why it works | 12:07 |
| persia | But git sets all the timestamps to be the same, doesn't it? | 12:07 |
| ssam2 | maybe | 12:07 |
| persia | I think it's a no-op that coincidentally worked for some sources because of file ordering. | 12:08 |
| ssam2 | that wouldn't surprise me. but I'm not going to start fixing something that isn't broken until I see it break :) | 12:08 |
| persia | If not, it's deep magic, and morph probably shouldn't do it (e.g. setting timestamps of all lex files, then all C files, etc.) | 12:09 |
| persia | tiagogomes: Is your failure in a morph-controlled biuld? | 12:09 |
| tiagogomes | persia correct | 12:09 |
| ssam2 | but http://paste.baserock.org/fanaditoye seems totally unrelated to timestamps | 12:10 |
| ssam2 | or are we talking about different failures ? | 12:10 |
| persia | I agree, which is why I asked how they were generated. | 12:11 |
| persia | In the event that this is broken because morph is being silly, we should fix that. If not, we can let morph be silly longer. | 12:11 |
| tiagogomes | syslex.c and sysinfo.c are present in the tarball, so flex and bison shouldn't be needed | 12:11 |
| persia | Do they both have main()? | 12:13 |
| tiagogomes | context: this happens building the final version of binutils, (but still using and older binutils on stage1 and stage2) | 12:13 |
| tiagogomes | but stage1-bintutils built fine | 12:14 |
| persia | Do we have an earlier-stage flex at this point? | 12:14 |
| tiagogomes | no | 12:15 |
| pdar | Hiya, Im having trouble starting a baserock vm in virtualbox after following the instruction here: http://wiki.baserock.org/guides/vm-setup/#index4h2 | 12:16 |
| pdar | I get the following error: http://paste.baserock.org/oyevuwupoh | 12:16 |
| tiagogomes | maybe building binutils 2.25 with 2.25 will fix the problem, but I don't know how | 12:16 |
| pedroalvarez | pdar: have you tried `modprobe vboxnetflt`? | 12:16 |
| pdar | I did, and the suggestions here: http://wiki.baserock.org/common-errors/#index4h2 | 12:17 |
| pdar | and it is still kaput :( | 12:17 |
| franred | pdar, have a look at your ipaddr or ifconfig and check that your ethernet name is eth0 or another | 12:18 |
| tiagogomes | pdar or be lazy and change your network connection to bridge or NAT | 12:20 |
| jmacs | We can't, host-only networking has to work for this project | 12:20 |
| tiagogomes | boo! | 12:20 |
| pdar | franred: it is called em1 | 12:21 |
| persia | Not en1? | 12:21 |
| pdar | persia: yep em1 | 12:22 |
| franred | pdar, replace eth0 by em1 | 12:22 |
| tiagogomes | pdar, have you tried file -> preferences -> network -> and then add a host only network | 12:22 |
| persia | Interesting. I've not seen that before. | 12:22 |
| franred | pdar, in the previous workaround | 12:22 |
| pdar | franred: I have tried that too and nada | 12:23 |
| franred | ummm odd | 12:23 |
| kejiahu | Hi, any suggestion on why 'Failed to start Remount Root and Kernel File Systems.' happens during boot? | 12:29 |
| Zara_ | Is there a simpler gem we could use as the basis for the rubygems import tool tutorial? I think it'd help to have a quickstart tutorial- so people can get to grips with the tool itself, and then a different, more detailed tutorial for rails (or another difficult gem). Or a 'common errors' section just for the importer! | 12:30 |
| Zara_ | I feel like we'll be adding things to this tutorial indefinitely, otherwise, because many gems need slightly different approaches. | 12:33 |
| Zara_ | It might even be worth it to have a table of gems and their respective approaches, though that's probably overkill, and could get out of date fast. :P | 12:33 |
| persia | Can the approaches be generalised to help make it easier to use? | 12:34 |
| persia | I also seem to remember hearing some complaints about the number of strata produced: are there ways we can change things to be easier to use that also simplify the documentation? | 12:35 |
| rdale_ | i have got quite a lot of gems built in order to get one of codethink's internal apps working - we could have a look at exactly what build commands i've needed to use and see if it could be automated more | 12:35 |
| persia | That sounds like a good strategy | 12:35 |
| Zara_ | persia: some can, but I think most things that can be completely generalisable can be automated, which then means you don't need the tutorial for the manual steps. | 12:35 |
| SotK | I want to send some patches, but don't have access to the machine which has my ssh key on it. Would people prefer I just don't push the branches until tomorrow, or for me to put them up on github? | 12:35 |
| persia | Although I'm a fan of documentation, I think I prefer when the documentation is short. | 12:36 |
| persia | SotK: There's been a few patchsets sent without branch references, and others sent with github references, so you have precedent for both. | 12:36 |
| pedroalvarez | jjardon: OOI, where you looking at the upgrade of systemd to 218? IIRC it wasn't a trivial upgrade? | 12:37 |
| pedroalvarez | s/where/were/ | 12:37 |
| Zara_ | persia: I like a lot of documentation, but not too much on any single page. :) I think that when it gets too long, it's a sign that either things are too complicated, or large sections are irrelevant to any single user. | 12:38 |
| persia | Or that the author has become distracted by writing the authoritative book, rather than providing tutorial and reference information for the code. | 12:38 |
| jjardon | pedroalvarez: it failed to compile with a weird compilation error | 12:39 |
| Zara_ | heh, I think the tutorial in this case is straightforward and well-written, though I came across some horrors on my Philosophy degree... | 12:40 |
| petefoth | or that the author is unclear about *why* they are writing what they are writing and *who* it is intended for | 12:40 |
| persia | petefoth: Better point. Sometimes it is correct to write the authoritative book. | 12:41 |
| petefoth | persia: indeed. But probably not today :) | 12:41 |
| pedroalvarez | jjardon: thanks for the info. | 12:41 |
| * paulsherwood finds 'no bootable medium found' on latest build-system image from d.b.o? | 12:52 | |
| paulsherwood | pdar: is this similar to your problem? | 12:52 |
| ssam2 | kejiahu: does the journal have any useful info? do you have a weird /etc/fstab? do you have weird kernel commandline arguments that might effect the root disk ? | 12:52 |
| ssam2 | re. the import tool tutorial, it's certainly not ideal | 12:53 |
| pedroalvarez | paulsherwood: :( | 12:53 |
| ssam2 | it tries to be both an introduction plus an in-depth 'all you need to know for rubygems' guide | 12:53 |
| paulsherwood | oh, actually. it's probably me being an idiot | 12:53 |
| ssam2 | if we had time to rewrite it into two separate documents, I'd be happy | 12:53 |
| paulsherwood | pedroalvarez: pleae hold, i think it's me | 12:54 |
| jjardon | mmm, my system is trying to build curl, is cache.baserock.org not working? | 12:56 |
| Zara_ | ssam2: Yeah, I'd prefer two separate documents; if someone can give me an example gem that can be used for an simple guide then I could make (or at least start!) a quickstart guide today. | 12:56 |
| Zara_ | otherwise I can look around for an example gem, but I suspect that'd take longer. | 12:57 |
| jjardon | (I didnt change anything in core or lower strata) | 12:57 |
| persia | What cache key did your curl attempt generate? | 12:58 |
| persia | Comparing that to the recent value from a mason log might give some guidance. | 12:58 |
| jjardon | persia: how I check that? | 12:59 |
| persia | Yours should have appeared in your morph log just before the build content (in a failure to fetch message), I think. | 13:00 |
| persia | I thought mason.baserock.org would work, but it doesn't. | 13:01 |
| persia | Maybe someone else knows the right hostname (as I'd like to know it as well) | 13:01 |
| kejiahu | +ssam2, seems caused by /etc/fstab, will check further, thank you. | 13:03 |
| radiofree | kejiahu: oooh | 13:03 |
| radiofree | if you're using the jetson image | 13:04 |
| radiofree | i think you'll need to delete /etc/fstab | 13:04 |
| radiofree | it's btrfs specific | 13:04 |
| kejiahu | radiofree, yes, that's what I found follow sam's suggestion.. | 13:05 |
| pedroalvarez | jjardon: I was debugging it before reading your comment about cache.b.o | 13:12 |
| pedroalvarez | jjardon: it looks ok now | 13:13 |
| jjardon | pedroalvarez: yep, morph stop building and fetching from the cache automatically :), thanks! | 13:32 |
| *** simonh_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:40 | |
| *** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 13:40 | |
| simonh_ is now known as mauricemoss_ | 13:55 | |
| straycat | ssam2, I think it may be worth making the comparison carried out in lorryset more flexible, one other reason I've had problems adjusting lorries is because the importer is comparing the strings using ==, rather than a case-insensitive comparison that also treats - and _ as equivalents | 13:59 |
| straycat | yeah let's do this | 14:07 |
| ssam2 | Zara: not sure about what Gem would be best, I picked Rails because it had a suitable number of complications for an in-depth tutorial :) (and because it's a well-known thing) | 14:51 |
| ssam2 | straycat: i'm not sure what you mean | 14:52 |
| ssam2 | which strings? | 14:52 |
| straycat | ssam2, I think the importer should optionally provide a comparison function for comparing package names | 14:52 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 14:53 | |
| straycat | when calling enable_importer | 14:53 |
| ssam2 | yes, makes sense (after in-person discussion) | 14:56 |
| tiagogomes | I am increasingly confused with my binutils problem. The Internet says in more than one place that the fix is to install flex; but both baserock and LFS don't install flex as part of the toolchain | 14:56 |
| straycat | heh | 14:56 |
| ssam2 | is the problem that the generated flex files in the tarball are out of date? | 14:56 |
| ssam2 | the .c files generated by flex, rather | 14:57 |
| radiofree | does the latest release of baserock have the systemd upgrade? | 14:58 |
| ssam2 | no, but there's a release being done tomorrow that will have it | 14:59 |
| ssam2 | and I believe the release is ready already, if you need it for something .. | 14:59 |
| tiagogomes | ssam2, looking at the modification times, it seems so. I'll try to see how binutils generates them | 15:00 |
| radiofree | ok, thanks ssam2 | 15:01 |
| ssam2 | tiagogomes: it's really strange that building from the binutils release tarball doesn't work | 15:01 |
| ssam2 | it suggests either we're doing something wrong, or the binutils release tarball is broken | 15:01 |
| ssam2 | you can make your own tarball with `make dist` and try that, perhaps | 15:01 |
| Zara_ | ssam2: I think we should definitely keep rails as an in-depth tutorial, but possibly use a gem with fewer complications as an intro to the rubygems tool. Otherwise, someone completely new to the tool and new to baserock won't know if they've made a mistake, or if the instructions they're following aren't sufficient. That leads to a lot of repeating steps, starting from scratch, etc. | 15:03 |
| tiagogomes | ssam2 I will try that, it seems that the release is broken, because stage1-binutils and stage2-binutils compile fine; as they use flex from the host, they don't use the generated C files | 15:03 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 15:04 | |
| ssam2 | zara: ok, but remember that each tutorial adds a cost to changing the import tool | 15:05 |
| ssam2 | there are a fair few changes that would improve the tool, and if each change requires updating 3 tutorials then it makes it a bit of a pain... | 15:07 |
| Zara_ | ssam2: yeah, I think whatever we do there's going to be more maintainence. :( I'd really like it if we could get a guinea pig and see if it's just me being dense, tbh. | 15:07 |
| ssam2 | I'm not trying to stop you from doing stuff, I just don't want to have out of date tutorials :) | 15:07 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:08 | |
| petefoth | The commandment whxcih says 'Code LESS: every line creates a work-chain. Code is a liability, not an asset' applies equalyy to to documentation. As do all the other commandments sice documentation is a form of software. We should only produce the dpocumentation that the spec says is required. | 15:10 |
| petefoth | Oh wait - there isn't a spec... | 15:10 |
| petefoth | See commandment #17 | 15:10 |
| Kinnison | You may need to link that for anyone here who isn't a Codethinker | 15:11 |
| petefoth | That public at http://www.codethink.co.uk/commandments.html | 15:11 |
| Kinnison | :-) | 15:12 |
| tiagogomes | ssam2, it sucks a but having to use generated C files. Do you think it would be hard to bring flex and bison to build essential | 15:13 |
| ssam2 | I don't think it sucks that much, it's what every other distro does | 15:13 |
| Kinnison | tiagogomes: I think that'd imply bringing autoconf, automake etc down into b-e if it's not there already | 15:13 |
| ssam2 | we're the weird ones for building stuff from git instead of tarballs | 15:13 |
| Kinnison | tiagogomes: which is a big can'o'worms thanks to m4 and perl | 15:14 |
| ssam2 | well, flex and bison can be built from tarballs too | 15:14 |
| ssam2 | but I think build-essential should be as small as possible | 15:14 |
| ssam2 | makes the bootstrap faster and simpler | 15:14 |
| ssam2 | and reduces the number of things we have to build from tarballs | 15:14 |
| ssam2 | (or rebuild from git afterwards) | 15:14 |
| * Kinnison concurs | 15:15 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 15:24 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 15:24 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 15:24 | |
| bwh | I did an upgrade yesterday, rebooted and journalctl doesn't show anything new since then | 15:27 |
| bwh | Any ideas? | 15:28 |
| paulsherwood | of a baserock system? | 15:31 |
| paulsherwood | (sorry, just to be sure) | 15:31 |
| bwh | yes | 15:32 |
| paulsherwood | maybe ssam2 can help? | 15:32 |
| bwh | I started with the x86_64 image and upgraded using baserock/baserock/definitions commit 2918868b8dbf | 15:32 |
| paulsherwood | but it boots ok, other things work? | 15:33 |
| bwh | It has networking and sshd | 15:34 |
| pedroalvarez | bwh: I've seen that, but I don't know why this happens | 15:34 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 15:34 | |
| pedroalvarez | bwh: I know how to solve it though: `systemctl restart systemd-journald` | 15:35 |
| pedroalvarez | "solve it" | 15:35 |
| pedroalvarez | looks like the systemd-journald unit starts writing in /var before the system mounts the /var btrfs subvolume | 15:36 |
| bwh | Oh... | 15:36 |
| * paulsherwood finds his own vm has the same issue | 15:37 | |
| Kinnison | Doesn't the systemd-journald unit have a guard in it for that kind of problem? | 15:37 |
| tiagogomes | can I tell morph to keep the staging areas | 15:37 |
| paulsherwood | tiagogomes: you mean to diagnose a build? or something else? | 15:37 |
| bwh | Yeah, if I move the /var mount out of the way then journalctl shows the missing log entries | 15:38 |
| pedroalvarez | Kinnison: no, and talked to some #systemd people about adding RequiresMountsFor=/var/log/journal | 15:38 |
| pedroalvarez | but they didn't agree | 15:38 |
| tiagogomes | paulsherwood something else, I know that the staging area is kept when building a chunk fails. But I am interested in all stating areas | 15:39 |
| Kinnison | pedroalvarez: :-( | 15:39 |
| Kinnison | pedroalvarez: did they suggest an alternative? | 15:39 |
| ratmice__ | tiagogomes: so ld/Makefile.am has a relevent comment right before overriding am__skiplex & friends, tried commenting those out? | 15:39 |
| pedroalvarez | Kinnison: I think they suggested an upgrade to 218 | 15:42 |
| Kinnison | pedroalvarez: aah | 15:42 |
| paulsherwood | tiagogomes: i agree it would be better if it did, but i don't think it's currently possible. you could hack morph to do so easily... | 15:42 |
| paulsherwood | comment out 'self.remove_staging_area(staging_area)' in buildcommand.py | 15:42 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:43 | |
| paulsherwood | s/if it did/if it could/ | 15:43 |
| robtaylo1 is now known as robtaylor | 15:43 | |
| tiagogomes | thanks paulsherwood | 15:44 |
| paulsherwood | win 15 | 15:45 |
| paulsherwood | bah | 15:45 |
| tiagogomes | ratmice__, I didn't, but I think the problem that I am facing is that the generated C files on the tarball are older than the .y and .l, which could be the root cause why binutils fails to compile | 15:45 |
| ratmice__ | tiagogomes: yeah, the am__skiplex/yacc macros disable regeneration of the lex/yacc files unless maintainer mode is enabled, and for some unexplained reason ld is avoiding that | 15:47 |
| tiagogomes | ratmice__, the C files will not be generated anyway, because there isn't an available flex/bison when the final version of binutils is built | 15:48 |
| ratmice__ | ahh, I thought that they existed but the timestamp was wrong | 15:50 |
| tiagogomes | mmm, empty commits seems to not cause a rebuild | 15:58 |
| persia | Nope. Morph looks at the tree sha, not the commit sha. | 16:00 |
| tiagogomes | ratmice__, they exist because they come from the tarball, and the timestamp is wrong, but I cannot regenerate them as flex/bison are not available | 16:01 |
| *** cosm [~Unknown@cspc154.cs.man.ac.uk] has joined #baserock | 16:01 | |
| ssam2 | tiagogomes: you can regenerate them on a system with flex/bison available and then commit them to Git | 16:02 |
| ssam2 | that's the point of having all the files from the tarball commited to Git | 16:02 |
| tiagogomes | ssam2 yap, but when I tried to that it failed with some link error :'( . That's why I asked whether it was possible to keep the staging areas, so I can import those files from the staging are to the git repo | 16:04 |
| ratmice__ | tiagogomes: okay, so if you get rid of the am__skiplex hack in the Makefile.am, and regenerate makefiles and such, then hopefully it shouldn't care about the timestamp unless maintainer mode is enabled (which i'd have to look and see if that gets automagically enabled when building from a git repo or not) | 16:04 |
| ratmice__ | but you could probably --disable-maintainer-mode regardless of that | 16:05 |
| ssam2 | tiagogomes: if you want a staging area to be kept around after a build, set the last line of the 'install-commands' to `false` | 16:06 |
| ssam2 | it's a bit of a trick, but it means the build will fail so the staging area gets kept around | 16:06 |
| ratmice__ | ahh, yeah libfl probably? | 16:06 |
| tiagogomes | ssam2, ah true, it is better than hacking on morph to not bin them | 16:07 |
| rdale_ | is it allowed for one chunk in a stratum to overwrite an executable created by an earlier chunk in the stratum? | 16:16 |
| paulsherwood | it works, if that's what you mean | 16:19 |
| paulsherwood | shouldn't be done, though, i think | 16:19 |
| rdale_ | ok thanks | 16:19 |
| rdale_ | yes, i'm trying to avoid it | 16:19 |
| paulsherwood | why would you need that? | 16:19 |
| rdale_ | i need gem version 1.8.25, but ruby 1.9 builds gem version 1.8.23.2 and i can't seem to get the option to stop ruby 1.9 from building the gem executable | 16:20 |
| rdale_ | working | 16:20 |
| ssam2 | we use that feature in build-essential, and it's horrid in theory, but I can't think of a better approach that's simple, and it does work | 16:21 |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 16:23 | |
| locallycompact | How do I force all my lorries to rerun? | 16:32 |
| pedroalvarez | Using the lorry-controller API (http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/lorry-controller.git/tree/ARCH) you can do the following: | 16:34 |
| pedroalvarez | curl -X POST -d 'path=delta/libflangrt' http://localhost:12765/1.0/move-to-top | 16:35 |
| pedroalvarez | to promote delta/libflangrt in this case | 16:35 |
| persia | Doesn't that just promote the lorry, rather than force a re-run? | 16:36 |
| pedroalvarez | hm.. then I don't know what locallycompact wants to do | 16:37 |
| locallycompact | I changed the urls in several hundred lorries from http to https due to url mistake and the interval is set to one week, I want them all to rerun now. | 16:38 |
| straycat | locallycompact, you can certainly stop new lorries from being added to the run queue, I can't remember if you can clear the run queue so that you can then restart it | 16:38 |
| straycat | I guess you could take a look at the api and see if there's anything of use | 16:38 |
| straycat | last time I tried doing stuff with lorry controller I found it could with some methods to provide more fine grained control | 16:39 |
| straycat | noteably, please stop everything now, clear the run queue, and lorry foo, bar and baz NOW | 16:39 |
| straycat | *could do with | 16:40 |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:45 | |
| locallycompact | That POST -d path=delta/blah just tells me the path doesn't exist | 16:48 |
| Zara_ | email re: rubygems tutorial sent. still hoping I'm being overly pessimistic and we don't actually need to change anything anywhere. | 16:49 |
| pedroalvarez | locallycompact: People may not recommend this, but in the past, in some trove tests I've removed /home/lorry/webapp.db to clear the queue | 16:50 |
| locallycompact | pedroalvarez: wait, I got it | 16:51 |
| locallycompact | I was using the name of the lorry file without .lorry rather than the name in the json | 16:51 |
| locallycompact | it does make it run now | 16:51 |
| locallycompact | now to do it for six million files | 16:51 |
| straycat | :) | 16:52 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:03 | |
| franred | ummm, looks like that apr-util and apache needs --with-apr (where that flag means that we need to specify the source directory :S) | 17:15 |
| Kinnison | Even if apr is installed on the system? | 17:15 |
| franred | Kinnison, I think so. I need to run ./buildconf to create configure and ./buildconf requires the source code | 17:16 |
| Kinnison | eww | 17:17 |
| richard_maw | not just the headers‽ | 17:17 |
| franred | richard_maw, it checks for a .m4 file | 17:17 |
| franred | if [ -f "$apr_src_dir/build/apr_common.m4" ]; then | 17:18 |
| franred | ummm, let me try other way | 17:18 |
| pedroalvarez | franred: can't you do --with-apr=/usr? | 17:19 |
| franred | pedroalvarez, /usr does not contain that file ;-) | 17:19 |
| * pedroalvarez shuts up | 17:19 | |
| pedroalvarez | LFS uses --with-apr=/usr/bin/apr-1-config | 17:20 |
| * pedroalvarez stops saying random hints | 17:20 | |
| richard_maw | franred: the debian package has a /usr/share/apr-1.0/build directory which contains apr_common.m4 | 17:21 |
| franred | pedroalvarez, but in the configure command | 17:21 |
| richard_maw | franred: so it may be worth looking at how debian makes libapr1-dev | 17:21 |
| franred | richard_maw, that means that I need to add the files need it --> https://github.com/apache/apr-util/blob/0.9.x/buildconf | 17:22 |
| franred | see the rm / cp commands | 17:22 |
| richard_maw | what do we get in our chunk artifacts when we build apr? | 17:23 |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 256 seconds] | 17:26 | |
| franred | richard_maw, it is still not enough | 17:37 |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:38 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:39 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 17:40 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 17:44 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 17:49 | |
| *** cosm [~Unknown@cspc154.cs.man.ac.uk] has quit [Ping timeout: 244 seconds] | 17:49 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 17:58 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 18:06 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 18:08 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:09 | |
| ssam2 | I got really excited about https://github.com/FedOAuth/FedOAuth/ because I thought we could get away from having to maintain our own OpenID server code | 18:23 |
| ssam2 | but then I realised that FedOAuth currently only has backends for LDAP or Fedora accounts | 18:23 |
| ssam2 | probably either setting up LDAP for Baserock, or writing a backend for FedOAuth that uses a MySQL database or django.contrib.accounts, will be as much work as fixing the remaining bugs in the baserock-openid-provider I wrote :( | 18:24 |
| *** cosm [Unknown@gateway/vpn/mullvad/x-cvyihuglkgcseoud] has joined #baserock | 18:33 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 18:35 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 18:39 | |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 18:54 | |
| *** rdale [~quassel@206.Red-79-157-80.dynamicIP.rima-tde.net] has joined #baserock | 19:41 | |
| *** rdale_ [~quassel@76.Red-79-157-220.dynamicIP.rima-tde.net] has quit [Ping timeout: 264 seconds] | 19:44 | |
| *** rdale_ [~quassel@196.Red-83-42-142.dynamicIP.rima-tde.net] has joined #baserock | 19:54 | |
| *** rdale [~quassel@206.Red-79-157-80.dynamicIP.rima-tde.net] has quit [Ping timeout: 244 seconds] | 19:57 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 20:01 | |
| *** rdale_ [~quassel@196.Red-83-42-142.dynamicIP.rima-tde.net] has quit [Ping timeout: 264 seconds] | 20:01 | |
| *** rdale [~quassel@231.Red-83-42-142.dynamicIP.rima-tde.net] has joined #baserock | 20:03 | |
| *** rdale_ [~quassel@112.Red-79-156-159.staticIP.rima-tde.net] has joined #baserock | 20:10 | |
| *** rdale [~quassel@231.Red-83-42-142.dynamicIP.rima-tde.net] has quit [Ping timeout: 255 seconds] | 20:13 | |
| *** cosm [Unknown@gateway/vpn/mullvad/x-cvyihuglkgcseoud] has quit [Quit: Leaving] | 20:14 | |
| *** rdale [~quassel@80.30.131.245] has joined #baserock | 20:28 | |
| *** rdale__ [~quassel@80.30.108.128] has joined #baserock | 20:31 | |
| *** rdale_ [~quassel@112.Red-79-156-159.staticIP.rima-tde.net] has quit [Ping timeout: 255 seconds] | 20:31 | |
| *** rdale [~quassel@80.30.131.245] has quit [Ping timeout: 252 seconds] | 20:34 | |
| *** rdale__ [~quassel@80.30.108.128] has quit [Read error: Connection reset by peer] | 20:34 | |
| *** rdale [~quassel@252.Red-95-123-184.staticIP.rima-tde.net] has joined #baserock | 20:36 | |
| *** rdale_ [~quassel@63.Red-88-8-219.dynamicIP.rima-tde.net] has joined #baserock | 21:09 | |
| *** rdale [~quassel@252.Red-95-123-184.staticIP.rima-tde.net] has quit [Ping timeout: 264 seconds] | 21:10 | |
| *** rdale [~quassel@212.Red-79-144-245.dynamicIP.rima-tde.net] has joined #baserock | 21:14 | |
| *** rdale_ [~quassel@63.Red-88-8-219.dynamicIP.rima-tde.net] has quit [Ping timeout: 240 seconds] | 21:15 | |
| *** rdale [~quassel@212.Red-79-144-245.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 21:18 | |
| *** rdale [~quassel@204.Red-83-49-88.dynamicIP.rima-tde.net] has joined #baserock | 21:23 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 21:25 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 21:27 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 21:41 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 21:41 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 21:41 | |
| paulsherwood | not mysql, please :) | 22:09 |
| persia | Why not? We're using it behind other baserock infrastructure systems. | 22:13 |
| paulsherwood | because i favour less code, with less dependencies, that's easier to install | 22:14 |
| paulsherwood | (i'm being as polite as i can) | 22:14 |
| persia | heh | 22:14 |
| paulsherwood | https://github.com/kgaughan/poit-wsgi | 22:14 |
| persia | I prefer using the same software for as many purposes as possible, rather than different software for different things. Since we know we can't use postgresql for some stuff, and have to carry mysql anyway, it seems extra work to do both. | 22:15 |
| persia | poit is single-user | 22:15 |
| paulsherwood | not hard to fix that, i would think? | 22:16 |
| paulsherwood | (says smartass, after alcohol) | 22:16 |
| persia | After looking at the code, I suspect the alcohol of having impaired judgement | 22:17 |
| paulsherwood | i didn't look at the code :) | 22:19 |
| paulsherwood | 'moin moin wiki includes an openid provider' - chance to move wiki to python too? :-) | 22:20 |
| persia | I played with that a bit: it seemed to work OK, but it was a bit annoying. | 22:21 |
| persia | Anyway, I've come to like git-backed wikis, with moinmoin most certainly isn't :) | 22:21 |
| paulsherwood | yes. why is nothing ever perfect? :) | 22:23 |
| persia | Everyone has different requirements, so when we look for open code, we either get a baseline that works for everyone but doesn't do enough or a specialised system. | 22:24 |
| persia | I'd like everything to be modular and flexible, but people always tell me that it's too hard to do it that way. I suspect that it's just a matter of time, and that everything will be perfect later, but it may be a very long time. | 22:25 |
| paulsherwood | heh | 22:26 |
| paulsherwood | https://bitbucket.org/thomaswaldmann/moin-2.0/issue/163/git-or-mercurial-backend | 22:26 |
| paulsherwood | maybe we could persuade everyone we know to ambush him in moin-dev and persuade him | 22:26 |
| persia | Probably not, because https://labix.org/editmoin | 22:28 |
| * paulsherwood gives up for the day... | 22:38 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 22:54 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 22:55 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Ping timeout: 240 seconds] | 23:06 | |
| rjek | MySQL makes me very sad. | 23:11 |
| bwh | rjek: I imagine you especially like MySQL security patches | 23:12 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!