Monday, 2018-06-18

*** frinring_ is now known as frinring02:26
NeoChapayabranson: i create pr for fix build master branch06:41
NeoChapayWho can help me with mic error ?
r0kk3rzValueError: invalid literal for int() with base 10: '1+git2'08:32
r0kk3rzsounds straight forward enough08:32
abransonNeoChapay, r0kk3rz: mic didn't work with the latest rpm, but a fix has been merged now I think. maybe that needs an upgrade? lbt?08:34
NeoChapayabranson: version 0.14+git5 work fine
r0kk3rzabranson: you had to delve into the arcane innards of mic? i hope you had a bottle of whisky handy08:43
abransonr0kk3rz: wasn't me, I haven't got my wizard robe and hat yet08:57
abransonNeoChapay: about the libzypp - thanks for the patch, but I've got a newer upgrade of that in progress.  you really shouldn't use the master atm - that version won't be used.08:58
abranson*it's not ready yet though*08:59
jusar0kk3rz: thank you! merged10:53
r0kk3rzthat was quick :)10:56
*** Son_Goku is now known as Conan_Kudo11:33
*** Conan_Kudo is now known as Son_Goku11:34
r0kk3rzlbt: another one for the mirror please -
malwhy do we keep mirrors of so many repos?11:54
r0kk3rzbecause thats TheWayTM11:55
r0kk3rzit works nicely with gitlab at least11:55
malI don't really understand why using the original git as the submodule would be any different12:00
r0kk3rzall i know is that lbt requested it be this way, im sure he has his reasons12:01
lbtsome of the packages in mer:core use a git submodules. That means they don't actually have the source in them. By using a local mirror we ensure that we can build even if gitlab/hub/orious/... goes down for a bit.12:09
lbtwe have had issues in the past where github was blocked for our users too12:09
lbtso like any distro we have a local copy of the src we build ... that's all there really is to it12:10
Son_Gokuit's generally not a bad idea to have a local copy in some form12:10
Son_Gokuusually having the tarball stored in something like dist-git is usually what's done, but having mirrors of the code tree works too12:11
r0kk3rzi like that i can click the module commit ref and view the source in a familiar interface, instead of whatever upstream happens to use12:13
mallbt: btw, how should we handle projects with using mercurial? for example SDL uses that and the current way is a bit annoying for updating, could we use mercurial to git converter and push te generated git repo as a mirror?12:13
w00tlbt: or worse, if it vanishes altogether - you're then left holding a license-compliance bag in some cases :)12:13
lbtw00t: *nod* :)12:13
lbtmal: drop SDL ?12:14
mallbt: ?12:14
lbtbut yeah - it's the Maintainer's call really. I'm not sure about using a convertor automatically but it seems fine if they do that12:15
mallbt: I was trying to update SDL and I was thinking how that should be done12:15
r0kk3rzsrc dump miror?12:15
mallbt: there is the SDL mirror on github but afaik that is unofficial12:15
lbtessentially get the source into git - either by converting or by doing a mega-commit12:16
lbtthe mega-commit needs to be super well documented in the commit so that it can be trusted - that's really hard12:16
malthere seems to be at least two tools for making git mirror of a mercurial repo, hg-git and git-remote-hg13:12
pvuorelamal: if sdl git mirror is not official enough, i'd maybe go with extracted sources + patch files.13:46
malpvuorela: would that extracted sources method be more preferred than using hg-git or something for creating a git mirror in mer-core?13:51
pvuorelamal: guess it depends on how it goes. if the git mirror is automated, sure that would be nice, but if's updated with a PR it would be hard to verify.13:55
lbtI would prefer to see a reproducable mirror - ie if hg-git produces an identical git mirror on 2 runs then that's a good solution to me13:57
pvuorelaif that mirror is updated by a contributor, i expect more work to me doing the same thing with hg-git compared to extracting upstream .tar.gz and running diff.13:59
mallbt: I need to test how those two tools I mentioned work14:00
r0kk3rzim not sure hg-git is what we want14:00
r0kk3rzits a plugin for mercurial, not the other way around14:00
malr0kk3rz: yes, but it can be used to mirror also, saw instructions how to do that14:01
r0kk3rzah nice14:01
malr0kk3rz: so hg-git is part of mercurial (or extension to that) whereas git-remote-hg is working on top of git directly14:02
malpvuorela: assuming the mirrow is updated via MRs you could also compare the mirror by downloading the source package and make the same diff, only difference would be that one method contains commit history and the other doesn't14:07
pvuorelamal: unless package and version control have differences. e.g. documentation generated. didn't check, though.14:10
malpvuorela: yep, I'll do some testing, just to make sure what did you mean by the method of extrating the sources, so we exact the sources to a git project? btw, in the past some hg to git system was probably used as has the history14:18
pvuorelamal: yea, was probably done that way. with extracting i meant something like: git rm everything except rpm dir in libsdl, extract .tar.gz into a sub-directory, git add the directory.14:25
malpvuorela: yep, thought something like that14:28
*** Nokius_ is now known as Nokius21:03

Generated by 2.14.0 by Marius Gedminas - find it at!