Re: Installation Media and supportability of i386 in 18.04 LTS Re: Ubuntu Desktop on i386

[Mark Shuttleworth]

OK, I'm reassured that we're thinking about this appropriately, thanks
Dimitri & friends.

Mark

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Installation Media and supportability of i386 in 18.04 LTS Re: Ubuntu Desktop on i386

[Dimitri John Ledkov]

Hello Mark,

On 29 June 2016 at 14:37, Mark Shuttleworth  wrote:
>
> Folks, I think we need to understand whether i386 won't be widely used
> for very small IoT devices and hence be important for developers
> targeting those. I accept i386 i no longer relevant for PC's and
> laptops, but I would not be surprised if 32-bit x86 is used in small
> 'embedded' environments. Please factor this in to the discussion, and
> let's circle back to review once there is an assessment that includes
> that insight.
>

Indeed. I believe we will continue to have 32-bit x86 port in 18.04
LTS and we will continue to asses which subsets of it are reasonable
to support and ship in various form factors.

Looking at the SoC and Embedded CPU product lines from Intel (Atom and
launched SoFIA), AMD, VIA - they are all 64-bit capable CPUs.

Is the choice to go i386 there is not due CPU capabilities, but due to
memory constraints?

I think it might make sense to investigate if we can optimise and
reduce our minimal required committed RAM usage on 64-bit, from fixing
software bugs to pulling tricks with compressed RAM and swap. If we
can hit low enough memory usage, a choice to use 64-bit will become
less of issue in such devices. And at the same time improve our
deployment density in the cloud scenarios.

Failing that, is there a sufficient demand in the embedded space for x32 port?

Above are some of the questions to resolve in the coming years.

-- 
Regards,

Dimitri.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Installation Media and supportability of i386 in 18.04 LTS Re: Ubuntu Desktop on i386

[Dimitri John Ledkov]

Hello,

On 28 June 2016 at 21:08, Seth Arnold  wrote:
>> 18.04 LTS:
>> * continue to provide i386 port to run legacy applications on amd64
>> * stop producing i386 d-i / netboot installer
>> * stop producing i386 kernel
>> * stop producing i386 cloud-images
>> * stop producing i386 ubuntu-desktop.iso
>> * stop producing i386 ubuntu-server.iso
>>
>> 18.10+:
>> * Stop providing i386 port
>> * Run legacy i386 only application in snaps / containers / virtual machines
>
> I'm afraid this proposal may strand some current i386 users on a release
> with no lifetime to it.
>
> 16.04's 32 bit support has a five-year lifespan. We may not be able to
> support the whole thing for the full five years but it should mostly work.
>
> But if we release 16.10, 17.04, 17.10 i386, we're basically encouraging
> users to install them and upgrade them and then find out in mid-2018 that
> they've reached the end of their OS life and no way back to the safety of
> 16.04 LTS.

My current hunch is like this at the moment:

- 18.04 to still have an i386 port in the archive, and be upgradable to.

- 18.04 not having desktop/server install media (however maybe even
releases before that)

- 18.04 has "ubuntu-desktop" but without security support

- 18.04 on i386 having a limited security support, driven only by
particular products if any are on the support timeline at the time

-- 
Regards,

Dimitri.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: python(3)-h5py not mpi-aware

[Nish Aravamudan]

On 30.06.2016 [16:17:31 +0200], Lars Bungum wrote:
> Dear all,
> 
> running this script:
> 
> import mpi4py
> from mpi4py import MPI
> import h5py
> 
> rank = MPI.COMM_WORLD.rank  # The process ID (integer 0-3 for 4-process run)
> 
> print(rank)
> f = h5py.File('parallel_test.hdf5', 'w', driver='mpio', comm=MPI.COMM_WORLD)
> 
> dset = f.create_dataset('test', (4,), dtype='i')
> dset[rank] = rank
> 
> f.close()
> 
> yields this result, for both python versions for as well 14.04 as 16.04
> (Kubuntu):
> 
> $ mpirun -np 4 python3 multiproc_hdf5_mpi4py.py
> Traceback (most recent call last):
>   File "multiproc_hdf5_mpi4py.py", line 1, in 
> import mpi4py
> ImportError: No module named 'mpi4py'

Do you have either python-mpi4py or python3-mpi4py installed?

-Nish

--
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

python(3)-h5py not mpi-aware

[Lars Bungum]

Dear all,

running this script:

import mpi4py
from mpi4py import MPI
import h5py

rank = MPI.COMM_WORLD.rank  # The process ID (integer 0-3 for 4-process run)

print(rank)
f = h5py.File('parallel_test.hdf5', 'w', driver='mpio', comm=MPI.COMM_WORLD)

dset = f.create_dataset('test', (4,), dtype='i')
dset[rank] = rank

f.close()

yields this result, for both python versions for as well 14.04 as 16.04 
(Kubuntu):


$ mpirun -np 4 python3 multiproc_hdf5_mpi4py.py
Traceback (most recent call last):
  File "multiproc_hdf5_mpi4py.py", line 1, in 
import mpi4py
ImportError: No module named 'mpi4py'
Traceback (most recent call last):
  File "multiproc_hdf5_mpi4py.py", line 1, in 
import mpi4py
ImportError: No module named 'mpi4py'
Traceback (most recent call last):
  File "multiproc_hdf5_mpi4py.py", line 1, in 
import mpi4py
ImportError: No module named 'mpi4py'
Traceback (most recent call last):
  File "multiproc_hdf5_mpi4py.py", line 1, in 
import mpi4py
ImportError: No module named 'mpi4py'
---
Primary job  terminated normally, but 1 process returned
a non-zero exit code.. Per user-direction, the job has been aborted.
---
--
mpirun detected that one or more processes exited with non-zero status, 
thus causing

the job to be terminated. The first process to do so was:

  Process name: [[43945,1],1]
  Exit code:1


I have googled it, and it seems  that the package must be rebuilt, with 
the correct options referring it to the installation of mpi.  I tried 
rebuilding the package myself, but was not (yet) able to figure out 
where to actually change that settings.  (debian/rules? how?).


Perhaps you could fix this in the central repository as package maintainers?

Kind regards,
Lars B







--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

re: bcmwl-kernel-source and linux kernel 4.7

[Javad Karabi]

it looks like IEEE80211_BAND_2GHZ/IEEE80211_BAND_5GHZ, has been renamed
to NL80211_BAND_2GHZ/NL80211_BAND_5GHZ

i have tested the below patch on my machine, and i am able to successfully
build, and use, my wireless adapter with it



diff --git a/src/wl/sys/wl_cfg80211_hybrid.c
b/src/wl/sys/wl_cfg80211_hybrid.c
index de0cc4b..b58268c 100644
--- a/src/wl/sys/wl_cfg80211_hybrid.c
+++ b/src/wl/sys/wl_cfg80211_hybrid.c
@@ -234,7 +234,7 @@ static s8 wl_dbg_estr[][WL_DBG_ESTR_MAX] = {
 #endif

 #define CHAN2G(_channel, _freq, _flags) { \
- .band = IEEE80211_BAND_2GHZ, \
+ .band = NL80211_BAND_2GHZ, \
  .center_freq = (_freq), \
  .hw_value = (_channel), \
  .flags = (_flags), \
@@ -243,7 +243,7 @@ static s8 wl_dbg_estr[][WL_DBG_ESTR_MAX] = {
 }

 #define CHAN5G(_channel, _flags) { \
- .band = IEEE80211_BAND_5GHZ, \
+ .band = NL80211_BAND_5GHZ, \
  .center_freq = 5000 + (5 * (_channel)), \
  .hw_value = (_channel), \
  .flags = (_flags), \
@@ -377,7 +377,7 @@ static struct ieee80211_channel __wl_5ghz_n_channels[]
= {
 };

 static struct ieee80211_supported_band __wl_band_2ghz = {
- .band = IEEE80211_BAND_2GHZ,
+ .band = NL80211_BAND_2GHZ,
  .channels = __wl_2ghz_channels,
  .n_channels = ARRAY_SIZE(__wl_2ghz_channels),
  .bitrates = wl_g_rates,
@@ -385,7 +385,7 @@ static struct ieee80211_supported_band __wl_band_2ghz =
{
 };

 static struct ieee80211_supported_band __wl_band_5ghz_a = {
- .band = IEEE80211_BAND_5GHZ,
+ .band = NL80211_BAND_5GHZ,
  .channels = __wl_5ghz_a_channels,
  .n_channels = ARRAY_SIZE(__wl_5ghz_a_channels),
  .bitrates = wl_a_rates,
@@ -393,7 +393,7 @@ static struct ieee80211_supported_band __wl_band_5ghz_a
= {
 };

 static struct ieee80211_supported_band __wl_band_5ghz_n = {
- .band = IEEE80211_BAND_5GHZ,
+ .band = NL80211_BAND_5GHZ,
  .channels = __wl_5ghz_n_channels,
  .n_channels = ARRAY_SIZE(__wl_5ghz_n_channels),
  .bitrates = wl_a_rates,
@@ -1874,8 +1874,8 @@ static s32 wl_alloc_wdev(struct device *dev, struct
wireless_dev **rwdev)
  wdev->wiphy->max_num_pmkids = WL_NUM_PMKIDS_MAX;
 #endif
  wdev->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
BIT(NL80211_IFTYPE_ADHOC);
- wdev->wiphy->bands[IEEE80211_BAND_2GHZ] = &__wl_band_2ghz;
- wdev->wiphy->bands[IEEE80211_BAND_5GHZ] = &__wl_band_5ghz_a;
+ wdev->wiphy->bands[NL80211_BAND_2GHZ] = &__wl_band_2ghz;
+ wdev->wiphy->bands[NL80211_BAND_5GHZ] = &__wl_band_5ghz_a;
  wdev->wiphy->signal_type = CFG80211_SIGNAL_TYPE_MBM;
  wdev->wiphy->cipher_suites = __wl_cipher_suites;
  wdev->wiphy->n_cipher_suites = ARRAY_SIZE(__wl_cipher_suites);
@@ -1998,7 +1998,7 @@ static s32 wl_inform_single_bss(struct
wl_cfg80211_priv *wl, struct wl_bss_info
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 39)
  freq = ieee80211_channel_to_frequency(notif_bss_info->channel,
  (notif_bss_info->channel <= CH_MAX_2G_CHANNEL) ?
- IEEE80211_BAND_2GHZ : IEEE80211_BAND_5GHZ);
+ NL80211_BAND_2GHZ : NL80211_BAND_5GHZ);
 #else
  freq = ieee80211_channel_to_frequency(notif_bss_info->channel);
 #endif
@@ -2112,7 +2112,7 @@ wl_notify_connect_status(struct wl_cfg80211_priv *wl,
struct net_device *ndev,

  freq = ieee80211_channel_to_frequency(bss_info_channel,
  (bss_info_channel <= CH_MAX_2G_CHANNEL) ?
- IEEE80211_BAND_2GHZ : IEEE80211_BAND_5GHZ);
+ NL80211_BAND_2GHZ : NL80211_BAND_5GHZ);

  channel = ieee80211_get_channel(wl_to_wiphy(wl), freq);
  cfg80211_ibss_joined(ndev, (u8 *)>bssid, channel, GFP_KERNEL);
@@ -2247,10 +2247,10 @@ static void wl_ch_to_chanspec(struct
ieee80211_channel *chan, struct wl_join_par
  join_params->params.chanspec_list[0] =
 ieee80211_frequency_to_channel(chan->center_freq);

- if (chan->band == IEEE80211_BAND_2GHZ) {
+ if (chan->band == NL80211_BAND_2GHZ) {
  chanspec |= WL_CHANSPEC_BAND_2G;
  }
- else if (chan->band == IEEE80211_BAND_5GHZ) {
+ else if (chan->band == NL80211_BAND_5GHZ) {
  chanspec |= WL_CHANSPEC_BAND_5G;
  }
  else {
@@ -2876,7 +2876,7 @@ static s32 wl_update_wiphybands(struct
wl_cfg80211_priv *wl)

  if (phy == 'n' || phy == 'a' || phy == 'v') {
  wiphy = wl_to_wiphy(wl);
- wiphy->bands[IEEE80211_BAND_5GHZ] = &__wl_band_5ghz_n;
+ wiphy->bands[NL80211_BAND_5GHZ] = &__wl_band_5ghz_n;
  }

  return err;
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss