Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Erich Titl]

Am 04.01.2016 um 10:54 schrieb Andrew:
> 04.01.2016 11:32, Erich Titl пишет:
>> Hi Andrew
>>
>> Am 04.01.2016 um 10:18 schrieb Andrew:
>>> IMHO it's bad idea - toolchain depends on system libs (so it may not
>>> work on some systems), + it may be 32bit or 64bit.
>> We used to not be system dependent, but I agree, it is a big difference.
> Binaries compiled for host system (gcc, binutils and so on) are 
> system-dependent and may not work on other distros (or, at least, all 
> that stuff should be compiled as static or on some old legacy distro - 
> there is some forward ABI compatibility in gcc/glibc, that may be 
> breaked between major gcc releases, but there's no backward compatibility).
> In any case, this is a headache to support it.

We need to build a standard virtual machine as a development environment
to overcome this.

>> Still, having multiple workspaces from the same repository is asking for
>> trouble.
> Why? I have 2-3 workspaces with same local git repo (that 1) saves space 
> and 2) allows to easily merge branches); there's script 
> 'git-new-workdir' to create sch environment; it is usually available in 
> git package.

Well, I am not that good at managing multiple Avatars of myself, that's why.

cheers

ET

--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Andrew]

04.01.2016 11:32, Erich Titl пишет:
> Hi Andrew
>
> Am 04.01.2016 um 10:18 schrieb Andrew:
>> IMHO it's bad idea - toolchain depends on system libs (so it may not
>> work on some systems), + it may be 32bit or 64bit.
> We used to not be system dependent, but I agree, it is a big difference.
Binaries compiled for host system (gcc, binutils and so on) are 
system-dependent and may not work on other distros (or, at least, all 
that stuff should be compiled as static or on some old legacy distro - 
there is some forward ABI compatibility in gcc/glibc, that may be 
breaked between major gcc releases, but there's no backward compatibility).
In any case, this is a headache to support it.
> Still, having multiple workspaces from the same repository is asking for
> trouble.
Why? I have 2-3 workspaces with same local git repo (that 1) saves space 
and 2) allows to easily merge branches); there's script 
'git-new-workdir' to create sch environment; it is usually available in 
git package.
> cheers
>
> ET
>
> --
>
> ___
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel


--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Erich Titl]

Hi Andrew

Am 04.01.2016 um 10:18 schrieb Andrew:
> IMHO it's bad idea - toolchain depends on system libs (so it may not 
> work on some systems), + it may be 32bit or 64bit.

We used to not be system dependent, but I agree, it is a big difference.
Still, having multiple workspaces from the same repository is asking for
trouble.

cheers

ET

--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Andrew]

IMHO it's bad idea - toolchain depends on system libs (so it may not 
work on some systems), + it may be 32bit or 64bit.

03.01.2016 22:54, Erich Titl пишет:
> Am 03.01.2016 um 20:28 schrieb Andrew:
>> Use two separate dirs with same repo?
>>
>> In any case, gcc update may also break binary compatibility.
>>
> Crufty way to handle this, we need to take the development environment
> into Git
>
> cheers
>
> ET
>
>
> --
>
> ___
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel


--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Erich Titl]

Am 03.01.2016 um 20:28 schrieb Andrew:
> Use two separate dirs with same repo?
> 
> In any case, gcc update may also break binary compatibility.
> 

Crufty way to handle this, we need to take the development environment
into Git

cheers

ET


--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Andrew]

Use two separate dirs with same repo?

In any case, gcc update may also break binary compatibility.

03.01.2016 20:40, Erich Titl пишет:
> Am 03.01.2016 um 16:11 schrieb Andrew:
>> I just replaced uClibc with uClibc-ng (uClibc fork) in toolchain. +
>> added some compat fixes to packages.
> Right, but how to switch from master to maint and back?
>
> cheers
>
> ET
>
>
>
> --
>
> ___
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel


--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Erich Titl]

Am 03.01.2016 um 16:11 schrieb Andrew:
> I just replaced uClibc with uClibc-ng (uClibc fork) in toolchain. + 
> added some compat fixes to packages.

Right, but how to switch from master to maint and back?

cheers

ET



--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Andrew]

I just replaced uClibc with uClibc-ng (uClibc fork) in toolchain. + 
added some compat fixes to packages.

Tree is compiled OK.

03.01.2016 16:25, Erich Titl пишет:
> Hi
>
> How do we handle this step for the development environment?
>
> cheers
>
> ET
>
>
>  Weitergeleitete Nachricht 
> Betreff:  [leaf:bering-uclibc] New commit by Andrew Denisenko
> Datum:Fri, 01 Jan 2016 14:57:33 +
> Von:  LEAF Linux Embedded Appliance Framework Git repository
> 
> Antwort an:   LEAF Linux Embedded Appliance Framework Git repository
> 
> An:   LEAF Linux Embedded Appliance Framework Git repository
> 
>
>
>
>  Branch: master
>
> toolchain: switch to uClibc-ng
>
> By Andrew Denisenko on 01/01/2016 14:56
> *View Changes*
> 
>
> 
>
> Sent from sourceforge.net because you indicated interest in
> https://sourceforge.net/p/leaf/bering-uclibc/
>
> To unsubscribe from further messages, please visit
> https://sourceforge.net/auth/subscriptions/
>
>
>
>
> --
>
> ___
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel


--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Andrew]

