*** thecorconian [~thecorcon@136.1.1.104] has quit [Remote host closed the connection] | 00:37 | |
*** vmeson [~quassel@128.224.252.2] has joined #baserock | 01:31 | |
paulsherwood | so i appear to be in a strange universe where localhost != 127.0.0.1 | 02:09 |
---|---|---|
paulsherwood | ping 127.0.0.1 | 02:09 |
paulsherwood | PING 127.0.0.1 (127.0.0.1): 56 data bytes | 02:09 |
paulsherwood | 64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.091 ms | 02:09 |
paulsherwood | ping localhost | 02:09 |
paulsherwood | PING localhost (54.200.75.96): 56 data bytes | 02:09 |
paulsherwood | ^C | 02:09 |
paulsherwood | --- localhost ping statistics --- | 02:09 |
paulsherwood | 6 packets transmitted, 0 packets received, 100% packet loss | 02:09 |
*** ratmice_______ [bosshog@nightfall.forlorn.net] has quit [Ping timeout: 246 seconds] | 06:35 | |
*** ratmice_______ [bosshog@nightfall.forlorn.net] has joined #baserock | 06:35 | |
*** 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:39 | |
*** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:53 | |
*** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 08:03 | |
*** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:15 | |
Kinnison | paulsherwood: that happens when people who shouldn't be allowed to operate computers put them on networks | 08:17 |
Kinnison | somewhere a computer *called* localhost will be DHCPing | 08:18 |
pedroalvarez | heheh, you where trying to upgrade someone's computer? | 08:30 |
pedroalvarez | ha | 08:30 |
pedroalvarez | s/where/were/ | 08:30 |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:31 | |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:31 | |
straycat | franred, You could add one as a submodule to the other? | 08:44 |
pedroalvarez | mercurial :S | 08:46 |
pedroalvarez | actually | 08:46 |
franred | straycat, that implies modify the repository after lorrying them - I rather copy the content of one in the other when B has to compile | 08:46 |
pedroalvarez | everything is on git | 08:46 |
franred | I did this and it works | 08:46 |
Kinnison | We have another case for multiple-repo sources | 08:47 |
Kinnison | \o/ | 08:47 |
straycat | franred, sure | 08:47 |
franred | straycat, although I will try the submodule approach | 08:49 |
pedroalvarez | franred: an example http://git.baserock.org/cgi-bin/cgit.cgi/delta/cgit.git/tree/.gitmodules?id=eeaffc33432d3cf91902cac3eab50c0598bdaa19 | 08:50 |
Kinnison | That is not sufficient | 08:50 |
Kinnison | you need both the .gitmodules *and* the submodule link | 08:50 |
Kinnison | use the git submodule commands | 08:50 |
Kinnison | don't try and write it yourself | 08:50 |
pedroalvarez | aha | 08:51 |
franred | AFAIK, if one repo has submodules, if that repo wants to use the latest version of the submodule it has to update it and push them, how baserock manages this? | 08:53 |
Kinnison | Currently a human will have to do it | 08:54 |
Kinnison | Frankly I doubt firehose ought to know how to | 08:54 |
Kinnison | since normally the submodules will be set by upstream | 08:54 |
franred | so we need to update 3 parts, the repo to update the submodule, and the references on the chunks? | 08:54 |
Kinnison | e.g. we wouldn't want to move cgit's git submodule | 08:54 |
Kinnison | franred: yes, you'd need to update the submodule, commit the update and push it (to the enclosing repo) and then update the chunk's entry in the stratum | 08:55 |
Kinnison | currently | 08:55 |
* Kinnison thinks this is another good indication that we need multi-source chunks | 08:55 | |
* franred doesn't like submodules at all | 08:55 | |
Kinnison | :-) | 08:56 |
*** zarazaimeche [~zarazaime@access.ducie-dc1.codethink.co.uk] has joined #baserock | 08:58 | |
zarazaimeche is now known as Zara | 08:59 | |
* pedroalvarez waves zarazaimeche | 08:59 | |
pedroalvarez | hm.. | 08:59 |
Zara | hi, pedroalvarez :) | 08:59 |
ratmice_______ | Kinnison: done some of that with iirc git read-tree checking out multiple repos into a working dir, then frobbing the GIT_DIR env var based on which which repo i want git commands to work on, can be interesting when the repos overlap/checkout order matters | 09:18 |
Kinnison | Frankly we probably don't need that per-se | 09:19 |
Kinnison | Just the ability to effectively provide a "repo+sha+location" set | 09:19 |
Kinnison | where the base repo+ref is what goes into chunkname.build/ | 09:19 |
Kinnison | and everything else is relative to (and locked inside) that dir | 09:19 |
pedroalvarez | that makes sense to me | 09:20 |
ratmice_______ | yeah, it was a fairly weird case configure script from one repo would test for dirs in the top-level srcdir from another repo | 09:21 |
Kinnison | :-) | 09:21 |
Kinnison | ratmice_______: sounds uncomfortable | 09:21 |
* Kinnison wonders why ratmice_______'s tail has grown quite so long :-) | 09:21 | |
* ratmice_______ too | 09:22 | |
ratmice_______ | I actually just want to discover what happens when it hits some arbitrary limit | 09:23 |
Kinnison | hehe | 09:23 |
ratmice_______ | anyhow in particular it was gcc+binutils+newlib repos stitching together the old 'uberbaum' tree out of git repos | 09:24 |
Kinnison | Mmm, I think I remember having to do something similar waaay back in about 2004 or so | 09:24 |
ratmice_______ | it actually worked fairly well, since you could easily see divergence between files existing in all the repos | 09:24 |
Kinnison | Back on MIPS | 09:24 |
Kinnison | Although I think that was glibc not newlib | 09:25 |
ratmice_______ | hmm, not aware of glibc ever being buildable like that | 09:25 |
Kinnison | It was some odd thing that MIPS did internally | 09:25 |
Kinnison | I think it was more that we layered things and patched them | 09:25 |
* Kinnison wasn't meant to be on toolchains though so wasn't deeply involved beyond writing build tools | 09:25 | |
ratmice_______ | anyhow, i liked it, really cut down on # rebuilds of all those various libs | 09:26 |
pedroalvarez | great, I finally confirmed the error that the jetson board was having to boot the latest relase | 09:31 |
paulsherwood | Kinnison: nonetheless, given that localhost can be screwed, what about my patch? | 09:32 |
paulsherwood | pedroalvarez: what was it? | 09:32 |
richard_maw | paulsherwood: I just sent you a reply about your patch | 09:32 |
pedroalvarez | paulsherwood: cma=256M in KERNEL_ARGS | 09:32 |
pedroalvarez | paulsherwood: after removing it, everything worked | 09:33 |
richard_maw | I have no problem with your patch, but it includes a command to fix it globally, and I'm going to try out the gerrit workflow when submitting the config fix | 09:33 |
pedroalvarez | richard_maw: :) | 09:33 |
paulsherwood | richard_maw: ok, thanks | 09:34 |
pedroalvarez | so, my question regarding fixing the release. What should I do? | 09:34 |
paulsherwood | 14.40.1 | 09:34 |
pedroalvarez | Put the patches on the top of the release branch? | 09:34 |
pedroalvarez | and tag it as paulsherwood suggested? | 09:35 |
Kinnison | works for me | 09:35 |
paulsherwood | +1 | 09:35 |
ssam2 | pedroalvarez: out of curiousity, how to did you work out that was the problem ? | 09:38 |
pedroalvarez | flashing, and reflashing and reflashing | 09:38 |
pedroalvarez | :( | 09:38 |
pedroalvarez | with various conbinations of rootfs and u-boot, I saw it wasn't u-boot the problem | 09:38 |
pedroalvarez | and it was something in the rootfs | 09:39 |
pedroalvarez | The only thing in the rootfs that could be causing problems was extlinux.conf | 09:39 |
pedroalvarez | then I remembered one change in the KERNEL_ARGS that radiofree did for the genivi system | 09:40 |
pedroalvarez | so, I wondered: Is that the problem? | 09:40 |
pedroalvarez | and it was | 09:40 |
pedroalvarez | the slowest part of this proccess has been: reflashing the jetson | 09:40 |
pedroalvarez | I know there is a way to mount the disk of the jetson and modify things. | 09:41 |
paulsherwood | pedroalvarez: why were you not using the cycle approach? (i'm sure there'll be a reason) | 09:41 |
Kinnison | paulsherwood: presumably because it wasn't booting | 09:41 |
pedroalvarez | exactly | 09:41 |
Kinnison | pedroalvarez: In theory you can run some uboot command which exposes the storage as a USB disk | 09:42 |
pedroalvarez | and at the beggining I thought the problem was on u-boot, and to reinstall it you have to flash it | 09:42 |
paulsherwood | pedroalvarez: ridght | 09:42 |
franred | :q | 09:43 |
pedroalvarez | now I wonder if reverting the upgrade of u-boot makes sense, but that means reflash the jetson to test it | 09:43 |
* franred is not good typing in the correct window.... | 09:43 | |
Kinnison | pedroalvarez: the uboot update was needed for ethernet and sata no? | 09:43 |
pedroalvarez | I shall try then | 09:44 |
pedroalvarez | the only thing I know, is that James thought that the u-boot upgrade was causing problems | 09:46 |
Kinnison | I think it might be truncating the kernel args if they're too long | 09:49 |
Kinnison | I heard him mumble something about that last week | 09:49 |
paulsherwood | pedroalvarez: i have the old u-boot on a jetson | 09:50 |
paulsherwood | but actually, given my localhost nonsense, i can't test for you | 09:51 |
pedroalvarez | heheh | 09:51 |
Kinnison | paulsherwood: fix your /etc/nsswitch.conf to put 'files' before the rest of the entries on the hosts line | 09:52 |
Kinnison | paulsherwood: that should cause it to ignore the network for localhost | 09:52 |
paulsherwood | ok | 09:52 |
paulsherwood | iin the meantime i got this http://fpaste.org/140180/ | 09:52 |
Kinnison | assuming I understood richard_maw's mail properly | 09:52 |
paulsherwood | (again) | 09:52 |
richard_maw | pedroalvarez: so before I can push to the gerrit, I need to register an account? | 09:53 |
Kinnison | ssam2: Any idea what could cause paulsherwood's problem? ^^^ | 09:53 |
richard_maw | Kinnison: no, you need to my myhostname just after files | 09:53 |
richard_maw | rather than at the end | 09:53 |
Kinnison | richard_maw: oh right | 09:53 |
paulsherwood | Kinnison: it already is: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 myhostname | 09:53 |
* Kinnison misunderstood your seddery | 09:53 | |
Kinnison | paulsherwood: so move myhostname to between files and mdns4_minimal | 09:53 |
paulsherwood | ok | 09:53 |
pedroalvarez | richard_maw: I'm not sure, but I think that makes sense that you have an user to be able to send a patch | 09:54 |
richard_maw | paulsherwood: are you missing VERSION_LABEL in that deploy you just fpasted? | 09:54 |
paulsherwood | oh, probably. | 09:55 |
paulsherwood | sorry. | 09:55 |
paulsherwood | can we make deply idiotproof? :) | 09:55 |
paulsherwood | deploy | 09:55 |
Kinnison | the world will invent better idiots if we try | 09:55 |
pedroalvarez | we should check that in the .check extension | 09:55 |
Kinnison | we should mandte VERSION_LABEL if you're using ssh+rsync though | 09:55 |
paulsherwood | what about making it default to TEST? | 09:56 |
Kinnison | I think if you're applying an update you should be specifying the basis (default to FACTORY) and the target (mandatory) | 09:56 |
Kinnison | and the .check can fail quickly | 09:57 |
pedroalvarez | sounds like updating .check is the right solution | 09:58 |
richard_maw | pedroalvarez: :-( the only OpenID I have that is listed is Google, and Google no worky | 09:58 |
paulsherwood | i note your suggestion. agree with default to factory (not FACTORY) but see no problem with defaulting to TEST | 09:58 |
pedroalvarez | richard_maw: google not worky, and they don't care about that | 09:58 |
pedroalvarez | richard_maw: you should have other openid providers | 09:59 |
pedroalvarez | I used launchpad yesterday (whch uses ubuntu one :( ) | 09:59 |
pedroalvarez | also yahoo works fine | 09:59 |
Kinnison | richard_maw: I can recommend stackoverflow's openid provider | 09:59 |
Kinnison | it works and is easy to use | 09:59 |
paulsherwood | mwilliams_ct: aren't you working on an open_id server? | 09:59 |
* Kinnison also recommends you set it up as a delegate for your real website | 10:00 | |
* Kinnison 's OpenID is www.digital-scurf.org | 10:00 | |
Kinnison | Just needs a couple of <link> tags on your front page | 10:00 |
richard_maw | eww, the registration page doesn't label what each text box is for | 10:01 |
Kinnison | it's javascripted | 10:02 |
Kinnison | email, realname, password, password-again, captcha, respectively | 10:02 |
ssam2 | Kinnison: how do I use stackoverflow as an OpenID ? | 10:02 |
ssam2 | I have https://stackoverflow.com/users/3082942/ssam | 10:02 |
Kinnison | ssam2: look at openid.stackexchange.com | 10:02 |
ssam2 | I get 'Provider is not supported, or was incorrectly entered.' | 10:03 |
Kinnison | ssam2: and the <link> tags on www.digital-scurf.org | 10:03 |
ssam2 | no sign of our Gerrit instance on that log | 10:03 |
Kinnison | (actually I should try the gerrit with this) | 10:03 |
Kinnison | pedroalvarez: can you provide me with a link to the gerrit, I've lost it | 10:03 |
richard_maw | http://85.199.252.116:8080/#/q/status:open | 10:03 |
Kinnison | ta | 10:03 |
pedroalvarez | note: Gerrit doesn't have configured the email, so you can't do things like change your email address | 10:04 |
franred | I couldn't manage to have and stackexchange account loggin into gerrit | 10:04 |
* richard_maw gets verification failed | 10:04 | |
Kinnison | Looks like it works with the approach I take | 10:04 |
Kinnison | I have delegated openid via my personal website | 10:04 |
ssam2 | I have to use the https://openid.stackexchange.com/user/xxx link from https://openid.stackexchange.com/user | 10:05 |
Kinnison | Better is to use something which delegates the ID | 10:05 |
ssam2 | to delegate that from my personal website do I just need to add the two <link> tags to index.html ? | 10:05 |
Kinnison | yep | 10:06 |
Kinnison | you can crib the approach from www.digital-scurf.org | 10:06 |
ssam2 | that's a bit much to ask every Baserock contributor to do, however :) | 10:06 |
Kinnison | I'm surprised the google login thing didn't work for richard_maw | 10:07 |
Kinnison | aah it's 'cause google deprecated their openid provider | 10:07 |
Kinnison | *plus* we're presenting an IP address not a domain name | 10:08 |
Kinnison | which they don't like | 10:08 |
Kinnison | However, if we could have a basic provider then it'd be a good thing | 10:08 |
ssam2 | yeah. Seems like there's no way to get a StackExchange OpenID to work for me | 10:10 |
ssam2 | I get forwarded to StackExchange and back, but I never actually get logged into Gerrit | 10:10 |
ssam2 | a problem in our instance franred thinks | 10:10 |
Kinnison | I can log in with my delegated ID | 10:11 |
straycat | Can tarballs be lorried from multiple urls? | 10:13 |
straycat | The spec seems to have a single url field, so I'm guessing we can't. | 10:16 |
Kinnison | No it's only one url | 10:17 |
pedroalvarez | straycat: does it makes sense? I mean, what use case are thinking of | 10:17 |
pedroalvarez | s/are/are you/ | 10:18 |
straycat | I was thinking it might be simpler to lorry all versions of a package so that you can easily use/switch between serveral versions of a package. | 10:19 |
Kinnison | Lorry one, then update the url, rinse and repeat | 10:20 |
Kinnison | it the current workflow for that | 10:20 |
* straycat nods | 10:21 | |
pedroalvarez | oh, I see why you are looking at this | 10:21 |
richard_maw | pedroalvarez: which url should I push to? | 10:21 |
pedroalvarez | is a definitions patch? | 10:21 |
richard_maw | ah, there's tiny buttons | 10:21 |
richard_maw | nevermind, got it | 10:21 |
pedroalvarez | richard_maw: the url is also in the cgit interface | 10:21 |
pedroalvarez | port :80 | 10:22 |
richard_maw | it's a different URL for submitting changes isn't it? | 10:22 |
pedroalvarez | ssh://USERNAME@85.199.252.116:29418/baserock/definitions | 10:23 |
richard_maw | bah! it's refusing my commits, because it doesn't like that I don't have an e-mail registered, because I get internal server errors | 10:23 |
pedroalvarez | the email in the commit has to be the same email that you used to register | 10:24 |
richard_maw | it didn't let me enter an e-mail at registration time | 10:24 |
pedroalvarez | hmm | 10:25 |
pedroalvarez | known error, not email server configured | 10:25 |
pedroalvarez | maybe worth fixing that | 10:25 |
richard_maw | how did you manage to have an e-mail registered anyway? | 10:25 |
pedroalvarez | I'm trying to figure it out | 10:25 |
paulsherwood | 2014-10-08 09:46:06 [Build 334/349] [enlightenment] Cloning upstream:enlightenment/enlightenment | 10:26 |
paulsherwood | 2014-10-08 10:25:19 [Build 334/349] [enlightenment] Creating staging area | 10:26 |
paulsherwood | urgh | 10:26 |
Kinnison | paulsherwood: That's an uncomfortbly long clone time | 10:26 |
pedroalvarez | you are far away from g.b.o | 10:26 |
* jmacs notes that python's platform.linux_distribution returns empty strings | 10:26 | |
pedroalvarez | richard_maw: seems like the launchpad openid provides the email when registering | 10:27 |
richard_maw | I see. Well mine doesn't, which means I can't use Gerrit | 10:28 |
pedroalvarez | :( | 10:29 |
pedroalvarez | I'd like to sort out the email server config | 10:29 |
* Kinnison suggests that exim4 is pretty easy to get going, | 10:31 | |
richard_maw | pedroalvarez: I'd suggest getting it working is a reasonably high priority, since it'll make patch review easier in the long run | 10:36 |
pedroalvarez | i agree | 10:37 |
ssam2 | jmacs: in Baserock, you mean ? | 10:38 |
jmacs | ssam2: Yes | 10:44 |
jmacs | I'm just looking to see how it's meant to work | 10:44 |
jjardon | paulsherwood: should I assume your changed your -1 to a +1 in the llvm series when I change to build 3.3.1 instead 3.5? | 10:45 |
ssam2 | I'm thinking that the import tooling should move out of its branch of morph.git and into its own repo | 10:49 |
ssam2 | any opinions on this, or names for it? | 10:49 |
ssam2 | if noone complains I think git://git.baserock.org/baserock/baserock/import should be its home | 10:49 |
Kinnison | I'm happy with that | 10:55 |
wikicat | Wiki change: http://wiki.baserock.org/recentchanges/#change-d7ab89455f52a32b22fb4ab650c997df64a5db2c | 11:03 |
ssam2 | ok. Can someone with appropriate permissions create that? I guess that's richard_maw or Kinnison, who have both left for lunch. | 11:04 |
ssam2 | or not. | 11:05 |
Kinnison | created | 11:08 |
ssam2 | thankyou! | 11:08 |
Kinnison | now I shall lunch | 11:08 |
*** JPohlmann [~jannis@m65s13.vlinux.de] has joined #baserock | 11:10 | |
*** JPohlmann [~jannis@m65s13.vlinux.de] has quit [Changing host] | 11:10 | |
*** JPohlmann [~jannis@xfce/core-developer/JPohlmann] has joined #baserock | 11:10 | |
jmacs | Is "build-essential" the first thing that gets built in a baserock system? | 11:28 |
straycat | yes | 11:34 |
jmacs | OK. I was just a bit confused as to why a stratum that seems to be mainly about compilers writes /etc/passwd etc | 11:36 |
ssam2 | from stage 3 of build-essential onwards, everything runs in a chroot, so it needs to be a viable chroot environment | 11:44 |
ssam2 | fhs-dirs is kind of treated as 'everything that doesn't fit in the other parts of bootstrap but is needed for the chroot to work' chunk | 11:44 |
jmacs | Yes, I thought that would be the case | 11:45 |
wikicat | Wiki change: http://wiki.baserock.org/recentchanges/#change-7a9cbddacf0c90c2c0dba396efdf9b805b5174fa | 12:21 |
richard_maw | pedroalvarez: how did the distbuild test with the .cache_key fix in worker_build_scheduler go? | 12:32 |
jmacs | What's VERSION_LABEL meant to contain? Is it arbitrary? | 12:40 |
richard_maw | yep, but I don't think it'll handle / too well | 12:40 |
jmacs | Is there another environment variable that contains the version of baserock? e.g. "14.40" | 12:42 |
Kinnison | jmacs: the version label is used to control the variant of the system which is booted | 12:42 |
Kinnison | jmacs: the default label being 'factory' | 12:42 |
Kinnison | I doubt there's anything with a Baserock version per-se currently | 12:42 |
Kinnison | We should probably make our lsb-release stuff work that out | 12:42 |
jmacs | Kinnison: That's what I'm trying to implement. Do we already have lsb-release stuff? | 12:43 |
Kinnison | I believe we have a small amount of lsb stuff | 12:43 |
richard_maw | we've got a minimal /etc/os-release | 12:43 |
Kinnison | how complete / correct it is, I have no idea | 12:43 |
richard_maw | it basically just says "Baserock" | 12:43 |
jmacs | There is no /etc/lsb-release on the system I have here | 12:44 |
Kinnison | then we're lacking all of that | 12:45 |
jmacs | Are there conflicting standards here? Should we have both lsb-release and os-release? | 12:45 |
richard_maw | I think the key difference is that lsb-release is executable, and os-release is machine parsable | 12:46 |
pedroalvarez | richard_maw: it's working fine | 12:58 |
richard_maw | is that an endorsement to merge :-) | 12:59 |
pedroalvarez | richard_maw: is a +1 to merge if you fix the missing artifact.cache_key | 13:00 |
pedroalvarez | and I believe you have already done that | 13:01 |
richard_maw | cool | 13:01 |
ssam2 | I don't have /etc/lsb-release on Fedora | 13:02 |
ssam2 | I do have /etc/os-release with VERSION and VERSION_ID fields | 13:02 |
ssam2 | VERSION_LABEL is user-defined, I tend to put the deployment date, but it's just a mnemonic for the user / admin of the system | 13:03 |
ssam2 | possibly it should be hidden in future | 13:03 |
jmacs | Interesting | 13:03 |
Kinnison | I have a program called lsb_release | 13:03 |
Kinnison | which is in /usr/bin | 13:03 |
ssam2 | the thing is that Baserock systems don't really have a version beyond 'SHA1 of the repo it was built from' | 13:04 |
Kinnison | Currently | 13:04 |
Kinnison | I wouldn't object to a configuration extension which could augment that with a release number when you deploy | 13:04 |
Kinnison | If Python can deal with getting that at runtime instead of build time | 13:04 |
ssam2 | that'd be cool, but I worry about potential for confusion with VERSION_LABEL | 13:05 |
jmacs | Ah, I misread platform.py. It should in fact check os-release | 13:05 |
Kinnison | then we need to know what's missing and how to fix it | 13:06 |
jmacs | ssam2: What's the first line of /etc/os-release on your Fedora system? | 13:10 |
ssam2 | jmacs: http://pastebin.com/rnB28md0 | 13:12 |
jmacs | Thanks | 13:13 |
jmacs | I don't think Python will do anything with /etc/os-release. It reads it because it looks for any file called .*[_-](release|version) in /etc, but it only checks the first line for something of the form "distro release x.y (codename)" | 13:14 |
jmacs | Which wouldn't be in os-release as that's only meant to contain assignments | 13:15 |
jmacs | To get Python to work we either need an lsb-release or a baserock-release | 13:15 |
Kinnison | will it read *any* file named .*[_-](release|version) ? | 13:15 |
jmacs | So far as I can tell, yes | 13:16 |
Kinnison | Debian's os-release starts PRETTY_NAME="Debian GNU/Linux 7 (wheezy)" | 13:16 |
Kinnison | (for stable) | 13:16 |
Kinnison | perhaps whoever wrote the code for python was a debianite but not very sensible? | 13:16 |
jmacs | Yes, but it also has debian_release, I think | 13:17 |
jmacs | It'll check os-release, not find a match, and continue to debian_release | 13:17 |
Kinnison | debian_release contains just the version number (7.4) iirc | 13:18 |
jmacs | It's debian_version, and yes, just the number | 13:18 |
Kinnison | :-( | 13:19 |
jmacs | Which probably means platform will fall through to other methods of detecting the OS | 13:19 |
ssam2 | FWIW, I see: | 13:23 |
ssam2 | >>> platform.linux_distribution() | 13:23 |
ssam2 | ('Fedora', '20', 'Heisenbug') | 13:23 |
jmacs | I've just added an /etc/lsb-release to my baserock system and I still get ('', '', ''). Oh well. | 13:24 |
ssam2 | richard_maw: I'm about to update definitions.git after merging a morph.git branch, so if you've not done so yet, don't worry about it | 13:43 |
richard_maw | already done | 13:43 |
richard_maw | you'll get a conflict | 13:43 |
richard_maw | currently sending mails to acknowledge | 13:44 |
ssam2 | ok, i'll pull first | 13:44 |
pedroalvarez | richard_maw: email working on gerrit :) | 13:59 |
pedroalvarez | Kinnison: thanks for your help :) | 14:00 |
Kinnison | y'welcome | 14:00 |
richard_maw | it's not errored when trying to register a mail, but it's not turned up in my inbox yet | 14:01 |
pedroalvarez | richard_maw: can you check your spam? | 14:01 |
richard_maw | there it is! | 14:02 |
pedroalvarez | :D | 14:02 |
* pedroalvarez dances | 14:02 | |
franred | yay!! | 14:03 |
* Kinnison waits for the greylisting on his domain to expire for the registration email | 14:05 | |
Kinnison | pedroalvarez: the @codethink.co.uk one came through, but my @digital-scurf.org is probably still suffering from greylisting | 14:07 |
pedroalvarez | let's see if I can do anything useful with google, greylist and exim4 | 14:08 |
Kinnison | Oh it's fine | 14:09 |
Kinnison | I just need to wait the greylisting timer and the retry timer on the gerrit server (which is likely ca. 15m or 30m depending) | 14:09 |
pedroalvarez | from exim4 logs: This domain has greylisting enabled. | 14:10 |
Kinnison | aye | 14:11 |
rjek | That sounds like an error message from my mail server. | 14:11 |
Kinnison | if you run 'exim4 -bpr' then you'll see it sat in the queue for retry later | 14:11 |
rjek | 2014-10-08 15:03:19 H=(gerrit) [85.199.252.116] F=<pedro.alvarez@codethink.co.uk> temporarily rejected RCPT <dsilvers@digital-scurf.org>: This domain has greylisting enabled. If you receive this email message, it is likely that your mail server is incorrectly configured. Please contact the person you wish to contact using another method. | 14:11 |
Kinnison | rjek: aye, it's all expected and good | 14:11 |
rjek | Good good! | 14:11 |
* Kinnison put in his work address which is, IIRC, postfix and no greylisting, and his home address which is exim4 and greylisting | 14:12 | |
Kinnison | pedro I believe tried gmail | 14:12 |
pedroalvarez | yup, and it worked | 14:13 |
richard_maw | http://85.199.252.116:8080/#/c/4/1/strata/build-essential/eglibc.morph may be of interest | 14:14 |
Kinnison | Is it right to hardcode the entire thing rather than to sed it like you suggesed before? | 14:15 |
richard_maw | I want to drop it from the delta, but we can't make changes to non baserock/ repositories in gerrit currently | 14:16 |
Kinnison | aah | 14:16 |
richard_maw | anyway, if I was sedding, there'd be two different things you need to look up before you know the result, and sed is not easily comprehensible | 14:17 |
richard_maw | anway, I think we need to get used to the comment buttons, so it may make more sense to do this on the instance | 14:17 |
Kinnison | :-) | 14:18 |
pedroalvarez | I've made a comment here: http://85.199.252.116:8080/#/c/4/1/strata/build-essential/eglibc.morph I wonder if the people can see it | 14:20 |
richard_maw | pedroalvarez: I don't see it | 14:22 |
richard_maw | but I do see Kinnison has added himself as a reviewer | 14:22 |
richard_maw | and he has a review in the history | 14:23 |
* Kinnison has reviewed it too | 14:23 | |
Kinnison | pedroalvarez: I can see your comment in the history of the change | 14:25 |
pedroalvarez | aha! | 14:25 |
pedroalvarez | so it has 2 +1s, but it doesn't have a +2 yet | 14:26 |
Kinnison | Not sure what the rules are by default in gerrit | 14:26 |
richard_maw | :-\ Now I want a Zuul instance to do the merge | 14:27 |
pedroalvarez | zuul needs a JSP like tomcat | 14:27 |
* Kinnison 's wrist vibrates | 14:27 | |
richard_maw | pedroalvarez: :-| | 14:28 |
Kinnison | (it's not an allergic reaction to JSP, but an email notification) | 14:28 |
* Kinnison pukes all over pedroalvarez -- that's the reaction to JSP | 14:28 | |
Kinnison | 2453 N + Oct 08 Pedro Alvarez (0.7K) [Gerrit Code Review] Email Verification | 14:28 |
pedroalvarez | i can be wrong, but that's whatI read | 14:28 |
*** genii [~quassel@ubuntu/member/genii] has joined #baserock | 14:28 | |
Kinnison | pedroalvarez: looks like the MTA on your gerrit instance is doing the right thing with greylisted domains \o/ | 14:29 |
pedroalvarez | Kinnison: yay \o/ | 14:29 |
Kinnison | pedroalvarez: how did you +2 ? | 14:39 |
pedroalvarez | from the admin user | 14:40 |
Kinnison | cheat! | 14:40 |
pedroalvarez | but if 1+1 is not 2, then some people has to have rights to +2 | 14:40 |
Kinnison | No, I think the idea is that it has 'n' +1s | 14:41 |
Kinnison | Overall I'd like to see a rule of ">= n +1s from humans, and a +1 from CI" | 14:41 |
Kinnison | But I don't know if we'll ever get there | 14:41 |
jjardon | pedroalvarez: that is looking cool ;) | 14:42 |
* Kinnison shall try and get git review and gerrymander going at some point | 14:42 | |
Kinnison | unless someone else wants to first? | 14:42 |
jjardon | I have a question about the troves: why are they needed? My understanding is for reproducibility reason: in case upstream repos dissapears or something. Also to have everything in git. Are those the only reasons? | 14:46 |
jmacs | Grr. Reading /etc/lsb-release is a Ubuntu-specific patch to python. | 14:46 |
Kinnison | jmacs: bleh | 14:47 |
Kinnison | jmacs: write a baserock-release with the data in the right format to shut python up/ | 14:47 |
Kinnison | s@/@?@ | 14:47 |
ssam2 | jjardon: also for speed. In some use cases it's good to have source code mirrored in a machine on the local network | 14:47 |
richard_maw | jjardon: also, to avoid overloading upstream's repository | 14:47 |
ssam2 | jjardon: although Morph also does local caching of Git repos, so there are currently two components doing caching which is not ideal | 14:48 |
richard_maw | stick a trove on devel machines! | 14:48 |
jmacs | Kinnison: I can do that, but I'll still have to patch Python since it won't recognise /etc/baserock-release unless I add baserock to its approved list of distributions (as I've now discovered) | 14:48 |
Kinnison | aah | 14:49 |
Kinnison | boo | 14:49 |
Kinnison | probably best not to need a python patch | 14:49 |
* Kinnison wonders if there's anything we can do instead | 14:49 | |
richard_maw | propose a proper /etc/os-release parser, so there doesn't need to be distro-specific hacks anywhere? | 14:50 |
jmacs | Presumably in baserock there's some way to patch the copy of python we produce | 14:50 |
jmacs | richard_maw: That sounds sensible | 14:50 |
richard_maw | yeah, but we try to avoid unnecessary deltas if possible | 14:50 |
richard_maw | if we do need a delta, then we need it to be something that's upstreamable | 14:51 |
richard_maw | I just wonder whether it would count as a bugfix, so python 2.7.x would take it | 14:51 |
jjardon | ssam2: richard_maw Id say those are not really important nowadays: connection speeds are fast! and do not think kernel.org/github/git.gnome.org/freedesktop have overloading problems. Well I meant not important enough to have to lorry every single piece of software you need | 14:51 |
jjardon | what happen if a force-push is done in one of repo? does trove do something spacial or it simply mirror what its in the upstream repo? | 14:52 |
straycat | Trove also gives you a way to convert non-git to git, and somewhere to put it. | 14:53 |
Kinnison | jjardon: By default we whinge about force-pushes and a human has to check on things and update the lorry specs | 14:53 |
straycat | trove's rulesets won't allow force pushes to certain refs. | 14:53 |
richard_maw | which gives us time to make a copy of the branch if we need to | 14:53 |
jjardon | ok, good. I think we can assume that the content in our trove is free of "missing sha's" problems then. Why then is not allow to use tags as a ref: instead the sha? | 14:56 |
ssam2 | jjardon: "connection speeds are fast"! call me when you're in a hotel. | 14:56 |
ssam2 | or on-site in Eastern Europe | 14:56 |
straycat | jjardon, you can use the ref if you want, it's better for definitions on gbo to use sha to stop things from changing under peoples' feet. | 14:57 |
jjardon | straycat: AFAIK you cant change a tag if you dont force-push? | 14:58 |
Kinnison | You can | 14:58 |
Kinnison | delete it | 14:58 |
Kinnison | wait a bit | 14:58 |
Kinnison | upload a new one | 14:58 |
Kinnison | Hell, you can delete tags | 14:58 |
jjardon | ssam2: are you suggesting I should have a trove in my laptop? :) | 14:59 |
Kinnison | And upstream *have* in the past moved tags | 14:59 |
Kinnison | esp. ones which are not annotated | 14:59 |
Kinnison | Although I've seen annotated tags being moved too | 14:59 |
ssam2 | jjardon: I'd like that to be possible, yeah | 15:01 |
ssam2 | main problem is it needs to be capable of having a subset of the full git.baserock.org content | 15:02 |
jjardon | Kinnison: yeah, but my point is, you cant move tags without force push? | 15:02 |
straycat | ssam2, I don't think running a trove on a laptop would be much fun, given the resource requirements for trove. | 15:02 |
ssam2 | agreed, but I'd like the resource requirements to be lower | 15:02 |
* straycat nods | 15:02 | |
Kinnison | jjardon: You can by deleting it, waiting, and then pushing a new one | 15:02 |
Kinnison | jjardon: just like you can with any branch | 15:02 |
Kinnison | tags are just refs | 15:03 |
pedroalvarez | Kinnison: I believe that you can now +2 patches | 15:04 |
Kinnison | runroh | 15:05 |
pedroalvarez | (in definitions.git) | 15:05 |
Kinnison | I'll become drunk with powah | 15:05 |
franred | you can do +2 but I think you are not able to merge the patch ... yet :P | 15:06 |
pedroalvarez | i think that now he is | 15:06 |
franred | ummm so much powah!! Kinnison is becoming Spiderman | 15:07 |
Kinnison | hm | 15:07 |
rjek | Thingy Garfield or Toby Whatisface? | 15:08 |
straycat | I take it we can't lorry from zip archives. | 15:08 |
Kinnison | Currently we cannot, no | 15:09 |
straycat | Okay | 15:09 |
ssam2 | would that be useful? I got a question from a customer about that the other day | 15:10 |
straycat | I was going to leave it until we see there's a need for it. | 15:11 |
straycat | But if we needed it I can't imagine it would be difficult to add support to lorry. | 15:11 |
Kinnison | The trick will be writing something to turn a zip file into a git fast-import stream | 15:11 |
Kinnison | We have some perl in lorry for doing that for tarballs | 15:11 |
jjardon | Kinnison: mmm, cant the trove have control of that in some way? Is it not possible to configure trove to not allow to remove tags? with a pre-receive or pre-update trigger maybe? Currently seems baserock is trying to solve the problem of "not desired changues upstream" in 2 different locations: in the trove (not allowing force-pushes) and in definitions | 15:16 |
jjardon | (making mandatory the use of refs) | 15:16 |
Kinnison | the use of sha1s also means we don't have to refer to the repo to resolve the ref | 15:18 |
ssam2 | that's true and there have been a few solutions proposed in the past | 15:18 |
Kinnison | which speeds things up | 15:18 |
Kinnison | Ultimately I want to get rid of referring to anything but the committed content of definitions to know how to build the artifact graph | 15:19 |
ssam2 | jjardon: http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2014-July/007245.html and http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2014-September/007992.html have been proposed | 15:21 |
richard_maw | is the gerrit down? I can't reach it currently | 15:21 |
pedroalvarez | richard_maw: yes, one second, I was trying one thing | 15:23 |
richard_maw | aah, it's green! | 15:24 |
jjardon | ssam2: thanks, I somehow missed the September email: Its exactly what I was thinking of! | 15:24 |
richard_maw | oops, accidentally clicked the submit button, now it's merged it onto the repository on the gerrit | 15:25 |
pedroalvarez | hm.. | 15:26 |
pedroalvarez | http://85.199.252.116/cgit/cgit.cgi/baserock/definitions.git/log/ | 15:27 |
pedroalvarez | richard_maw: how was your merging experience> | 15:27 |
pedroalvarez | ? | 15:27 |
richard_maw | well, now we need to work out how it's going to apply that to git.baserock.org | 15:28 |
Kinnison | ideally we'd make them one and the same thing eventually | 15:28 |
Kinnison | but zuul won't have to use gerrit's merge stuff | 15:28 |
jjardon | ssam2: so, I think your idea is the one that makes more sense. In the end of the day upsrteam repos that remove/move tags are the exception, not the rule | 15:29 |
richard_maw | I disagree, it often happens in releases | 15:29 |
pedroalvarez | richard_maw: just to let you know, your patch is not going to appear in g.b.o :) | 15:30 |
richard_maw | I know | 15:30 |
pedroalvarez | just in case | 15:30 |
richard_maw | not unless I push it myself | 15:30 |
richard_maw | which defeats the point of having the review bit really | 15:31 |
richard_maw | well, maybe not entirely | 15:31 |
Kinnison | Looks like we really need the zuul bit now, even if only as the gatekeeper to master | 15:31 |
richard_maw | as there's still tracking patches going on, but merging is manual | 15:31 |
Kinnison | pedroalvarez: Can you change the send address? | 15:34 |
Kinnison | pedroalvarez: it's very distracting getting mail from you about things from gerrit :-) | 15:34 |
pedroalvarez | I can, what should I put? | 15:34 |
pedroalvarez | I had problems with fake addres | 15:34 |
rjek | From: Gerrit Rietveld <gerrit.rietveld@baserock.org> | 15:35 |
jjardon | richard_maw: I didnt say it doesnt happen, but I really cant think the majority of maintainers use the tags incorrectly | 15:35 |
pedroalvarez | rietveld? | 15:35 |
rjek | pedroalvarez: It's who gerrit is named for: https://en.wikipedia.org/wiki/Gerrit_Rietveld | 15:35 |
ssam2 | richard_maw: in the case that someone's making a release and pushes the same tag a few times, it's unlikely that Baserock would be consuming the release tag any valuable versions of definitions.git straight away | 15:36 |
ssam2 | *in any valuable versions of definitions.git | 15:36 |
Kinnison | gerrit@baserock.org would be acceptable IMO | 15:36 |
Kinnison | one sec | 15:36 |
Kinnison | pedroalvarez: give it 60s and gerrit@baserock.org will forward to you | 15:38 |
pedroalvarez | great | 15:41 |
pedroalvarez | address changed | 15:41 |
pedroalvarez | now you can filter them and throw them to de bin | 15:41 |
pedroalvarez | s/de/the/ | 15:41 |
Kinnison | :-) | 15:41 |
pedroalvarez | I have to stop thinking phonetically | 15:42 |
franred | pedroalvarez, hahaha or jajaja | 15:42 |
*** tlsa [REVts2I8rW@gateway/shell/pepperfish/x-aftcrstyufiffyre] has quit [Ping timeout: 260 seconds] | 15:48 | |
franred | are we interested to update cpython to v2.7.8? this will avoid us to use some monkey-patches done in the pass and probably another errors | 15:53 |
franred | I can easily make a patch for it | 15:54 |
pedroalvarez | a gerrit patch? :P | 15:55 |
franred | if I can register my email sure | 15:56 |
ssam2 | franred: there'll be security fixes too, it's a good thing | 16:02 |
richard_maw | it's probably a good idea that my gerrit patch wasn't automatically applied to definitions.git | 16:08 |
richard_maw | there is no /dev/stdin at that point apparently | 16:08 |
richard_maw | hence the need for the review bot | 16:08 |
*** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 16:09 | |
*** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 258 seconds] | 16:22 | |
franred | python update sent for review!! \o/ thanks pedroalvarez for the configuration and the help!! | 16:28 |
pedroalvarez | richard_maw: so is your reverting patch a real patch? | 16:29 |
pedroalvarez | do you want to revert the change? | 16:29 |
richard_maw | that depends on whether we treat it as having really been applied | 16:29 |
pedroalvarez | meh, having 2 differents repositories is confusing me | 16:30 |
franred | :) | 16:30 |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:31 | |
franred | should we send patches to the mailing list? or are the people looking at http://85.199.252.116:8080 for review patches? | 17:07 |
*** mSher [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:19 | |
ssam2 | I think it's worth notifying the mailing list if you post something to the experimental gerrit instance | 17:27 |
franred | ok, I will do it | 17:32 |
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 17:41 | |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 17:51 | |
*** De|ta [~arc@195.242.156.171] has quit [Quit: leaving] | 21:24 | |
pedroalvarez | Search results for Zuul are really confusing.. Maybe I was wrong saying that we need a JSP to run it. | 22:01 |
rjek | There is no JSP, only Zuul. | 22:06 |
*** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 22:13 | |
pedroalvarez | Which is python | 22:15 |
pedroalvarez | I cant find instructions about how to configure it | 22:16 |
pedroalvarez | Maybe I can install it in the Gerrit host. | 22:17 |
* Kinnison heads to bed after that headache of an evening I feel awful :-( | 22:28 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!