14:32:09 <Xu_R> #startmeeting
14:32:09 <chwido> Meeting started Tue Dec  3 14:32:09 2013 UTC.  The chair is Xu_R. Information about MeetBot at https://wiki.openmandriva.org/om/en/MeetBot.
14:32:09 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:32:17 <Xu_R> who's here for the meeting?
14:32:40 * bero is here, but chances are we're postponing the meeting to tomorrow (see mailing list)
14:33:12 * Xu_R saw and noted
14:33:33 <n3npq> here (but won't be here tomorroww)
14:34:58 <Xu_R> arisel, benatto, crisb, fedya|2, itchka, here?
14:35:08 <fedya|2> yes
14:35:19 <Xu_R> _TPG, back?
14:36:29 <jclv> Hi :)
14:36:44 <Xu_R> hi jclv!
14:37:13 <Xu_R> Right,
14:37:19 <Xu_R> I guess we'll start then...
14:38:01 <Xu_R> Agenda: All about 2014.0 (and etc)... Dates, Specs, New Features, Prague Meeting Followup
14:38:42 <Xu_R> 1. Dates. _TPG posted a release plan, any objection to said release plan?
14:41:58 * Xu_R guesses no then?
14:42:10 <Xu_R> (http://wiki.openmandriva.org/en/2014.0/Release_plan)
14:44:19 <Xu_R> a TPG| has reappeared
14:44:29 <TPG|> Waiting for a doc :)
14:45:01 <TPG|> Lurking for conversation :)
14:45:06 <Xu_R> TPG|: :) I started on 1, heard nothing for objecting it...
14:45:38 <TPG|> Good
14:46:38 <Xu_R> Ok, guessing nobody has any objections or comments? (I personally won't be very available for the alpha release, at least... but ok)
14:47:12 <Xu_R> Guess we're moving on, then.
14:47:23 <TPG|> Ok so looks like TC accepted roadmap then
14:47:26 <Xu_R> 2. Specifications - which one stays or which one are we throwing out then?
14:48:01 <Xu_R> (https://wiki.openmandriva.org/en/2014.0/Specifications)
14:48:35 <TPG|> Sad is there are not much ideas :(
14:48:50 <Xu_R> :/
14:49:05 <Xu_R> One thing I need to wonder - does openmandriva2013.0 have an ARM port already?
14:49:07 <n3npq> TPG: careful what you wish for: hero is listening.
14:49:21 <Xu_R> Or will that be the only thing branching from Cooker?
14:49:33 * Xu_R wonders if the ARM port can get up to speed that quickly...
14:49:42 <TPG|> Let's give all people time to prepare on hard questions on Spefiications for tommorow follow-up
14:49:54 <bero> TPG|: I think the lack of ideas is mostly because we decided not to do anything big for 2014.0
14:49:59 <bero> I do have a lot of big ideas ;)
14:50:24 <bero> Xu_R: cooker has an ARM port, openmandriva2013.0 doesn't (but right now the difference between the 2 is fairly small)
14:50:29 <Xu_R> Also, I'm a bit concerned about some of those toolchain-like upgrades :|
14:50:34 <Xu_R> bero: ok
14:50:50 <n3npq> Xu_R: all depends on what you call a "port". the usage case for tablets etc is very different than desktops even if much of the software is the same. "port" != "product" on ARM.
14:51:16 <pcpa> about build options, can remove ix86_64 section. all x86_64 have sse2, so, no need to change anything. about ix86, I would want to switch to i686, that is, to not support pre p6 hardware
14:51:18 <Xu_R> n3npq: True. In this case I'm assuming a similar usage case.
14:51:54 <n3npq> Xu_R: you might try to define the usage case to better prioritize the "port"
14:52:10 <n3npq> Shubin at ROSA has many solid opinionsd
14:53:10 <bero> pcpa: i686 would bring some advantages... I think the only thing to worry about there is losing support for the earlier Geode chips (like the one in 1st and 2nd generation OLPCs), but I think at some point we can simply declare them obsolete
14:53:19 * ashweb (present)
14:53:31 <TPG|> I'm not telling that we have to collect millions of ideas, but we need few cruical things to stick with them
14:53:55 <pcpa> bero: at least in Brazil, the few oem use cases we had, they did not want Mandriva, but did want some custom image anyway
14:54:42 <bero> n3npq: I think the initial idea w/ the ARM port is to just build the same thing we have on x86 (there's no reason not to e.g. replace a traditional desktop with e.g. an Arndale Octa board), and then allow people to build customized builds that are more suitable for tablets, phones etc.
14:55:07 <n3npq> bero: obviously. you know that is just the starting point.
14:55:16 <pcpa> bero: I guesstimate that requiring i686 should make the 32 bit packages 5% or more faster on average, just considering the p6 instructions
14:55:57 <bero> n3npq: sure, we currently don't have a phone application etc. that would be needed for many uses there
14:55:57 <TPG|> Wow whole 5%
14:55:59 <Xu_R> n3npq: I'm personally unsure of ARM usage cases... Other than raspberry pi, and even that has a lot of usage cases behind it...
14:56:02 <n3npq> pcpa: basis for estimate?
14:56:28 <pcpa> conditional moves and conditional branches instructions, and my experience with jit :-)
14:56:35 <n3npq> Xu_R: you can get far more functionality for a few bucks more than Rasberry_PI.
14:56:45 <bero> pcpa: Agreed... We could decide to go a bit farther and add SSE etc., but then I think people with a modern CPU will use the 64bit port anyway
14:56:49 <TPG|> I wonder if this 5% gain is worth the effort to achieve it?
14:56:53 <n3npq> Xu_R: and most of the devel interest is  aarch64
14:57:10 <n3npq> pcpa: thankjs
14:57:42 <pcpa> bero: we need 32 bit mostly because of closed source software that only has a 32 bit build
14:58:01 <Xu_R> n3npq: ah, good to know.
14:58:09 <n3npq> bero: the problem with on beyond see is invariably "one size fits all". suddenly you have a litter of packages to support what you choose to chase
14:58:40 <bero> Xu_R: e.g. This board http://www.arndaleboard.org/wiki/index.php/O_WiKi can be used as a full PC replacement -- uses way less power and is about as fast as a PC from 2 years ago, so really usable
14:59:01 <n3npq> there is/was ELF mechanism to optionally use see+ etc that should be examined before creating a litter of packages that rpm needs to deal with.
14:59:14 <n3npq> sse+ … excuse my topes please
14:59:19 <n3npq> typoes
14:59:26 <pcpa> TPG|: most complicated part should be rpm setup, changing optflags is easy... Well, fedora already only builds i686 or newer for several years
14:59:55 <n3npq> pcpa: rpm always available to blame. see khruykin's message today.
15:01:01 <bero> yes, pretty sure that's actually libtool messing up
15:01:15 <pcpa> n3npq: :-) I think not really rpm, but repositories and any other possible side effects of s/i586/i686/ on package names
15:01:30 <n3npq> bero: my job is to wager on "Not rpm." ;-)
15:01:40 <fedya|2> n3npq: i'm working right now on aarch64 port
15:01:44 <TPG|> Pcpa yes, but is this worth to spend time on this? You need to provide all packages from main and contrib, restricted and nom-free to be rebuild and work with i686 specs.
15:02:12 <n3npq> pcpa: yes. btw, we left ARM together in agreement that aarch64 needs multilib (but wasn't there yet). Are we still in agreement?
15:02:36 <pcpa> TPG|: this is a pre mass rebuild thing to do... start with generating a gcc that defaults to i686 build
15:03:52 <TPG|> Pcpa so I guess you want to do this, and be rosponsible for i586 to i686 change?
15:03:54 <pcpa> n3npq: I did not follow much aarch64 multilib discussions, why is it required?
15:03:57 <n3npq> TPG: I don't see x32abi on your specs (and don't know the reasoning well enuf to say whether that is what you want)
15:04:30 <Xu_R> TPG|: I don't even think it's worth it for 2014.0 right now to move to i686... Shouldn't we wait for 2015.0?
15:04:32 <TPG|> Can we achieve working x32 in 4 months ?
15:05:12 <pcpa> TPG|: I am fine with it. Unless someone has some really strong reason to require support for original p5 (earlier than 2000)
15:05:18 <bero> TPG|: probably, shouldn't be a big deal aside from the mass rebuild
15:05:54 <n3npq> pcpa: I recall discussions on soft vs hard "options" (where 32 vs 64 is an "option" too because a tax is a vax) that became simpler to deploy if/when aarch64 was available. the simplification comes from prior experience on other platforms to handle 32 vs 64.
15:05:59 <pcpa> afaik we do not build a i586 kernel to start...
15:06:27 <TPG|> Well that's all about, which Coling bolded today on ML. We do not have time nor manpower for big changes, also we decided that 2014 will be only update release with new KDE, kernel, xorg and few more things. So please let's get back to topic of this TC.
15:06:36 <n3npq> but perhaps we disagree, so let me ask the question: should aarch64 be handled like every other platform using what is commonly called "multiplib"? Or something else instead?
15:07:16 <pcpa> n3npq: I do not know exactly how aarch64 is supposed to run armv7 binaries, because the instruction set is not the same, that is the 32 bit mode in aarch64 is not the same instructions of arm
15:07:43 <pcpa> should be some kind of emulation
15:07:58 <bero> n3npq: Putting on my Linaro hat, aarch64 needs special treatment because people may need more-than-2-arches (aarch64-linux-gnu, armv7-linux-gnueabi, armv7hf-linux-gnueabi and possibly even armv7hf-linux-gnu (without eabi))
15:08:20 <TPG|> Look guys if you have ideas for 2014 please add them to dedicated wiki page
15:08:29 <bero> n3npq: Putting on my "it's retarded to install 4 versions of the same library" hat, we can go with lib/lib64 just like on x86_64
15:08:43 <n3npq> TPG: re "working x32" … aldepends on what you want. using x32abi build options isn't a whole lot different than i586 -> i686 and other issues being attempted for 2014.0. but "working" is not as well defined for x32abi
15:08:45 <TPG|> If no let's get back to topic
15:09:08 <bero> But I kind of like the idea the aarch64 multilib guys have been proposing, just put all libraries in /usr/lib/ARCH/ rather than straight /usr/lib, that will also make sysroots more consistent
15:09:42 <n3npq> bero: the "multilib" battle was fought years ago, give it up. "optionally" installing what is needed isn't retarded.
15:10:33 <pcpa> bero: I only see 2 reasons for 32 bit, first is power, second is to be able to run binary only programs/libraries (e.g. armv7hl root reason was to use nvidia opengl in linux)
15:10:38 <n3npq> bero: the "yellow brick road" framework for multilib would be preferred to reinventing Newer! Better! Bestest!
15:12:41 <bero> I think it's also a bit of looking at what everyone else is/will be doing
15:13:08 <bero> If pretty much everyone else goes for a new approach, we should try to be compatible
15:13:12 <n3npq> bero: crack smoke hand waking isn't too informative
15:13:59 <n3npq> waving
15:15:54 <bero> https://wiki.debian.org/Multiarch <--- this is where the Debian based world seems to be heading
15:16:20 <bero> I don't fully like it, but I do see it has its advantages
15:17:38 <n3npq> bero: dunno what is to be gained by doing what Debian does in a OMA desktop. I'd look more closely at Poky/Yocto than Debian for ideas.
15:21:10 <n3npq> bero: that multi arch page is ancient ancient history.
15:23:15 <n3npq> I'd suggest looking closely at multlib conventions for an OMA arm "port" because of similarity to other arches. but pcpa has pointed out the fallacy that emulator is needed to do 32bit on aarch64
15:23:42 <pcpa> bero: only problem I see is that it is against KISS, and is normally required to "help" one to run closed source sotfware
15:24:13 <n3npq> and to return to TC topics: you need to identify/deploy an emulator in order for aarch64 to meet expectations of 2014.0 imho
15:25:18 <pcpa> we would need several months building aarch64 packages anyway, unless we can get real hardware, because the emulator is really slow, I guess building gcc would take like a week
15:25:43 <fedya|2> pcpa: gcc for aarch64 is ready
15:25:53 <fedya|2> pcpa: and tons of aarch64 rpms too
15:26:27 <n3npq> pcpa: slower than hercules? ;-)
15:26:38 <pcpa> n3npq: yes, hercules is quite fast
15:26:47 <fedya|2> pcpa: main issue with aarch64 it's not compiler it is making RPM's
15:27:04 <n3npq> fedya|2: wanna bet? ;-)
15:27:04 <fedya|2> n3npq: simple hello-world.c compiles about 7 seconds
15:27:10 <pcpa> fedya|2: I said gcc as a random package, assuming there was already a gcc
15:28:05 <fedya|2> pcpa:  sophisticated packages are RPM, urpmi, perl, glibc, gcc, mesa, llvm
15:28:52 <fedya|2> in my personal opinion the most laborious package it is rpm
15:29:00 <n3npq> fedya|2: are you following the stage1 -> stage4 deploy as pcpa (and Fedora-ARM) did?
15:29:19 <pcpa> just in case this is the fedora wiki page for i586 -> i686: https://fedoraproject.org/wiki/Features/F12X86Support
15:29:42 <fedya|2> n3npq: not, i use crossbuild scripts (by Bero with my improvements)
15:30:09 <n3npq> fedya|2: ok. good luck!
15:30:43 <fedya|2> n3npq: it's works little bit beter than stage1-scripts from fedora
15:30:48 <fedya|2> better*
15:31:32 <n3npq> pcpa has (or had) better and was way way ahead of Fedora-ARM using his stage1 -> stage4 scripting.
15:31:39 <fedya|2> hm
15:32:09 <fedya|2> Main issue with aarch64 it is way "how to connect it to ABF"
15:32:57 <fedya|2> now %arm packages building on ABF with qemu-static binary, but for aarch64 qemu isn't ready
15:33:07 <n3npq> the issue there was soft vs hard. 32 vs 64 needs a model (like multilib/multiarch) which appears to need an emulator (users are gonna expect a vax is a tax is a tax … no matter what the hardware does).
15:33:26 <fedya|2> and emulator V8_Foundation is slow like herd of turtles
15:35:35 <n3npq> fedya|2: I believe you. meanwhile users are going to expect interoperability no matter what anyone tells them. and an emulator (no matter how slow) would permit existing known good multilib model to be reused in ABF and in tool chains. so the TC frelevant suggestion is "FInd/deploy an emulator so that multilib could be used for 2014.0 aarch64"
15:36:12 <n3npq> you can of course do whatever you wish
15:36:46 <pcpa> http://news.opensuse.org/2013/10/01/suse-speeds-up-building-aarch64-software-in-qemu/
15:37:22 <n3npq> qemu qualifies as an emulator last I checked.
15:38:02 <fedya|2> pcpa: i saw this link
15:38:08 <fedya|2> pcpa: but it's FAKE
15:38:36 <pcpa> fedya|2: what is the problem with it?
15:38:59 <bero> aarch64 in qemu is a work in progress, currently about 70% of the instructions are implemented, but both gcc and clang use the missing 30% of instructions
15:39:04 <fedya|2> pcpa: not problems with it, it's a fake
15:39:20 <bero> So while some stuff is possible in qemu-aarch64, a lot of stuff will just fail
15:39:59 <n3npq> so the TC relevant suggestion would be to use turtle-slow V8 emulator with further switch to qemu when avail.
15:41:10 <pcpa> well, I did port lightning to aarch64 reverse engineering binutils sources and reading disasm, but afaik 1+ month ago specs are no longer under nda...
15:41:50 <n3npq> pcpa: is lightning your hit?
15:41:54 <n3npq> jit
15:41:59 <pcpa> yes
15:42:05 <fedya|2> pcpa: opensuse newsmakers said that opensuse devs boost up aarch64 builds with qemu, but devs not published sources, binaries, etc,etc, just did blah-blah-blah in maillist
15:42:11 <n3npq> worthy of being called an emulator?
15:42:46 <n3npq> fedya|2: did you ask?
15:42:55 <pcpa> n3npq: no, just telling about nda and lack of information
15:43:02 <pcpa> so most stuff was done behind curtains
15:43:09 <pcpa> as well as qemu aarch64
15:43:20 <fedya|2> pcpa: follow link from news article, to OBS, and check this: aarch64: excluded: 6802
15:43:34 <n3npq> pcpa: got it: so removal of nda should speed up emulator development
15:43:45 <bero> fedya|2: Actually suse aarch64 work is available in a public git, let me find the link
15:44:35 <bero> https://github.com/openSUSE/qemu/commits/aarch64-work
15:45:03 <fedya|2> bero: last commit 4 months ago
15:45:21 <n3npq> has qemu dealt with all the myriad vendor forks well enuf that there is One True Version? Or is it all still a vendor mess ...
15:46:41 <bero> n3npq: Still a vendor mess for the most part... Things are starting to get back on track, but it's still a long way to go
15:48:18 <bero> fedya|2: git://git.linaro.org/people/jcrigby/qemu-aarch64.git may also be interesting, AFAIK that's based on the latest opensuse codedrop
15:48:45 <fedya|2> bero: anyway Opensuse nowhere described how to working with their creativity
15:48:47 <bero> but quite old too
15:49:01 <fedya|2> how to work*
15:49:13 <bero> https://github.com/hw-claudio/qemu-aarch64-queue <--- This may actually be the best one to look at
15:49:41 <n3npq> fedya|2: asking "Show me the code." hurts little if done nicely.
15:51:05 <fedya|2> bero: i requested funding from Kate to buy arm64 boards when will be available
15:51:57 <n3npq> fedyas|2: what boards?
15:52:39 <bero> fedya|2: It'll probably be at least 4 more months before they become available unfortunately. Somehow Crapple seems to be the only company that managed to build them already :/
15:52:44 <fedya|2> n3npq: n3npq: http://www.kebur.co.uk/cms_uploads/images/SDEK002.jpg
15:52:49 <fedya|2> n3npq: :D
15:53:12 <fedya|2> n3npq: no names for boards
15:53:17 <fedya|2> n3npq: i don't know
15:53:23 <n3npq> bero: which boards expected first?
15:53:54 <bero> n3npq: My bet would be on Calxeda currently
15:54:25 <n3npq> and what is wrong with iHone5s devel? at least you have pretty parts when the world moves on … ;-)
15:54:31 <bero> I know Samsung is working on something as well, but there's a good chance they won't make it public until they already have their own end-user devices (Galaxy S5 or S6) out
15:54:51 <fedya|2> n3npq: iphone is not suitable for the development haha
15:54:57 <n3npq> bero: anyone ever talked to calxeda (or HP)?
15:55:17 <n3npq> fadya|2: that depends on the devel
15:55:18 <bero> n3npq: If someone managed to crack the bootloader, it would be fun... But without that, wrong kernel...
15:56:03 <fedya|2> bero: hm
15:56:13 <bero> n3npq: I know Linaro is in contact with calxeda (and I know I'll be among the first 20 Linaro people to get hold of an aarch64 board, so we might even have one at our disposal before they become public)
15:56:21 <fedya|2> bero: issue with static files still remain https://abf.rosalinux.ru/build_lists/1452420
15:56:49 <n3npq> bero: I was talking to Calxeda manager wrto @rpm5.org build hosts 1y ago. OpenMandriva (and ROSA) should have far more clout than I had
15:56:51 <fedya|2> bero: i have a lots of affected packages with static files, gcc, ppl, few libs...
15:56:59 <n3npq> 1.5y ago
15:57:06 <fedya|2> bero: let me create an ARM chroot on your pc
15:57:12 <fedya|2> with qemu-static
15:57:32 <bero> fedya|2: That is expected, --disable-static was added to cooker defaults after 2013.0 was branched off (we'll likely also see that failure on x86 rebuilds)
15:57:56 <fedya|2> bero: on x86 all working well
15:58:11 <fedya|2> bero: https://abf.rosalinux.ru/build_lists/1452419 - ARM
15:58:19 <fedya|2> bero: https://abf.rosalinux.ru/build_lists/1452418 X86
15:58:35 <fedya|2> same build, same RPM package, same macro...
15:58:53 <fedya|2> and different results
15:58:59 <n3npq> fedya|2: https://abf.rosalinux.ru/build_lists/1452420 is insanely simple rpm issue to fix or hack around afaict
15:59:44 <fedya|2> n3npq: yes, i can add to spec --enable-static, but WHY onm x86 with same configure options all working well?
16:00:03 <fedya|2> ARM and X86 have same options for configure with --disable-static
16:00:13 <fedya|2> but it's working only for ARM
16:00:17 <fedya|2> static always disabled
16:00:32 <n3npq> fedya|2: some questions aren't worth asking. there are many work arounds
16:01:08 <bero> fedya|2: weird... Looks like only ARM is doing the right thing there, will investigate
16:01:22 <fedya|2> bero: YES
16:01:35 <fedya|2> bero: x86 always ignore --disable-static
16:01:37 <n3npq> my guess is that ABF is having issues configuring identical VM's for builds.
16:01:46 <fedya|2> bero: just see at build log
16:02:00 <fedya|2> n3npq: not
16:02:09 <fedya|2> n3npq: you're not right
16:02:22 <n3npq> fedya|2 it most surely is my "guess" ;-)
16:03:07 <fedya|2> n3npq: ABF launch  reference virtual machine, and mock-urpm creates a chroot
16:03:11 <fedya|2> it's not cached chroot
16:03:19 <n3npq> heaven forbid that I should commit heresy and sacrilege in the Church of ROSA: I'm not "pussy riot" ;-)
16:03:43 <fedya|2> n3npq: i'm not rosist ;)
16:04:44 <fedya|2> n3npq: i did not hired by ROSA
16:04:49 <n3npq> fedya|2: note that the underlying design flaw is trying to track/configure builds according to arch (or platform) strings. we had this discussion privately
16:04:56 <fedya|2> just doing things in free time
16:05:14 <fedya|2> n3npq: yes, i remember it
16:05:23 <n3npq> good
16:06:04 <fedya|2> https://issues.openmandriva.org/show_bug.cgi?id=389
16:06:15 <fedya|2> aarch64 related RPM bug
16:09:58 <bero> fedya|2: I'm pretty sure that's libtool's doing and not rpm's
16:10:43 <n3npq> fedya|2: seen. RPM is commonly blamed for everything: Cапожник без сапог.
16:11:10 <bero> fedya|2: Hmm, on my x86_64 box, ppl rebuild doesn't put --disable-static on the configure command line. I guess we have an arch specific configure override somewhere
16:12:28 <n3npq> bero: why would one want to use a broken configuration? I'm shocked, simply shocked.
16:14:29 <fedya|2> n3npq: "Сапожник без сапог" it not relevant proverb for RPM :)
16:14:51 <bero> n3npq: "broken" as in --disable-static?
16:15:34 <n3npq> fedya|2: how irrelevant? irreverent I'm sure
16:15:55 <fedya|2> n3npq: not ;)
16:16:20 <fedya|2> n3npq: it's pretty good sounds if RPM can't install rpm files
16:17:13 <n3npq> if you examine ML, then you will quickly see that what RPM is _EXPECTED_ to do is not install rpm files correctly
16:17:38 <n3npq> man bites dog
16:20:26 <fedya|2> bero:
16:20:40 <fedya|2> bero: while ur sabrelite does not working
16:20:43 <fedya|2> bero: just do
16:20:46 <fedya|2> bero: su - fedya
16:20:50 <fedya|2> bero: ssh localhost -p 19999
16:22:00 <bero> fedya|2: [fedya@filzbach ~]$ ssh -p 19999 localhost
16:22:00 <bero> fedya@localhost's password:
16:22:00 <bero> I don't have your password... Guess we need to place ssh keys
16:22:08 <fedya|2> bero: see pm
16:22:14 <bero> ok, thx
16:22:45 * Xu_R is going to #endmeeting here because he forgot to
16:22:48 <Xu_R> #endmeeting