30.11.2015 10:59, Erich Titl пишет:
> Hi Andrew
>
> Am 30.11.2015 um 00:19 schrieb Andrew:
>> Hi.
>>
>> I just renamed kernel configs corresponding to kernel minor version, not
>> kernel release (in this case - *-4.1.13-* to *-4.1-*).
>>
>> Storing kernel revision in config name IMHO is useless; kernels usually
>> doesn't provide any new config variables in fresh bugfix releases (I
>> can't remember such cases), but kernel update adds useless configs
>> renaming actions.
> Is there a difference in the generated image names?
No. Only kernel configs were renamed.

--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Erich Titl]

Hi Andrew

Am 30.11.2015 um 00:19 schrieb Andrew:
> Hi.
> 
> I just renamed kernel configs corresponding to kernel minor version, not 
> kernel release (in this case - *-4.1.13-* to *-4.1-*).
> 
> Storing kernel revision in config name IMHO is useless; kernels usually 
> doesn't provide any new config variables in fresh bugfix releases (I 
> can't remember such cases), but kernel update adds useless configs 
> renaming actions.

Is there a difference in the generated image names? If so, there may be
a clash in the upgrade utility. I was never happy with kernel images
having a release number in the name, but if this changed now we have to
provide a migration in upgrade.

cheers

Erich


--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Andrew]

Hi.

I just renamed kernel configs corresponding to kernel minor version, not 
kernel release (in this case - *-4.1.13-* to *-4.1-*).

Storing kernel revision in config name IMHO is useless; kernels usually 
doesn't provide any new config variables in fresh bugfix releases (I 
can't remember such cases), but kernel update adds useless configs 
renaming actions.

30.11.2015 00:23, Erich Titl пишет:
> Hi Andrew
>
> What exactly will this change and why is it necessary?
>
> Thanks
>
> ET
>
>  Weitergeleitete Nachricht 
> Betreff:  [leaf:bering-uclibc] New commit by Andrew Denisenko
> Datum:Sun, 29 Nov 2015 22:20:56 +
> Von:  LEAF Linux Embedded Appliance Framework Git repository
> 
> Antwort an:   LEAF Linux Embedded Appliance Framework Git repository
> 
> An:   LEAF Linux Embedded Appliance Framework Git repository
> 
>
>
>
>  Branch: master
>
> linux: use branch name instead of release name for kernel configs
>
> By Andrew Denisenko on 11/29/2015 22:19
> *View Changes*
> 
>
> 
>
> Sent from sourceforge.net because you indicated interest in
> https://sourceforge.net/p/leaf/bering-uclibc/
>
> To unsubscribe from further messages, please visit
> https://sourceforge.net/auth/subscriptions/
>
>
>
>
> --
>
> ___
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel


--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Andrew]

What files do you mean?
You can check what is changed during merge by 'git diff  

22.11.2015 13:41, Erich Titl пишет:
> Am 22.11.2015 um 11:23 schrieb Andrew:
>> Hi.
>>
>> Merge just touches files which contains fixes.
> Logical, but what about files that are newer?
>
> cheers
>
> ET
>
>
>
> --
>
> ___
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel


--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Erich Titl]

Am 22.11.2015 um 11:23 schrieb Andrew:
> Hi.
> 
> Merge just touches files which contains fixes.

Logical, but what about files that are newer?

cheers

ET



--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Andrew]

Hi.

Merge just touches files which contains fixes.

21.11.2015 17:29, Erich Titl пишет:
> Am 21.11.2015 um 08:56 schrieb Andrew:
>> Hi.
>>
>> I've added some minor fixes to maint-5.1 branch (for ex.,
>> usbhid-ups-related hiddev nodes privileges), and then merge it to maint
> Ah, and these fixes did not make it to maint before. Is there no risk of
> carrying unwanted backport changes this way? Would a cherry picked
> change not be the more intuitive way?
>
> cheers
>
> ET
>
> --
>
> ___
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel


--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Erich Titl]

Am 21.11.2015 um 08:56 schrieb Andrew:
> Hi.
> 
> I've added some minor fixes to maint-5.1 branch (for ex., 
> usbhid-ups-related hiddev nodes privileges), and then merge it to maint

Ah, and these fixes did not make it to maint before. Is there no risk of
carrying unwanted backport changes this way? Would a cherry picked
change not be the more intuitive way?

cheers

ET

--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Andrew]

Hi.

I've added some minor fixes to maint-5.1 branch (for ex., 
usbhid-ups-related hiddev nodes privileges), and then merge it to maint

21.11.2015 00:40, Erich Titl пишет:
> Hi Andrew
>
> Just for curiosity, what does this achieve? I don't understand the logic
> in this.
>
> cheers
>
> ET
>
>
>  Weitergeleitete Nachricht 
> Betreff:  [leaf:bering-uclibc] New commit by Andrew Denisenko
> Datum:Fri, 20 Nov 2015 21:25:21 +
> Von:  LEAF Linux Embedded Appliance Framework Git repository
> 
> Antwort an:   LEAF Linux Embedded Appliance Framework Git repository
> 
> An:   LEAF Linux Embedded Appliance Framework Git repository
> 
>
>
>
>  Branch: maint
>
> Merge branch 'maint-5.1' into maint
>
> By Andrew Denisenko on 11/20/2015 21:25
> *View Changes*
> 
>
> 
>
> Sent from sourceforge.net because you indicated interest in
> https://sourceforge.net/p/leaf/bering-uclibc/
>
> To unsubscribe from further messages, please visit
> https://sourceforge.net/auth/subscriptions/
>
>
>
>
> --
>
> ___
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel


--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel