Re: [dpdk-dev] [PATCH] pci: fix glibc 2.25 warning regarding major/minor definitions
Hi Nirmoy, On 04/04/2017 01:32 PM, Nirmoy Das wrote: > fixes: > error: In the GNU C Library, "makedev" is defined > by . For historical compatibility, it is > currently defined by as well, but we plan to > remove this soon. To use "makedev", include > directly. If you did not intend to use a system-defined macro > "makedev", you should undefine it after including . [-Werror] > dev = makedev(major, minor); > You forgot the 'Signed-off-by' line which is required for patches. See doc/guides/contributing/patches.rst -- markos SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
Re: [dpdk-dev] [PATCH] pci: fix glibc 2.25 warning regarding major/minor definitions
On 04/04/2017 01:50 PM, Markos Chandras wrote: > Hi Nirmoy, > > On 04/04/2017 01:32 PM, Nirmoy Das wrote: >> fixes: >> error: In the GNU C Library, "makedev" is defined >> by . For historical compatibility, it is >> currently defined by as well, but we plan to >> remove this soon. To use "makedev", include >> directly. If you did not intend to use a system-defined macro >> "makedev", you should undefine it after including . [-Werror] >> dev = makedev(major, minor); >> > > You forgot the 'Signed-off-by' line which is required for patches. > > See doc/guides/contributing/patches.rst > Ah never mind I just saw v2. -- markos SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
[dpdk-dev] [PATCH] examples: ethtool: Link against librte_pmd_ixgbe if necessary
The librte_ethtool library depends on librte_pmd_ixgbe if that pmd driver is enabled so we need to link against it when we compile the ethtool application. It fixes the following build problem: /usr/lib64/gcc/x86_64-suse-linux/6/../../../../x86_64-suse-linux/bin/ld: warning: librte_pmd_ixgbe.so.1, needed by /home/abuild/rpmbuild/BUILD/ dpdk-17.02/examples/ethtool/lib/x86_64-native-linuxapp-gcc/lib/ librte_ethtool.so, not found (try using -rpath or -rpath-link) /home/abuild/rpmbuild/BUILD/dpdk-17.02/examples/ethtool/lib/ x86_64-native-linuxapp-gcc/lib/librte_ethtool.so: undefined reference to `rte_pmd_ixgbe_set_vf_rxmode@DPDK_17.02' collect2: error: ld returned 1 exit status Cc: Nirmoy Das Signed-off-by: Markos Chandras --- examples/ethtool/ethtool-app/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/examples/ethtool/ethtool-app/Makefile b/examples/ethtool/ethtool-app/Makefile index 09c66ad19..9382ca7c3 100644 --- a/examples/ethtool/ethtool-app/Makefile +++ b/examples/ethtool/ethtool-app/Makefile @@ -50,5 +50,8 @@ CFLAGS += $(WERROR_FLAGS) LDLIBS += -L$(subst ethtool-app,lib,$(RTE_OUTPUT))/lib LDLIBS += -lrte_ethtool +ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y) +LDLIBS += -lrte_pmd_ixgbe +endif include $(RTE_SDK)/mk/rte.extapp.mk -- 2.11.0
Re: [dpdk-dev] [PATCH] examples: ethtool: Link against librte_pmd_ixgbe if necessary
On 02/17/2017 04:11 PM, Remy Horton wrote: > > On 16/02/2017 16:17, Markos Chandras wrote: >> The librte_ethtool library depends on librte_pmd_ixgbe if that >> pmd driver is enabled so we need to link against it when we compile >> the ethtool application. It fixes the following build problem: > > For some reason this is not an issue with my Fedora box, so I'm guessing > SUSE is stricter with sub-depenencies of libraries. Does this affect any > of the OpenSUSE Linux distributions? > > ..Remy Hi Remy, Yeah I am seen this problem in the openSUSE Tumbleweed distribution. I think Nirmoy may have seen that in openSUSE Leap but I will let him confirm that. -- markos SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
Re: [dpdk-dev] [PATCH] mk: disable new gcc truncation flag
On 06/02/2017 05:31 PM, Nirmoy Das wrote: > disable truncation check to ignore below warning > dpdk/x86_64-native-linuxapp-gcc-default/build/lib/librte_eal/linuxapp/kni/igb_main.c:2476:30: > error: '%d' directive output may be truncated writing between 1 and 5 bytes > into a region of size between 0 and 11 [-Werror=format-truncation=] > > Signed-off-by: Nirmoy Das > --- I haven't check the code but is this a bogus warning or a real one? If it's bogus then could you explain why in the commit message so we do not bring it back in the future? If it's a real problem, then perhaps worth fixing it instead of masking it? -- markos SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
Re: [dpdk-dev] [PATCH] mk: disable new gcc truncation flag
On 06/02/2017 07:38 PM, Markos Chandras wrote: > On 06/02/2017 05:31 PM, Nirmoy Das wrote: >> disable truncation check to ignore below warning >> dpdk/x86_64-native-linuxapp-gcc-default/build/lib/librte_eal/linuxapp/kni/igb_main.c:2476:30: >> error: '%d' directive output may be truncated writing between 1 and 5 bytes >> into a region of size between 0 and 11 [-Werror=format-truncation=] >> >> Signed-off-by: Nirmoy Das >> --- > > I haven't check the code but is this a bogus warning or a real one? If > it's bogus then could you explain why in the commit message so we do not > bring it back in the future? If it's a real problem, then perhaps worth > fixing it instead of masking it? > Actually this should have already been fixed in the series posted in http://dpdk.org/ml/archives/dev/2017-May/065261.html -- markos SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
Re: [dpdk-dev] [PATCH] mk: disable new gcc truncation flag
On 06/13/2017 12:18 PM, Nirmoy Das wrote: > > > On 06/12/2017 04:35 PM, Markos Chandras wrote: >> On 06/02/2017 07:38 PM, Markos Chandras wrote: >>> On 06/02/2017 05:31 PM, Nirmoy Das wrote: >>>> disable truncation check to ignore below warning >>>> dpdk/x86_64-native-linuxapp-gcc-default/build/lib/librte_eal/linuxapp/kni/igb_main.c:2476:30: >>>> error: '%d' directive output may be truncated writing between 1 and 5 >>>> bytes into a region of size between 0 and 11 [-Werror=format-truncation=] >>>> >>>> Signed-off-by: Nirmoy Das >>>> --- >>> I haven't check the code but is this a bogus warning or a real one? If >>> it's bogus then could you explain why in the commit message so we do not >>> bring it back in the future? If it's a real problem, then perhaps worth >>> fixing it instead of masking it? >>> >> Actually this should have already been fixed in the series posted in >> http://dpdk.org/ml/archives/dev/2017-May/065261.html > I see the issue in master with CONFIG_RTE_KNI_KMOD_ETHTOOL=y > Yeah I think you are right. This doesn't seem to have been fixed yet. In the end, I think your patch is good so: Reviewed-by: Markos Chandras -- markos SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
Re: [dpdk-dev] [PATCH] mk: disable new gcc truncation flag
On 06/13/2017 04:45 PM, Ferruh Yigit wrote:
> On 6/13/2017 10:18 AM, Nirmoy Das wrote:
>>
>>
>> On 06/12/2017 04:35 PM, Markos Chandras wrote:
>>> On 06/02/2017 07:38 PM, Markos Chandras wrote:
>>>> On 06/02/2017 05:31 PM, Nirmoy Das wrote:
>>>>> disable truncation check to ignore below warning
>>>>> dpdk/x86_64-native-linuxapp-gcc-default/build/lib/librte_eal/linuxapp/kni/igb_main.c:2476:30:
>>>>> error: '%d' directive output may be truncated writing between 1 and 5
>>>>> bytes into a region of size between 0 and 11 [-Werror=format-truncation=]
>>>>>
>>>>> Signed-off-by: Nirmoy Das
>>>>> ---
>>>> I haven't check the code but is this a bogus warning or a real one? If
>>>> it's bogus then could you explain why in the commit message so we do not
>>>> bring it back in the future? If it's a real problem, then perhaps worth
>>>> fixing it instead of masking it?
>>>>
>>> Actually this should have already been fixed in the series posted in
>>> http://dpdk.org/ml/archives/dev/2017-May/065261.html
>> I see the issue in master with CONFIG_RTE_KNI_KMOD_ETHTOOL=y
>
> I confirm the build error, and patch fixes it.
>
> Although that piece of code most probably will not be used at all, and
> previous solution was to disable warnings, since this warning is only
> single place in KNI code, it is easy to fix and I am for fixing it [1],
> what do you think?
>
>
> diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb.h
> b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb.h
> index d077b49e9..8667f29ca 100644
> --- a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb.h
> +++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb.h
> @@ -607,7 +607,7 @@ struct igb_adapter {
> int int_mode;
> u32 rss_queues;
> u32 vmdq_pools;
> - char fw_version[32];
> + char fw_version[43];
> u32 wvbr;
> struct igb_mac_addr *mac_table;
> #ifdef CONFIG_IGB_VMDQ_NETDEV
>
Looks reasonable to me
--
markos
SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
[dpdk-dev] [PATCH] e1000/base: Add missing braces to the 'if' statements
Add the missing braces to the 'if' statements to fix the misleading
identation. This also fixes the following build errors when building
with gcc >= 6:
drivers/net/e1000/base/e1000_phy.c:4156:2:
error: this 'if' clause does not guard... [-Werror=misleading-indentation]
if (locked)
^~
drivers/net/e1000/base/e1000_phy.c:4158:3:
note: ...this statement, but the latter is misleadingly indented as if it is
guarded by the 'if'
if (!ready)
^~
drivers/net/e1000/base/e1000_phy.c: In function 'e1000_write_phy_reg_mphy':
drivers/net/e1000/base/e1000_phy.c:4221:2:
error: this 'if' clause does not guard... [-Werror=misleading-indentation]
if (locked)
^~
drivers/net/e1000/base/e1000_phy.c:4223:3:
note: ...this statement, but the latter is misleadingly indented as if it is
guarded by the 'if'
if (!ready)
^~
Signed-off-by: Markos Chandras
---
drivers/net/e1000/base/e1000_phy.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e1000/base/e1000_phy.c
b/drivers/net/e1000/base/e1000_phy.c
index d43b7ce..33f478b 100644
--- a/drivers/net/e1000/base/e1000_phy.c
+++ b/drivers/net/e1000/base/e1000_phy.c
@@ -4153,12 +4153,13 @@ s32 e1000_read_phy_reg_mphy(struct e1000_hw *hw, u32
address, u32 *data)
*data = E1000_READ_REG(hw, E1000_MPHY_DATA);
/* Disable access to mPHY if it was originally disabled */
- if (locked)
+ if (locked) {
ready = e1000_is_mphy_ready(hw);
if (!ready)
return -E1000_ERR_PHY;
E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL,
E1000_MPHY_DIS_ACCESS);
+ }
return E1000_SUCCESS;
}
@@ -4218,12 +4219,13 @@ s32 e1000_write_phy_reg_mphy(struct e1000_hw *hw, u32
address, u32 data,
E1000_WRITE_REG(hw, E1000_MPHY_DATA, data);
/* Disable access to mPHY if it was originally disabled */
- if (locked)
+ if (locked) {
ready = e1000_is_mphy_ready(hw);
if (!ready)
return -E1000_ERR_PHY;
E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL,
E1000_MPHY_DIS_ACCESS);
+ }
return E1000_SUCCESS;
}
--
2.8.4
[dpdk-dev] [PATCH] e1000/base: Add missing braces to the 'if' statements
Hi Anupam,
I have seen your commit, but my patch fixes a different file (although
the fix is similar).
Am I missing something?
On 2016-06-23 11:26, Anupam Kapoor wrote:
> hi markos,
>
> please see : cba50f6be0db9efdf694dcf4bce4a6945a275182, which should
> already
> fix this.
>
> --
> thanks
> anupam
>
>
> On Thu, Jun 23, 2016 at 2:55 PM, Markos Chandras
> wrote:
>
>> Add the missing braces to the 'if' statements to fix the misleading
>> identation. This also fixes the following build errors when building
>> with gcc >= 6:
>>
>> drivers/net/e1000/base/e1000_phy.c:4156:2:
>> error: this 'if' clause does not guard...
>> [-Werror=misleading-indentation]
>> if (locked)
>> ^~
>>
>> drivers/net/e1000/base/e1000_phy.c:4158:3:
>> note: ...this statement, but the latter is misleadingly indented as if
>> it
>> is guarded by the 'if'
>> if (!ready)
>> ^~
>>
>> drivers/net/e1000/base/e1000_phy.c: In function
>> 'e1000_write_phy_reg_mphy':
>> drivers/net/e1000/base/e1000_phy.c:4221:2:
>> error: this 'if' clause does not guard...
>> [-Werror=misleading-indentation]
>> if (locked)
>> ^~
>>
>> drivers/net/e1000/base/e1000_phy.c:4223:3:
>> note: ...this statement, but the latter is misleadingly indented as if
>> it
>> is guarded by the 'if'
>> if (!ready)
>> ^~
>>
>> Signed-off-by: Markos Chandras
>> ---
>> drivers/net/e1000/base/e1000_phy.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/e1000/base/e1000_phy.c
>> b/drivers/net/e1000/base/e1000_phy.c
>> index d43b7ce..33f478b 100644
>> --- a/drivers/net/e1000/base/e1000_phy.c
>> +++ b/drivers/net/e1000/base/e1000_phy.c
>> @@ -4153,12 +4153,13 @@ s32 e1000_read_phy_reg_mphy(struct e1000_hw
>> *hw,
>> u32 address, u32 *data)
>> *data = E1000_READ_REG(hw, E1000_MPHY_DATA);
>>
>> /* Disable access to mPHY if it was originally disabled */
>> - if (locked)
>> + if (locked) {
>> ready = e1000_is_mphy_ready(hw);
>> if (!ready)
>> return -E1000_ERR_PHY;
>> E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL,
>> E1000_MPHY_DIS_ACCESS);
>> + }
>>
>> return E1000_SUCCESS;
>> }
>> @@ -4218,12 +4219,13 @@ s32 e1000_write_phy_reg_mphy(struct e1000_hw
>> *hw,
>> u32 address, u32 data,
>> E1000_WRITE_REG(hw, E1000_MPHY_DATA, data);
>>
>> /* Disable access to mPHY if it was originally disabled */
>> - if (locked)
>> + if (locked) {
>> ready = e1000_is_mphy_ready(hw);
>> if (!ready)
>> return -E1000_ERR_PHY;
>> E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL,
>> E1000_MPHY_DIS_ACCESS);
>> + }
>>
>> return E1000_SUCCESS;
>> }
>> --
>> 2.8.4
>>
>>
--
SUSE LINUX GmbH | GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg) Maxfeldstr. 5, D-90409, N?rnberg
[dpdk-dev] [PATCH] e1000/base: Add missing braces to the 'if' statements
Hi Bruce, On 06/27/2016 03:39 PM, Bruce Richardson wrote: > On Thu, Jun 23, 2016 at 10:25:52AM +0100, Markos Chandras wrote: >> Add the missing braces to the 'if' statements to fix the misleading >> identation. This also fixes the following build errors when building >> with gcc >= 6: >> >> drivers/net/e1000/base/e1000_phy.c:4156:2: >> error: this 'if' clause does not guard... [-Werror=misleading-indentation] >> if (locked) >> ^~ >> >> drivers/net/e1000/base/e1000_phy.c:4158:3: >> note: ...this statement, but the latter is misleadingly indented as if it is >> guarded by the 'if' >> if (!ready) >> ^~ >> >> drivers/net/e1000/base/e1000_phy.c: In function 'e1000_write_phy_reg_mphy': >> drivers/net/e1000/base/e1000_phy.c:4221:2: >> error: this 'if' clause does not guard... [-Werror=misleading-indentation] >> if (locked) >> ^~ >> >> drivers/net/e1000/base/e1000_phy.c:4223:3: >> note: ...this statement, but the latter is misleadingly indented as if it is >> guarded by the 'if' >> if (!ready) >> ^~ >> >> Signed-off-by: Markos Chandras >> --- > > Any particular compiler flags needed to reproduce this issue? Compiling with > gcc6.1 I don't see any errors reported. > > /Bruce > I only have the log from the 2.2.0 + gcc-6 build so here is the line gcc -Wp,-MD,./.e1000_phy.o.d.tmp -m64 -pthread -fPIC -march=core2 -DRTE_MACHINE_CPUFLAG_SSE -DRTE_MACHINE_CPUFLAG_SSE2 -DRTE_MACHINE_CPUFLAG_SSE3 -DRTE_MACHINE_CPUFLAG_SSSE3 -DRTE_COMPILE_TIME_CPUFLAGS =RTE_CPUFLAG_SSE,RTE_CPUFLAG_SSE2,RTE_CPUFLAG_SSE3,RTE_CPUFLAG_SSSE3 -I/home/abuild/rpmbuild/BUILD/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include -include /home/abuild/rpmbuild/BUILD/dpdk-2.2.0/x86_64-native-linuxapp-gcc/include/rte_config.h -O3 -W -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wold-style-definition -Wpointer-arith -Wcast-align -Wnested-externs -Wcast-qual -Wformat-nonli teral -Wformat-security -Wundef -Wwrite-strings -Wno-uninitialized -Wno-unused-parameter -Wno-unused-variable -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funw ind-tables -fasynchronous-unwind-tables -g -Wformat -fPIC -Wno-error=array-bounds -o e1000_phy.o -c /home/abuild/rpmbuild/BUILD/dpdk-2.2.0/drivers/net/e1000/base/e1000_phy.c But next time I will make sure I will add the command line that causes the problem in the comment section of the patch as well. -- markos SUSE LINUX GmbH | GF: Felix Imend?rffer, Jane Smithard, Graham Norton HRB 21284 (AG N?rnberg) Maxfeldstr. 5, D-90409, N?rnberg
[dpdk-dev] [PATCH] mk: toolchain: gcc: query the compiler macros to obtain the gcc version
This is similar to what's being used in the Linux kernel. Querying the GCC macros directly gives more accurate results compared to -dumpversion which could vary across distributions. Signed-off-by: Markos Chandras --- In openSUSE Tumbleweed (and in any other SUSE distribution which uses (or will use) gcc >= 5), gcc -dumpversion returns '5'. This is on purpose as discussed in https://bugzilla.opensuse.org/show_bug.cgi?id=941428 As a result of which, the gcc-4.x comparison (40 against 5) does not work leading to tons of warnings and failures during build. This patch aims to change the way the gcc version is obtained by using the gcc macros directly. --- mk/toolchain/gcc/rte.toolchain-compat.mk | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/mk/toolchain/gcc/rte.toolchain-compat.mk b/mk/toolchain/gcc/rte.toolchain-compat.mk index e144216..6eed20c 100644 --- a/mk/toolchain/gcc/rte.toolchain-compat.mk +++ b/mk/toolchain/gcc/rte.toolchain-compat.mk @@ -38,7 +38,9 @@ #find out GCC version -GCC_VERSION = $(subst .,,$(shell $(CC) -dumpversion | cut -f1-2 -d.)) +GCC_MAJOR = $(shell echo __GNUC__ | $(CC) -E -x c - | tail -n 1) +GCC_MINOR = $(shell echo __GNUC_MINOR__ | $(CC) -E -x c - | tail -n 1) +GCC_VERSION = $(GCC_MAJOR)$(GCC_MINOR) # if GCC is older than 4.x ifeq ($(shell test $(GCC_VERSION) -lt 40 && echo 1), 1) -- 2.7.3
[dpdk-dev] [PATCH] mk: toolchain: gcc: query the compiler macros to obtain the gcc version
Hi, On 22/03/16 22:34, Thomas Monjalon wrote: > 2016-03-22 17:13, Markos Chandras: >> This is similar to what's being used in the Linux kernel. Querying the >> GCC macros directly gives more accurate results compared to -dumpversion >> which could vary across distributions. >> >> Signed-off-by: Markos Chandras >> --- >> In openSUSE Tumbleweed (and in any other SUSE distribution which >> uses (or will use) gcc >= 5), gcc -dumpversion returns '5'. This is on >> purpose as discussed in https://bugzilla.opensuse.org/show_bug.cgi?id=941428 > > Good to know. It could be in the commit log. I can add this information to the commit message and send a v2 if needed. > >> -GCC_VERSION = $(subst .,,$(shell $(CC) -dumpversion | cut -f1-2 -d.)) >> +GCC_MAJOR = $(shell echo __GNUC__ | $(CC) -E -x c - | tail -n 1) >> +GCC_MINOR = $(shell echo __GNUC_MINOR__ | $(CC) -E -x c - | tail -n 1) >> +GCC_VERSION = $(GCC_MAJOR)$(GCC_MINOR) > > Are we sure the minor will always be only one digit? > Well, I can't be sure but minor has always been a single digit since gcc >= 3 if I am not mistaken. But does it matter? What if it is two or more digits? The previous code did something similar so if you had gcc 5.12.34 installed (and lets assume this is what is being returned by -dumpversion), it would have returned 512. The comparison would still work as it is at the moment no? -- markos
[dpdk-dev] [PATCH] mk: toolchain: gcc: query the compiler macros to obtain the gcc version
On 03/23/2016 09:49 AM, Thomas Monjalon wrote: > 2016-03-22 22:50, Markos Chandras: >> On 22/03/16 22:34, Thomas Monjalon wrote: >>> 2016-03-22 17:13, Markos Chandras: >>>> This is similar to what's being used in the Linux kernel. Querying the >>>> GCC macros directly gives more accurate results compared to -dumpversion >>>> which could vary across distributions. >>>> >>>> Signed-off-by: Markos Chandras >>>> --- >>>> In openSUSE Tumbleweed (and in any other SUSE distribution which >>>> uses (or will use) gcc >= 5), gcc -dumpversion returns '5'. This is on >>>> purpose as discussed in >>>> https://bugzilla.opensuse.org/show_bug.cgi?id=941428 >>> >>> Good to know. It could be in the commit log. >> >> I can add this information to the commit message and send a v2 if needed. > > I will apply with this info. Thank you Thomas. -- markos
[dpdk-dev] Suggestions for the dpdk stable tree
Hi, On 05/20/2016 04:54 PM, Christian Ehrhardt wrote: > Hi, > it would be great to have an actively maintained LTS release. > > Clearly all us "Distribution People" like Panu, Me and a few others should > - whenever bugs are identified as potential backports - start the > discussion. > And having an stable-maintainer on the other end sounds great. > > The active maintainer you provide would do the usual auto-backport of fixes > once they come up upstream. > While us others would provide input from real exposure to users that flows > in via bug tracking tools. > > Looking forward for you coming back to the list once you have found one. Yes that sounds like a very good idea indeed! -- markos SUSE LINUX GmbH | GF: Felix Imend?rffer, Jane Smithard, Graham Norton HRB 21284 (AG N?rnberg) Maxfeldstr. 5, D-90409, N?rnberg
